From speermint-bounces@ietf.org Sat Apr 01 14:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPlyw-0003IS-QQ; Sat, 01 Apr 2006 14:41:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPlyv-0003IM-F1 for speermint@ietf.org; Sat, 01 Apr 2006 14:41:57 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPlyt-0005lZ-VY for speermint@ietf.org; Sat, 01 Apr 2006 14:41:57 -0500 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 Date: Sat, 1 Apr 2006 21:45:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C495C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIA== From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Speermint] Reachability 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 Folks, =20 after reading the document from Scott Markus on NGN Interconnect=20 I referenced for weekend reading in my last posting http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.pd= f =20 IMHO we started the discussion from the wrong end. =20 First we talked primarily about peering, which is according to the FCC definition always bilateral and not about interconnect and transit =20 and second we always started naturally at provider A in direction of call set-up and not at provider B =20 Provider B is giving out a Public User Identity=20 (an AoR (SIP URI), an E.164 number or both) to a user. =20 This Public User Identity can now be reached ONLY via this provider, so he has a monopoly, or in EU terms, he automatically has significant market power. Provider B has now (currently only for Public User Identities in the form of E.164 numbers) the OBLIGATION=20 making this PUI reachable for the public by interconnecting=20 with the public network (in this case at least via the PSTN) =20 Scott Marcus is indicating that this may be extended to IP-based networks (and eventually also to SIP URIs) very soon if the regulators get their act together and if IP based interconnect is introduced in some countries (e.g in UK) =20 In some countries also the obligation for provider A may exist to=20 make the PUI in question reachable (in some not, because it is not a monopoly, a customer has the choice to select another=20 provider, in this case the obligation is only to providers with SMP), but provider A can only do so AFTER provider B is reachable at all. =20 So IMHO we can assume that provider B hosting a Public User Identity (a SIP URI) MUST make this PUI reachable in principle. =20 Question: Is provider B able to define conditions to be meet and what are they?=20 =20 In the PSTN interconnect he must make an interconnection offer public and if somebody is fulfilling the requirements stated in the = offer,=20 Provider B must accept interconnection non-discriminatory. The NRA normally sets the limits to such an offer. These offers contain normally technical and commercial issues e.g protocols to be used and acccounting requirements, etc speermint should not deal with commercial agreements, but it could povide guidelines for the technical part, e.g. be setting minimum requirements for signaling protocols, security, = identifcation of provider A and his users, etc.in other words a set of BCPs. I said speermint should not be involved to much in commercial = agreements, but it may also provide some tools to make these workable and scaleable. Bi-lateral agreements do not scale on a global level, so we may assume = that the agreements come in groups i.e. federations or whatever we may call = it So it may be useful to provide means for a provider B to annouce what = kind of agreements he is requesting to accept incoming calls. I do not think that speermint should go into issues like how to exchange accounting data (for this there exists protocoals such as OSP which may be used) To summarize: Provider B may have an obligation to make his customers reachable, provided some technical and commercial conditions are met by provider A speermint should work what these conditions could be, what is required protocol-wise to meet the technical conditions and how these conditions (technical and commercial) could be annonced from provider B to provider A, taking into account that bi-laterel agreements do not scale cheers Richard =20 =20 =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Apr 01 16:23:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPnYt-0004vC-4v; Sat, 01 Apr 2006 16:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPnYr-0004v7-7K for speermint@ietf.org; Sat, 01 Apr 2006 16:23:09 -0500 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPnYo-0001gU-0L for speermint@ietf.org; Sat, 01 Apr 2006 16:23:09 -0500 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Sat, 1 Apr 2006 16:22:51 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040116225105453 ; Sat, 01 Apr 2006 16:22:51 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Sat, 1 Apr 2006 16:22:50 -0500 Message-Id: <62D92A9A02BCC845B202323D49A48426209C0B@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Stastny Richard , speermint@ietf.org Subject: RE: [Speermint] Reachability Date: Sat, 1 Apr 2006 16:22:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Richard and all: OSP is one of the peering models that we need to keep in our mind as we know that the bidirectional peering scheme is NOT scalable. Moreover, there is a little need for standardization of the bidirectional peering. Whatever we come up for peering in Speemint WG, we have to compare its pros and cons wrt OSP without reinventing all the things from the scratch. Best regards, Radhika _____ From: speermint-bounces@ietf.org on behalf of Stastny Richard Sent: Sat 4/1/2006 2:45 PM To: speermint@ietf.org Subject: [Speermint] Reachability I do not think that speermint should go into issues like how to exchange accounting data (for this there exists protocoals such as OSP which may be used) cheers Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZg-0005Sv-3A; Sun, 02 Apr 2006 21:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZe-0005QW-K7 for speermint@ietf.org; Sun, 02 Apr 2006 21:09:42 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZb-00041e-Bg for speermint@ietf.org; Sun, 02 Apr 2006 21:09:42 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Definition of "Peering" Date: Sun, 2 Apr 2006 21:09:13 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D1E@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAbwYCAADH+b8AAKNt7QAAxmW5AAc4uq0A== From: "Livingood, Jason" To: "Hadriel Kaplan" , "Stastny Richard" , X-OriginalArrivalTime: 03 Apr 2006 01:09:13.0998 (UTC) FILETIME=[38E40AE0:01C656BB] 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 We needn't endlessly debate whether or not speermint should accomodate peering over only "IP networks" or only the "Public Internet" (and, in turn, each of these terms is perhaps endlessly debatable). It is clear from list and f2f discussion that both are needed. Which one is used, and when, could depend upon a great number of factors. We should not exclude anything so early in the WG, IMHO. Jason > For example, one of the arguments I heard people raised at=20 > IETF 65 was "what about this is the Internet? The I in IETF=20 > is for Internet, so this group is out of scope." First, it=20 > is obviously untrue that the IETF only concerns itself with=20 > the ip network transport layer, nor of routing protocols to=20 > create an Internet. One need only look at the areas and=20 > working groups to see that. It's not only layer 3 protocols=20 > being defined. Second, there is one area actually titled=20 > "Internet Area", yet even within that area are groups who's=20 > entire existence in life is to define VPNs, at layers 2 and 3. >=20 >=20 > How are VPNs the Internet? Extending that idea, there are=20 > IETF groups who are (or were last time I was at the IETF)=20 > working to define how such VPNs can work between providers,=20 > and bridge the VPNs together. For me, if that is acceptable=20 > work for the IETF, then there should also be a case for=20 > allowing layer-5 VPNs to be bridged together. And that's=20 > only if you look at it one way (as L5 VPNs). There are other=20 > ways to look at it that I think make it acceptable as well. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZc-0005QI-UE; Sun, 02 Apr 2006 21:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZb-0005Q1-7M for speermint@ietf.org; Sun, 02 Apr 2006 21:09:39 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZa-00041b-0e for speermint@ietf.org; Sun, 02 Apr 2006 21:09:39 -0400 Received: from ([10.52.116.10]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18165181; Sun, 02 Apr 2006 21:09:16 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 21:09:15 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Definition of "Peering" Date: Sun, 2 Apr 2006 21:09:15 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D20@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAcqVgMAlp8IIA== From: "Livingood, Jason" To: "Stastny Richard" , "Patrick Melampy" , "Otmar Lendl" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 03 Apr 2006 01:09:15.0778 (UTC) FILETIME=[39F3A620:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 we should work on improving the charter and the=20 > requirements i.e. stick to ou knitting - this is only a=20 > little IETF WG ;-) It would be a shame to have to go back to the charter so soon. I am not so sure I see a clear reason for doing so, as of yet. But your point of focusing on requirements and focusing in general is an excellent one! With respect to the current discussion of the definition of Peering, may I refer everyone to the most recent draft the the Terminology document (excerpted below). We hope to close that out by July of this year. So may I humbly suggest that if folks have suggested changes to this, that they get comments to Dave as soon as possible. Thanks Jason 3.7. Peering While the precise definition of the term "peering" is the subject of some debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers. This document distinguishes two types of peering, Layer 3 Peering and Layer 5 peering, which are described below. 3.7.1. Layer 3 Peering Layer 3 peering refers to interconnection of two service providers for the purposes of exchanging IP packets. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as BGP [RFC1771] to exchange the required routing information. 3.7.2. Layer 5 Peering Layer 5 peering refers to interconnection of two service providers for the purposes of SIP signaling. Note that in the layer 5 peering case, there is no intervening network. That is, for purposes of this discussion, there is no such thing as a "Layer 5 Transit Network". 3.8. VoIP Peering VoIP peering is defined to be a layer 5 peering between two VoIP providers for purposes of routing real-time (or quasi-real time) call signaling between their respective customers. Media streams associated with this signaling (if any) are not constrained to follow the same set of paths. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZh-0005WD-AP; Sun, 02 Apr 2006 21:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZg-0005Sx-2z for speermint@ietf.org; Sun, 02 Apr 2006 21:09:44 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZc-00041j-Rv for speermint@ietf.org; Sun, 02 Apr 2006 21:09:44 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Definition of "Peering" Date: Sun, 2 Apr 2006 21:09:12 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D1D@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Definition of "Peering" Thread-Index: AcZUBqO5ZI1IWw0ZQL+j/PzYaZIi3QAHTtuQAAcqVgMAllaqEA== From: "Livingood, Jason" To: "Stastny Richard" , "Patrick Melampy" , "Otmar Lendl" , "Michael Hammer \(mhammer\)" X-OriginalArrivalTime: 03 Apr 2006 01:09:13.0764 (UTC) FILETIME=[38C05640:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > >Balkanized? Walled gardens? Net-Neutrality?=20 > =20 > and political >=20 > I think we should work on improving the charter and the=20 > requirements i.e. stick to ou knitting - this is only a=20 > little IETF WG ;-) Yes, I think the Political Layer is Layer 8 or 9 or something like that. ;-) =20 Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZm-0005gg-M3; Sun, 02 Apr 2006 21:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZl-0005d9-NC for speermint@ietf.org; Sun, 02 Apr 2006 21:09:49 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZj-000420-VZ for speermint@ietf.org; Sun, 02 Apr 2006 21:09:49 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18165184; Sun, 02 Apr 2006 21:09:22 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 21:09:21 -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="Windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Sun, 2 Apr 2006 21:09:20 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D26@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZTOSVrh3wcnDMuRQ2wxSPTIqNljQAAPi5gANj+U/A= From: "Livingood, Jason" To: "Bob Natale" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Apr 2006 01:09:21.0360 (UTC) FILETIME=[3D476500:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5aabda64dfed42b05d59af317aa9763c 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 my opinion, it is not up to the WG to define economic models or fee = structures in any way. But many people have noted that they'd like an = Accounting capability of some sort, and therefore, this is a requirement = (we can debate later whether it is a MUST, SHOULD, MAY, etc.). How = domains choose to use this info (like the data a web server might log = for HTTP access) is up to that domain. It may be useful for = troubleshooting, capacity planning, or perhaps even billing in the same = way that any other logging / accounting information may be used in such = ways. Regards Jason=20 > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com]=20 > Sent: Wednesday, March 29, 2006 9:19 AM > To: Paul Kyzivat > Cc: speermint@ietf.org > Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging >=20 > Hi Paul, >=20 > I'm not interested in charging (in the billing sense) wrt=20 > SPEERMINT, and I don't presume to prejudge what SPs will=20 > attempt to charge (bill) for in the future. (I expect to be=20 > negatively surprised. :) >=20 > However, my point was that: > - Pure signaling apps are likely to become more prevalent and=20 > more valuable; Therefore, > - SPEERMINT may need to cover the *accounting* requirements=20 > for such traffic at all relevant points in the SPEERMINT=20 > peering architecture (which is yet to be defined by this WG). >=20 > Cheers, > BobN > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 29, 2006 8:58 AM > To: Bob Natale > Cc: Stastny Richard; speermint@ietf.org > Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging >=20 > Bob Natale wrote: > > =20 > > Hi Richard, > >=20 > > 1. Your point about the possible relevance for SPEERMINT's=20 > scope of accounting requirements, and not billing=20 > requirements, is well-taken and will be reflected clearly in=20 > the next rev of the Requirements BCP draft. > >=20 > > 2. Wrt your comment: "3. So why is it necessary to charge=20 > termination fees to the O-user at all for SIGNALLING?": > > Might it not be true that some applications of value to the=20 > user might=20 > > involve signaling only, and not media per se? (I am thinking of=20 > > certain presence and notification apps...?) >=20 > What does that change? >=20 > IMO it makes sense to charge for services actually rendered,=20 > and not for services the SP isn't involved in but wishes they=20 > could get some revenue from. >=20 > The terminating proxy does render some identifiable services=20 > that could potentially be charged for: > - supplying the AOR > - processing (routing) requests to the AOR >=20 > These are of value precisely because they eliminate the need=20 > for the end user to keep a UA online at all times, and=20 > because it permits the end user to dynamically associate UAs=20 > with the AOR, by providing a potentially recognized and=20 > trusted domain. >=20 > This doesn't seem like stuff that justifies per-use charging,=20 > and the amount of charging that can be extracted for these=20 > basic services is probably limited, but its something. >=20 > If an SP wants to charge more, then they will have to provide=20 > more services - ones that users are interested in paying for. >=20 > Paul >=20 > > Cheers, > > BobN > >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, March 29, 2006 6:08 AM > > To: Medhavi Bhatia; Reinaldo Penno; David Schwartz;=20 > speermint@ietf.org > > Subject: [Speermint] Billing, Accounting, Tariffing and Charging > >=20 > >=20 > >>>These are not rhetoric questions; I really do not know the answer. > >=20 > >=20 > > Welcome to the club, you are not alone ;-) > >=20 > >=20 > >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay > >> > >>sensitive, need > >> > >>>prioritization and will be billed. > >>> > >> > >>Good point. What we need is to separate the problem of=20 > peering into at=20 > >>least two parts: terminating the call and the traffic=20 > itself (data part). > >>The email model applies only to the termination part. > >=20 > >=20 > > Hmmm, I think it is even more complicated. > >=20 > > Terminology: > >=20 > > Billing is between end-users and a SP (out of scope in=20 > spearmint) Accounting is between SP (in scope of spearmint?)=20 > Tariffing is the calculation of a charge for using a certain=20 > resource for a certain amount of time. > >=20 > > I consider it also paradox that we are discussing accounting and=20 > > charging, particularly termination charges (fees) 1. in a=20 > time even in=20 > > the PSTN issues are moving to bill-and-keep 2. on an inappropriate=20 > > layer (L5) > >=20 > > A substantial part of the problems with VoIP peering=20 > derives not from trust, QoS, SPIT, etc. problems, but simply=20 > how to keep up the existing regime of termination fees. > >=20 > > Especially mobile operators make a living on this. > >=20 > > Where is this problem coming from on the PSTN? > > (Lets for a moment forget problems caused by reverse > > charging) > >=20 > > In the PSTN there was originally an accounting regime based=20 > on cascading. The O-SP bills the O-user for the call (based=20 > on distance), and keeping part of it and paying out part to=20 > the next (transit) SP.=20 > > This goes on until the destination > > (T-SP) is reached, which also gets a share. > >=20 > > The implicit assumptions here are: the originator has the=20 > benefit of the call and also call set-up is in one direction=20 > and call signalling and the mediastream is traversing all=20 > networks in question. > >=20 > > This principle is only broken with call forwarding and also with=20 > > mobile roaming. In the US also the mobile T-user pays=20 > air-time, not so=20 > > in Europe, hence the problems with mobile NP > >=20 > > Note: in my remark to my previous post on terminating=20 > network monopoly (SMP), one may consider the termination fee=20 > also as a compensation for the remedy that a terminating=20 > network MUST accept any call. > >=20 > > This regime was quite simple, but was more and more=20 > complicated over time by burdening it with additional issues=20 > such as subsidies, etc. as it is currently in the US. > >=20 > >=20 > > What does this imply now for VoIP peering or interconnect > >=20 > > VoIP; RTC and IP separate signalling (L5) from transport=20 > (L3) It also separates the SP from the access Now taking into=20 > account some facts: > >=20 > > 1. Although SIP signalling (call set-up) is directed from O=20 > to T, the=20 > > mediastream is both ways and symmetric (so much for=20 > Whitacre, he may=20 > > eventually blame Google Video, but not VoIP providers) > >=20 > > 2. The cost for the mediastream is moving more and more to=20 > the ends (access), even in the PSTN (see the latest OFCOM=20 > report on distance gradients), and the access is already paid=20 > in some way or the other by the end-users. > >=20 > > 3. So why is it necessary to charge termination fees to the=20 > O-user at all for SIGNALLING? > >=20 > > There is one issue where termination fees may apply=20 > (although this is going away also - e.g. > > Voipbuster): if you connect to the PSTN. > >=20 > > But this is out of scope in Speermint and in addition=20 > solutions exist here since years. > >=20 > > My recommendation is that as long as speermint is dealing=20 > with L5 peering only, accounting i.e. termination fees should=20 > not be dealt with. > >=20 > > Cheers > >=20 > > Richard > >=20 > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > >>Sent: Wednesday, March 29, 2006 4:28 AM > >>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > >>Subject: RE: [Speermint] Comments on > >>reqs-and-terminology-01andpolicy-dds- > >>00(Peerign concepts and others..) > >> > >>Hi Reinaldo, > >> > >> > >>>-----Original Message----- > >>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>Sent: Tuesday, March 28, 2006 8:31 PM > >>>To: Medhavi Bhatia; David Schwartz; speermint@ietf.org > >>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > >>>andpolicy- > >> > >>dds-00(Peerign > >> > >>>concepts and others..) > >>> > >>>Hello, > >>> > >>>I tend to agree that the email model sounds attractive except the=20 > >>>delay > >> > >>and business > >> > >>>requirements of email and VoIP are quire different. > >>> > >>>Email is not delay sensitive, does not require any type of > >> > >>prioritization and is not charged > >> > >>>(or at least it wasn't). > >>> > >>>VoIP is exactly the opposite. VoIP (signaling and media) are delay > >> > >>sensitive, need > >> > >>>prioritization and will be billed. > >>> > >> > >>Good point. What we need is to separate the problem of=20 > peering into at=20 > >>least two parts: terminating the call and the traffic=20 > itself (data part). > >>The email model applies only to the termination part. > >> > >> > >>>I believe a call to a public number is (or should) always=20 > going to be > >> > >>routable. I guess my > >> > >>>main question is: is the general belief that VoIP=20 > providers will just > >> > >>configure their proxy > >> > >>>servers to talk to each other in an email type model? No business > >> > >>agreements similar to > >> > >>>PSTN/Wireless, no charging, no extra billing for "roaming", etc? > >>> > >> > >>I agree those are issues. It would be good if we can work out=20 > >>something which is generic (compared to IMS/PSTN specific).=20 > Maybe they=20 > >>are out of scope since we are dealing with protocol and=20 > architecture=20 > >>issues in the WG. The only aspect billing and roaming=20 > affect is that=20 > >>if all technical requirements (e.g the ones this WG specifies) are=20 > >>satisfied, the peer could still reject traffic (w/o consulting the=20 > >>destination user, in Richard's terms) if the commercial=20 > relationship=20 > >>does not exist. I think this is what hampers connectivity=20 > today. All=20 > >>these commercial relationships exist because SPs want to be layer 5=20 > >>aware (they cannot seem to find a way to evolve their=20 > business models=20 > >>otherwise... :), where only the origination SP (Core-O) and Core-T=20 > >>need to have a commercial relationship. The roaming aspect=20 > again may=20 > >>be quite artificial and could be questionable going=20 > forward... Just my personal comments. > >> > >>-Medhavi. > >> > >> > >>>My reply to David's email was more to the idea that you=20 > can install a > >> > >>proxy server > >> > >>>somewhere, point the "MX" to the next upstream "proxy=20 > server" and be > >> > >>done with it? As > >> > >>>VoIP takes off wouldn't some basic regulatory issues, numbering=20 > >>>schemes > >> > >>and others > >> > >>>prevent such behavior? > >>> > >>>These are not rhetoric questions; I really do not know the answer. > >>> > >>>Regards, > >>> > >>>Reinaldo > >>> > >>> > >>>>-----Original Message----- > >>>>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > >>>>Sent: Tuesday, March 28, 2006 5:13 PM > >>>>To: Reinaldo Penno; David Schwartz; speermint@ietf.org > >>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 > >> > >>andpolicy- > >> > >>>>dds-00(Peerign concepts and others..) > >>>> > >>>> > >>>>>It begs the question why the two entities exchanging SIP=20 > signaling > >> > >>do > >> > >>>>not exchange policy > >>>> > >>>>>information themselves through some SIP extension/new=20 > >>>>>protocol/ >>>> > >>>>name> and the > >>>> > >>>>>role played by DNS. I'm not advocating this model but it seems a > >>>> > >>>>pertinent question. > >>>> > >>>>I think peering in L3 must be basic, given how=20 > fundamental L3 is to > >> > >>the > >> > >>>>internet. For SIP, TRIP provides functionality similar to=20 > BGP (only > >> > >>for > >> > >>>>phone numbers though, I think). > >>>> > >>>>In my opinion, SIP peering ought to follow the email model. Once > >> > >>location > >> > >>>>is done and basic requirements are satisfied at the SIP=20 > layer (like=20 > >>>>identity etc), the call should be routable. As Richard said in the > >> > >>earlier > >> > >>>>email, the destination SP may still reject or challenge=20 > the call if=20 > >>>>it lacks either the basic requirements we agree to in the=20 > WG or some > >> > >>extra > >> > >>>>requirements specific to the termination SP (Core-T in my=20 > ID). The=20 > >>>>challenge is that in some cases there are going to be IXPs > >> > >>(Interconnects) > >> > >>>>which sit in the middle due to commercial or regulatory reasons.=20 > >>>>The location of an IXP, the provisioning of this IXP and=20 > the Core-T=20 > >>>>SP are > >> > >>the > >> > >>>>architectural problems which this WG needs to solve as well. > >>>> > >>>>-Medhavi. > >>>> > >>>> > >>>>>Regards, > >>>>> > >>>>>Reinaldo > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: David Schwartz [mailto:David.Schwartz@Kayote.com] > >>>>>>Sent: Tuesday, March 28, 2006 3:18 PM > >>>>>>To: Reinaldo Penno; speermint@ietf.org > >>>>>>Subject: RE: [Speermint] Comments on reqs-and-terminology-01 and > >>>> > >>>>policy- > >>>> > >>>>>>dds-00(Peerign concepts and others..) > >>>>>> > >>>>>>Hi Reinaldo > >>>>>> > >>>>>>I am not sure the goal of SPEERMINT is to recreate L3 peering at > >> > >>L5. > >> > >>>>The > >>>> > >>>>>>problem being solved is different in that L3 peering is always > >> > >>with a > >> > >>>>>>fixed number of neighbors. These are stored as you mention in > >> > >>static > >> > >>>>>>routing tables at each node and do not change from call to call. > >> > >>In > >> > >>>>>>contrast, L5 peering is not necessarily static (unless you are > >> > >>talking > >> > >>>>>>about a federation model). The destination is chosen=20 > only when the > >>>> > >>>>call is > >>>> > >>>>>>made and may be to a peer that a given service provider/domain=20 > >>>>>>administrator/node has never spoken to before. > >>>>>> > >>>>>>Assuming DNS is used to find the peering node, the query is made > >> > >>on a > >> > >>>>call > >>>> > >>>>>>by call basis. Now clearly, this DNS info can be cached at the > >>>> > >>>>originating > >>>> > >>>>>>node but the cache still has a very different nature=20 > than that of > >> > >>an > >> > >>>>L3 > >>>> > >>>>>>routing table. > >>>>>> > >>>>>>Policy is an entirely different issue (as is the case in L3) and > >> > >>it is > >> > >>>>>>important to separate it out from the routing issue.=20 > The draft you > >>>> > >>>>mention > >>>> > >>>>>>about pushing policy via DNS is dealing with one out of many > >> > >>possible > >> > >>>>>>topologies - namely that of ad hoc federations. There was very > >> > >>little > >> > >>>>>>discussion about policy at IETF 65 as the foundations of L5 > >> > >>routing > >> > >>>>need > >>>> > >>>>>>to be cemented before the higher level policy issues can be > >> > >>addressed. > >> > >>>>>>Cheers, > >>>>>> > >>>>>>David > >>>>>> > >>>>>>-----Original Message----- > >>>>>>From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>>>>Sent: =E2 28 =EE=F8=F5 2006 23:34 > >>>>>>To: speermint@ietf.org > >>>>>>Subject: [Speermint] Comments on reqs-and-terminology-01 and > >> > >>policy- > >> > >>>>dds- > >>>> > >>>>>>00(Peerign concepts and others..) > >>>>>> > >>>>>>Hello, > >>>>>> > >>>>>>I've been reading "reqs and terminology" and I would=20 > like to step > >> > >>back > >> > >>>>>>and ask some questions about some of the definitions. > >>>>>> > >>>>>> > >>>>>>Peering: > >>>>>>=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>> > >>>>>>In layer 3 peering two routers exchange their routing tables, > >> > >>reach a > >> > >>>>>>steady state, and after that data packets can flow between the=20 > >>>>>>two domains. > >>>>>> > >>>>>>Layer 5 peering means, "interconnection of two service=20 > >>>>>>providers > >> > >>for > >> > >>>>the > >>>> > >>>>>>purposes of SIP signaling". > >>>>>> > >>>>>>Making the inevitable comparison with layer 3 peering, there=20 > >>>>>>are > >> > >>some > >> > >>>>>>fundamental differences that I'm trying to reconcile. > >>>>>> > >>>>>>1) In a traditional (a.k.a. layer 3) peering, both routers > >> > >>exchange > >> > >>>>all > >>>> > >>>>>>necessary routing information and enter a steady state. At=20 > >>>>>>this > >> > >>point, > >> > >>>>>>no other routes are exchanged and routers concentrate on > >> > >>forwarding > >> > >>>>>>packets. > >>>>>> > >>>>>>I know the WG is in the beginning, but it is not clear to me=20 > >>>>>>what > >>>> > >>>>pieces > >>>> > >>>>>>are needed for an equivalent functionality. For example: > >>>>>> > >>>>>>1) Are the entities exchanging SIP signaling for the purpose=20 > >>>>>>of > >>>> > >>>>peering > >>>> > >>>>>>doing so on a _per call_ basis? Is there going to be some > >> > >>mechanism > >> > >>>>to > >>>> > >>>>>>exchange such information in bulk such as in a routing protocol? > >> > >>Maybe > >> > >>>>>>based on domain names or something similar? > >>>>>> > >>>>>>2) The draft states that " A > >>>>>> domain's ingress point can be thought of as the location > >> > >>pointed to > >> > >>>>>> by the SRV record that resulted from the resolution of the=20 > >>>>>>CRD > >>>> > >>>>(i.e., > >>>> > >>>>>> a SIP URI)." > >>>>>> > >>>>>>So, it seems to me that although the "layer 5 peering" is > >> > >>happening > >> > >>>>>>between the two entities exchanging SIP signaling, the peering > >> > >>point > >> > >>>>>>discovery is a result of a SRV query. But the draft also=20 > >>>>>>states > >> > >>that " > >> > >>>>>>SPEERMINT Working Group is focused on the use of such CRD." > >>>>>> > >>>>>>Draft peering-policy states that " This documents proposes the=20 > >>>>>>use > >> > >>of > >> > >>>>>>DNS entries to publish a SIP proxy's policy for accepting=20 > >>>>>>incoming calls" proposes DNS as a way of exchange polices. > >>>>>> > >>>>>>This begs the question of what are the two "peering" entities > >> > >>really > >> > >>>>>>doing besides exchange traditional SIP signaling? It seems the > >> > >>real > >> > >>>>>>_information peering_ (for the lack of a better term) is=20 > >>>>>>happening between DNS servers. All important information=20 > >>>>>>related to > >> > >>"peering" is > >> > >>>>>>coming from a DNS server which might as well be on your own=20 > >>>>>>domain > >> > >>(if > >> > >>>>>>your exchange DNS information). > >>>>>> > >>>>>>In summary, it seems to me the whole architecture is quite a > >> > >>departure > >> > >>>>>>from layer 3 peering where the entities peering are the=20 > >>>>>>holders of > >> > >>the > >> > >>>>>>necessary information to allow data packets to flow. Here the > >> > >>entities > >> > >>>>>>peering publish their peering information to third party=20 > >>>>>>server > >> > >>which > >> > >>>>>>does the actual "peering" (exchange inter-domain information). > >>>>>> > >>>>>> > >>>>>>Anyway, the idea of the mail is to try to clarify things.=20 > >>>>>>There is > >>>> > >>>>much > >>>> > >>>>>>emphasis on SIP but it seems DNS plays a more central role. Or > >> > >>maybe > >> > >>>>>>some SIP extension will be made to exchange peering policies? > >>>>>> > >>>>>> > >>>>>>Policies and Independence of lower layers: > = >>>>>>=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 > >>>>>> > >>>>>>It seems sections 5.5 and 5.6 are _somewhat_ conflicting.=20 > >>>>>>Today > >> > >>BGP > >> > >>>>>>exchange QoS and VPN information, performs discovery, etc.=20 > >>>>>>This > >>>> > >>>>implies > >>>> > >>>>>>that BGP indirectly (or directly) knows the capabilities of=20 > >>>>>>the transport layer (thus the name capability negotiation). > >>>>>> > >>>>>>So, although the mechanism to exchange the actual policies=20 > >>>>>>needs > >> > >>to be > >> > >>>>>>independent of the lower layers, there needs to be a way to=20 > >>>>>>input > >>>> > >>>>lower > >>>> > >>>>>>layer information into the devices exchanging the policies.=20 > >>>>>>Just > >> > >>like > >> > >>>>>>BGP has filters and priorities based on a myriad of options.=20 > >>>>>>So, > >> > >>maybe > >> > >>>>>>the wording should change a little. > >>>>>> > >>>>>>As far as 5.6 goes, it seems to me the policies can be quite > >> > >>complex. > >> > >>>>>>The experience of BGP tells us that in the end policies can be > >> > >>huge. > >> > >>>>So, > >>>> > >>>>>>if policies are going to be huge, what draft dds-00 states as=20 > >>>>>>a possibility > >>>>>> > >>>>>>" If the simple boolean logic and the limited space in the DNS > >> > >>answers > >> > >>>>>> are insufficient for an application then a type of policy=20 > >>>>>>rule > >> > >>URIs > >> > >>>>>> can be defined which links to policy statements written in=20 > >>>>>>a > >> > >>fully > >> > >>>>>> featured policy description language like SAML [14] or=20 > >>>>>>XACML > >> > >>[15]." > >> > >>>>>>will actually going to be the rule. So, this begs the question=20 > >>>>>>of > >> > >>DNS > >> > >>>>is > >>>> > >>>>>>a good choice to publish peering policies. > >>>>>> > >>>>>>Thanks, > >>>>>> > >>>>>>Reinaldo > >>>>>> > >>>>>>_______________________________________________ > >>>>>>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 > >>>>> > >>>>>-- > >>>>>No virus found in this incoming message. > >>>>>Checked by AVG Free Edition. > >>>>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: > >> > >>3/24/2006 > >> > >>>-- > >>>No virus found in this incoming message. > >>>Checked by AVG Free Edition. > >>>Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date:=20 > >>>3/24/2006 > >>> > >> > >>_______________________________________________ > >>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 > >=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 Sun Apr 02 21:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZp-0005mm-Fs; Sun, 02 Apr 2006 21:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZn-0005iy-4Z for speermint@ietf.org; Sun, 02 Apr 2006 21:09:51 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZm-00042A-PW for speermint@ietf.org; Sun, 02 Apr 2006 21:09:51 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Speermint Charter Date: Sun, 2 Apr 2006 21:09:17 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D22@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwAJVH7tA= From: "Livingood, Jason" To: , "Stastny Richard" , "Reinaldo Penno" , "Malas, Daryl" , "Khan, Sohel Q [CTO]" X-OriginalArrivalTime: 03 Apr 2006 01:09:18.0086 (UTC) FILETIME=[3B53D260:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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-here, Brian! Excellent and well considered response. I recommend to everyone that is in the thread that you re-read the charter very carefully. It is intended to be as specific as possible, while not overly restrictive. Suggest we focus on finishing the Terminology Draft as soon as we can. So let's have it out on all of the terms there one more time. Any terms raised in Dallas that are not in the draft should be suggested by someone. Let's get every term in there and defined, as is reasonable and appropriate to our work. Regards Jason > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, March 30, 2006 5:39 PM > To: 'Stastny Richard'; 'Reinaldo Penno'; 'Malas, Daryl';=20 > 'Khan, Sohel Q [CTO]' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter >=20 > Wading in the middle: >=20 > Just for fun, I re-read our charter. I came away saying=20 > "that's pretty clear". I now turn to this discussion and say=20 > "please re-read the charter". >=20 > The charter is clear we are talking about all forms of real=20 > time communications. The charter doesn't explicitly rule out=20 > one way (streaming) but I think we can assume it. So, it's=20 > not just voice. >=20 > The charter is clear we are talking about SIP. We aren't=20 > talking about XMPP for example or H.323. The charter does=20 > not discuss p2p SIP. I believe that until there is a working=20 > group on p2p SIP, and until that group produces some=20 > interesting results, it's out of scope for us. We're dealing=20 > with proxy to proxy peering. >=20 > The charter is pretty clear that we are talking about BOTH=20 > inter-carrier as well as any inter-domain peering. I suppose=20 > it could be clearer about that point. I think=20 > inter-enterprise VoIP, to take an example, without benefit of=20 > a carrier, is probably in scope. We could, within the group,=20 > decide to treat carrier peering and other interdomain peering=20 > separately. It's not clear to me that we need to or should,=20 > at least at the moment. I don't think anyone can say "we are=20 > NOT working on inter-carrier peering". > Similarly, I don't believe we are limited to e.164 addresses.=20 > I think we include mapping of e.164s to SIP URIs within our=20 > documents as one of the things a proxy may do. I think we=20 > can also be somewhat cavalier with the differences between=20 > public ENUM, infrastructure/carrier ENUM and private ENUM. I=20 > don't think we even want to offer guidance on what to do when=20 > more than one is available other than observing that such a=20 > case will be common. >=20 > The charter is clear we are talking about BOTH the media and=20 > the signaling. > If you combine that with "inter-carrier vs inter-domain" then=20 > you have BOTH the case of a direct media connection as well=20 > as one that goes through > (horrors) SBCs, even when two UAs are in the same hotel. =20 > Most enterprises seem to like SBCs anyway. Unless someone=20 > gives me a really good explanation of why it actually matters=20 > if they do run through SBCs with respect to our work, I think=20 > we probably can ignore the difference. >=20 > Finally, in my checkered past, I have had many occasions to=20 > observe the difference between a pile of documents that=20 > purport to define interoperable implementations, and the=20 > reality of actually achieving it. While in general, in the=20 > IETF, "profiles" are not a nice word, Best Current Practices > are. Our charter is clear we are to develop BCPs. One of=20 > the biggest > values we can have on peering is to be VERY explicit about=20 > what the (SIP) signaling looks like across the peering=20 > points. Remember, the wonderful thing about standards is=20 > that there are so many to choose from. There is no better=20 > example of that than the area in which we find ourselves=20 > here, and we CAN do something about making choices. It's all=20 > well and good to say "dip ENUM if you have an e.164, use SRV=20 > to find the server for the domain of the URI, send an INVITE=20 > there", but, in the real world, it's MUCH more complicated=20 > then that, and our job is to describe all the dreck that you=20 > really have to do. >=20 > I think our problem is more to define what we do first then=20 > what we do. >=20 > Brian >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, March 30, 2006 5:07 PM > To: Reinaldo Penno; Malas, Daryl; Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: Re: [Speermint] Speermint Charter >=20 > Hi Reinaldo, > =20 > inline > =20 > >> > >> >I responded to soon before. You have a good point. So=20 > what you are=20 > >> >suggesting is peering can encompass multiple SIP based services=20 > >> >(P2P, ENUM, SIMPLE, etc.), and should not be limited to basic SIP > >telephony? > >> > > >> >Thanks... > >> > >> Thank you for bringing this up again and in focus > >> > >> The basic idea of SPEERMINT is to bring an SIP INVITE from=20 > Provider=20 > >> (or admin domain) A to B without immediately being rejected. > >[[Reinaldo]] > > > >Hello Richard, > > > >If all we need is what you said above, then what we need is already=20 > >defined in SIP/SIPPING, right? They already standardized=20 > procedures for=20 > >DNS lookup, etc, etc > > > >Let me rephrase the question by asking what is missing=20 > instead of what=20 > >is already defined. If we have two SIP domains, with the=20 > DNSs properly=20 > >SIPpenized, where the SIP border proxies are configured to=20 > talk to each=20 > >other, is there anything else needed besides what is in SIP/SIPPING? > > > >Is the policy piece the missing link? >=20 > I think so. And eventually a profile and minimum requirements=20 > for interconnect >=20 > >Sorry, I'm trying to peel another layer to look under=20 > "enabling to SIP=20 > >messages between the two domains", "Layer 5 peering" and other=20 > >expressions. > > > >I'm trying to understand what exactly is missing if all we=20 > want is to=20 > >enable Sip messages from domain A to reach B. Are today VoIP peering=20 > >points just exchange of media or there is signaling going on as well? >=20 > Either signaling only or also signaling+media (called SBC) > > > >I think we should rephrase the charter to be much, much more=20 > specific=20 > >on what our goals are, the drafts we need and milestones. >=20 > Yes, and I think this discussion helped very much to make this clear >=20 > >Thanks, >=20 > Thank you > Richard >=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 Sun Apr 02 21:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZm-0005gr-Sh; Sun, 02 Apr 2006 21:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDZl-0005f0-TI for speermint@ietf.org; Sun, 02 Apr 2006 21:09:49 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDZl-000420-Nh for speermint@ietf.org; Sun, 02 Apr 2006 21:09:49 -0400 Received: from ([10.20.9.174]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18165185; Sun, 02 Apr 2006 21:09:23 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 21:09:22 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging Date: Sun, 2 Apr 2006 21:09:21 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D27@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Billing, Accounting, Tariffing and Charging Thread-Index: AcZCvhdIwIgwYlXTQHKl1aPKIH64XgAFs9YAAtZkjaAA9ALNkAAqEeegAAUeiZAAAN0oIAADd+DgAAB009AAAcZysAAQUy8AAAnRr4AAA7MKowAB2MbwAAHB6bAAAr5KagDOGHAQ From: "Livingood, Jason" To: "Stastny Richard" , "Reinaldo Penno" , , "Medhavi Bhatia" , "David Schwartz" , X-OriginalArrivalTime: 03 Apr 2006 01:09:22.0748 (UTC) FILETIME=[3E1B2FC0:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 >Two options exist: > 1. cable operators and fixed operators create their own=20 > clubs, and agree to peer with GSMA via a super IPX >=20 > 2. All others are joining the GSMA club (GSMA is working on a=20 > proposal. >=20 > Minor problem: the others still do not even have a club to=20 > negotiate e.g. TISPAN (the fixed operators) has still no clue=20 > which way to go The cable operators are currently doing=20 > something in between using private peering fabrics e.g.=20 > Xconnect (e.g. in NL) >=20 > And VoIP providers on the Internet are left behind We ought not panic as of yet. ;-) And we ought not confuse steps different providers take with the destination many of them may be aiming for. In the end, I think standards and openness wins the day. But that is also all within reason (openness), as I don't think we want to bring the SPAM problem along and have your phone or softclient ringing every two minutes or two seconds with an automated offer for some or other kind of product you don't want. Also, FWIW, I'd encourage you to ask some of your contacts at these VoIP providers to join the WG list (several already have, but the more the merrier). Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:10:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDa4-0005xM-V2; Sun, 02 Apr 2006 21:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQDa4-0005x7-69 for speermint@ietf.org; Sun, 02 Apr 2006 21:10:08 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQDa4-000430-0F for speermint@ietf.org; Sun, 02 Apr 2006 21:10:08 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18165189; Sun, 02 Apr 2006 21:09:44 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 21:09:23 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Sun, 2 Apr 2006 21:09:22 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D28@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAA2xtRQ From: "Livingood, Jason" To: "Stastny Richard" , X-OriginalArrivalTime: 03 Apr 2006 01:09:23.0336 (UTC) FILETIME=[3E74E880:01C656BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > First we talked primarily about peering, which is according=20 > to the FCC definition always bilateral and not about=20 > interconnect and transit Luckily, we can make up our own definitions in the Terminology Draft. Last I checked, we were not bound by FCC definitions (and thankfully so, I hasten to add). ;-) > speermint should not deal with commercial agreements, but it=20 > could povide guidelines for the technical part, e.g. > be setting minimum requirements for signaling protocols,=20 > security, identifcation of provider A and his users, etc.in=20 > other words a set of BCPs. Sounds right. I think the charter's milestones prove that out to some extent. > I said speermint should not be involved to much in commercial=20 > agreements, but it may also provide some tools to make these=20 > workable and scaleable. Sounds right; we're not expecting to create a business here for the IETF. ;-) > Bi-lateral agreements do not scale on a global level, so we=20 > may assume that the agreements come in groups i.e.=20 > federations or whatever we may call it Sounds right on the part about bilateral agreements not scaling. Imagine trying to use bilateral agreements to make email work (shudder). =20 > So it may be useful to provide means for a provider B to=20 > annouce what kind of agreements he is requesting to accept=20 > incoming calls. This has come up a few times, including in Dallas. Sounds like this is the start of some more requirements for the Requirements Draft. :-) I can imagine some domains/providers will want some kind of a capability like this, while others may choose not to use it. But it sounds like such a policy / announcement method should be considered and discussed more fully. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Apr 02 21:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQEAY-0006Iq-Jz; Sun, 02 Apr 2006 21:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQEAX-0006Ik-BE for speermint@ietf.org; Sun, 02 Apr 2006 21:47:49 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQEAW-0005Rx-1g for speermint@ietf.org; Sun, 02 Apr 2006 21:47:49 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AEBE0348; Sun, 02 Apr 2006 21:47:42 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , Subject: RE: [Speermint] Reachability Date: Sun, 2 Apr 2006 21:47:47 -0400 Message-ID: <02b601c656c0$9c10bcd0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1w In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C495C@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Richard, comments inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, April 01, 2006 2:46 PM > To: speermint@ietf.org > Subject: [Speermint] Reachability > > after reading the document from Scott Markus on NGN Interconnect > I referenced for weekend reading in my last posting > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.pdf Indeed that was an interesting paper - thanks for the pointer! (not that I agree with everything in it) > and second we always started naturally at provider A in direction > of call set-up and not at provider B Personally, I think the bigger "problem" is the provider C, the one after B. :) C trying to be reachable by A through B. But that's out of scope I guess. It's too bad, because that's when BGP got interesting, for example. > Provider B has now (currently only for Public User > Identities in the form of E.164 numbers) the OBLIGATION > making this PUI reachable for the public by interconnecting > with the public network (in this case at least via the PSTN) > [snipped] > So IMHO we can assume that provider B hosting a Public User Identity > (a SIP URI) MUST make this PUI reachable in principle. I would think that would only be true if you define the AoR to be a public identity in the public domain, and such regulation was to be created for AoRs. E.164 numbers are by definition such numbers, I think. But if, for example, I build a private enterprise network - there's no way I'm obligated to do so just because I use the same SIP fields AoRs are used in. Having said that, I would think most providers _want_ to make them reachable, because that increases their value. But as the paper pointed out, peering is difficult to manage beyond a few hundred peers, nor do IP or PSTN providers peer with everyone directly to achieve universal reachability. That's why, for me, the more complex problem is the peer(s) between. But documenting A-B/B-A is a good start. > The NRA normally sets the limits to such an offer. The power of the national rifle association is staggering. ;) -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 02:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIYJ-0000yb-EP; Mon, 03 Apr 2006 02:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQIYC-0000p7-MH for speermint@ietf.org; Mon, 03 Apr 2006 02:28:32 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQIYC-0000Bj-Cx for speermint@ietf.org; Mon, 03 Apr 2006 02:28:32 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A07F0128; Mon, 03 Apr 2006 02:28:15 -0400 From: "Hadriel Kaplan" To: Subject: RE: [Speermint] Speermint Charter Date: Mon, 3 Apr 2006 02:28:20 -0400 Message-ID: <02d801c656e7$cd60b8e0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4A= In-Reply-To: <05a701c6544a$b4679c40$b9201f0a@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 Hi Brian, Your comments were astute, as always. :) To your question of "does it matter if they go through SBCs for our work?": I have been thinking this question myself for the past week or so since I joined this mailing list. Obviously I work at a company which makes SBCs, so I'm going to have a biased view, and I'd rather whatever we document works with them. If it doesn't, it would be a waste of your time in my opinion, because as far as I can tell SBCs will still be used by service providers; and their use is fairly dominant in peering, not just access. Most infrastructure-based voip service providers use them for peering, and many non-infrastructure ones do as well. For example, of the service providers on this mailing list, I know a majority use SBCs at their voip peering points. Even if you don't believe the vendors or the market analysts (who would? ;), it doesn't take many providers using them for it to be an issue, since peering is a 2-way deal and the odds of at least one side having one are big. So, to your actual question: it depends. If the end goal of this WG is to define BCPs of call flows for peering, then that's easy: someone can just send an ethereal trace. :) If it's to define best future (vs. current/common) practices, then yes it may hit issues if the reality (from my perspective) isn't taken into account. It's like talking about IP peering without acknowledging routers exist. The irony from my perspective is what SBCs do "differently" is used by many for very valuable peering-related benefits. I think you put it exactly right when you said: "I think our problem is more to define what we do first than what we do." -Hadriel p.s. 2 UAs at the same hotel need not be media-relayed, depending on the SBC vendor; though one would wonder why they'd call themselves using hosted-voip instead of picking up the desk-phones. ;) But hosted-nat-traversal is not the most common reason for using SBCs. (not even in the top 3 reasons, though probably 4 or 5) p.p.s. Long time no see! (we met several times back in early megaco days) > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, March 30, 2006 5:39 PM > To: 'Stastny Richard'; 'Reinaldo Penno'; 'Malas, Daryl'; 'Khan, Sohel Q > [CTO]' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter > > The charter is clear we are talking about BOTH the media and the > signaling. > If you combine that with "inter-carrier vs inter-domain" then you have > BOTH > the case of a direct media connection as well as one that goes through > (horrors) SBCs, even when two UAs are in the same hotel. Most enterprises > seem to like SBCs anyway. Unless someone gives me a really good > explanation > of why it actually matters if they do run through SBCs with respect to our > work, I think we probably can ignore the difference. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 04:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKeA-0002qh-VR; Mon, 03 Apr 2006 04:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKe9-0002mW-3F for speermint@ietf.org; Mon, 03 Apr 2006 04:42:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQKe7-0006fy-IC for speermint@ietf.org; Mon, 03 Apr 2006 04:42:49 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Mon, 3 Apr 2006 10:46:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EA0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALA= From: "Stastny Richard" To: "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 > > Provider B has now (currently only for Public User > > Identities in the form of E.164 numbers) the OBLIGATION > > making this PUI reachable for the public by interconnecting > > with the public network (in this case at least via the PSTN) > > [snipped] > > So IMHO we can assume that provider B hosting a Public User Identity > > (a SIP URI) MUST make this PUI reachable in principle. >=20 > I would think that would only be true if you define the AoR to be a public > identity in the public domain, and such regulation was to be created for > AoRs. E.164 numbers are by definition such numbers, I think. But if, for > example, I build a private enterprise network - there's no way I'm > obligated > to do so just because I use the same SIP fields AoRs are used in. I think here we are at the core of the problem. It is the fuzzy definition of public and private on the Internet. E.164 numbers are by definition public. If you build a private network, you may create private numbering plans as much as you like, they need not to be reachable. But if you map the private numbering plan to E.164 and make it reachable e.g. via DDI (or DID) via a UNI provided by a (public) SP, they become part of the E.164 numbering=20 plan and therefore reachable. So what is the definition of a "public" (SIP) AoR? The provision of SRV records in the public DNS? Side remark: In DDI not all extensions need to be reachable from outside, but at least the pilot number and the=20 switchboard is. A rough equivalent to AoRs is the domain name part and the user part. Which raises another question: what is equivalent of a switchboard in sip:?@example.com ? In E.164, if say +43 50811 is considered the pilot number, it is either calling +43 50811, +43 50811 0 or calling a non-existent or nor-reachable extension e.g. +43 50811 9999. Any thoughts? Richard > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 3:48 AM > To: Stastny Richard; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Richard, comments inline... >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, April 01, 2006 2:46 PM > > To: speermint@ietf.org > > Subject: [Speermint] Reachability > > > > after reading the document from Scott Markus on NGN Interconnect > > I referenced for weekend reading in my last posting > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin- > v2.1.pdf >=20 > Indeed that was an interesting paper - thanks for the pointer! (not that I > agree with everything in it) >=20 > > and second we always started naturally at provider A in direction > > of call set-up and not at provider B >=20 > Personally, I think the bigger "problem" is the provider C, the one after > B. > :) C trying to be reachable by A through B. But that's out of scope I > guess. It's too bad, because that's when BGP got interesting, for > example. >=20 > > Provider B has now (currently only for Public User > > Identities in the form of E.164 numbers) the OBLIGATION > > making this PUI reachable for the public by interconnecting > > with the public network (in this case at least via the PSTN) > > [snipped] > > So IMHO we can assume that provider B hosting a Public User Identity > > (a SIP URI) MUST make this PUI reachable in principle. >=20 > I would think that would only be true if you define the AoR to be a public > identity in the public domain, and such regulation was to be created for > AoRs. E.164 numbers are by definition such numbers, I think. But if, for > example, I build a private enterprise network - there's no way I'm > obligated > to do so just because I use the same SIP fields AoRs are used in. >=20 > Having said that, I would think most providers _want_ to make them > reachable, because that increases their value. But as the paper pointed > out, peering is difficult to manage beyond a few hundred peers, nor do IP > or > PSTN providers peer with everyone directly to achieve universal > reachability. That's why, for me, the more complex problem is the peer(s) > between. But documenting A-B/B-A is a good start. >=20 > > The NRA normally sets the limits to such an offer. >=20 > The power of the national rifle association is staggering. ;) >=20 > -hadriel >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 07:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQN3j-00054P-PA; Mon, 03 Apr 2006 07:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQN3j-00054K-2Y for speermint@ietf.org; Mon, 03 Apr 2006 07:17:23 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQN3g-0005Kb-IC for speermint@ietf.org; Mon, 03 Apr 2006 07:17:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 03 Apr 2006 04:17:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,157,1141632000"; d="scan'208"; a="540649979:sNHT29011080" 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] Reachability Date: Mon, 3 Apr 2006 07:17:17 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5CE@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8A== From: "Reinaldo Penno" To: "Stastny Richard" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Monday, April 03, 2006 1:47 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 >=20 >=20 > > > Provider B has now (currently only for Public User > > > Identities in the form of E.164 numbers) the OBLIGATION > > > making this PUI reachable for the public by interconnecting > > > with the public network (in this case at least via the PSTN) > > > [snipped] > > > So IMHO we can assume that provider B hosting a Public User Identity > > > (a SIP URI) MUST make this PUI reachable in principle. > > > > I would think that would only be true if you define the AoR to be a > public > > identity in the public domain, and such regulation was to be created > for > > AoRs. E.164 numbers are by definition such numbers, I think. But if, > for > > example, I build a private enterprise network - there's no way I'm > > obligated > > to do so just because I use the same SIP fields AoRs are used in. >=20 > I think here we are at the core of the problem. It is the > fuzzy definition of public and private on the Internet. > E.164 numbers are by definition public. If you build a > private network, you may create private numbering plans > as much as you like, they need not to be reachable. But > if you map the private numbering plan to E.164 and make > it reachable e.g. via DDI (or DID) via a UNI provided > by a (public) SP, they become part of the E.164 numbering > plan and therefore reachable. >=20 > So what is the definition of a "public" (SIP) AoR? [[Reinaldo]]=20 Hello, Maybe I'm missing something, but given that this workgroup is interested only in call routing (E.164 is out of scope), do we really need to care about that? An AoR in the end will be translated to an IP address, and IP addresses have a very good definition of public and private (in IPv4 and IPv6). If this _IP_ address is public, a connection will be attempted. I say attempted because there are no guarantees it will succeed. If the IP address is private, it means you are in a private network yourself or there is a misconfiguration somewhere. For you to be "SIP reachable", you need to be IP reachable first, let's not forget about that. And if you are IP reachable, you could potentially be SIP reachable by registering to some free SIP service (or the SIP "domain" above you in the hierarchy...if this was the email/DNS model). Thanks, Reinaldo >=20 > The provision of SRV records in the public DNS? >=20 > Side remark: In DDI not all extensions need to be > reachable from outside, but at least the pilot number and the > switchboard is. >=20 > A rough equivalent to AoRs is the domain name > part and the user part. Which raises another question: > what is equivalent of a switchboard in sip:?@example.com ? >=20 > In E.164, if say +43 50811 is considered the pilot number, > it is either calling +43 50811, +43 50811 0 or calling > a non-existent or nor-reachable extension e.g. > +43 50811 9999. >=20 > Any thoughts? >=20 > Richard >=20 >=20 >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 3:48 AM > > To: Stastny Richard; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Richard, comments inline... > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, April 01, 2006 2:46 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Reachability > > > > > > after reading the document from Scott Markus on NGN Interconnect > > > I referenced for weekend reading in my last posting > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin- > > v2.1.pdf > > > > Indeed that was an interesting paper - thanks for the pointer! (not > that I > > agree with everything in it) > > > > > and second we always started naturally at provider A in direction > > > of call set-up and not at provider B > > > > Personally, I think the bigger "problem" is the provider C, the one > after > > B. > > :) C trying to be reachable by A through B. But that's out of scope > I > > guess. It's too bad, because that's when BGP got interesting, for > > example. > > > > > Provider B has now (currently only for Public User > > > Identities in the form of E.164 numbers) the OBLIGATION > > > making this PUI reachable for the public by interconnecting > > > with the public network (in this case at least via the PSTN) > > > [snipped] > > > So IMHO we can assume that provider B hosting a Public User Identity > > > (a SIP URI) MUST make this PUI reachable in principle. > > > > I would think that would only be true if you define the AoR to be a > public > > identity in the public domain, and such regulation was to be created > for > > AoRs. E.164 numbers are by definition such numbers, I think. But if, > for > > example, I build a private enterprise network - there's no way I'm > > obligated > > to do so just because I use the same SIP fields AoRs are used in. > > > > Having said that, I would think most providers _want_ to make them > > reachable, because that increases their value. But as the paper > pointed > > out, peering is difficult to manage beyond a few hundred peers, nor do > IP > > or > > PSTN providers peer with everyone directly to achieve universal > > reachability. That's why, for me, the more complex problem is the > peer(s) > > between. But documenting A-B/B-A is a good start. > > > > > The NRA normally sets the limits to such an offer. > > > > The power of the national rifle association is staggering. ;) > > > > -hadriel > > >=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 Apr 03 08:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQOMn-0007Tt-Eg; Mon, 03 Apr 2006 08:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQOMm-0007TU-EE for speermint@ietf.org; Mon, 03 Apr 2006 08:41:08 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQOMl-0000Mi-7Q for speermint@ietf.org; Mon, 03 Apr 2006 08:41:08 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 08:40:54 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D30@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0A== From: "Livingood, Jason" To: "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2006 12:40:55.0584 (UTC) FILETIME=[D9C38200:01C6571B] 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 > To your question of "does it matter if they go through SBCs=20 > for our work?" > So, to your actual question: it depends. If the end goal of=20 > this WG is to define BCPs of call flows for peering, then=20 > that's easy: someone can just send an ethereal trace. :) If=20 > it's to define best future (vs. > current/common) practices, then yes it may hit issues if the=20 > reality (from my perspective) isn't taken into account. It's=20 > like talking about IP peering without acknowledging routers=20 > exist. The irony from my perspective is what SBCs do=20 > "differently" is used by many for very valuable=20 > peering-related benefits. I suspect this issue will continue to arise every so often as it has before (which is okay, by the way; continued discussion is generally a signal of a lack of consensus). IMHO, the architecture and BCPs proposed will need to show how you can do SIP peering without and with session border elements. There are some domains that will not want to use them, and some that will want to use them. And even where a domain prefers to use such an element, it may be application-specific such that it is perhaps used for SIP-VoIP but not for SIP-IM. =20 Anyway, I think the point is that I don't expect we'll try to dictate that session border elements absolutely must or must not be used. For some domains with particular requirements (business, IP networking, IP addressing, whatever), for some applications, such elements may make sense and may be considered. For those that feel strongly about the fact that use of such elements are not a good trend, we should be able to spell out how a domain can meet all of their requirements and deploy a SIP peering architecture without them if they so choose (and so we'll ask for your constructive assistance on such work). Thus, we first describe requirements, then we describe all of the different architecture options that would accomodate those requirements, and then implementers better understand all of the issues and can make decisions based on this expert information as well as their own particular needs. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 10:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQPK-0005e9-Ve; Mon, 03 Apr 2006 10:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQPI-0005TG-Uc for speermint@ietf.org; Mon, 03 Apr 2006 10:51:52 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQPI-0005aq-Lt for speermint@ietf.org; Mon, 03 Apr 2006 10:51:52 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 10:51: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] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 10:51:51 -0400 Message-ID: <8812D8156467224C9E9739E513037EF1517D95@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) thread-index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIw From: "Medhavi Bhatia" To: "Livingood, Jason" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2006 14:51:52.0206 (UTC) FILETIME=[24ACE2E0:01C6572E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Jason, Our focus at this point should be trying to keep it simple and practical. Commercial choices (whether to use SBCs, firwewalls or SIP proxies) for peering should be kept out of scope of the charter. The specification of any sort of architecture can be very consuming at this point and the usefulness is quite limited. I suggest starting with the following simple use cases which have no architecture implications or dependencies: - Direct peering between Core-O and Core-T o Technology required (ENUM/DNS, SIP Requirements) - Peering with IXP in the middle o Technology required (ENUM/DNS, SIP Requirements) In addition, the role of federations and IXPs needs to be well documented since that affects the technology we develop or use. -Medhavi. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, April 03, 2006 8:41 AM > To: Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) >=20 >=20 > > To your question of "does it matter if they go through SBCs > > for our work?" > > So, to your actual question: it depends. If the end goal of > > this WG is to define BCPs of call flows for peering, then > > that's easy: someone can just send an ethereal trace. :) If > > it's to define best future (vs. > > current/common) practices, then yes it may hit issues if the > > reality (from my perspective) isn't taken into account. It's > > like talking about IP peering without acknowledging routers > > exist. The irony from my perspective is what SBCs do > > "differently" is used by many for very valuable > > peering-related benefits. >=20 > I suspect this issue will continue to arise every so often as it has > before (which is okay, by the way; continued discussion is generally a > signal of a lack of consensus). IMHO, the architecture and BCPs > proposed will need to show how you can do SIP peering without and with > session border elements. There are some domains that will not want to > use them, and some that will want to use them. And even where a domain > prefers to use such an element, it may be application-specific such that > it is perhaps used for SIP-VoIP but not for SIP-IM. >=20 > Anyway, I think the point is that I don't expect we'll try to dictate > that session border elements absolutely must or must not be used. For > some domains with particular requirements (business, IP networking, IP > addressing, whatever), for some applications, such elements may make > sense and may be considered. For those that feel strongly about the > fact that use of such elements are not a good trend, we should be able > to spell out how a domain can meet all of their requirements and deploy > a SIP peering architecture without them if they so choose (and so we'll > ask for your constructive assistance on such work). Thus, we first > describe requirements, then we describe all of the different > architecture options that would accomodate those requirements, and then > implementers better understand all of the issues and can make decisions > based on this expert information as well as their own particular needs. >=20 > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: 3/31/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 11:17:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQoA-0003AI-HB; Mon, 03 Apr 2006 11:17:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQo9-0003AD-2N for speermint@ietf.org; Mon, 03 Apr 2006 11:17:33 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQQo8-0006cI-Gi for speermint@ietf.org; Mon, 03 Apr 2006 11:17:33 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 17:21:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EA6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIwAAFQj8A= From: "Stastny Richard" To: "Medhavi Bhatia" , "Livingood, Jason" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 tend to agree with Medhavi that from the point of the Core-O it does not matter very much if a given an AoR is to be routed< to a SIP proxy direct via a SBC pretending to be one or an I-CSCF or whatever. This is also ok with the ENUM Charter talking about discovering points of interconnect This may be an issue later regarding transparent end2end user connections, but one problem after the other Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Monday, April 03, 2006 4:52 PM > To: Livingood, Jason; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) >=20 > Hi Jason, >=20 > Our focus at this point should be trying to keep it simple and > practical. Commercial choices (whether to use SBCs, firwewalls or SIP > proxies) for peering should be kept out of scope of the charter. The > specification of any sort of architecture can be very consuming at this > point and the usefulness is quite limited. >=20 > I suggest starting with the following simple use cases which have no > architecture implications or dependencies: >=20 > - Direct peering between Core-O and Core-T > o Technology required (ENUM/DNS, SIP Requirements) > - Peering with IXP in the middle > o Technology required (ENUM/DNS, SIP Requirements) >=20 > In addition, the role of federations and IXPs needs to be well > documented since that affects the technology we develop or use. >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, April 03, 2006 8:41 AM > > To: Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > > > > > > To your question of "does it matter if they go through SBCs > > > for our work?" > > > So, to your actual question: it depends. If the end goal of > > > this WG is to define BCPs of call flows for peering, then > > > that's easy: someone can just send an ethereal trace. :) If > > > it's to define best future (vs. > > > current/common) practices, then yes it may hit issues if the > > > reality (from my perspective) isn't taken into account. It's > > > like talking about IP peering without acknowledging routers > > > exist. The irony from my perspective is what SBCs do > > > "differently" is used by many for very valuable > > > peering-related benefits. > > > > I suspect this issue will continue to arise every so often as it has > > before (which is okay, by the way; continued discussion is generally a > > signal of a lack of consensus). IMHO, the architecture and BCPs > > proposed will need to show how you can do SIP peering without and with > > session border elements. There are some domains that will not want to > > use them, and some that will want to use them. And even where a > domain > > prefers to use such an element, it may be application-specific such > that > > it is perhaps used for SIP-VoIP but not for SIP-IM. > > > > Anyway, I think the point is that I don't expect we'll try to dictate > > that session border elements absolutely must or must not be used. For > > some domains with particular requirements (business, IP networking, IP > > addressing, whatever), for some applications, such elements may make > > sense and may be considered. For those that feel strongly about the > > fact that use of such elements are not a good trend, we should be able > > to spell out how a domain can meet all of their requirements and > deploy > > a SIP peering architecture without them if they so choose (and so > we'll > > ask for your constructive assistance on such work). Thus, we first > > describe requirements, then we describe all of the different > > architecture options that would accomodate those requirements, and > then > > implementers better understand all of the issues and can make > decisions > > based on this expert information as well as their own particular > needs. > > > > Jason > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: > 3/31/2006 > > >=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 Apr 03 11:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQzA-0001uk-01; Mon, 03 Apr 2006 11:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQz8-0001tR-LR for speermint@ietf.org; Mon, 03 Apr 2006 11:28:54 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQz7-0007L6-Dq for speermint@ietf.org; Mon, 03 Apr 2006 11:28:54 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 3 Apr 2006 11:28:26 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040311282532722 ; Mon, 03 Apr 2006 11:28:25 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Apr 2006 11:28:22 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D77@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Stastny Richard , Hadriel Kaplan , speermint@ietf.org Subject: RE: [Speermint] Reachability Date: Mon, 3 Apr 2006 11:28:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============0623668227==" Errors-To: speermint-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0623668227== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65733.36B5C305" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C65733.36B5C305 Content-Type: text/plain; charset="iso-8859-1" I do not believe that there is any definition of public AoR per se. If AoR is resolved to a public IP address, we can then say that the physical address is public. Otherwise, it is private. Best regards, Radhika -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org ] On Behalf Of Stastny Richard Sent: Monday, April 03, 2006 4:47 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability So what is the definition of a "public" (SIP) AoR? Any thoughts? Richard ------_=_NextPart_001_01C65733.36B5C305 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Speermint] Reachability

I do not believe that there is any definition of public AoR per = se. If AoR is resolved to a public IP address, we can then say that the = physical address is public. Otherwise, it is private.

Best regards,

Radhika

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf= .org] On Behalf Of Stastny Richard
Sent: Monday, April 03, 2006 4:47 AM
To: Hadriel Kaplan; speermint@ietf.org
Subject: RE: [Speermint] Reachability



So what is the definition of a "public" (SIP) = AoR?


Any thoughts?

Richard



------_=_NextPart_001_01C65733.36B5C305-- --===============0623668227== 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 --===============0623668227==-- From speermint-bounces@ietf.org Mon Apr 03 12:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRzv-0000IH-0J; Mon, 03 Apr 2006 12:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRzt-0000IC-Qr for speermint@ietf.org; Mon, 03 Apr 2006 12:33:45 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRzt-0001zU-Ax for speermint@ietf.org; Mon, 03 Apr 2006 12:33:45 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-3.cisco.com with ESMTP; 03 Apr 2006 09:33:44 -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 k33GXd1x019438; Mon, 3 Apr 2006 09:33:44 -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.211); Mon, 3 Apr 2006 12:33: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] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 12:33:42 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3014A37E7@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIwAAQkfIA= From: "Michael Hammer \(mhammer\)" To: "Medhavi Bhatia" , "Livingood, Jason" , "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2006 16:33:43.0054 (UTC) FILETIME=[5F064AE0:01C6573C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 agree. Let's not get the tail wagging the dog here. Product X needs to support the peering specification, not vice versa. Mike =20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com]=20 > Sent: Monday, April 03, 2006 10:52 AM > To: Livingood, Jason; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) >=20 > Hi Jason, >=20 > Our focus at this point should be trying to keep it simple=20 > and practical. Commercial choices (whether to use SBCs,=20 > firwewalls or SIP > proxies) for peering should be kept out of scope of the=20 > charter. The specification of any sort of architecture can be=20 > very consuming at this point and the usefulness is quite limited. >=20 > I suggest starting with the following simple use cases which=20 > have no architecture implications or dependencies: >=20 > - Direct peering between Core-O and Core-T > o Technology required (ENUM/DNS, SIP Requirements) > - Peering with IXP in the middle > o Technology required (ENUM/DNS, SIP Requirements) >=20 > In addition, the role of federations and IXPs needs to be=20 > well documented since that affects the technology we develop or use. >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, April 03, 2006 8:41 AM > > To: Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > >=20 > >=20 > > > To your question of "does it matter if they go through=20 > SBCs for our=20 > > > work?" > > > So, to your actual question: it depends. If the end goal=20 > of this WG=20 > > > is to define BCPs of call flows for peering, then that's easy:=20 > > > someone can just send an ethereal trace. :) If it's to=20 > define best=20 > > > future (vs. > > > current/common) practices, then yes it may hit issues if=20 > the reality=20 > > > (from my perspective) isn't taken into account. It's=20 > like talking=20 > > > about IP peering without acknowledging routers exist. The irony=20 > > > from my perspective is what SBCs do "differently" is used by many=20 > > > for very valuable peering-related benefits. > >=20 > > I suspect this issue will continue to arise every so often=20 > as it has=20 > > before (which is okay, by the way; continued discussion is=20 > generally a=20 > > signal of a lack of consensus). IMHO, the architecture and BCPs=20 > > proposed will need to show how you can do SIP peering=20 > without and with=20 > > session border elements. There are some domains that will=20 > not want to=20 > > use them, and some that will want to use them. And even where a > domain > > prefers to use such an element, it may be application-specific such > that > > it is perhaps used for SIP-VoIP but not for SIP-IM. > >=20 > > Anyway, I think the point is that I don't expect we'll try=20 > to dictate=20 > > that session border elements absolutely must or must not be=20 > used. For=20 > > some domains with particular requirements (business, IP=20 > networking, IP=20 > > addressing, whatever), for some applications, such elements=20 > may make=20 > > sense and may be considered. For those that feel strongly=20 > about the=20 > > fact that use of such elements are not a good trend, we=20 > should be able=20 > > to spell out how a domain can meet all of their requirements and > deploy > > a SIP peering architecture without them if they so choose (and so > we'll > > ask for your constructive assistance on such work). Thus, we first=20 > > describe requirements, then we describe all of the different=20 > > architecture options that would accomodate those requirements, and > then > > implementers better understand all of the issues and can make > decisions > > based on this expert information as well as their own particular > needs. > >=20 > > Jason > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: > 3/31/2006 > >=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 Apr 03 12:42:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQS8A-0003eE-6I; Mon, 03 Apr 2006 12:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQS88-0003e8-9Q for speermint@ietf.org; Mon, 03 Apr 2006 12:42:16 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQS87-0002JD-Uw for speermint@ietf.org; Mon, 03 Apr 2006 12:42:16 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A06502D8; Mon, 03 Apr 2006 12:42:13 -0400 From: "Hadriel Kaplan" To: "'Livingood, Jason'" Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 12:42:20 -0400 Message-ID: <034201c6573d$93973660$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAG12ng In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7305247D30@PACDCEXCMB01.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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 Of course I agree. I would never expect that SBCs be mandated by any IETF work, nor that they be the starting point; nor could they be from a political perspective. I only raised it because Brian asked if we should care about them for the WG's work. That would only be the case if the WG mandated something that wouldn't work with SBCs. :) That's very different than mandating they be used, or starting with them in the picture - it's really only about keeping an eye on what's being defined to be as broadly applicable as possible. -hadriel > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, April 03, 2006 8:41 AM > To: Hadriel Kaplan > Cc: speermint@ietf.org; David Meyer > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > > > To your question of "does it matter if they go through SBCs > > for our work?" > > So, to your actual question: it depends. If the end goal of > > this WG is to define BCPs of call flows for peering, then > > that's easy: someone can just send an ethereal trace. :) If > > it's to define best future (vs. > > current/common) practices, then yes it may hit issues if the > > reality (from my perspective) isn't taken into account. It's > > like talking about IP peering without acknowledging routers > > exist. The irony from my perspective is what SBCs do > > "differently" is used by many for very valuable > > peering-related benefits. > > I suspect this issue will continue to arise every so often as it has > before (which is okay, by the way; continued discussion is generally a > signal of a lack of consensus). IMHO, the architecture and BCPs > proposed will need to show how you can do SIP peering without and with > session border elements. There are some domains that will not want to > use them, and some that will want to use them. And even where a domain > prefers to use such an element, it may be application-specific such that > it is perhaps used for SIP-VoIP but not for SIP-IM. > > Anyway, I think the point is that I don't expect we'll try to dictate > that session border elements absolutely must or must not be used. For > some domains with particular requirements (business, IP networking, IP > addressing, whatever), for some applications, such elements may make > sense and may be considered. For those that feel strongly about the > fact that use of such elements are not a good trend, we should be able > to spell out how a domain can meet all of their requirements and deploy > a SIP peering architecture without them if they so choose (and so we'll > ask for your constructive assistance on such work). Thus, we first > describe requirements, then we describe all of the different > architecture options that would accomodate those requirements, and then > implementers better understand all of the issues and can make decisions > based on this expert information as well as their own particular needs. > > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 14:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTu6-0006Th-Cb; Mon, 03 Apr 2006 14:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTu5-0006S0-Es for speermint@ietf.org; Mon, 03 Apr 2006 14:35:53 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTu4-0006qM-2C for speermint@ietf.org; Mon, 03 Apr 2006 14:35:53 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k33IZnI2027367; Mon, 3 Apr 2006 11:35:49 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k33IZjVN027366; Mon, 3 Apr 2006 11:35:45 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Apr 2006 11:35:45 -0700 From: David Meyer To: "Livingood, Jason" Subject: Re: [Speermint] Definition of "Peering" Message-ID: <20060403183545.GA27231@1-4-5.net> References: <6EEEACD9D7F52940BEE26F5467C02C7305247D1E@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7305247D1E@PACDCEXCMB01.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: 082a9cbf4d599f360ac7f815372a6a15 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: , Content-Type: multipart/mixed; boundary="===============0683564908==" Errors-To: speermint-bounces@ietf.org --===============0683564908== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 02, 2006 at 09:09:13PM -0400, Livingood, Jason wrote: > We needn't endlessly debate whether or not speermint should accomodate > peering over only "IP networks" or only the "Public Internet" (and, in > turn, each of these terms is perhaps endlessly debatable). It is clear > from list and f2f discussion that both are needed. Which one is used, > and when, could depend upon a great number of factors. We should not > exclude anything so early in the WG, IMHO. Sorry about the delay in jumping in (post IETF travel, illness). In any event, I do agree with Jason here. However, this discussion has be excellent and has refined out thinking. There have been many suggestions about for improvments to the terminology draft in this thread (which I hope to get to this week), as well as the conclusion that we should split requirements out of that document. Dave >=20 > Jason >=20 > > For example, one of the arguments I heard people raised at=20 > > IETF 65 was "what about this is the Internet? The I in IETF=20 > > is for Internet, so this group is out of scope." First, it=20 > > is obviously untrue that the IETF only concerns itself with=20 > > the ip network transport layer, nor of routing protocols to=20 > > create an Internet. One need only look at the areas and=20 > > working groups to see that. It's not only layer 3 protocols=20 > > being defined. Second, there is one area actually titled=20 > > "Internet Area", yet even within that area are groups who's=20 > > entire existence in life is to define VPNs, at layers 2 and 3. > >=20 > >=20 > > How are VPNs the Internet? Extending that idea, there are=20 > > IETF groups who are (or were last time I was at the IETF)=20 > > working to define how such VPNs can work between providers,=20 > > and bridge the VPNs together. For me, if that is acceptable=20 > > work for the IETF, then there should also be a case for=20 > > allowing layer-5 VPNs to be bridged together. And that's=20 > > only if you look at it one way (as L5 VPNs). There are other=20 > > ways to look at it that I think make it acceptable as well. --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMWsBORgD1qCZ2KcRAnBRAJ4vbNz6KCw2HBgnUWjjnEjYNnaFUgCeOoPo gjYjr+nWoPfQ6sMRdB7iDak= =qP6P -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============0683564908== 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 --===============0683564908==-- From speermint-bounces@ietf.org Mon Apr 03 14:39:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTy1-0008LK-FE; Mon, 03 Apr 2006 14:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTy0-0008Ky-Pj for speermint@ietf.org; Mon, 03 Apr 2006 14:39:56 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTxz-0006w7-De for speermint@ietf.org; Mon, 03 Apr 2006 14:39:56 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k33Idg0J027418; Mon, 3 Apr 2006 11:39:42 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k33IdfJL027417; Mon, 3 Apr 2006 11:39:41 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Apr 2006 11:39:41 -0700 From: David Meyer To: "Livingood, Jason" Subject: Re: [Speermint] Speermint Charter Message-ID: <20060403183941.GC27231@1-4-5.net> References: <6EEEACD9D7F52940BEE26F5467C02C7305247D22@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7305247D22@PACDCEXCMB01.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Khan, Sohel Q \[CTO\]" , Stastny Richard , speermint@ietf.org, "Malas, Daryl" 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="===============1392827344==" Errors-To: speermint-bounces@ietf.org --===============1392827344== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 02, 2006 at 09:09:17PM -0400, Livingood, Jason wrote: > Here-here, Brian! Excellent and well considered response. I recommend > to everyone that is in the thread that you re-read the charter very > carefully. It is intended to be as specific as possible, while not > overly restrictive. >=20 > Suggest we focus on finishing the Terminology Draft as soon as we can. > So let's have it out on all of the terms there one more time. Any terms > raised in Dallas that are not in the draft should be suggested by > someone. Let's get every term in there and defined, as is reasonable > and appropriate to our work. Updates in the queue on the terminology draft. You should see the revision this week (I'm going to rename it, since we're removing the requirements stuff). Dave --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMWvtORgD1qCZ2KcRAsb2AKCIT4tQEg1aHF4RxICXWc++2oyBIwCfbpPw WuFgMA0oq6RUxepqpq997Yo= =BeDF -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- --===============1392827344== 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 --===============1392827344==-- From speermint-bounces@ietf.org Mon Apr 03 14:41:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTzv-0002e8-7e; Mon, 03 Apr 2006 14:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTzt-0002aM-Vk for speermint@ietf.org; Mon, 03 Apr 2006 14:41:53 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTzs-0006y5-Ig for speermint@ietf.org; Mon, 03 Apr 2006 14:41:53 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k33IfpRw027489; Mon, 3 Apr 2006 11:41:51 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k33Ifp2p027488; Mon, 3 Apr 2006 11:41:51 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Apr 2006 11:41:51 -0700 From: David Meyer To: "Livingood, Jason" Subject: Re: [Speermint] Reachability Message-ID: <20060403184151.GD27231@1-4-5.net> References: <6EEEACD9D7F52940BEE26F5467C02C7305247D28@PACDCEXCMB01.cable.comcast.com> Mime-Version: 1.0 In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7305247D28@PACDCEXCMB01.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: 92df29fa99cf13e554b84c8374345c17 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: , Content-Type: multipart/mixed; boundary="===============0681800609==" Errors-To: speermint-bounces@ietf.org --===============0681800609== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cHMo6Wbp1wrKhbfi" Content-Disposition: inline --cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 02, 2006 at 09:09:22PM -0400, Livingood, Jason wrote: > > First we talked primarily about peering, which is according=20 > > to the FCC definition always bilateral and not about=20 > > interconnect and transit >=20 >=20 > Luckily, we can make up our own definitions in the Terminology Draft. > Last I checked, we were not bound by FCC definitions (and thankfully so, > I hasten to add). ;-) >=20 > > speermint should not deal with commercial agreements, but it=20 > > could povide guidelines for the technical part, e.g. > > be setting minimum requirements for signaling protocols,=20 > > security, identifcation of provider A and his users, etc.in=20 > > other words a set of BCPs. >=20 > Sounds right. I think the charter's milestones prove that out to some > extent. >=20 > > I said speermint should not be involved to much in commercial=20 > > agreements, but it may also provide some tools to make these=20 > > workable and scaleable. >=20 > Sounds right; we're not expecting to create a business here for the > IETF. ;-) >=20 > > Bi-lateral agreements do not scale on a global level, so we=20 > > may assume that the agreements come in groups i.e.=20 > > federations or whatever we may call it >=20 > Sounds right on the part about bilateral agreements not scaling. > Imagine trying to use bilateral agreements to make email work (shudder). Well, bilat's do scale at layer 3 (you might argue that O(n^2) isn't scaling, but in practice that's a loose upperbound, but then, the world is different there). > > So it may be useful to provide means for a provider B to=20 > > annouce what kind of agreements he is requesting to accept=20 > > incoming calls. >=20 > This has come up a few times, including in Dallas. Sounds like this is > the start of some more requirements for the Requirements Draft. :-) I > can imagine some domains/providers will want some kind of a capability > like this, while others may choose not to use it. But it sounds like > such a policy / announcement method should be considered and discussed > more fully. Yep. Dave --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMWxvORgD1qCZ2KcRAhmSAJ9mPVuvSg2ae+eqHgwEbLjnBs9yRACeN32y oQI9lwS3OUD5YkiMq7Z9weo= =ujpP -----END PGP SIGNATURE----- --cHMo6Wbp1wrKhbfi-- --===============0681800609== 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 --===============0681800609==-- From speermint-bounces@ietf.org Mon Apr 03 14:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQU80-0001T1-0h; Mon, 03 Apr 2006 14:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQU7y-0001Sn-VG for speermint@ietf.org; Mon, 03 Apr 2006 14:50:14 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQU7y-0007GE-Gc for speermint@ietf.org; Mon, 03 Apr 2006 14:50:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k33IoCLQ027725; Mon, 3 Apr 2006 11:50:12 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k33IoBoF027724; Mon, 3 Apr 2006 11:50:11 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Apr 2006 11:50:11 -0700 From: David Meyer To: Medhavi Bhatia Subject: Re: [Speermint] Speermint Charter (now re SBCs) Message-ID: <20060403185011.GA27679@1-4-5.net> References: <8812D8156467224C9E9739E513037EF1517D95@moe.nextone.local> Mime-Version: 1.0 In-Reply-To: <8812D8156467224C9E9739E513037EF1517D95@moe.nextone.local> 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: speermint@ietf.org, "Livingood, Jason" 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="===============0314330892==" Errors-To: speermint-bounces@ietf.org --===============0314330892== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Medhavi, > Our focus at this point should be trying to keep it simple and > practical.=20 Exactly. > Commercial choices (whether to use SBCs, firwewalls or SIP > proxies) for peering should be kept out of scope of the charter. The > specification of any sort of architecture can be very consuming at this > point and the usefulness is quite limited. I agree, at least initially. > I suggest starting with the following simple use cases which have no > architecture implications or dependencies: >=20 > - Direct peering between Core-O and Core-T > o Technology required (ENUM/DNS, SIP Requirements) > - Peering with IXP in the middle > o Technology required (ENUM/DNS, SIP Requirements) >=20 > In addition, the role of federations and IXPs needs to be well > documented since that affects the technology we develop or use. Do you think we need to add terminology (to the terminology draft) for these last 2? Dave >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, April 03, 2006 8:41 AM > > To: Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > >=20 > >=20 > > > To your question of "does it matter if they go through SBCs > > > for our work?" > > > So, to your actual question: it depends. If the end goal of > > > this WG is to define BCPs of call flows for peering, then > > > that's easy: someone can just send an ethereal trace. :) If > > > it's to define best future (vs. > > > current/common) practices, then yes it may hit issues if the > > > reality (from my perspective) isn't taken into account. It's > > > like talking about IP peering without acknowledging routers > > > exist. The irony from my perspective is what SBCs do > > > "differently" is used by many for very valuable > > > peering-related benefits. > >=20 > > I suspect this issue will continue to arise every so often as it has > > before (which is okay, by the way; continued discussion is generally a > > signal of a lack of consensus). IMHO, the architecture and BCPs > > proposed will need to show how you can do SIP peering without and with > > session border elements. There are some domains that will not want to > > use them, and some that will want to use them. And even where a > domain > > prefers to use such an element, it may be application-specific such > that > > it is perhaps used for SIP-VoIP but not for SIP-IM. > >=20 > > Anyway, I think the point is that I don't expect we'll try to dictate > > that session border elements absolutely must or must not be used. For > > some domains with particular requirements (business, IP networking, IP > > addressing, whatever), for some applications, such elements may make > > sense and may be considered. For those that feel strongly about the > > fact that use of such elements are not a good trend, we should be able > > to spell out how a domain can meet all of their requirements and > deploy > > a SIP peering architecture without them if they so choose (and so > we'll > > ask for your constructive assistance on such work). Thus, we first > > describe requirements, then we describe all of the different > > architecture options that would accomodate those requirements, and > then > > implementers better understand all of the issues and can make > decisions > > based on this expert information as well as their own particular > needs. > >=20 > > Jason > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: > 3/31/2006 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMW5jORgD1qCZ2KcRAsisAJ9lcAgUhjBA7h9yV1tuQxj3YbX49gCeJgBl B8gTEUfqLKFwJeUvSoc6eQk= =FleI -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- --===============0314330892== 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 --===============0314330892==-- From speermint-bounces@ietf.org Mon Apr 03 17:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWSH-0000Sc-Ew; Mon, 03 Apr 2006 17:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWSG-0000SX-F8 for speermint@ietf.org; Mon, 03 Apr 2006 17:19:20 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWSF-00061U-0Q for speermint@ietf.org; Mon, 03 Apr 2006 17:19:20 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A154030C; Mon, 03 Apr 2006 17:19:16 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 17:19:23 -0400 Message-ID: <03b001c65764$47675be0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIwAAQkfIAAA96bcA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3014A37E7@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Michael, That's a good point, and I'm not suggesting otherwise. I think there may be confusion about my email which I would like to clear up. I have no doubt product X (proxies, SBCs, whatever) would be changed to support a peering specification, if their customers wished it. It is, in fact, why I joined this list! :) However, I am responding to Brian's question, which may be important (or not) to WG members regarding the work of this WG. I am NOT suggesting devices (including SBCs) won't change specific things for this work. Brian asked: "should we care about them when thinking about this work?" So my response was: it depends. There is a large installed base, which does things for various reasons, so in my opinion we could hit issues if we do not to take that into account. We should support either model, so that the applicability of Speermint is as broad as possible. Since the charter currently overlaps functions that SBCs do today, it would, in my opinion, be less useful if the resulting work did not "care about them when doing this work". That's all. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, April 03, 2006 12:34 PM > To: Medhavi Bhatia; Livingood, Jason; Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > I agree. Let's not get the tail wagging the dog here. > > Product X needs to support the peering specification, not vice versa. > > Mike > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 03 18:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXDW-0004iG-LU; Mon, 03 Apr 2006 18:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXDW-0004hJ-48 for speermint@ietf.org; Mon, 03 Apr 2006 18:08:10 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXDV-00081a-GD for speermint@ietf.org; Mon, 03 Apr 2006 18:08:10 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k33M88ZF005212; Mon, 3 Apr 2006 15:08:08 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k33M88D7005211; Mon, 3 Apr 2006 15:08:08 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 3 Apr 2006 15:08:08 -0700 From: David Meyer To: Eli Katz Subject: Re: [Speermint] Speermint Charter (now re SBCs) Message-ID: <20060403220808.GB5059@1-4-5.net> References: <062B8EE81F2EC945A577C3EFAE1DD68E07FF34@mail.xconnect.net> Mime-Version: 1.0 In-Reply-To: <062B8EE81F2EC945A577C3EFAE1DD68E07FF34@mail.xconnect.net> 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: a743e34ab8eb08259de9a7307caed594 Cc: speermint@ietf.org, "Livingood, Jason" 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="===============0382973434==" Errors-To: speermint-bounces@ietf.org --===============0382973434== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 03, 2006 at 10:54:54PM +0100, Eli Katz wrote: > >> In addition, the role of federations and IXPs needs to be well=20 > >> documented since that affects the technology we develop or use. > > > > Do you think we need to add terminology (to the > > terminology draft) for these last 2? > > > > Dave >=20 > Dave, >=20 > I certainly feel it would be helpful to provide some > terminology/definition of Federations / IXPs, and if reqd, can help. Ok, thnx. I have a huge number of changes to put into that do, so let me get a -00.txt out (it will be -00 since it will have a new name), then we can work on that.=20 > There is a wide variety today of IP Communications Federations, all of > which are involved in voip peering, both in the real-world, and as > referenced in various I-Ds posted to this group (e.g. Otmar, Medhavi > etc..). They exist in their various forms, as the multi-lateral (aka > federation) type approach to interconnection/peering, is usually far > more scalable then the n*n bi-lateral approach to interconnection, which > is the basis for much of the (legacy!) telecoms interconnects today. Understood. > Bringing (some) clarity to the different types and roles of the > federations, is likely to enable a more focussed discussion and useful > output. Yes, that would seem useful. > Looking thru the current I-Ds, the types of Federations (Groups of > ITSPs) range from some OR all of the following :- >=20 > - a virtual Federation of ITSPs with common policy (both the > ad-hoc concept and the pre-agreed) > - with Federated (Private) ENUM / DNS / SRV trees, including > Origination based responses (a more secure/flexible version of > split-dns) > - with Layer 5 signalling (e.g Interconnect SP) > - Hubbing of Media (e.g IPX) (optional QoS) - usually standard > L2 / L3 IP peering > - Security, Trust, Best Practice and Identity management and > policy=20 >=20 > BTW all the above can (and does!) exist in public or private IP space.. Yep... > To reinforce, previous messages on this point, all of the above, and > federations in general, are not and should not be mandatory, as the only > speermint architecture solution. Rather it is simply one of the viable > voip peering methodologies (as used by numerous communications service > providers of all types throughout the world today), and we should keep > our charter as reasonably broad as possible, and certainly, wherever > possible, not to exclude real-world activities. Agreed. Dave >=20 > Eli > =20 > PS this could also help clarify the 3.6.2 L5 issue .. > PPS Hopefully the Layer 8 (Commercial), Layer 9 (Political) and Layer 10 > (Philosophical) issues can be and will be ignored.. :-) >=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: 03 April 2006 19:50 > To: Medhavi Bhatia > Cc: speermint@ietf.org; Livingood, Jason > Subject: Re: [Speermint] Speermint Charter (now re SBCs) >=20 > Medhavi, >=20 > > Our focus at this point should be trying to keep it simple and=20 > > practical. >=20 > Exactly. >=20 > > Commercial choices (whether to use SBCs, firwewalls or SIP > > proxies) for peering should be kept out of scope of the charter. The=20 > > specification of any sort of architecture can be very consuming at=20 > > this point and the usefulness is quite limited. >=20 > I agree, at least initially. >=20 > > I suggest starting with the following simple use cases which have no=20 > > architecture implications or dependencies: > >=20 > > - Direct peering between Core-O and Core-T > > o Technology required (ENUM/DNS, SIP Requirements) > > - Peering with IXP in the middle > > o Technology required (ENUM/DNS, SIP Requirements) > >=20 > > In addition, the role of federations and IXPs needs to be well=20 > > documented since that affects the technology we develop or use. >=20 > Do you think we need to add terminology (to the > terminology draft) for these last 2? >=20 > Dave >=20 >=20 > >=20 > > -Medhavi. > >=20 > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, April 03, 2006 8:41 AM > > > To: Hadriel Kaplan > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > >=20 > > >=20 > > > > To your question of "does it matter if they go through SBCs for=20 > > > > our work?" > > > > So, to your actual question: it depends. If the end goal of this= =20 > > > > WG is to define BCPs of call flows for peering, then that's easy:= =20 > > > > someone can just send an ethereal trace. :) If it's to define=20 > > > > best future (vs. > > > > current/common) practices, then yes it may hit issues if the=20 > > > > reality (from my perspective) isn't taken into account. It's like >=20 > > > > talking about IP peering without acknowledging routers exist. The >=20 > > > > irony from my perspective is what SBCs do "differently" is used by >=20 > > > > many for very valuable peering-related benefits. > > >=20 > > > I suspect this issue will continue to arise every so often as it has >=20 > > > before (which is okay, by the way; continued discussion is generally >=20 > > > a signal of a lack of consensus). IMHO, the architecture and BCPs=20 > > > proposed will need to show how you can do SIP peering without and=20 > > > with session border elements. There are some domains that will not= =20 > > > want to use them, and some that will want to use them. And even=20 > > > where a > > domain > > > prefers to use such an element, it may be application-specific such > > that > > > it is perhaps used for SIP-VoIP but not for SIP-IM. > > >=20 > > > Anyway, I think the point is that I don't expect we'll try to=20 > > > dictate that session border elements absolutely must or must not be= =20 > > > used. For some domains with particular requirements (business, IP=20 > > > networking, IP addressing, whatever), for some applications, such=20 > > > elements may make sense and may be considered. For those that feel= =20 > > > strongly about the fact that use of such elements are not a good=20 > > > trend, we should be able to spell out how a domain can meet all of=20 > > > their requirements and > > deploy > > > a SIP peering architecture without them if they so choose (and so > > we'll > > > ask for your constructive assistance on such work). Thus, we first= =20 > > > describe requirements, then we describe all of the different=20 > > > architecture options that would accomodate those requirements, and > > then > > > implementers better understand all of the issues and can make > > decisions > > > based on this expert information as well as their own particular > > needs. > > >=20 > > > Jason > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: > > 3/31/2006 > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMZzIORgD1qCZ2KcRAub/AJ9T4wmdDDtGaoRDsHZTOc7PgYhOVACeO7YD lnmXeWdrK/ToJijSDAaPWIA= =tjF8 -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- --===============0382973434== 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 --===============0382973434==-- From speermint-bounces@ietf.org Mon Apr 03 19:06:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY7a-0007ub-1H; Mon, 03 Apr 2006 19:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY7Y-0007uW-Bb for speermint@ietf.org; Mon, 03 Apr 2006 19:06:04 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQY7X-0002mK-2f for speermint@ietf.org; Mon, 03 Apr 2006 19:06:04 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18198113; Mon, 03 Apr 2006 19:05:39 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 19:05:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Reachability Date: Mon, 3 Apr 2006 19:05:26 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D67@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZXM2meCpG3+inMQJ66x1LR05n0CQAP5C4Q From: "Livingood, Jason" To: "Roy, Radhika R." , "Stastny Richard" , "Hadriel Kaplan" , X-OriginalArrivalTime: 03 Apr 2006 23:05:28.0323 (UTC) FILETIME=[1941B530:01C65773] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============2045222955==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============2045222955== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65773.1873825C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65773.1873825C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like we need to make some additions to the Terminology draft... ;-) =20 JL ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Monday, April 03, 2006 11:28 AM To: Stastny Richard; Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability =09 =09 I do not believe that there is any definition of public AoR per se. If AoR is resolved to a public IP address, we can then say that the physical address is public. Otherwise, it is private. Best regards, Radhika -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Monday, April 03, 2006 4:47 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability So what is the definition of a "public" (SIP) AoR? Any thoughts? Richard ------_=_NextPart_001_01C65773.1873825C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Speermint] Reachability
Sounds like we need to make some additions to = the=20 Terminology draft...  ;-)
 
JL

From: Roy, Radhika R.=20 [mailto:RADHIKA.R.ROY@saic.com]
Sent: Monday, April 03, = 2006 11:28=20 AM
To: Stastny Richard; Hadriel Kaplan;=20 speermint@ietf.org
Subject: RE: [Speermint]=20 Reachability

I do not=20 believe that there is any definition of public AoR per se. If AoR is = resolved=20 to a public IP address, we can then say that the physical address is=20 public. = Otherwise, it is = private.

Best=20 regards,

Radhika

-----Original Message-----
From: = speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.= org]=20 On Behalf Of Stastny Richard
Sent: Monday, April 03, 2006 4:47 = AM
To:=20 Hadriel Kaplan; speermint@ietf.org
Subject: RE: [Speermint]=20 Reachability



So what is=20 the definition of a "public" (SIP) AoR?


Any=20 thoughts?

Richard



------_=_NextPart_001_01C65773.1873825C-- --===============2045222955== 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 --===============2045222955==-- From speermint-bounces@ietf.org Mon Apr 03 19:10:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYBa-0000yq-A1; Mon, 03 Apr 2006 19:10:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYBZ-0000yl-0p for speermint@ietf.org; Mon, 03 Apr 2006 19:10:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQYBX-0002uo-Mx for speermint@ietf.org; Mon, 03 Apr 2006 19:10:13 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2006 19:10:12 -0400 X-IronPort-AV: i="4.03,160,1141621200"; d="scan'208"; a="85616480:sNHT31406464" 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 k33NABVW000630; Mon, 3 Apr 2006 19:10:11 -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.211); Mon, 3 Apr 2006 19:10: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 Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Mon, 3 Apr 2006 19:10:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3014A39DA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIwAAQkfIAAA96bcAAJ1vQQ From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" X-OriginalArrivalTime: 03 Apr 2006 23:10:11.0241 (UTC) FILETIME=[C1E39190:01C65773] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Hadriel, Some folks think that SBC's are supposed to be transparent, but what I think you are pointing out is that SBCs may already do some degree of peering and thus any new peering requirements represent a backwards compatibility problem for you, but perhaps also an opportunity for the IETF to mine lessons learned. Mike > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, April 03, 2006 5:19 PM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) >=20 > Hi Michael, > That's a good point, and I'm not suggesting otherwise. I=20 > think there may be confusion about my email which I would=20 > like to clear up. I have no doubt product X (proxies, SBCs,=20 > whatever) would be changed to support a peering=20 > specification, if their customers wished it. It is, in fact,=20 > why I joined this list! :) >=20 > However, I am responding to Brian's question, which may be=20 > important (or > not) to WG members regarding the work of this WG. I am NOT=20 > suggesting devices (including SBCs) won't change specific=20 > things for this work. Brian > asked: "should we care about them when thinking about this=20 > work?" So my response was: it depends. There is a large=20 > installed base, which does things for various reasons, so in=20 > my opinion we could hit issues if we do not to take that into=20 > account. We should support either model, so that the=20 > applicability of Speermint is as broad as possible. Since=20 > the charter currently overlaps functions that SBCs do today,=20 > it would, in my opinion, be less useful if the resulting work=20 > did not "care about them when doing this work". That's all. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, April 03, 2006 12:34 PM > > To: Medhavi Bhatia; Livingood, Jason; Hadriel Kaplan > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > >=20 > > I agree. Let's not get the tail wagging the dog here. > >=20 > > Product X needs to support the peering specification, not=20 > vice versa. > >=20 > > Mike > >=20 > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 00:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQd4E-0000q8-JM; Tue, 04 Apr 2006 00:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQd4D-0000pB-8g for speermint@ietf.org; Tue, 04 Apr 2006 00:22:57 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQd4B-0000CB-S0 for speermint@ietf.org; Tue, 04 Apr 2006 00:22:57 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 00:22:55 -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] Speermint Charter (now re SBCs) Date: Tue, 4 Apr 2006 00:22:44 -0400 Message-ID: <8812D8156467224C9E9739E513037EF151824C@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter (now re SBCs) thread-index: AcZXT81CBkQCunEKRICD6oCCytkICwATdFhA From: "Medhavi Bhatia" To: "David Meyer" X-OriginalArrivalTime: 04 Apr 2006 04:22:55.0343 (UTC) FILETIME=[722A4FF0:01C6579F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: speermint@ietf.org, "Livingood, Jason" 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 addition, the role of federations and IXPs needs to be well > > documented since that affects the technology we develop or use. >=20 > Do you think we need to add terminology (to the > terminology draft) for these last 2? >=20 > Dave >=20 Yes, I think that would be a good idea. We need the use cases documented as well. -Medhavi.=20 >=20 > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, April 03, 2006 8:41 AM > > > To: Hadriel Kaplan > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > > > > > > > > > To your question of "does it matter if they go through SBCs > > > > for our work?" > > > > So, to your actual question: it depends. If the end goal of > > > > this WG is to define BCPs of call flows for peering, then > > > > that's easy: someone can just send an ethereal trace. :) If > > > > it's to define best future (vs. > > > > current/common) practices, then yes it may hit issues if the > > > > reality (from my perspective) isn't taken into account. It's > > > > like talking about IP peering without acknowledging routers > > > > exist. The irony from my perspective is what SBCs do > > > > "differently" is used by many for very valuable > > > > peering-related benefits. > > > > > > I suspect this issue will continue to arise every so often as it has > > > before (which is okay, by the way; continued discussion is generally a > > > signal of a lack of consensus). IMHO, the architecture and BCPs > > > proposed will need to show how you can do SIP peering without and with > > > session border elements. There are some domains that will not want to > > > use them, and some that will want to use them. And even where a > > domain > > > prefers to use such an element, it may be application-specific such > > that > > > it is perhaps used for SIP-VoIP but not for SIP-IM. > > > > > > Anyway, I think the point is that I don't expect we'll try to dictate > > > that session border elements absolutely must or must not be used. For > > > some domains with particular requirements (business, IP networking, IP > > > addressing, whatever), for some applications, such elements may make > > > sense and may be considered. For those that feel strongly about the > > > fact that use of such elements are not a good trend, we should be able > > > to spell out how a domain can meet all of their requirements and > > deploy > > > a SIP peering architecture without them if they so choose (and so > > we'll > > > ask for your constructive assistance on such work). Thus, we first > > > describe requirements, then we describe all of the different > > > architecture options that would accomodate those requirements, and > > then > > > implementers better understand all of the issues and can make > > decisions > > > based on this expert information as well as their own particular > > needs. > > > > > > Jason > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: > > 3/31/2006 > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.4/299 - Release Date: 3/31/2006 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 01:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeDL-000591-NE; Tue, 04 Apr 2006 01:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeDF-00056B-4O for speermint@ietf.org; Tue, 04 Apr 2006 01:36:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQeDD-0002iR-OP for speermint@ietf.org; Tue, 04 Apr 2006 01:36:21 -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] Reachability Date: Tue, 4 Apr 2006 07:38:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4960@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZXM+JLHVVvEcjHSxWYUtkcQE0YUwAdhTcs From: "Stastny Richard" To: "Roy, Radhika R." , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 do not believe that there is any definition of public AoR per se. If = AoR is resolved to a public IP address, we can then say >that the = physical address is public. Otherwise, it is private. I do not completely understand this. Do you mean the IP address of the = proxy, or the IP address of the end-device? Richard =20 ________________________________ Von: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] Gesendet: Mo 03.04.2006 17:28 An: Stastny Richard; Hadriel Kaplan; speermint@ietf.org Betreff: RE: [Speermint] Reachability I do not believe that there is any definition of public AoR per se. If = AoR is resolved to a public IP address, we can then say that the = physical address is public. Otherwise, it is private. Best regards, Radhika -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On = Behalf Of Stastny Richard Sent: Monday, April 03, 2006 4:47 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability So what is the definition of a "public" (SIP) AoR? Any thoughts? Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 01:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeTl-0005j6-EG; Tue, 04 Apr 2006 01:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeTj-0005Xb-Nd for speermint@ietf.org; Tue, 04 Apr 2006 01:53:23 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQeJ5-0002qq-3m for speermint@ietf.org; Tue, 04 Apr 2006 01:42:24 -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] Speermint Charter Date: Tue, 4 Apr 2006 07:42:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4961@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Speermint Charter Thread-Index: AcZXjZM/k0nGMtjyR7W8dNVUpgnqwQAHQ4eH From: "Stastny Richard" To: "Scott W Brim" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Khan, Sohel Q \[CTO\]" , 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 >P2P SIP is about connecting participants, >while Speermint is about connecting services. No? But the P2P connected participants, e.g. a small enterprise may want to connect to the rest of the world. And also speermint is not only about services (servive providers) also enterprises may prarticipate And since we do not care how the sip network within the enterprise is organized, it could be client server SIP or P2P Richard ________________________________ Von: Scott W Brim [mailto:swb@employees.org] Gesendet: Di 04.04.2006 04:10 An: Stastny Richard Cc: Khan, Sohel Q [CTO]; speermint@ietf.org Betreff: Re: [Speermint] Speermint Charter On 03/30/2006 15:34 PM, Stastny Richard allegedly wrote: > Hi Sohel, >=20 > This is no so simple >=20 > 1. P2P SIP has a complete different charter > 2. What if a P2P network is provided by a provider who wants to peer > with another provider? >=20 > Richard Unless I'm mistaken this is fairly straightforward. The key is "provider". Speermint is about peering arrangements between provided SIP services (inter-domain, inter-carrier, whatever). P2P SIP is about establishing connectivity between SIP users. What does it mean to "provide" a P2P network? Perhaps it means establishing some seeds for a Chord ring, but communication between P2P SIP participants does not have to be via provided servers. P2P SIP is about connecting participants, while Speermint is about connecting services. No? swb _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 02:16:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQepO-0008FQ-Md; Tue, 04 Apr 2006 02:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQepN-0008FL-NB for speermint@ietf.org; Tue, 04 Apr 2006 02:15:45 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQepM-0004Fp-Da for speermint@ietf.org; Tue, 04 Apr 2006 02:15:45 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AF0901F8; Tue, 04 Apr 2006 02:15:37 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] Speermint Charter (now re SBCs) Date: Tue, 4 Apr 2006 02:15:43 -0400 Message-ID: <040301c657af$348013a0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZTc0ki9A+BtnaxSKeHcJ+7zeOdWgANDhDgAAKbS1AAGKKwIAAH2a9AAAFcWhgAABUzUAAA5l7xAACSADAAAU5QAgAAn6HwACXoP4AAjtbF0AAEVTIwAAQkfIAAA96bcAAJ1vQQAACRdxA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3014A39DA@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 Mike, Yes, I have heard that question from several people recently, much to my surprise. The term "SBC" is defined by the vendors, and it doesn't always mean the same thing these days, but I don't know of any SBC vendors in the service provider space who are "transparent". (And I know most of them) They are not firewalls. They are an addressed entity from all "sides", and they typically appear as a B2BUA, depending on who makes it and how they're deployed. But no, any new requirements don't represent a backwards-compatibility problem for me. If the WG adds new requirements my guess is any SBC vendor would implement them, if their customers wanted them to and it was technically sound. If you want to peer across to the current ones, then obviously it could be an issue. I'm not saying everyone uses them, but it's pervasive enough that if you cross more than one provider the odds are very high. (which is why I said the multi-provider issue is more interesting personally, in another email) There are some things SBCs do which have intrinsic value to those operators, and thus there are some facets which cannot be changed and would be fruitless to mandate against, IMHO. They are not, as some people think, used to block reachability of users to the Internet. They are in many ways the inverse. So I agree with Jason that the best model would be one which encompassed all of the ways. And that was my point as well. :) -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, April 03, 2006 7:10 PM > To: Hadriel Kaplan > Cc: speermint@ietf.org > Subject: RE: [Speermint] Speermint Charter (now re SBCs) > > Hadriel, > > Some folks think that SBC's are supposed to be transparent, but what I > think you are pointing out is that SBCs may already do some degree of > peering and thus any new peering requirements represent a backwards > compatibility problem for you, but perhaps also an opportunity for the > IETF to mine lessons learned. > > Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 02:16:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQeqW-0000dd-AE; Tue, 04 Apr 2006 02:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQenD-0007IW-5c for speermint@ietf.org; Tue, 04 Apr 2006 02:13:31 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQeaf-0003Xv-PU for speermint@ietf.org; Tue, 04 Apr 2006 02:00:35 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AB7F036C; Tue, 04 Apr 2006 02:00:31 -0400 From: "Hadriel Kaplan" To: "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 02:00:37 -0400 Message-ID: <040001c657ad$187e31c0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQ In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5CE@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 Hi Reinaldo, Comments inline... > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Maybe I'm missing something, but given that this workgroup is interested > only in call routing (E.164 is out of scope), do we really need to care > about that? An AoR in the end will be translated to an IP address, and > IP addresses have a very good definition of public and private (in IPv4 > and IPv6). I don't understand fully what you mean. An AoR is only fully "translated" to an IP Address (and really to a contact URI) by the AoR's domain. So what you're saying is if the AoR's user-part represents a consumer behind a home NAT (a private IP), then it is a private AoR; but for those consumers who don't use home-NATs then it's a public AoR? And if the AoR gets translated into an IP by a registrar inside a private IP subnet, and somehow it later gets translated into the public IP address space, that's also private because the AoR was translated to a private IP originally? Or maybe you mean what the domain part of the AoR resolves to? > For you to be "SIP reachable", you need to be IP reachable first, let's > not forget about that. And if you are IP reachable, you could > potentially be SIP reachable by registering to some free SIP service (or > the SIP "domain" above you in the hierarchy...if this was the email/DNS > model). Actually, to be very specific ultimate target of the AoR can be "sip reachable" but not IP reachable. But I think for now we should ignore the implications of that, unless it becomes a problem. -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 03:51:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgK6-00059d-Tj; Tue, 04 Apr 2006 03:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgK6-00058F-7r for speermint@ietf.org; Tue, 04 Apr 2006 03:51:34 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQgK2-0000RH-O5 for speermint@ietf.org; Tue, 04 Apr 2006 03:51:34 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 09:55:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EA9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABTYcHA= From: "Stastny Richard" To: "Hadriel Kaplan" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Hadrian added some more details to my previous question. I would like to add more two issues: 1. A Public User Identity (i.e. a public AoR) is what the T-customers perceives what it is, or what he has been=20 sold. If I get an AoR with the remark I may put it on my business card (say like an E.164 number or a e-mail address), as 3GPP is explaining it, I assume the AoR to be "public". You do not put your internal extension of a PBX on your business without any further remark. 2. > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. A typical example of this would be a (non-transparent) SBC with a B2BUA. So we should ignore such beasts? Fine with me ;-) Richard > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, April 04, 2006 8:01 AM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Reinaldo, > Comments inline... >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). >=20 > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home > NAT (a private IP), then it is a private AoR; but for those consumers who > don't use home-NATs then it's a public AoR? And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private > because the AoR was translated to a private IP originally? >=20 > Or maybe you mean what the domain part of the AoR resolves to? >=20 > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). >=20 > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. >=20 > -hadriel >=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 Tue Apr 04 05:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhqv-0008Sv-31; Tue, 04 Apr 2006 05:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhqt-0008Sq-UY for speermint@ietf.org; Tue, 04 Apr 2006 05:29:31 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQhqt-0004Yh-Kl for speermint@ietf.org; Tue, 04 Apr 2006 05:29:31 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 04 Apr 2006 02:29:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,162,1141632000"; d="scan'208"; a="537707459:sNHT23964056" 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] Reachability Date: Tue, 4 Apr 2006 05:29:29 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5D7@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43A= From: "Reinaldo Penno" To: "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Reinaldo, > Comments inline... >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). >=20 > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home > NAT (a private IP), then it is a private AoR; but for those consumers who > don't use home-NATs then it's a public AoR?=20 [[Reinaldo]]=20 Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918).=20 This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her.=20 b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions?=20 If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo =20 And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private > because the AoR was translated to a private IP originally? >=20 > Or maybe you mean what the domain part of the AoR resolves to? >=20 > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). >=20 > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. >=20 > -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 09:29:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlah-0003kc-Ie; Tue, 04 Apr 2006 09:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlag-0003kW-Cs for speermint@ietf.org; Tue, 04 Apr 2006 09:29:02 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlag-0005Zd-1K for speermint@ietf.org; Tue, 04 Apr 2006 09:29:02 -0400 Received: from PMelampy [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A49B013C; Tue, 04 Apr 2006 09:28:59 -0400 From: "Patrick Melampy" To: "'Reinaldo Penno'" , "'Hadriel Kaplan'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 09:29:02 -0400 Message-ID: <012e01c657eb$bcd1b970$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcA== In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5D7@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Reinaldo -- I agree with your assertions. But I want to ensure everybody understands what your really saying here. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. This means that for carrier to carrier peering models, each and every customer of every carrier that wants to inter-connect needs to have a 'public NAT binding'. I believe by extension, this means that a serving proxy/registrar for the target of a communication must ALSO have either a public address or a public NAT binding. The conclusion here -- every endpoint and every serving proxy/registrar needs to be publicly addressable. Am I correct? -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, April 04, 2006 5:29 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hi Reinaldo, > Comments inline... > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). > > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home > NAT (a private IP), then it is a private AoR; but for those consumers who > don't use home-NATs then it's a public AoR? [[Reinaldo]] Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918). This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions? If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private > because the AoR was translated to a private IP originally? > > Or maybe you mean what the domain part of the AoR resolves to? > > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). > > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. > > -hadriel _______________________________________________ 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 Apr 04 10:45:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmmE-0006T9-NX; Tue, 04 Apr 2006 10:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmmD-0006S3-9k for speermint@ietf.org; Tue, 04 Apr 2006 10:45:01 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmmB-0000zU-Tq for speermint@ietf.org; Tue, 04 Apr 2006 10:45:01 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k34EiwI3032020; Tue, 4 Apr 2006 07:44:58 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k34EiwD7032019; Tue, 4 Apr 2006 07:44:58 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 4 Apr 2006 07:44:58 -0700 From: David Meyer To: Medhavi Bhatia Subject: Re: [Speermint] Speermint Charter (now re SBCs) Message-ID: <20060404144458.GA32012@1-4-5.net> References: <8812D8156467224C9E9739E513037EF151824C@moe.nextone.local> Mime-Version: 1.0 In-Reply-To: <8812D8156467224C9E9739E513037EF151824C@moe.nextone.local> 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: speermint@ietf.org, "Livingood, Jason" 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="===============1215812495==" Errors-To: speermint-bounces@ietf.org --===============1215812495== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 04, 2006 at 12:22:44AM -0400, Medhavi Bhatia wrote: > > > > > > In addition, the role of federations and IXPs needs to be well > > > documented since that affects the technology we develop or use. > >=20 > > Do you think we need to add terminology (to the > > terminology draft) for these last 2? > >=20 > > Dave > >=20 >=20 > Yes, I think that would be a good idea. We need the use cases documented > as well. OK, in the queue. Dave --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEMoZqORgD1qCZ2KcRAt4XAJ9ANug18OqUn+gFeBG7gvLlA3r02QCfaT9F XgMpj4W+nsA43r6z6i6ayfE= =0mue -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- --===============1215812495== 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 --===============1215812495==-- From speermint-bounces@ietf.org Tue Apr 04 11:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQn1p-0005Qd-CM; Tue, 04 Apr 2006 11:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQn1n-0005QG-03 for speermint@ietf.org; Tue, 04 Apr 2006 11:01:07 -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 1FQm8j-0007Br-Nb for speermint@ietf.org; Tue, 04 Apr 2006 10:04:13 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FQlvn-0001kl-Ie for speermint@ietf.org; Tue, 04 Apr 2006 09:50:53 -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] Reachability Date: Tue, 4 Apr 2006 15:54:51 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4964@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyq From: "Stastny Richard" To: "Patrick Melampy" , "Reinaldo Penno" , "Hadriel Kaplan" , X-Spam-Score: -2.0 (--) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 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 conclusion here -- every endpoint and every serving proxy/registrar >needs to be publicly addressable. This was my basic assumption, and I seemed not so clear to everybody. This was also why I had a problem with Sohel's presentation at the IETF, because I did not see any public adressable entities AT ALL. =20 For the avoidance of doubt: I have no problem if the same peering principles we develop here are used between some entities in a private = network, but it is not out task to consider this separately. Because if it works on the Internet, it also works in a private network (extranet in this = case) (see DNS). this private network may even use public IP adresses, but if = the are not routable from the public Internet, they are could as well be = private (example IPX) =20 What never can work is a peering between one entity on the public = network and one on a private network. The private entities need at least to have = one ingress element on the public network =20 Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Di 04.04.2006 15:29 An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Reinaldo -- I agree with your assertions. But I want to ensure everybody understands what your really saying here. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from = the public side can be made to him/her. This means that for carrier to carrier peering models, each and every customer of every carrier that wants to inter-connect needs to have a 'public NAT binding'. I believe by extension, this means that a serving proxy/registrar for = the target of a communication must ALSO have either a public address or a = public NAT binding. The conclusion here -- every endpoint and every serving proxy/registrar needs to be publicly addressable. Am I correct? -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, April 04, 2006 5:29 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hi Reinaldo, > Comments inline... > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). > > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home > NAT (a private IP), then it is a private AoR; but for those consumers who > don't use home-NATs then it's a public AoR? [[Reinaldo]] Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918). This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions? If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private > because the AoR was translated to a private IP originally? > > Or maybe you mean what the domain part of the AoR resolves to? > > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). > > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. > > -hadriel _______________________________________________ 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 Apr 04 11:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnHu-0006ws-QF; Tue, 04 Apr 2006 11:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnHu-0006wm-BO for speermint@ietf.org; Tue, 04 Apr 2006 11:17:46 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnHt-0002jD-PR for speermint@ietf.org; Tue, 04 Apr 2006 11:17:46 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 051EC6AA36B; Tue, 4 Apr 2006 15:17:45 +0000 (UTC) Received: from mail82-cpk-R.bigfish.com (unknown [192.168.21.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 0361C6AA0A4; Tue, 4 Apr 2006 15:17:45 +0000 (UTC) Received: from mail82-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail82-cpk-R.bigfish.com (Postfix) with ESMTP id E27A93FC8DB; Tue, 4 Apr 2006 15:17:44 +0000 (UTC) X-BigFish: V Received: by mail82-cpk (MessageSwitch) id 1144163864777334_27309; Tue, 4 Apr 2006 15:17:44 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail82-cpk.bigfish.com (Postfix) with ESMTP id 81C383FCC27; Tue, 4 Apr 2006 15:17:44 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k34FHh5l001380; Tue, 4 Apr 2006 10:17:43 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k34FHfc15868; Tue, 4 Apr 2006 10:17:41 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 10:17:41 -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] Reachability Date: Tue, 4 Apr 2006 10:17:40 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E072377FF@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAD2pHw From: "Khan, Sohel Q [CTO]" To: "Patrick Melampy" , "Reinaldo Penno" , "Hadriel Kaplan" , X-OriginalArrivalTime: 04 Apr 2006 15:17:41.0544 (UTC) FILETIME=[EA90DA80:01C657FA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 If you ar saying that "every endpoint and every serving proxy/registrar needs to be publicly addressable through the "public NAT binding"', then it is okay.=20 -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 Sent: Tuesday, April 04, 2006 8:29 AM To: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org Subject: RE: [Speermint] Reachability Reinaldo -- I agree with your assertions. But I want to ensure everybody understands what your really saying here. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. This means that for carrier to carrier peering models, each and every customer of every carrier that wants to inter-connect needs to have a 'public NAT binding'.=20 I believe by extension, this means that a serving proxy/registrar for the target of a communication must ALSO have either a public address or a public NAT binding. The conclusion here -- every endpoint and every serving proxy/registrar needs to be publicly addressable. Am I correct? -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, April 04, 2006 5:29 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Reinaldo, > Comments inline... >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). >=20 > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home NAT (a private IP), then it is a private AoR; but for those=20 > consumers who > don't use home-NATs then it's a public AoR?=20 [[Reinaldo]]=20 Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918).=20 This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her.=20 b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions?=20 If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo =20 And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private=20 > because the AoR was translated to a private IP originally? >=20 > Or maybe you mean what the domain part of the AoR resolves to? >=20 > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could=20 > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). >=20 > Actually, to be very specific ultimate target of the AoR can be "sip=20 > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. >=20 > -hadriel _______________________________________________ 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 Apr 04 11:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnOb-0002Jc-2F; Tue, 04 Apr 2006 11:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnOa-0002JX-5C for speermint@ietf.org; Tue, 04 Apr 2006 11:24:40 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnOZ-000318-N8 for speermint@ietf.org; Tue, 04 Apr 2006 11:24:40 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 284976A91C4; Tue, 4 Apr 2006 15:24:39 +0000 (UTC) Received: from mail4-cpk-R.bigfish.com (unknown [192.168.21.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 251AC6A88A0; Tue, 4 Apr 2006 15:24:39 +0000 (UTC) Received: from mail4-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-cpk-R.bigfish.com (Postfix) with ESMTP id 0DB43477CA8; Tue, 4 Apr 2006 15:24:39 +0000 (UTC) X-BigFish: V Received: by mail4-cpk (MessageSwitch) id 1144164278959084_8317; Tue, 4 Apr 2006 15:24:38 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail4-cpk.bigfish.com (Postfix) with ESMTP id C7C6C477C8D; Tue, 4 Apr 2006 15:24:38 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k34FOc5l013982; Tue, 4 Apr 2006 10:24:38 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k34FOYc20162; Tue, 4 Apr 2006 10:24:35 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 10:24:34 -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] Reachability Date: Tue, 4 Apr 2006 10:24:33 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E0723782E@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABTYcHAAD9+kcA== From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" , "Hadriel Kaplan" , "Reinaldo Penno" , X-OriginalArrivalTime: 04 Apr 2006 15:24:34.0722 (UTC) FILETIME=[E0D6D020:01C657FB] X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 >1. A Public User Identity (i.e. a public AoR) is what the T-customers perceives what it is, or what he has been sold. >If I get an AoR with the remark I may put it on my business card (say like an E.164 number or a e-mail address), as >3GPP is explaining it, I assume the AoR to be "public". =20 I agree.=20 But, we have to ensure that private network topology can be hidden and appropriate security mechansim is placed on the border. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 2:56 AM To: Hadriel Kaplan; Reinaldo Penno; speermint@ietf.org Subject: RE: [Speermint] Reachability Hadrian added some more details to my previous question. I would like to add more two issues: 1. A Public User Identity (i.e. a public AoR) is what the T-customers perceives what it is, or what he has been sold. If I get an AoR with the remark I may put it on my business card (say like an E.164 number or a e-mail address), as 3GPP is explaining it, I assume the AoR to be "public". You do not put your internal extension of a PBX on your business without any further remark. 2. > Actually, to be very specific ultimate target of the AoR can be "sip=20 > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. A typical example of this would be a (non-transparent) SBC with a B2BUA. So we should ignore such beasts? Fine with me ;-) Richard > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Tuesday, April 04, 2006 8:01 AM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Reinaldo, > Comments inline... >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). >=20 > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home NAT (a private IP), then it is a private AoR; but for those=20 > consumers who > don't use home-NATs then it's a public AoR? And if the AoR gets=20 > translated into an IP by a registrar inside a private IP subnet, and=20 > somehow it later > gets translated into the public IP address space, that's also private=20 > because the AoR was translated to a private IP originally? >=20 > Or maybe you mean what the domain part of the AoR resolves to? >=20 > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could=20 > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). >=20 > Actually, to be very specific ultimate target of the AoR can be "sip=20 > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. >=20 > -hadriel >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 11:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnYq-0005OE-1o; Tue, 04 Apr 2006 11:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnYo-0005LW-Gv for speermint@ietf.org; Tue, 04 Apr 2006 11:35:14 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnYo-0003bn-5y for speermint@ietf.org; Tue, 04 Apr 2006 11:35:14 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id BCFA36A9ACA; Tue, 4 Apr 2006 15:14:34 +0000 (UTC) Received: from mail12-cpk-R.bigfish.com (unknown [192.168.21.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id BB51C6748FD; Tue, 4 Apr 2006 15:14:34 +0000 (UTC) Received: from mail12-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail12-cpk-R.bigfish.com (Postfix) with ESMTP id A170B43CA32; Tue, 4 Apr 2006 15:14:34 +0000 (UTC) X-BigFish: V Received: by mail12-cpk (MessageSwitch) id 1144163674588081_3196; Tue, 4 Apr 2006 15:14:34 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail12-cpk.bigfish.com (Postfix) with ESMTP id 6D93A43E584; Tue, 4 Apr 2006 15:14:34 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k34FEX5l024807; Tue, 4 Apr 2006 10:14:33 -0500 (CDT) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k34FETc26582; Tue, 4 Apr 2006 10:14:30 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 10:14:29 -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] Reachability Date: Tue, 4 Apr 2006 10:14:28 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E072377DD@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAALpLpA= From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" , "Patrick Melampy" , "Reinaldo Penno" , "Hadriel Kaplan" , X-OriginalArrivalTime: 04 Apr 2006 15:14:29.0904 (UTC) FILETIME=[7856E900:01C657FA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 =20 >>The conclusion here -- every endpoint and every serving proxy/registrar=20 >>needs to be publicly addressable. I do not agree. Every endpoint or every serving proxy/registrart may or may NOT be publicly addressable. ... >What never can work is a peering between one entity on the public network and one on a private network.=20 >The private entities need at least to have one ingress element on the public network Here, I agree.=20 At least one ingress element of a private network may be publicly addressable. Sohel =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 12:01:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnyb-0000XM-CS; Tue, 04 Apr 2006 12:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnya-0000V2-HZ for speermint@ietf.org; Tue, 04 Apr 2006 12:01:52 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQnyZ-0004sL-Sk for speermint@ietf.org; Tue, 04 Apr 2006 12:01: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] Reachability Date: Tue, 4 Apr 2006 18:05:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4966@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAD2pHwAAF5msY= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" , "Patrick Melampy" , "Reinaldo Penno" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 Sohel, =20 I think we are slowly converging here ;-) =20 but I think we have still to clarify some issues: =20 In the SIP trapezoid (if we forget for a moment "transit" peers) we have O-UA - O-Core proxy - T-Core proxy - T-UA =20 >From the point of the O-Core the T-Core has always to be public and = before the NAT, or do you mean the in first Ingress proxy can also be behind a = NAT? (there may be others behind the NAT) =20 The T-UA may of course be behind the NAT (with a binding) =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Di 04.04.2006 17:17 An: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org Betreff: RE: [Speermint] Reachability If you ar saying that "every endpoint and every serving proxy/registrar needs to be publicly addressable through the "public NAT binding"', then it is okay. -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Tuesday, April 04, 2006 8:29 AM To: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org Subject: RE: [Speermint] Reachability Reinaldo -- I agree with your assertions. But I want to ensure everybody understands what your really saying here. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. This means that for carrier to carrier peering models, each and every customer of every carrier that wants to inter-connect needs to have a 'public NAT binding'. I believe by extension, this means that a serving proxy/registrar for the target of a communication must ALSO have either a public address or a public NAT binding. The conclusion here -- every endpoint and every serving proxy/registrar needs to be publicly addressable. Am I correct? -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, April 04, 2006 5:29 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hi Reinaldo, > Comments inline... > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). > > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home NAT (a private IP), then it is a private AoR; but for those > consumers who > don't use home-NATs then it's a public AoR? [[Reinaldo]] Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918). This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions? If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private > because the AoR was translated to a private IP originally? > > Or maybe you mean what the domain part of the AoR resolves to? > > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). > > Actually, to be very specific ultimate target of the AoR can be "sip > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. > > -hadriel _______________________________________________ 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 Tue Apr 04 12:02:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnzG-00019a-8Z; Tue, 04 Apr 2006 12:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnzE-00017c-Sm for speermint@ietf.org; Tue, 04 Apr 2006 12:02:32 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnzE-0004up-JK for speermint@ietf.org; Tue, 04 Apr 2006 12:02:32 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A8960290; Tue, 04 Apr 2006 12:02:30 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 12:02:37 -0400 Message-ID: <04cc01c65801$31c12170$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABTYcHAADx94oA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EA9@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Richard, Comments inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 3:56 AM > To: Hadriel Kaplan; Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > 1. A Public User Identity (i.e. a public AoR) is what > the T-customers perceives what it is, or what he has been > sold. > > If I get an AoR with the remark I may put it on > my business card (say like an E.164 number or a > e-mail address), as 3GPP is explaining it, > I assume the AoR to be "public". You do > not put your internal extension of a PBX on > your business without any further remark. That's not for me to say, I'm not in legal. But I wonder, if you put a private extension on your business card and don't add extra words, does it now mean it has to be publicly reachable, simply because you or your card printer made a mistake? ;) Again, I think operators want to make the AoR's reachable publicly, by the very fact this working group exists. Who the AoR belongs to, or which portion of it, is a legal issue I know nothing about. > 2. > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > A typical example of this would be a (non-transparent) SBC with > a B2BUA. So we should ignore such beasts? > > Fine with me ;-) I'm not sure how you meant it, but that is NOT the typical example at all, and a common misconception I think; SBCs don't block IP reachability. The very fact that the SBC is not "transparent" as a firewall makes it virtually impossible for the SBC to do, and it's not what the operators of SBCs typically wish to do. The only thing that could do such a thing in a service provider infrastructure typically is a router. So are they now evil beasts in the IETF's eyes? :) What SBCs do is _enable_ reachability. If the operator didn't want reachability they'd simply pull the plugs. It could be that the user's UA is behind a NAT, and in that sense they're not IP reachable and it's true an SBC can make them so through SIP, but in theory the UA could make themselves so with STUN/ICE. (in some ways such an SBC is a TURN server from a media perspective, but it just uses the SIP signaling to do TURN instead of a new protocol) Providing NAT traversal is not the main reason SBCs are used, typically. It could also be that there is a privately-addressed IP VPN of SIP nodes, and the SBC enables them to communicate out and be reachable from the outside. So if you meant it that way, then yes, an SBC enables you to reach an AoR target in case you don't have IP reachability. But from the aspects of the AoR resolving to an IP (whatever that means) which was the context of the discussion, we should be able to ignore that piece. :) -Hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 12:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoGK-0001Mi-9E; Tue, 04 Apr 2006 12:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoGI-0001Md-En for speermint@ietf.org; Tue, 04 Apr 2006 12:20:10 -0400 Received: from outbound-kan.frontbridge.com ([63.161.60.23] helo=outbound2-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoGG-0005WR-SB for speermint@ietf.org; Tue, 04 Apr 2006 12:20:10 -0400 Received: from outbound2-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-kan-R.bigfish.com (Postfix) with ESMTP id 6E3983E9884; Tue, 4 Apr 2006 16:20:06 +0000 (UTC) Received: from mail47-kan-R.bigfish.com (unknown [172.18.7.1]) by outbound2-kan.bigfish.com (Postfix) with ESMTP id 6C7653E95CB; Tue, 4 Apr 2006 16:20:06 +0000 (UTC) Received: from mail47-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail47-kan-R.bigfish.com (Postfix) with ESMTP id 6076321C7C2; Tue, 4 Apr 2006 16:20:06 +0000 (UTC) X-BigFish: V Received: by mail47-kan (MessageSwitch) id 1144167606237735_3767; Tue, 4 Apr 2006 16:20:06 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail47-kan.bigfish.com (Postfix) with ESMTP id 31B9521BD20; Tue, 4 Apr 2006 16:20:06 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k34GK55l020996; Tue, 4 Apr 2006 11:20:05 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k34GK3027509; Tue, 4 Apr 2006 11:20:03 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:20:03 -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] Reachability Date: Tue, 4 Apr 2006 11:20:01 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E072379CE@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAD2pHwAAF5msYAAEKOkA== From: "Khan, Sohel Q [CTO]" To: "Stastny Richard" , "Patrick Melampy" , "Reinaldo Penno" , "Hadriel Kaplan" , X-OriginalArrivalTime: 04 Apr 2006 16:20:03.0103 (UTC) FILETIME=[A0B572F0:01C65803] X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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, phone numbers whether it is (***)-***-**** format or an e-mail format is publicly reachable. However, provider's networks are private. It is for security and regulations. To make end-users publicly reachable at least one network entity of a provider may have a public address.=20 These public network entity most probably is the peering interface with others.=20 It may look like this: Acore peer interface|<-----public---->|Bcore peer interface But, there need to have something like this also: Acore peer interface|<----private---->|Bcore peer interface Although, you can say why IETF should work on this?=20 Please understand that implementations may be almost the same and in both cases providers will use IETF RFCs. Question is how the second case users will be reachable by public? Here is how: Acore peer interface|<----private---->|Bcore peer interface|<----public---->|Ccore peer interface I hope, it makes sense.. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 11:06 AM To: Khan, Sohel Q [CTO]; Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Sohel, =20 I think we are slowly converging here ;-) =20 but I think we have still to clarify some issues: =20 In the SIP trapezoid (if we forget for a moment "transit" peers) we have O-UA - O-Core proxy - T-Core proxy - T-UA =20 >From the point of the O-Core the T-Core has always to be public and=20 >before the NAT, or do you mean the in first Ingress proxy can also be behind a NAT? (there may be others behind the NAT) =20 The T-UA may of course be behind the NAT (with a binding) =20 Richard ________________________________ Von: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] Gesendet: Di 04.04.2006 17:17 An: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org Betreff: RE: [Speermint] Reachability If you ar saying that "every endpoint and every serving proxy/registrar needs to be publicly addressable through the "public NAT binding"', then it is okay. -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Tuesday, April 04, 2006 8:29 AM To: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org Subject: RE: [Speermint] Reachability Reinaldo -- I agree with your assertions. But I want to ensure everybody understands what your really saying here. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. This means that for carrier to carrier peering models, each and every customer of every carrier that wants to inter-connect needs to have a 'public NAT binding'. I believe by extension, this means that a serving proxy/registrar for the target of a communication must ALSO have either a public address or a public NAT binding. The conclusion here -- every endpoint and every serving proxy/registrar needs to be publicly addressable. Am I correct? -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Tuesday, April 04, 2006 5:29 AM To: Hadriel Kaplan; speermint@ietf.org Subject: RE: [Speermint] Reachability Hello Hadriel, Comment inline.... > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, April 03, 2006 11:01 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hi Reinaldo, > Comments inline... > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Maybe I'm missing something, but given that this workgroup is interested > > only in call routing (E.164 is out of scope), do we really need to care > > about that? An AoR in the end will be translated to an IP address, and > > IP addresses have a very good definition of public and private (in IPv4 > > and IPv6). > > I don't understand fully what you mean. An AoR is only fully "translated" > to an IP Address (and really to a contact URI) by the AoR's domain. So > what > you're saying is if the AoR's user-part represents a consumer behind a > home NAT (a private IP), then it is a private AoR; but for those=20 > consumers who > don't use home-NATs then it's a public AoR? [[Reinaldo]] Hello, Actually I'm trying to understand the whole purpose of the discussion, that's why I gave that example. I was trying to understand why it matters, before getting knee deep into the classification. Can someone refresh that for me? So, if SIP peering is going to get woven into the fabric of the internet, the rules for domains names, DNS resolution, private vs. public IP address, etc should apply, right? I believe the current model of host to host or email communication is not different for SIP. We could have the following main situations...(correct me where I'm wrong). 1) The AoR (just like a traditional domain name or email), in the end will get resolved into an IP address. Then there are only two situations. a) the IP address is private (RFC 1918). This means the SIP endpoint is unreachable unless you are also in the same private network. Actually I believe a private IP address cannot even be provisioned in a public DNS. Before somebody mentions it...for a UA behind a NAT to be reachable, he/she needs a public NAT binding so that a session _initiated_ from the public side can be made to him/her. b) the IP address is public. The SIP endpoint is theoretically reachable. 2) The AoR cannot get translated. Again, just like the Internet we have today, this means the domain name/user is private, does not exist, etc All this has been happening okay with just a few basic rules. If an AoR is very similar to an email address, why it would not work with the current infrastructure/definitions? If somebody says that they have a "private" email address or domain name, what is your interpretation of that? Regards, Reinaldo And if the AoR gets > translated > into an IP by a registrar inside a private IP subnet, and somehow it later > gets translated into the public IP address space, that's also private=20 > because the AoR was translated to a private IP originally? > > Or maybe you mean what the domain part of the AoR resolves to? > > > For you to be "SIP reachable", you need to be IP reachable first, let's > > not forget about that. And if you are IP reachable, you could=20 > > potentially be SIP reachable by registering to some free SIP service (or > > the SIP "domain" above you in the hierarchy...if this was the email/DNS > > model). > > Actually, to be very specific ultimate target of the AoR can be "sip=20 > reachable" but not IP reachable. But I think for now we should ignore the > implications of that, unless it becomes a problem. > > -hadriel _______________________________________________ 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 Tue Apr 04 12:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoIh-0002K3-6y; Tue, 04 Apr 2006 12:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoIg-0002Jo-Ef for speermint@ietf.org; Tue, 04 Apr 2006 12:22:38 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoIg-0005d5-04 for speermint@ietf.org; Tue, 04 Apr 2006 12:22:38 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AD4C01AC; Tue, 04 Apr 2006 12:22:36 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Patrick Melampy'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 12:22:43 -0400 Message-ID: <04d001c65804$003c8ec0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4964@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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 Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Apr 04 12:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQocM-00016z-3M; Tue, 04 Apr 2006 12:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQocK-000165-Il for speermint@ietf.org; Tue, 04 Apr 2006 12:42:56 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQocJ-0006aG-HQ for speermint@ietf.org; Tue, 04 Apr 2006 12:42:56 -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] Reachability Date: Tue, 4 Apr 2006 18:45:00 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4968@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQ== From: "Stastny Richard" To: "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 >Most consumers on the planet Earth are in private address spaces at = this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. = Entire >networks in some countries are privately addressed, yet they are = members of, >and use, the Internet. =20 =20 Yes, but if you put your mailserver only in 192.168.x.x, you will get a = problem =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; = speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be = publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with = allowing, enabling, and inter-working private address spaces and VPNs. What's = missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself.=20 Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. = Entire networks in some countries are privately addressed, yet they are members = of, and use, the Internet. There are also now 2 disjoint address groups = defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress = (and egress) point(s), either on the public network for it to be public, or = for it to cross into another private address domain. For this WG's purpose, = I recommend we allow either model to work, as well as the model of the = private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; = speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving = proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the = IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it = works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but = if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public = network > and one on a private network. The private entities need at least to = have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying = here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from = the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for = the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving = proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind = a > > home > > NAT (a private IP), then it is a private AoR; but for those = consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in = the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be = reachable, > he/she needs a public NAT binding so that a session _initiated_ from = the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we = have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an = AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also = private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP = service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should = ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Apr 04 13:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoxS-0005ck-9E; Tue, 04 Apr 2006 13:04:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoxR-0005ZW-2c for speermint@ietf.org; Tue, 04 Apr 2006 13:04:45 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoxQ-0007ai-RQ for speermint@ietf.org; Tue, 04 Apr 2006 13:04:45 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A72A013C; Tue, 04 Apr 2006 13:04:42 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Patrick Melampy'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 13:04:49 -0400 Message-ID: <04d901c65809$e210f570$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAmpCg In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4968@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Ergo, SBC's exist. :) (although it's not the only reason they're used, thinking of it this way is probably the most reasonable one for the IETF) -hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 12:45 PM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >Most consumers on the planet Earth are in private address spaces at this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are members > of, > >and use, the Internet. > > Yes, but if you put your mailserver only in 192.168.x.x, you will get a > problem > > Richard _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 13:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp2t-0008Jv-UZ; Tue, 04 Apr 2006 13:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp2s-0008Iw-0t for speermint@ietf.org; Tue, 04 Apr 2006 13:10:22 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQp2r-00089f-IL for speermint@ietf.org; Tue, 04 Apr 2006 13:10:22 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k34H9W6r000217; Tue, 4 Apr 2006 17:09:37 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 871B7124828; Tue, 4 Apr 2006 17:09:21 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 20ED6124807; Tue, 4 Apr 2006 17:09:21 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:09:20 -0600 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] Reachability Date: Tue, 4 Apr 2006 11:09:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQ From: "Malas, Daryl" To: "Stastny Richard" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-OriginalArrivalTime: 04 Apr 2006 17:09:20.0638 (UTC) FILETIME=[838979E0:01C6580A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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 Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. =20 =20 Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself.=20 Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Tue Apr 04 13:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp3k-0008PY-7s; Tue, 04 Apr 2006 13:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp3j-0008PT-1z for speermint@ietf.org; Tue, 04 Apr 2006 13:11:15 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQp3i-0008AQ-7C for speermint@ietf.org; Tue, 04 Apr 2006 13:11:15 -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 Date: Tue, 4 Apr 2006 19:15:15 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4969@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NATs and Firewalls Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSA== From: "Stastny Richard" To: "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: Subject: [Speermint] NATs and Firewalls 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 some people out there either do not understand the difference between NATs and firewalls or are starting to believe their own propaganda =20 NATs are NATs and firewalls are firewalls =20 The worst misconception here is that a NAT is for providing you security against the bad Internet =20 Private adress spaces have been introduced to save a scarce ressource (or what some believed are a scarce ressource at some point of time) =20 You can live very safe behind a properly configured firewall using only public IP adresses. =20 The basic idea of IPv6 was to give every device on earth and also within the solar system a unique public IP address =20 But the fake security of NATs was already in the minds of most people, that the first things that were implemented in IPv6 where NATs for IPv6, which is a perversion =20 Geoff Huston had once a nice eleborate on this in an IETF paper =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; = speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be = publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with = allowing, enabling, and inter-working private address spaces and VPNs. What's = missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself.=20 Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. = Entire networks in some countries are privately addressed, yet they are members = of, and use, the Internet. There are also now 2 disjoint address groups = defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress = (and egress) point(s), either on the public network for it to be public, or = for it to cross into another private address domain. For this WG's purpose, = I recommend we allow either model to work, as well as the model of the = private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; = speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving = proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the = IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it = works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but = if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public = network > and one on a private network. The private entities need at least to = have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying = here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from = the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for = the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving = proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind = a > > home > > NAT (a private IP), then it is a private AoR; but for those = consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in = the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be = reachable, > he/she needs a public NAT binding so that a session _initiated_ from = the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we = have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an = AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also = private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP = service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should = ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Apr 04 13:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp8m-0003dz-8b; Tue, 04 Apr 2006 13:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQp8k-0003Z1-R9 for speermint@ietf.org; Tue, 04 Apr 2006 13:16:26 -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 1FQp8k-0008WR-B4 for speermint@ietf.org; Tue, 04 Apr 2006 13:16:26 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k34HGMaK006047; Tue, 4 Apr 2006 17:16:22 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id B87E9124807; Tue, 4 Apr 2006 17:16:21 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 56B2212481C; Tue, 4 Apr 2006 17:16:21 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:16:21 -0600 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] NATs and Firewalls Date: Tue, 4 Apr 2006 11:16:20 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSAAAPudw From: "Malas, Daryl" To: "Stastny Richard" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-OriginalArrivalTime: 04 Apr 2006 17:16:21.0078 (UTC) FILETIME=[7E238760:01C6580B] X-Spam-Score: 0.1 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a 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 Totally agree!!! Anyone who was configuring firewalls back in the day when ARIN was giving away subnets like candy should definitely understand the difference. Thanks for the reminder... Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 11:15 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: [Speermint] NATs and Firewalls I think some people out there either do not understand the difference between NATs and firewalls or are starting to believe their own propaganda =20 NATs are NATs and firewalls are firewalls =20 The worst misconception here is that a NAT is for providing you security against the bad Internet =20 Private adress spaces have been introduced to save a scarce ressource (or what some believed are a scarce ressource at some point of time) =20 You can live very safe behind a properly configured firewall using only public IP adresses. =20 The basic idea of IPv6 was to give every device on earth and also within the solar system a unique public IP address =20 But the fake security of NATs was already in the minds of most people, that the first things that were implemented in IPv6 where NATs for IPv6, which is a perversion =20 Geoff Huston had once a nice eleborate on this in an IETF paper =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself.=20 Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Tue Apr 04 13:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpFC-00068h-61; Tue, 04 Apr 2006 13:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpFB-000682-0W for speermint@ietf.org; Tue, 04 Apr 2006 13:23:05 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQpF9-0000ny-K8 for speermint@ietf.org; Tue, 04 Apr 2006 13:23:04 -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] Reachability Date: Tue, 4 Apr 2006 19:27:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOM= From: "Stastny Richard" To: "Malas, Daryl" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 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 Nice analysis, and useful =20 But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing = information =20 Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. =20 He could do this by interrogating his own local databases,=20 (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) =20 I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself =20 So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. =20 If they then do peering by whatever means on l3, so they could =20 Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; = speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet.=20 Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Tue Apr 04 13:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpPh-0005ML-AR; Tue, 04 Apr 2006 13:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpPg-0005MG-Qx for speermint@ietf.org; Tue, 04 Apr 2006 13:33: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 1FQpPg-00018J-8U for speermint@ietf.org; Tue, 04 Apr 2006 13:33:56 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k34HXqaK011855; Tue, 4 Apr 2006 17:33:53 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 54B96124818; Tue, 4 Apr 2006 17:33:52 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id DCD9612480E; Tue, 4 Apr 2006 17:33:51 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:33:51 -0600 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] Reachability Date: Tue, 4 Apr 2006 11:33:50 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQA== From: "Malas, Daryl" To: "Stastny Richard" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-OriginalArrivalTime: 04 Apr 2006 17:33:51.0102 (UTC) FILETIME=[F00079E0:01C6580D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 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 Comments in-line... Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 11:27 AM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful =20 But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing information [Daryl] I agree, by defining the environment (e.g. public, private, carrier), I think it will be easier to specify the required database. =20 Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. [Daryl] Agreed. =20 He could do this by interrogating his own local databases,=20 (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) [Daryl] I think this is a little presumptuous, but is ultimately their choice. If their choice is not to use DNS, then another more cost effective method may be used by the operator (i.e. think along the lines of class 4 switching), as long as it is within the specific environment (e.g. private/carrier peering...basically eliminates public peering if not DNS). =20 I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself =20 So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. [Daryl] I think this is the only method capable of supporting a public peering model. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. =20 If they then do peering by whatever means on l3, so they could =20 Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet.=20 Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 13:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpYv-0000yS-CJ; Tue, 04 Apr 2006 13:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpYt-0000xl-UU for speermint@ietf.org; Tue, 04 Apr 2006 13:43:27 -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 1FQpYt-0001JR-BW for speermint@ietf.org; Tue, 04 Apr 2006 13:43:27 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k34HhNaK014843; Tue, 4 Apr 2006 17:43:24 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 6734578B40F; Tue, 4 Apr 2006 17:43:23 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 3700078B4A5; Tue, 4 Apr 2006 17:43:23 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 11:43:23 -0600 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] Reachability Date: Tue, 4 Apr 2006 11:43:22 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQAAAhkZw From: "Malas, Daryl" To: "Stastny Richard" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" X-OriginalArrivalTime: 04 Apr 2006 17:43:23.0079 (UTC) FILETIME=[44ED3D70:01C6580F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 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 BTW, I was not trying to de-rail your discussion; I was just trying to provide another perspective. I may be getting too far off base in my thinking. If so...sorry... Daryl M. -----Original Message----- From: Malas, Daryl=20 Sent: Tuesday, April 04, 2006 11:34 AM To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: RE: [Speermint] Reachability Comments in-line... Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 04, 2006 11:27 AM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful =20 But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing information [Daryl] I agree, by defining the environment (e.g. public, private, carrier), I think it will be easier to specify the required database. =20 Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. [Daryl] Agreed. =20 He could do this by interrogating his own local databases,=20 (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) [Daryl] I think this is a little presumptuous, but is ultimately their choice. If their choice is not to use DNS, then another more cost effective method may be used by the operator (i.e. think along the lines of class 4 switching), as long as it is within the specific environment (e.g. private/carrier peering...basically eliminates public peering if not DNS). =20 I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself =20 So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. [Daryl] I think this is the only method capable of supporting a public peering model. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. =20 If they then do peering by whatever means on l3, so they could =20 Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet.=20 Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint 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 Apr 04 13:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpcw-0004YF-C5; Tue, 04 Apr 2006 13:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpcu-0004YA-Rd for speermint@ietf.org; Tue, 04 Apr 2006 13:47:36 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQpcu-0001N4-91 for speermint@ietf.org; Tue, 04 Apr 2006 13:47:36 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A1360188; Tue, 04 Apr 2006 13:47:34 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Patrick Melampy'" , "'Reinaldo Penno'" , Date: Tue, 4 Apr 2006 13:47:41 -0400 Message-ID: <04e301c6580f$dee1c6d0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSAAAkOqA In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4969@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: Subject: [Speermint] RE: NATs and Firewalls 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 Richard, I hope you're not referring to me. Who said anything about NATs providing security? They don't, plain and simple. Firewalls only provide (some) security if they can be assured they're in the path of the data. Such a thing is very difficult in a service-provider IP network, because there is no constant/default route out, nor a guaranteed route in, without severely constraining the deployment design and increasing complexity. Firewalls have another difficulty with SIP service specifically for service-providers, and they provide a very false sense of security due to them, but we need not get into that. This is not the right forum. There are many reasons SBCs also do NAT. One of them is they can bridge the private address spaces together at a transport and application level. That's the one which is probably the most beneficial/accepted from the IETF's perspective today, and why I prefer to stick with it. It is also not the case, IMHO, that consumer NATs are popular for "security" reasons. I think this is another popular misconception. In my view, consumer NATs became popular for another reason which people often ignore: the integrated DHCP server. Consumers know nothing of IP Addresses, subnets, DNS servers, etc. A NAT providing many IP Addresses was great, but the DHCP server built in was the key, because it enabled a consumer to plug in multiple devices without configuring anything, even for the DNS. It's all about achieving the goals with the least complexity for the end-user. (of course the price level didn't hurt :) Once those goals were reached, the cost/pain of converting to IPv6 became difficult to justify on a global basis. -hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 1:15 PM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: NATs and Firewalls > > I think some people out there either do not understand > the difference between NATs and firewalls or are starting > to believe their own propaganda > > NATs are NATs and firewalls are firewalls > > The worst misconception here is that a NAT is for providing you security > against the bad Internet > > Private adress spaces have been introduced to save a scarce ressource > (or what some believed are a scarce ressource at some point of time) > > You can live very safe behind a properly configured firewall using only > public IP adresses. > > The basic idea of IPv6 was to give every device on earth and also > within the solar system a unique public IP address > > But the fake security of NATs was already in the minds of > most people, that the first things that were implemented > in IPv6 where NATs for IPv6, which is a perversion > > Geoff Huston had once a nice eleborate on this in an IETF paper > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to be publicly > addressable is neither an Internet requirement, nor a requirement of the > IETF. Entire working groups in the IETF concern themselves with allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an ingress (and > egress) point(s), either on the public network for it to be public, or for > it to cross into another private address domain. For this WG's purpose, I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to everybody. > > This was also why I had a problem with Sohel's presentation at the IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a private > > network, > > but it is not out task to consider this separately. Because if it works > > on the Internet, it also works in a private network (extranet in this > > case) > > (see DNS). this private network may even use public IP adresses, but if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying here. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and every > > customer of every carrier that wants to inter-connect needs to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar for > the > > target of a communication must ALSO have either a public address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need to > > care > > > > about that? An AoR in the end will be translated to an IP address, > > and > > > > IP addresses have a very good definition of public and private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer behind a > > > home > > > NAT (a private IP), then it is a private AoR; but for those consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we have > > today, this means the domain name/user is private, does not exist, etc > > > > All this has been happening okay with just a few basic rules. If an AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow it > > later > > > gets translated into the public IP address space, that's also private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > > reachable" but not IP reachable. But I think for now we should ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > 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 Apr 04 14:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpwi-0000EN-C3; Tue, 04 Apr 2006 14:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQpwg-0000EI-Mo for speermint@ietf.org; Tue, 04 Apr 2006 14:08:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQpwf-0001z8-BB for speermint@ietf.org; Tue, 04 Apr 2006 14:08:02 -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 Date: Tue, 4 Apr 2006 20:12:02 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NATs and Firewalls Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSAAAkOqAAAF/Jf4= From: "Stastny Richard" To: "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: Subject: [Speermint] Re: NATs and Firewalls 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 hope you're not referring to me. No, sorry if you got this impression =20 but I have heard this argument over and over if I asked telcos (and these are really experts regarding IP ;-), why they implement 10.x.x.x address spaces. =20 I understand your argument about DHCP and consumer LANs, but this "private" address spaces are not our problem here =20 Richar ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 19:47 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; = speermint@ietf.org Betreff: RE: NATs and Firewalls Hi Richard, I hope you're not referring to me. Who said anything about NATs providing security? They don't, plain and simple.=20 Firewalls only provide (some) security if they can be assured they're in = the path of the data. Such a thing is very difficult in a service-provider = IP network, because there is no constant/default route out, nor a = guaranteed route in, without severely constraining the deployment design and = increasing complexity. Firewalls have another difficulty with SIP service = specifically for service-providers, and they provide a very false sense of security = due to them, but we need not get into that. This is not the right forum. There are many reasons SBCs also do NAT. One of them is they can bridge = the private address spaces together at a transport and application level. That's the one which is probably the most beneficial/accepted from the IETF's perspective today, and why I prefer to stick with it.=20 It is also not the case, IMHO, that consumer NATs are popular for = "security" reasons. I think this is another popular misconception. In my view, consumer NATs became popular for another reason which people often = ignore: the integrated DHCP server. Consumers know nothing of IP Addresses, subnets, DNS servers, etc. A NAT providing many IP Addresses was great, = but the DHCP server built in was the key, because it enabled a consumer to = plug in multiple devices without configuring anything, even for the DNS. = It's all about achieving the goals with the least complexity for the = end-user. (of course the price level didn't hurt :) Once those goals were = reached, the cost/pain of converting to IPv6 became difficult to justify on a = global basis.=20 -hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 1:15 PM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; = speermint@ietf.org > Subject: NATs and Firewalls > > I think some people out there either do not understand > the difference between NATs and firewalls or are starting > to believe their own propaganda > > NATs are NATs and firewalls are firewalls > > The worst misconception here is that a NAT is for providing you = security > against the bad Internet > > Private adress spaces have been introduced to save a scarce ressource > (or what some believed are a scarce ressource at some point of time) > > You can live very safe behind a properly configured firewall using = only > public IP adresses. > > The basic idea of IPv6 was to give every device on earth and also > within the solar system a unique public IP address > > But the fake security of NATs was already in the minds of > most people, that the first things that were implemented > in IPv6 where NATs for IPv6, which is a perversion > > Geoff Huston had once a nice eleborate on this in an IETF paper > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to be = publicly > addressable is neither an Internet requirement, nor a requirement of = the > IETF. Entire working groups in the IETF concern themselves with = allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address spaces at = this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are = members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try = to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an ingress = (and > egress) point(s), either on the public network for it to be public, or = for > it to cross into another private address domain. For this WG's = purpose, I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of = both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; = speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving = proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to = everybody. > > This was also why I had a problem with Sohel's presentation at the = IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a = private > > network, > > but it is not out task to consider this separately. Because if it = works > > on the Internet, it also works in a private network (extranet in = this > > case) > > (see DNS). this private network may even use public IP adresses, but = if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to = have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying = here. > > > > Before somebody mentions it...for a UA behind a NAT to be = reachable, > > he/she needs a public NAT binding so that a session _initiated_ = from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and = every > > customer of every carrier that wants to inter-connect needs to have = a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar = for > the > > target of a communication must ALSO have either a public address or = a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving = proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need = to > > care > > > > about that? An AoR in the end will be translated to an IP = address, > > and > > > > IP addresses have a very good definition of public and private = (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's = domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer = behind a > > > home > > > NAT (a private IP), then it is a private AoR; but for those = consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the = discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can = someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication = is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the = end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in = the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be = reachable, > > he/she needs a public NAT binding so that a session _initiated_ from = the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we = have > > today, this means the domain name/user is private, does not exist, = etc > > > > All this has been happening okay with just a few basic rules. If an = AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow = it > > later > > > gets translated into the public IP address space, that's also = private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable = first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP = service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be = "sip > > > reachable" but not IP reachable. But I think for now we should = ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > 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 Apr 04 15:07:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqsb-0001JH-N8; Tue, 04 Apr 2006 15:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQqsa-0001JC-OA for speermint@ietf.org; Tue, 04 Apr 2006 15:07:52 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQqsZ-0004GE-GA for speermint@ietf.org; Tue, 04 Apr 2006 15:07:52 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A4050190; Tue, 04 Apr 2006 15:07:49 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , Date: Tue, 4 Apr 2006 15:07:56 -0400 Message-ID: <050501c6581b$14ee4a40$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSAAAkOqAAAF/Jf4AAD1QoA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C496B@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Speermint] RE: NATs and Firewalls 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 Richard, comments inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 2:12 PM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: NATs and Firewalls > > but I have heard this argument over and over if I asked telcos > (and these are really experts regarding IP ;-), why they implement > 10.x.x.x address spaces. Ahh. Actually, they're somewhat right from my perspective, but not for the reasons they probably think. It's really because of the fact they are an Internet service-provider; so using a private address space simplifies the security deployment architecture and avoids some common screw-ups, but it doesn't "provide" security. Obfuscation alone has little value, IMHO, and is not why most SBCs obfuscate I think. It all depends on the attack vectors and threats you're trying to protect against, and how. But we probably shouldn't get into that on this list - I'm just saying we should support the case of a private (or non-routable) address space joining a public or another private one through the peering element(s). It may have no implications whatsoever on this WG's work, or it may have some. That's TBD. :) -Hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 15:21:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr5J-0006zp-Qe; Tue, 04 Apr 2006 15:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQr5H-0006zk-UZ for speermint@ietf.org; Tue, 04 Apr 2006 15:20:59 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQr5H-0004b4-9E for speermint@ietf.org; Tue, 04 Apr 2006 15:20:59 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A7190360; Tue, 04 Apr 2006 15:20:57 -0400 From: "Hadriel Kaplan" To: "'Malas, Daryl'" , "'Stastny Richard'" Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 15:21:04 -0400 Message-ID: <050c01c6581c$ea765530$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQAAD1pkg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 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 Darryl/Richard, Just a quick question: did the WG decide on ENUM/DNS as the location mechanism already? (could be, I joined late) I like the idea, but it's having the tail wag the dog. ;) Seriously, though - we may find a missing piece or 2 if we start with terminology + requirements. Sorry if I mis-interpreted your comments. -hadriel > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 04, 2006 1:34 PM > To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Comments in-line... > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 11:27 AM > To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: Re: [Speermint] Reachability > > Nice analysis, and useful > > But I think we get more and more down to L2 and L3, but our prime > or first goal is to enable peering on L5. > to do so, we basically need a common database to get the routing > information > > [Daryl] I agree, by defining the environment (e.g. public, private, > carrier), I think it will be easier to specify the required database. > > Of course any provider can peer with ony other provider bilaterally > as he likes, if he has finally found out which VPN or other bi-lateral > peering on Ip level he wants to use. > > [Daryl] Agreed. > > He could do this by interrogating his own local databases, > (which he has to maintain by himself, spendig a lot of money and > making a lot of mistakes) or he may interrogate a common global database > e.g. the DNS (both for SRV and ENUM) > > [Daryl] I think this is a little presumptuous, but is ultimately their > choice. If their choice is not to use DNS, then another more cost > effective method may be used by the operator (i.e. think along the lines > of class 4 switching), as long as it is within the specific environment > (e.g. private/carrier peering...basically eliminates public peering if > not DNS). > > I know that split horizon DNS may be used, but the drawback of > this is that the DNS behind the curtain must be administrated by himself > > So the prime question in ENUM WG is where to place a globally > reachable ENUM DNS and the question in speermint WG is what > information has to be placed in the public DNS. > > [Daryl] I think this is the only method capable of supporting a public > peering model. > > Both can only be in the public address spece to be useful, and > therefore everybody needs access to thsi address space. > > If they then do peering by whatever means on l3, so they could > > Richard > > ________________________________ > > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Di 04.04.2006 19:09 > An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents. I think by now it should be generally understood, if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: > > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection > c. Media and signaling are not accessible from the public > internet > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). > > Does it make sense to break up the issues/requirements based on these 3 > different environments? > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 10:45 AM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >Most consumers on the planet Earth are in private address spaces at > this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are > members of, > >and use, the Internet. > > Yes, but if you put your mailserver only in 192.168.x.x, you will get a > problem > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to be > publicly > addressable is neither an Internet requirement, nor a requirement of the > IETF. Entire working groups in the IETF concern themselves with > allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an ingress > (and > egress) point(s), either on the public network for it to be public, or > for > it to cross into another private address domain. For this WG's purpose, > I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to everybody. > > This was also why I had a problem with Sohel's presentation at the > IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a private > > network, > > but it is not out task to consider this separately. Because if it > works > > on the Internet, it also works in a private network (extranet in this > > case) > > (see DNS). this private network may even use public IP adresses, but > if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to > have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying > here. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and every > > customer of every carrier that wants to inter-connect needs to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar for > the > > target of a communication must ALSO have either a public address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need to > > care > > > > about that? An AoR in the end will be translated to an IP address, > > and > > > > IP addresses have a very good definition of public and private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer behind > a > > > home > > > NAT (a private IP), then it is a private AoR; but for those > consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in > the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we > have > > today, this means the domain name/user is private, does not exist, etc > > > > All this has been happening okay with just a few basic rules. If an > AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow it > > later > > > gets translated into the public IP address space, that's also > private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP > service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > > reachable" but not IP reachable. But I think for now we should > ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 15:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrIA-0008Qz-U7; Tue, 04 Apr 2006 15:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrI9-0008PD-7Q for speermint@ietf.org; Tue, 04 Apr 2006 15:34:17 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQrI8-00053q-Kl for speermint@ietf.org; Tue, 04 Apr 2006 15:34:17 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k34JXI6r029714; Tue, 4 Apr 2006 19:33:34 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 2FE3C78B51A; Tue, 4 Apr 2006 19:33:07 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id DC87478B502; Tue, 4 Apr 2006 19:33:04 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 13:33:04 -0600 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] ENUM: Reachability Date: Tue, 4 Apr 2006 13:33:03 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] ENUM: Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQAAD1pkgAABlANA= From: "Malas, Daryl" To: "Hadriel Kaplan" , "Stastny Richard" X-OriginalArrivalTime: 04 Apr 2006 19:33:04.0422 (UTC) FILETIME=[97B67C60:01C6581E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 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 Good question...I brought this up at the WG meeting last month. ENUM is heavily referenced within the SPEERMINT WG's terminology and requirements draft. Although I fully expect ENUM to be part of some aspect of varying peering topologies, I do not think it is the only "location mechanism". I believe this was agreed upon at the WG meeting; therefore, consider it in context as an inclusive, but not exclusive method. --Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Tuesday, April 04, 2006 1:21 PM To: Malas, Daryl; 'Stastny Richard' Cc: speermint@ietf.org Subject: RE: [Speermint] Reachability Hi Darryl/Richard, Just a quick question: did the WG decide on ENUM/DNS as the location mechanism already? (could be, I joined late) =20 I like the idea, but it's having the tail wag the dog. ;) Seriously, though - we may find a missing piece or 2 if we start with terminology + requirements. Sorry if I mis-interpreted your comments. -hadriel > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 04, 2006 1:34 PM > To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Comments in-line... >=20 > Daryl M. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 11:27 AM > To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > Nice analysis, and useful >=20 > But I think we get more and more down to L2 and L3, but our prime > or first goal is to enable peering on L5. > to do so, we basically need a common database to get the routing > information >=20 > [Daryl] I agree, by defining the environment (e.g. public, private, > carrier), I think it will be easier to specify the required database. >=20 > Of course any provider can peer with ony other provider bilaterally > as he likes, if he has finally found out which VPN or other bi-lateral > peering on Ip level he wants to use. >=20 > [Daryl] Agreed. >=20 > He could do this by interrogating his own local databases, > (which he has to maintain by himself, spendig a lot of money and > making a lot of mistakes) or he may interrogate a common global database > e.g. the DNS (both for SRV and ENUM) >=20 > [Daryl] I think this is a little presumptuous, but is ultimately their > choice. If their choice is not to use DNS, then another more cost > effective method may be used by the operator (i.e. think along the lines > of class 4 switching), as long as it is within the specific environment > (e.g. private/carrier peering...basically eliminates public peering if > not DNS). >=20 > I know that split horizon DNS may be used, but the drawback of > this is that the DNS behind the curtain must be administrated by himself >=20 > So the prime question in ENUM WG is where to place a globally > reachable ENUM DNS and the question in speermint WG is what > information has to be placed in the public DNS. >=20 > [Daryl] I think this is the only method capable of supporting a public > peering model. >=20 > Both can only be in the public address spece to be useful, and > therefore everybody needs access to thsi address space. >=20 > If they then do peering by whatever means on l3, so they could >=20 > Richard >=20 > ________________________________ >=20 > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Di 04.04.2006 19:09 > An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability >=20 >=20 >=20 > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents. I think by now it should be generally understood, if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: >=20 > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection > c. Media and signaling are not accessible from the public > internet > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). >=20 > Does it make sense to break up the issues/requirements based on these 3 > different environments? >=20 > Daryl M. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 10:45 AM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > >Most consumers on the planet Earth are in private address spaces at > this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are > members of, > >and use, the Internet. >=20 > Yes, but if you put your mailserver only in 192.168.x.x, you will get a > problem >=20 > Richard >=20 > ________________________________ >=20 > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability >=20 >=20 >=20 > Hi Richard, > And here we get to the fun stuff. :) >=20 > The idea of every serving proxy/registrar/sip-node needing to be > publicly > addressable is neither an Internet requirement, nor a requirement of the > IETF. Entire working groups in the IETF concern themselves with > allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. >=20 > Most consumers on the planet Earth are in private address spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. >=20 > So I agree with you there needs to be an entity providing an ingress > (and > egress) point(s), either on the public network for it to be public, or > for > it to cross into another private address domain. For this WG's purpose, > I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of both > sides are in the same public or private space. >=20 > -Hadriel >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to everybody. > > This was also why I had a problem with Sohel's presentation at the > IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a private > > network, > > but it is not out task to consider this separately. Because if it > works > > on the Internet, it also works in a private network (extranet in this > > case) > > (see DNS). this private network may even use public IP adresses, but > if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to > have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying > here. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and every > > customer of every carrier that wants to inter-connect needs to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar for > the > > target of a communication must ALSO have either a public address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need to > > care > > > > about that? An AoR in the end will be translated to an IP address, > > and > > > > IP addresses have a very good definition of public and private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer behind > a > > > home > > > NAT (a private IP), then it is a private AoR; but for those > consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in > the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we > have > > today, this means the domain name/user is private, does not exist, etc > > > > All this has been happening okay with just a few basic rules. If an > AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow it > > later > > > gets translated into the public IP address space, that's also > private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP > service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > > reachable" but not IP reachable. But I think for now we should > ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > 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 >=20 >=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 >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 15:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrJn-0000YZ-Tr; Tue, 04 Apr 2006 15:35:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrJm-0000YU-Ms for speermint@ietf.org; Tue, 04 Apr 2006 15:35:58 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQrJl-000596-Dx for speermint@ietf.org; Tue, 04 Apr 2006 15:35:58 -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] Reachability Date: Tue, 4 Apr 2006 21:39:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQAAD1pkgAAChQNM= From: "Stastny Richard" To: "Hadriel Kaplan" , "Malas, Daryl" X-Spam-Score: 0.0 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 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 ENUM is out-of-scope in speermint, it is only providing eventaully inter = alia the call routing data =20 speermint is using the call routing data and IMHO it is not defined yet what is used to locate the next hop. OTOH, since sip and sip standards are to be used, RFC3263 implies somewhat the DNS =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 21:21 An: 'Malas, Daryl'; Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Darryl/Richard, Just a quick question: did the WG decide on ENUM/DNS as the location mechanism already? (could be, I joined late)=20 I like the idea, but it's having the tail wag the dog. ;) Seriously, though - we may find a missing piece or 2 if we start with terminology + requirements. Sorry if I mis-interpreted your comments. -hadriel > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 04, 2006 1:34 PM > To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Comments in-line... > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 11:27 AM > To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: Re: [Speermint] Reachability > > Nice analysis, and useful > > But I think we get more and more down to L2 and L3, but our prime > or first goal is to enable peering on L5. > to do so, we basically need a common database to get the routing > information > > [Daryl] I agree, by defining the environment (e.g. public, private, > carrier), I think it will be easier to specify the required database. > > Of course any provider can peer with ony other provider bilaterally > as he likes, if he has finally found out which VPN or other bi-lateral > peering on Ip level he wants to use. > > [Daryl] Agreed. > > He could do this by interrogating his own local databases, > (which he has to maintain by himself, spendig a lot of money and > making a lot of mistakes) or he may interrogate a common global = database > e.g. the DNS (both for SRV and ENUM) > > [Daryl] I think this is a little presumptuous, but is ultimately = their > choice. If their choice is not to use DNS, then another more cost > effective method may be used by the operator (i.e. think along the = lines > of class 4 switching), as long as it is within the specific = environment > (e.g. private/carrier peering...basically eliminates public peering if > not DNS). > > I know that split horizon DNS may be used, but the drawback of > this is that the DNS behind the curtain must be administrated by = himself > > So the prime question in ENUM WG is where to place a globally > reachable ENUM DNS and the question in speermint WG is what > information has to be placed in the public DNS. > > [Daryl] I think this is the only method capable of supporting a public > peering model. > > Both can only be in the public address spece to be useful, and > therefore everybody needs access to thsi address space. > > If they then do peering by whatever means on l3, so they could > > Richard > > ________________________________ > > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Di 04.04.2006 19:09 > An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents. I think by now it should be generally understood, = if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: > > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be = accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection > c. Media and signaling are not accessible from the public > internet > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). > > Does it make sense to break up the issues/requirements based on these = 3 > different environments? > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 10:45 AM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; = speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >Most consumers on the planet Earth are in private address spaces at > this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are > members of, > >and use, the Internet. > > Yes, but if you put your mailserver only in 192.168.x.x, you will get = a > problem > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to be > publicly > addressable is neither an Internet requirement, nor a requirement of = the > IETF. Entire working groups in the IETF concern themselves with > allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address spaces at = this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are = members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try = to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an ingress > (and > egress) point(s), either on the public network for it to be public, or > for > it to cross into another private address domain. For this WG's = purpose, > I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of = both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to = everybody. > > This was also why I had a problem with Sohel's presentation at the > IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a = private > > network, > > but it is not out task to consider this separately. Because if it > works > > on the Internet, it also works in a private network (extranet in = this > > case) > > (see DNS). this private network may even use public IP adresses, but > if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to > have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying > here. > > > > Before somebody mentions it...for a UA behind a NAT to be = reachable, > > he/she needs a public NAT binding so that a session _initiated_ = from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and = every > > customer of every carrier that wants to inter-connect needs to have = a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar = for > the > > target of a communication must ALSO have either a public address or = a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need = to > > care > > > > about that? An AoR in the end will be translated to an IP = address, > > and > > > > IP addresses have a very good definition of public and private = (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's = domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer = behind > a > > > home > > > NAT (a private IP), then it is a private AoR; but for those > consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the = discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can = someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication = is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the = end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in > the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we > have > > today, this means the domain name/user is private, does not exist, = etc > > > > All this has been happening okay with just a few basic rules. If an > AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow = it > > later > > > gets translated into the public IP address space, that's also > private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable = first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP > service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be = "sip > > > reachable" but not IP reachable. But I think for now we should > ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 15:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrOL-0003O0-Up; Tue, 04 Apr 2006 15:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQrOK-0003Nv-S7 for speermint@ietf.org; Tue, 04 Apr 2006 15:40:41 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQrOJ-0005HV-3N for speermint@ietf.org; Tue, 04 Apr 2006 15:40:40 -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] ENUM: Reachability Date: Tue, 4 Apr 2006 21:40:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] ENUM: Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMAAEaZQAAD1pkgAABlANAAAHdBlA== From: "Stastny Richard" To: "Malas, Daryl" , "Hadriel Kaplan" X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 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 clarify, ENUM is not a location mechanism it is a mapping from E.164 numbers to AoR =20 Call routing on IP is only done via AoR =20 so AoR is the output from ENUM, which is the input to speermint =20 Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 21:33 An: Hadriel Kaplan; Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] ENUM: Reachability Good question...I brought this up at the WG meeting last month. ENUM is heavily referenced within the SPEERMINT WG's terminology and requirements draft. Although I fully expect ENUM to be part of some aspect of varying peering topologies, I do not think it is the only "location mechanism". I believe this was agreed upon at the WG meeting; therefore, consider it in context as an inclusive, but not exclusive method. --Daryl -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Tuesday, April 04, 2006 1:21 PM To: Malas, Daryl; 'Stastny Richard' Cc: speermint@ietf.org Subject: RE: [Speermint] Reachability Hi Darryl/Richard, Just a quick question: did the WG decide on ENUM/DNS as the location mechanism already? (could be, I joined late)=20 I like the idea, but it's having the tail wag the dog. ;) Seriously, though - we may find a missing piece or 2 if we start with terminology + requirements. Sorry if I mis-interpreted your comments. -hadriel > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 04, 2006 1:34 PM > To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Comments in-line... > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 11:27 AM > To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: Re: [Speermint] Reachability > > Nice analysis, and useful > > But I think we get more and more down to L2 and L3, but our prime > or first goal is to enable peering on L5. > to do so, we basically need a common database to get the routing > information > > [Daryl] I agree, by defining the environment (e.g. public, private, > carrier), I think it will be easier to specify the required database. > > Of course any provider can peer with ony other provider bilaterally > as he likes, if he has finally found out which VPN or other bi-lateral > peering on Ip level he wants to use. > > [Daryl] Agreed. > > He could do this by interrogating his own local databases, > (which he has to maintain by himself, spendig a lot of money and > making a lot of mistakes) or he may interrogate a common global database > e.g. the DNS (both for SRV and ENUM) > > [Daryl] I think this is a little presumptuous, but is ultimately their > choice. If their choice is not to use DNS, then another more cost > effective method may be used by the operator (i.e. think along the lines > of class 4 switching), as long as it is within the specific environment > (e.g. private/carrier peering...basically eliminates public peering if > not DNS). > > I know that split horizon DNS may be used, but the drawback of > this is that the DNS behind the curtain must be administrated by himself > > So the prime question in ENUM WG is where to place a globally > reachable ENUM DNS and the question in speermint WG is what > information has to be placed in the public DNS. > > [Daryl] I think this is the only method capable of supporting a public > peering model. > > Both can only be in the public address spece to be useful, and > therefore everybody needs access to thsi address space. > > If they then do peering by whatever means on l3, so they could > > Richard > > ________________________________ > > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Di 04.04.2006 19:09 > An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents. I think by now it should be generally understood, if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: > > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection > c. Media and signaling are not accessible from the public > internet > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). > > Does it make sense to break up the issues/requirements based on these 3 > different environments? > > Daryl M. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 10:45 AM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >Most consumers on the planet Earth are in private address spaces at > this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are > members of, > >and use, the Internet. > > Yes, but if you put your mailserver only in 192.168.x.x, you will get a > problem > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to be > publicly > addressable is neither an Internet requirement, nor a requirement of the > IETF. Entire working groups in the IETF concern themselves with > allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an ingress > (and > egress) point(s), either on the public network for it to be public, or > for > it to cross into another private address domain. For this WG's purpose, > I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to everybody. > > This was also why I had a problem with Sohel's presentation at the > IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a private > > network, > > but it is not out task to consider this separately. Because if it > works > > on the Internet, it also works in a private network (extranet in this > > case) > > (see DNS). this private network may even use public IP adresses, but > if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to > have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying > here. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and every > > customer of every carrier that wants to inter-connect needs to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar for > the > > target of a communication must ALSO have either a public address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need to > > care > > > > about that? An AoR in the end will be translated to an IP address, > > and > > > > IP addresses have a very good definition of public and private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer behind > a > > > home > > > NAT (a private IP), then it is a private AoR; but for those > consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in > the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we > have > > today, this means the domain name/user is private, does not exist, etc > > > > All this has been happening okay with just a few basic rules. If an > AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow it > > later > > > gets translated into the public IP address space, that's also > private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP > service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > > reachable" but not IP reachable. But I think for now we should > ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint 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 Apr 04 16:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQs6C-0008FS-4G; Tue, 04 Apr 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 1FQs6B-0008FK-FB for speermint@ietf.org; Tue, 04 Apr 2006 16:25:59 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQs6A-0008Kb-ME for speermint@ietf.org; Tue, 04 Apr 2006 16:25:59 -0400 Received: from PMelampy [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A65302A0; Tue, 04 Apr 2006 16:25:55 -0400 From: "Patrick Melampy" To: "'Stastny Richard'" , "'Hadriel Kaplan'" , "'Reinaldo Penno'" , Date: Tue, 4 Apr 2006 16:25:57 -0400 Message-ID: <020001c65825$facd7180$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAifPSAABRpNw In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4969@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: Subject: [Speermint] RE: NATs and Firewalls 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 wrote: You can live very safe behind a properly configured firewall using only public IP adresses. This is true. However, the NAPT functions of a firewall are perhaps the primary mechanism for performing all other security related activities. Even if both networks are public address spaces. I think this is because many of the security functions require flow based state. I think the term firewall is very confusing I agree with you. I prefer to describe the function .. NAT/NAPT/Filter This will help those reading documents to understand how the packets are flowing, where they having their address changed, and where they are subject to a go/nogo filter of some kind. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:15 PM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: NATs and Firewalls I think some people out there either do not understand the difference between NATs and firewalls or are starting to believe their own propaganda NATs are NATs and firewalls are firewalls The worst misconception here is that a NAT is for providing you security against the bad Internet Private adress spaces have been introduced to save a scarce ressource (or what some believed are a scarce ressource at some point of time) You can live very safe behind a properly configured firewall using only public IP adresses. The basic idea of IPv6 was to give every device on earth and also within the solar system a unique public IP address But the fake security of NATs was already in the minds of most people, that the first things that were implemented in IPv6 where NATs for IPv6, which is a perversion Geoff Huston had once a nice eleborate on this in an IETF paper Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Apr 04 16:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsDw-0003rf-IF; Tue, 04 Apr 2006 16:34:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsDv-0003ra-Hb for speermint@ietf.org; Tue, 04 Apr 2006 16:33:59 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsDu-0000DV-Ur for speermint@ietf.org; Tue, 04 Apr 2006 16:33:59 -0400 Received: from PMelampy [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A8340398; Tue, 04 Apr 2006 16:33:56 -0400 From: "Patrick Melampy" To: "'Stastny Richard'" , "'Malas, Daryl'" , "'Hadriel Kaplan'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 16:33:58 -0400 Message-ID: <020101c65827$199ac4e0$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABrR4MA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C496A@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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 use the word ROUTING to mean different things. In some discussions it directly refers to the path packets take form end to end (L3). In other discussions it seems to be what next-hop proxy should a SIP message be forwarded to (L5). In some cases I think lots of us are confused about which type of routing is being referenced. I would like to propose that ROUTING be a term that defines the path that packets will take and that we refrain from using the term ROUTING in regards to selection of next-hop proxies. For selection of next-hop proxies -- why not suggest SERVICE PATH. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Tue Apr 04 16:40:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsJt-0000aS-G2; Tue, 04 Apr 2006 16:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsJs-0000XF-VW for speermint@ietf.org; Tue, 04 Apr 2006 16:40:08 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsJs-0000ID-Eu for speermint@ietf.org; Tue, 04 Apr 2006 16:40:08 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 04 Apr 2006 13:40:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208"; a="541019112:sNHT25554180" 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] Reachability Date: Tue, 4 Apr 2006 16:40:06 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5DB@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAOU4iQ From: "Reinaldo Penno" To: "Patrick Melampy" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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 Hello Patrick, Suddenly I'm some 30 emails behind but... That's what I was trying to say _if_ by publicly addressable you mean a mapping somewhere in the case of RFC1918 addresses. As some people mentioned (Sohel, Richard), including you, the main points are: 1) SIP entities (just like emails, web servers and others) can be on a private network, that's perfect fine, but a mapping somewhere is needed to communicate with non-RFC1918 endpoints. 2) Between the mapping ingress point and the actual SIP entity, you can traverse many layer 3 hops, VPNs, etc. that's perfect fine. All this infrastructure is out there and working. The only requirement for communication with non-RFC1918 IP addresses is (1) above. 3) There is no mapping needed anywhere if all entities are in a private address space and only communicate with each other - this is the traditional Layer 3 VPN.=20 As I mentioned the rules of host to host and email communication should apply to SIP otherwise we will need to invent another internet for it.=20 Regards, Reinaldo > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Tuesday, April 04, 2006 6:29 AM > To: Reinaldo Penno; 'Hadriel Kaplan'; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Reinaldo -- I agree with your assertions. >=20 > But I want to ensure everybody understands what your really saying here. >=20 > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. >=20 > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. >=20 > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. >=20 > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. >=20 > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hello Hadriel, >=20 > Comment inline.... >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] >=20 > Hello, >=20 > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? >=20 > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? >=20 > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). >=20 > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. >=20 > a) the IP address is private (RFC 1918). >=20 > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. >=20 > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. >=20 > b) the IP address is public. >=20 > The SIP endpoint is theoretically reachable. >=20 > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc >=20 > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? >=20 > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? >=20 > Regards, >=20 > Reinaldo >=20 >=20 >=20 >=20 >=20 >=20 > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel >=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 Tue Apr 04 16:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsO4-0004B8-7a; Tue, 04 Apr 2006 16:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsO3-00047U-7P for speermint@ietf.org; Tue, 04 Apr 2006 16:44:27 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsO2-0000NS-Iz for speermint@ietf.org; Tue, 04 Apr 2006 16:44:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FQsNn-0005ai-20; Tue, 04 Apr 2006 15:44:11 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Malas, Daryl'" , "'Hadriel Kaplan'" , "'Patrick Melampy'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 16:44:11 -0400 Message-ID: <0c1301c65828$89aefac0$b9201f0a@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.2670 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABttsEA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C496A@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net 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: 14278aea5bdd1edf35ec09ffb7b61f9d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Sorry, my head is hurting. First of all, for peering to work, the peers have to be in the same address space, at least the part facing the peering point. Does it matter to us what address space that is? Clearly, if it was the Internet, it has to work, but if, for example, the peering "fabric" is it's own private address space, so what? What in the documents needs to care about address space other than something that states the obvious (peers have to be in the same address space)? And then we get to ENUM. Who the heck cares where the database is as long as the entity querying it is in the same address space? If the database is in the O network, which is a completely private network, who cares as long as it's an O-entity that does the ENUM dip? If the database is in the peering address space, wherever that is, who cares as long as the entity doing the dip is in that address space? What in the documents has to worry about what address space the DNS database is in as long as it's accessible by the entity that needs it? Clearly, if the DATA itself is public data (real ENUM or some form of carrier enum in the e164.arpa tree), then at least a part of the DNS system has to be connected to the public internet, but we all know of systems that suck data from a public side while serving clients on a private side. Why are we making this harder that it seems to need to be? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 16:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsWh-0006Q3-7X; Tue, 04 Apr 2006 16:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsWg-0006Pt-6q for speermint@ietf.org; Tue, 04 Apr 2006 16:53:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsWf-0000b1-If for speermint@ietf.org; Tue, 04 Apr 2006 16:53:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FQsWP-0006Kk-Ei; Tue, 04 Apr 2006 15:53:05 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , "'Stastny Richard'" , "'Malas, Daryl'" , "'Hadriel Kaplan'" , "'Reinaldo Penno'" , Subject: RE: [Speermint] Reachability Date: Tue, 4 Apr 2006 16:53:06 -0400 Message-ID: <0c1a01c65829$c835a4a0$b9201f0a@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.2670 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABrR4MAAAmimQ In-Reply-To: <020101c65827$199ac4e0$9dc8000a@acmepacket.com> X-PopBeforeSMTPSenders: br@brianrosen.net 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: bfef20db74c24e87b6dbcd42ea7ba67c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 can't do that because the bell heads and the sip heads use the term "routing" for the act of determining the path call signaling takes. The L3 guys can't even claim it first, since the bell heads have them by decades. Trying to get one camp to give up their term is unworkable I think. You can call it "l3 routing" or "packet routing" and "l5" or "sip routing" or "call routing" if you want. -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Tuesday, April 04, 2006 4:34 PM To: 'Stastny Richard'; 'Malas, Daryl'; 'Hadriel Kaplan'; 'Reinaldo Penno'; speermint@ietf.org Subject: RE: [Speermint] Reachability We use the word ROUTING to mean different things. In some discussions it directly refers to the path packets take form end to end (L3). In other discussions it seems to be what next-hop proxy should a SIP message be forwarded to (L5). In some cases I think lots of us are confused about which type of routing is being referenced. I would like to propose that ROUTING be a term that defines the path that packets will take and that we refrain from using the term ROUTING in regards to selection of next-hop proxies. For selection of next-hop proxies -- why not suggest SERVICE PATH. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 17:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsfB-00035o-C7; Tue, 04 Apr 2006 17:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsfA-0002xs-2X for speermint@ietf.org; Tue, 04 Apr 2006 17:02:08 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQsf8-0000xz-Tt for speermint@ietf.org; Tue, 04 Apr 2006 17:02:08 -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 Date: Tue, 4 Apr 2006 23:06:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definition of routing Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABrR4MAAA62A1 From: "Stastny Richard" To: "Patrick Melampy" , "Malas, Daryl" , "Hadriel Kaplan" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: Subject: [Speermint] Definition of routing 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 Patrik, =20 I am well aware of this clash of terminology regarding routing in = bellhead and nethead world, but =20 I am raised as a bellhead and use this term since ages in your definition: >In other >discussions it seems to be what next-hop proxy should a SIP message be >forwarded to (L5).=20 =20 and living in standard body groups names NNAR (Numbering, Naming, Addressing and ROUTING) Routing is defined there as the function to find the next hop (be it another switching system or a SIP proxy) =20 and this is BTW all a ROUTER does, find the next hop, and this is why it is called router =20 And I am too old to change this definition =20 your definition: =20 > In some discussions it >directly refers to the path packets take form end to end (L3).=20 =20 is NOT what routing originally means =20 so please if you want to coin a new term, find a new one for your definition e.g routing chain, or chain of routings, etc good luck ;-) =20 Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Di 04.04.2006 22:33 An: Stastny Richard; 'Malas, Daryl'; 'Hadriel Kaplan'; 'Reinaldo Penno'; = speermint@ietf.org Betreff: RE: [Speermint] Reachability We use the word ROUTING to mean different things. In some discussions it directly refers to the path packets take form end to end (L3). In other discussions it seems to be what next-hop proxy should a SIP message be forwarded to (L5). In some cases I think lots of us are confused about = which type of routing is being referenced. I would like to propose that ROUTING be a term that defines the path = that packets will take and that we refrain from using the term ROUTING in = regards to selection of next-hop proxies. For selection of next-hop proxies -- why not suggest SERVICE PATH. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing = information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > 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 Tue Apr 04 17:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQskb-0008Kd-E9; Tue, 04 Apr 2006 17:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQska-0008J2-HK for speermint@ietf.org; Tue, 04 Apr 2006 17:07:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQskY-00017I-WA for speermint@ietf.org; Tue, 04 Apr 2006 17:07:44 -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] Reachability Date: Tue, 4 Apr 2006 23:08:03 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C496F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABttsEAABK6G3 From: "Stastny Richard" To: , "Malas, Daryl" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 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 Brian, =20 my condolences regarding your headache, but welcome to the club ;-) =20 I agree with everything you said, but having these kind of discussions since apprx. three years (first with ENUM, then with IMS people and now = in speermint) the whole issue pops up again and again >Why are we making this harder that it seems to need to be? sigh, good question any answers? =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 04.04.2006 22:44 An: Stastny Richard; 'Malas, Daryl'; 'Hadriel Kaplan'; 'Patrick = Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Sorry, my head is hurting. First of all, for peering to work, the peers have to be in the same = address space, at least the part facing the peering point. Does it matter to us what address space that is? Clearly, if it was the Internet, it has to work, but if, for example, the peering "fabric" is it's own private = address space, so what? What in the documents needs to care about address space other than = something that states the obvious (peers have to be in the same address space)? And then we get to ENUM. Who the heck cares where the database is as = long as the entity querying it is in the same address space? If the database is in the O network, which is a completely private = network, who cares as long as it's an O-entity that does the ENUM dip? If the database is in the peering address space, wherever that is, who = cares as long as the entity doing the dip is in that address space? What in the documents has to worry about what address space the DNS = database is in as long as it's accessible by the entity that needs it? Clearly, if the DATA itself is public data (real ENUM or some form of carrier enum in the e164.arpa tree), then at least a part of the DNS = system has to be connected to the public internet, but we all know of systems = that suck data from a public side while serving clients on a private side. Why are we making this harder that it seems to need to be? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing = information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 17:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsoJ-00035t-Lj; Tue, 04 Apr 2006 17:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsoI-00035m-3J for speermint@ietf.org; Tue, 04 Apr 2006 17:11:34 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQsoG-0001Op-J1 for speermint@ietf.org; Tue, 04 Apr 2006 17:11:34 -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] Reachability Date: Tue, 4 Apr 2006 23:12:57 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4970@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAAUGYQAADYeOMABrR4MAAAmimQAADkOgg= From: "Stastny Richard" To: , "Patrick Melampy" , "Malas, Daryl" , "Hadriel Kaplan" , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f 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 >You can call it "l3 routing" or "packet routing" and "l5" or "sip = routing" >or "call routing" if you want =20 This could work, at least in documents where there may arise ambiguity we may use the terms "packet routing" and "session setip routing"(to be = more general ;-) to distinguish =20 Dave? =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Di 04.04.2006 22:53 An: 'Patrick Melampy'; Stastny Richard; 'Malas, Daryl'; 'Hadriel = Kaplan'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability You can't do that because the bell heads and the sip heads use the term "routing" for the act of determining the path call signaling takes. The = L3 guys can't even claim it first, since the bell heads have them by = decades. Trying to get one camp to give up their term is unworkable I think. You can call it "l3 routing" or "packet routing" and "l5" or "sip = routing" or "call routing" if you want. -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Tuesday, April 04, 2006 4:34 PM To: 'Stastny Richard'; 'Malas, Daryl'; 'Hadriel Kaplan'; 'Reinaldo = Penno'; speermint@ietf.org Subject: RE: [Speermint] Reachability We use the word ROUTING to mean different things. In some discussions it directly refers to the path packets take form end to end (L3). In other discussions it seems to be what next-hop proxy should a SIP message be forwarded to (L5). In some cases I think lots of us are confused about = which type of routing is being referenced. I would like to propose that ROUTING be a term that defines the path = that packets will take and that we refrain from using the term ROUTING in = regards to selection of next-hop proxies. For selection of next-hop proxies -- why not suggest SERVICE PATH. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 1:27 PM To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability Nice analysis, and useful But I think we get more and more down to L2 and L3, but our prime or first goal is to enable peering on L5. to do so, we basically need a common database to get the routing = information Of course any provider can peer with ony other provider bilaterally as he likes, if he has finally found out which VPN or other bi-lateral peering on Ip level he wants to use. He could do this by interrogating his own local databases, (which he has to maintain by himself, spendig a lot of money and making a lot of mistakes) or he may interrogate a common global database e.g. the DNS (both for SRV and ENUM) I know that split horizon DNS may be used, but the drawback of this is that the DNS behind the curtain must be administrated by himself So the prime question in ENUM WG is where to place a globally reachable ENUM DNS and the question in speermint WG is what information has to be placed in the public DNS. Both can only be in the public address spece to be useful, and therefore everybody needs access to thsi address space. If they then do peering by whatever means on l3, so they could Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Di 04.04.2006 19:09 An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Betreff: RE: [Speermint] Reachability Okay, I apologize for jumping into the middle of this, but I wanted to add my two cents. I think by now it should be generally understood, if you want to interconnect with non-RFC1918 address spaces; you need to utilize a method (any number of options, such as STUN, B2BUA, etc...etc...)in order to be addressable and routable on the public registered address space. This being said, I think peering will be applicable in 3 different environments: 1. Public peering (somehow connected and routable by the public internet) a. Public addressable space b. Routed across the public internet c. Media and signaling accessible from the public internet 1. May be encrypted for privacy reasons 2. Authentication mechanisms likely in place 2. Private peering (either public addresses (non-routable to the internet) or RFC1918 address space) a. Public address space -- not routed via the Internet b. RFC1918 address space -- non-NAT req'd c. Little or no security likely implemented d. Not accessible from the public internet (may be accomplished by private tunnels l2TP, PPTP, IPSEC, etc.) 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 or non-RFC1918 address space as necessary) a. Utilizes public or private addresses b. Intended capabilities such as l2vpn or l3vpn for interconnection c. Media and signaling are not accessible from the public internet d. Primarily intended for peering between carriers as opposed to enterprises (this might include "Federations" depending on def.). Does it make sense to break up the issues/requirements based on these 3 different environments? Daryl M. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Tuesday, April 04, 2006 10:45 AM To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] Reachability >Most consumers on the planet Earth are in private address spaces at this >point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire >networks in some countries are privately addressed, yet they are members of, >and use, the Internet. Yes, but if you put your mailserver only in 192.168.x.x, you will get a problem Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Di 04.04.2006 18:22 An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; speermint@ietf.org Betreff: RE: [Speermint] Reachability Hi Richard, And here we get to the fun stuff. :) The idea of every serving proxy/registrar/sip-node needing to be publicly addressable is neither an Internet requirement, nor a requirement of the IETF. Entire working groups in the IETF concern themselves with allowing, enabling, and inter-working private address spaces and VPNs. What's missing is how to join them at the application and transport layer, when that application layer embeds addressing in itself. Most consumers on the planet Earth are in private address spaces at this point I think (i.e., 192.168.x.x), and many Enterprises are as well. Entire networks in some countries are privately addressed, yet they are members of, and use, the Internet. There are also now 2 disjoint address groups defined by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to provide interoperation/migration support for them, but that typically requires intermediaries. So I agree with you there needs to be an entity providing an ingress (and egress) point(s), either on the public network for it to be public, or for it to cross into another private address domain. For this WG's purpose, I recommend we allow either model to work, as well as the model of the private going to public (and vice-versa) so long as the peering element of both sides are in the same public or private space. -Hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 9:55 AM > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; speermint@ietf.org > Subject: Re: [Speermint] Reachability > > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. > > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private > network, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this > case) > (see DNS). this private network may even use public IP adresses, but if > the > are not routable from the public Internet, they are could as well be > private > (example IPX) > > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have > one > ingress element on the public network > > Richard > > ________________________________ > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Gesendet: Di 04.04.2006 15:29 > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Reinaldo -- I agree with your assertions. > > But I want to ensure everybody understands what your really saying here. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > This means that for carrier to carrier peering models, each and every > customer of every carrier that wants to inter-connect needs to have a > 'public NAT binding'. > > I believe by extension, this means that a serving proxy/registrar for the > target of a communication must ALSO have either a public address or a > public > NAT binding. > > The conclusion here -- every endpoint and every serving proxy/registrar > needs to be publicly addressable. > > Am I correct? > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Tuesday, April 04, 2006 5:29 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Hello Hadriel, > > Comment inline.... > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Monday, April 03, 2006 11:01 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Reinaldo, > > Comments inline... > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > Maybe I'm missing something, but given that this workgroup is > interested > > > only in call routing (E.164 is out of scope), do we really need to > care > > > about that? An AoR in the end will be translated to an IP address, > and > > > IP addresses have a very good definition of public and private (in > IPv4 > > > and IPv6). > > > > I don't understand fully what you mean. An AoR is only fully > "translated" > > to an IP Address (and really to a contact URI) by the AoR's domain. > So > > what > > you're saying is if the AoR's user-part represents a consumer behind a > > home > > NAT (a private IP), then it is a private AoR; but for those consumers > who > > don't use home-NATs then it's a public AoR? > [[Reinaldo]] > > Hello, > > Actually I'm trying to understand the whole purpose of the discussion, > that's why I gave that example. I was trying to understand why it > matters, before getting knee deep into the classification. Can someone > refresh that for me? > > So, if SIP peering is going to get woven into the fabric of the > internet, the rules for domains names, DNS resolution, private vs. > public IP address, etc should apply, right? > > I believe the current model of host to host or email communication is > not different for SIP. We could have the following main > situations...(correct me where I'm wrong). > > 1) The AoR (just like a traditional domain name or email), in the end > will get resolved into an IP address. Then there are only two > situations. > > a) the IP address is private (RFC 1918). > > This means the SIP endpoint is unreachable unless you are also in the > same private network. Actually I believe a private IP address cannot > even be provisioned in a public DNS. > > Before somebody mentions it...for a UA behind a NAT to be reachable, > he/she needs a public NAT binding so that a session _initiated_ from the > public side can be made to him/her. > > b) the IP address is public. > > The SIP endpoint is theoretically reachable. > > 2) The AoR cannot get translated. Again, just like the Internet we have > today, this means the domain name/user is private, does not exist, etc > > All this has been happening okay with just a few basic rules. If an AoR > is very similar to an email address, why it would not work with the > current infrastructure/definitions? > > If somebody says that they have a "private" email address or domain > name, what is your interpretation of that? > > Regards, > > Reinaldo > > > > > > > And if the AoR gets > > translated > > into an IP by a registrar inside a private IP subnet, and somehow it > later > > gets translated into the public IP address space, that's also private > > because the AoR was translated to a private IP originally? > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > For you to be "SIP reachable", you need to be IP reachable first, > let's > > > not forget about that. And if you are IP reachable, you could > > > potentially be SIP reachable by registering to some free SIP service > (or > > > the SIP "domain" above you in the hierarchy...if this was the > email/DNS > > > model). > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > reachable" but not IP reachable. But I think for now we should ignore > the > > implications of that, unless it becomes a problem. > > > > -hadriel > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 04 23:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQygu-00025v-Gj; Tue, 04 Apr 2006 23:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQygt-00025n-KK for speermint@ietf.org; Tue, 04 Apr 2006 23:28:19 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQygs-0007tK-M0 for speermint@ietf.org; Tue, 04 Apr 2006 23:28:19 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k353S7Bf016425; Tue, 4 Apr 2006 20:28:07 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k353RrVP016424; Tue, 4 Apr 2006 20:27:53 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 4 Apr 2006 20:27:53 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] Reachability Message-ID: <20060405032753.GA16405@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C4970@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4970@oefeg-s04.oefeg.loc> 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: 089da5e32269fece1072c9ff54523f20 Cc: speermint@ietf.org, "Malas, Daryl" 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="===============1255909820==" Errors-To: speermint-bounces@ietf.org --===============1255909820== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 04, 2006 at 11:12:57PM +0200, Stastny Richard wrote: > >You can call it "l3 routing" or "packet routing" and "l5" or "sip routin= g" > >or "call routing" if you want > =20 > This could work, at least in documents where there may arise ambiguity > we may use the terms "packet routing" and "session setip routing"(to be m= ore general ;-) > to distinguish > =20 > Dave? If you mean me Dave, let me look at what we have and see if this approach could clarify things. Its in the queue. Dave =09 > =20 > Richard >=20 > ________________________________ >=20 > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Di 04.04.2006 22:53 > An: 'Patrick Melampy'; Stastny Richard; 'Malas, Daryl'; 'Hadriel Kaplan';= 'Reinaldo Penno'; speermint@ietf.org > Betreff: RE: [Speermint] Reachability >=20 >=20 >=20 > You can't do that because the bell heads and the sip heads use the term > "routing" for the act of determining the path call signaling takes. The = L3 > guys can't even claim it first, since the bell heads have them by decades. > Trying to get one camp to give up their term is unworkable I think. >=20 > You can call it "l3 routing" or "packet routing" and "l5" or "sip routing" > or "call routing" if you want. >=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Tuesday, April 04, 2006 4:34 PM > To: 'Stastny Richard'; 'Malas, Daryl'; 'Hadriel Kaplan'; 'Reinaldo Penno'; > speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > We use the word ROUTING to mean different things. In some discussions it > directly refers to the path packets take form end to end (L3). In other > discussions it seems to be what next-hop proxy should a SIP message be > forwarded to (L5). In some cases I think lots of us are confused about wh= ich > type of routing is being referenced. >=20 > I would like to propose that ROUTING be a term that defines the path that > packets will take and that we refrain from using the term ROUTING in rega= rds > to selection of next-hop proxies. >=20 > For selection of next-hop proxies -- why not suggest SERVICE PATH. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 1:27 PM > To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > Nice analysis, and useful >=20 > But I think we get more and more down to L2 and L3, but our prime > or first goal is to enable peering on L5. > to do so, we basically need a common database to get the routing informat= ion >=20 > Of course any provider can peer with ony other provider bilaterally > as he likes, if he has finally found out which VPN or other bi-lateral > peering on Ip level he wants to use. >=20 > He could do this by interrogating his own local databases, > (which he has to maintain by himself, spendig a lot of money and > making a lot of mistakes) or he may interrogate a common global database > e.g. the DNS (both for SRV and ENUM) >=20 > I know that split horizon DNS may be used, but the drawback of > this is that the DNS behind the curtain must be administrated by himself >=20 > So the prime question in ENUM WG is where to place a globally > reachable ENUM DNS and the question in speermint WG is what > information has to be placed in the public DNS. >=20 > Both can only be in the public address spece to be useful, and > therefore everybody needs access to thsi address space. >=20 > If they then do peering by whatever means on l3, so they could >=20 > Richard >=20 > ________________________________ >=20 > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Di 04.04.2006 19:09 > An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability >=20 >=20 >=20 > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents. I think by now it should be generally understood, if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: >=20 > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection > c. Media and signaling are not accessible from the public > internet > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). >=20 > Does it make sense to break up the issues/requirements based on these 3 > different environments? >=20 > Daryl M. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Tuesday, April 04, 2006 10:45 AM > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > >Most consumers on the planet Earth are in private address spaces at > this > >point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > >networks in some countries are privately addressed, yet they are > members of, > >and use, the Internet. >=20 > Yes, but if you put your mailserver only in 192.168.x.x, you will get a > problem >=20 > Richard >=20 > ________________________________ >=20 > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability >=20 >=20 >=20 > Hi Richard, > And here we get to the fun stuff. :) >=20 > The idea of every serving proxy/registrar/sip-node needing to be > publicly > addressable is neither an Internet requirement, nor a requirement of the > IETF. Entire working groups in the IETF concern themselves with > allowing, > enabling, and inter-working private address spaces and VPNs. What's > missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. >=20 > Most consumers on the planet Earth are in private address spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are as well. > Entire > networks in some countries are privately addressed, yet they are members > of, > and use, the Internet. There are also now 2 disjoint address groups > defined > by the IETF, as you know: IPv4 and IPv6. There are mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. >=20 > So I agree with you there needs to be an entity providing an ingress > (and > egress) point(s), either on the public network for it to be public, or > for > it to cross into another private address domain. For this WG's purpose, > I > recommend we allow either model to work, as well as the model of the > private > going to public (and vice-versa) so long as the peering element of both > sides are in the same public or private space. >=20 > -Hadriel >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to everybody. > > This was also why I had a problem with Sohel's presentation at the > IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities in a private > > network, > > but it is not out task to consider this separately. Because if it > works > > on the Internet, it also works in a private network (extranet in this > > case) > > (see DNS). this private network may even use public IP adresses, but > if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the public > network > > and one on a private network. The private entities need at least to > have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really saying > here. > > > > Before somebody mentions it...for a UA behind a NAT to be reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each and every > > customer of every carrier that wants to inter-connect needs to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving proxy/registrar for > the > > target of a communication must ALSO have either a public address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we really need to > > care > > > > about that? An AoR in the end will be translated to an IP address, > > and > > > > IP addresses have a very good definition of public and private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a consumer behind > a > > > home > > > NAT (a private IP), then it is a private AoR; but for those > consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you are also in > the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session _initiated_ from > the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the Internet we > have > > today, this means the domain name/user is private, does not exist, etc > > > > All this has been happening okay with just a few basic rules. If an > AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and somehow it > > later > > > gets translated into the public IP address space, that's also > private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some free SIP > service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR can be "sip > > > reachable" but not IP reachable. But I think for now we should > ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > 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 >=20 >=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 >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFEMzk5ORgD1qCZ2KcRAhgsAJ9H5Dguyfr1lFq8V6sBDVcLYoTnWgCY2b1T K26o4fn5pfY6a582dC66pQ== =BzM+ -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- --===============1255909820== 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 --===============1255909820==-- From speermint-bounces@ietf.org Wed Apr 05 00:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQzz3-0006Fd-Av; Wed, 05 Apr 2006 00:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQzz2-0006FY-0Y for speermint@ietf.org; Wed, 05 Apr 2006 00:51:08 -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 1FQzyz-0002g1-Ot for speermint@ietf.org; Wed, 05 Apr 2006 00:51:07 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.18342221; Wed, 05 Apr 2006 00:50:50 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 00:50:50 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Wed, 5 Apr 2006 00:50:43 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247D94@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wADz0ALAABT4E8AAWq7GQABZq43AACjelcAAAvbyqAATKgxAAAW5uuQAY562g From: "Livingood, Jason" To: "Stastny Richard" , "Hadriel Kaplan" , "Patrick Melampy" , "Reinaldo Penno" , X-OriginalArrivalTime: 05 Apr 2006 04:50:50.0259 (UTC) FILETIME=[82E7F630:01C6586C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > >Most consumers on the planet Earth are in private address spaces at=20 > >this point I think (i.e., 192.168.x.x), and many Enterprises are as=20 > >well. Entire networks in some countries are privately=20 > addressed, yet=20 > >they are members of, and use, the Internet. > =20 > Yes, but if you put your mailserver only in 192.168.x.x, you=20 > will get a problem But this is an excellent example. I may publish a single MX record for my inbound email MTAs. That is a port 25 load balancer virtual IP for example. Behind it is a private IP space of a hundred anti-spam / anti-virus MTAs, behind which may be dozens of mailstores. A domain, for legitimate purposes, may not reveal all of that in publicly routable space (or if it does, perhaps the routes are unannounced), but the ingress point and associated addressing *must* be public (as with egress) if one intendes to exchanges messages with the outside world via the Internet. Hence, your discussion of a public address of record that translates into a publically-addressed element of some kind. I believe similar service provider (domain) examples may be found in SIP peering as we progress our work. And there will be everything else in between as well. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 05:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Ey-0006AF-Gs; Wed, 05 Apr 2006 05:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4Ex-00067d-23 for speermint@ietf.org; Wed, 05 Apr 2006 05:23:51 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4Ev-0005HK-Jg for speermint@ietf.org; Wed, 05 Apr 2006 05:23:51 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k359Nm0P027579 for ; Wed, 5 Apr 2006 04:23:48 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Apr 2006 10:23:48 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0129680D2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 10:23:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 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 to support Richard on this. Please avoid using the term "SBC" in the speermint area. Please clearly identify the function of these supposed wonder boxes that you are addressing as an area of concern or advantage. Therefore if you mean NAT, say NAT, if you mean firewall, say firewall, if you mean something else, say so. These boxes contain so many features (in the widest sense of the word) that in the absence of specific information we get lost. regards Keith > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: 04 April 2006 18:15 > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > speermint@ietf.org > Subject: [Speermint] NATs and Firewalls > > > I think some people out there either do not understand > the difference between NATs and firewalls or are starting > to believe their own propaganda > > NATs are NATs and firewalls are firewalls > > The worst misconception here is that a NAT is for providing > you security > against the bad Internet > > Private adress spaces have been introduced to save a scarce ressource > (or what some believed are a scarce ressource at some point of time) > > You can live very safe behind a properly configured firewall > using only > public IP adresses. > > The basic idea of IPv6 was to give every device on earth and also > within the solar system a unique public IP address > > But the fake security of NATs was already in the minds of > most people, that the first things that were implemented > in IPv6 where NATs for IPv6, which is a perversion > > Geoff Huston had once a nice eleborate on this in an IETF paper > > Richard > > ________________________________ > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Di 04.04.2006 18:22 > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Betreff: RE: [Speermint] Reachability > > > > Hi Richard, > And here we get to the fun stuff. :) > > The idea of every serving proxy/registrar/sip-node needing to > be publicly > addressable is neither an Internet requirement, nor a > requirement of the > IETF. Entire working groups in the IETF concern themselves > with allowing, > enabling, and inter-working private address spaces and VPNs. > What's missing > is how to join them at the application and transport layer, when that > application layer embeds addressing in itself. > > Most consumers on the planet Earth are in private address > spaces at this > point I think (i.e., 192.168.x.x), and many Enterprises are > as well. Entire > networks in some countries are privately addressed, yet they > are members of, > and use, the Internet. There are also now 2 disjoint address > groups defined > by the IETF, as you know: IPv4 and IPv6. There are > mechanisms to try to > provide interoperation/migration support for them, but that typically > requires intermediaries. > > So I agree with you there needs to be an entity providing an > ingress (and > egress) point(s), either on the public network for it to be > public, or for > it to cross into another private address domain. For this > WG's purpose, I > recommend we allow either model to work, as well as the model > of the private > going to public (and vice-versa) so long as the peering > element of both > sides are in the same public or private space. > > -Hadriel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 04, 2006 9:55 AM > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > >The conclusion here -- every endpoint and every serving > proxy/registrar > > >needs to be publicly addressable. > > > > This was my basic assumption, and I seemed not so clear to > everybody. > > This was also why I had a problem with Sohel's presentation > at the IETF, > > because I did not see any public adressable entities AT ALL. > > > > For the avoidance of doubt: I have no problem if the same peering > > principles we develop here are used between some entities > in a private > > network, > > but it is not out task to consider this separately. Because > if it works > > on the Internet, it also works in a private network > (extranet in this > > case) > > (see DNS). this private network may even use public IP > adresses, but if > > the > > are not routable from the public Internet, they are could as well be > > private > > (example IPX) > > > > What never can work is a peering between one entity on the > public network > > and one on a private network. The private entities need at > least to have > > one > > ingress element on the public network > > > > Richard > > > > ________________________________ > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Gesendet: Di 04.04.2006 15:29 > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Reinaldo -- I agree with your assertions. > > > > But I want to ensure everybody understands what your really > saying here. > > > > Before somebody mentions it...for a UA behind a NAT to be > reachable, > > he/she needs a public NAT binding so that a session > _initiated_ from the > > public side can be made to him/her. > > > > This means that for carrier to carrier peering models, each > and every > > customer of every carrier that wants to inter-connect needs > to have a > > 'public NAT binding'. > > > > I believe by extension, this means that a serving > proxy/registrar for the > > target of a communication must ALSO have either a public > address or a > > public > > NAT binding. > > > > The conclusion here -- every endpoint and every serving > proxy/registrar > > needs to be publicly addressable. > > > > Am I correct? > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Tuesday, April 04, 2006 5:29 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hello Hadriel, > > > > Comment inline.... > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Monday, April 03, 2006 11:01 PM > > > To: Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Reinaldo, > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > interested > > > > only in call routing (E.164 is out of scope), do we > really need to > > care > > > > about that? An AoR in the end will be translated to an > IP address, > > and > > > > IP addresses have a very good definition of public and > private (in > > IPv4 > > > > and IPv6). > > > > > > I don't understand fully what you mean. An AoR is only fully > > "translated" > > > to an IP Address (and really to a contact URI) by the > AoR's domain. > > So > > > what > > > you're saying is if the AoR's user-part represents a > consumer behind a > > > home > > > NAT (a private IP), then it is a private AoR; but for > those consumers > > who > > > don't use home-NATs then it's a public AoR? > > [[Reinaldo]] > > > > Hello, > > > > Actually I'm trying to understand the whole purpose of the > discussion, > > that's why I gave that example. I was trying to understand why it > > matters, before getting knee deep into the classification. > Can someone > > refresh that for me? > > > > So, if SIP peering is going to get woven into the fabric of the > > internet, the rules for domains names, DNS resolution, private vs. > > public IP address, etc should apply, right? > > > > I believe the current model of host to host or email > communication is > > not different for SIP. We could have the following main > > situations...(correct me where I'm wrong). > > > > 1) The AoR (just like a traditional domain name or email), > in the end > > will get resolved into an IP address. Then there are only two > > situations. > > > > a) the IP address is private (RFC 1918). > > > > This means the SIP endpoint is unreachable unless you > are also in the > > same private network. Actually I believe a private IP address cannot > > even be provisioned in a public DNS. > > > > Before somebody mentions it...for a UA behind a NAT to > be reachable, > > he/she needs a public NAT binding so that a session > _initiated_ from the > > public side can be made to him/her. > > > > b) the IP address is public. > > > > The SIP endpoint is theoretically reachable. > > > > 2) The AoR cannot get translated. Again, just like the > Internet we have > > today, this means the domain name/user is private, does not > exist, etc > > > > All this has been happening okay with just a few basic > rules. If an AoR > > is very similar to an email address, why it would not work with the > > current infrastructure/definitions? > > > > If somebody says that they have a "private" email address or domain > > name, what is your interpretation of that? > > > > Regards, > > > > Reinaldo > > > > > > > > > > > > > > And if the AoR gets > > > translated > > > into an IP by a registrar inside a private IP subnet, and > somehow it > > later > > > gets translated into the public IP address space, that's > also private > > > because the AoR was translated to a private IP originally? > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > For you to be "SIP reachable", you need to be IP > reachable first, > > let's > > > > not forget about that. And if you are IP reachable, you could > > > > potentially be SIP reachable by registering to some > free SIP service > > (or > > > > the SIP "domain" above you in the hierarchy...if this was the > > email/DNS > > > > model). > > > > > > Actually, to be very specific ultimate target of the AoR > can be "sip > > > reachable" but not IP reachable. But I think for now we > should ignore > > the > > > implications of that, unless it becomes a problem. > > > > > > -hadriel > > > > _______________________________________________ > > 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 Apr 05 08:36:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7FF-00019R-Ns; Wed, 05 Apr 2006 08:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7FE-00019M-DO for speermint@ietf.org; Wed, 05 Apr 2006 08:36:20 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7FD-0004TO-5V for speermint@ietf.org; Wed, 05 Apr 2006 08:36:20 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc13) with SMTP id <20060405123618m13003nop3e>; Wed, 5 Apr 2006 12:36:18 +0000 Message-ID: <070001c658ad$37969600$ea087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <475FF955A05DD411980D00508B6D5FB0129680D2@en0033exch001u.uk.lucent.com> Subject: Re: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 07:34:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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 And if people avoided using the term "SBC" anywhere in RAI, that would be lovely, too, for exactly the reasons that Keith cited (we don't get smarter in other RAI working groups :-) Thanks, Spencer From: "Drage, Keith (Keith)" To: Sent: Wednesday, April 05, 2006 4:23 AM Subject: RE: [Speermint] NATs and Firewalls > And to support Richard on this. > > Please avoid using the term "SBC" in the speermint area. Please clearly > identify the function of these supposed wonder boxes that you are > addressing as an area of concern or advantage. Therefore if you mean NAT, > say NAT, if you mean firewall, say firewall, if you mean something else, > say so. These boxes contain so many features (in the widest sense of the > word) that in the absence of specific information we get lost. > > regards > > Keith _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 09:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR84e-0001Rv-ME; Wed, 05 Apr 2006 09:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR84d-0001Rq-Jn for speermint@ietf.org; Wed, 05 Apr 2006 09:29:27 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR84a-0006c8-9C for speermint@ietf.org; Wed, 05 Apr 2006 09:29:27 -0400 Received: from PMelampy [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A62E037C; Wed, 05 Apr 2006 09:29:18 -0400 From: "Patrick Melampy" To: "'Spencer Dawkins'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 09:29:19 -0400 Message-ID: <027901c658b4$f1809050$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYrY+xvS9fpXG5TyK7XWySFV//TwABylvw In-Reply-To: <070001c658ad$37969600$ea087c0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 What should we call the function(s) that an SBC provides? How about... Edge Proxy/NAPT/Media Proxy/Security Firewall -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] Sent: Wednesday, April 05, 2006 8:34 AM To: speermint@ietf.org Subject: Re: [Speermint] NATs and Firewalls And if people avoided using the term "SBC" anywhere in RAI, that would be lovely, too, for exactly the reasons that Keith cited (we don't get smarter in other RAI working groups :-) Thanks, Spencer From: "Drage, Keith (Keith)" To: Sent: Wednesday, April 05, 2006 4:23 AM Subject: RE: [Speermint] NATs and Firewalls > And to support Richard on this. > > Please avoid using the term "SBC" in the speermint area. Please clearly > identify the function of these supposed wonder boxes that you are > addressing as an area of concern or advantage. Therefore if you mean NAT, > say NAT, if you mean firewall, say firewall, if you mean something else, > say so. These boxes contain so many features (in the widest sense of the > word) that in the absence of specific information we get lost. > > regards > > Keith _______________________________________________ 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 Apr 05 09:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR87Q-0001mh-NO; Wed, 05 Apr 2006 09:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR87P-0001mc-C0 for speermint@ietf.org; Wed, 05 Apr 2006 09:32:19 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR87N-0006hw-09 for speermint@ietf.org; Wed, 05 Apr 2006 09:32:19 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 05 Apr 2006 06:32:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k35DWF7T002069; Wed, 5 Apr 2006 06:32:15 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 06:32:15 -0700 Received: from [24.120.193.53] ([10.21.80.197]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 06:32:14 -0700 Message-ID: <4433C6DE.7000206@cisco.com> Date: Wed, 05 Apr 2006 09:32:14 -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: Hadriel Kaplan Subject: Re: [Speermint] RE: NATs and Firewalls References: <04e301c6580f$dee1c6d0$6501a8c0@acmepacket.com> In-Reply-To: <04e301c6580f$dee1c6d0$6501a8c0@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2006 13:32:14.0839 (UTC) FILETIME=[59F80870:01C658B5] 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 Hadriel Kaplan wrote: > Hi Richard, > I hope you're not referring to me. > Who said anything about NATs providing security? They don't, plain and > simple. Well, that is false. One of the properties of a NAT (see the behave documents, draft-ietf-behave-nat-udp and draft-ietf-behave-tcp) is that they have the notion of a permission, which decides whether a packet from the outside gets let into the inside. Permissions are established by a NAT through the transmission of a packet from the inside to the outside. As a consequence, NATs do in fact block incoming packets unless they correspond to a permission created from sending a packet out. This is most definitely a form of firewall. It will, for example, prevent a port probe from hitting machines behind the NAT. It will prevent a machine on the outside from sending packets to specific service ports. And so on. A firewall will generally have more complex policies about what packets get let in (and out). Note that a firewall can in fact have the same permission rules that a NAT implements, without the translation function, and they will have very similar security properties. Folks also claim that NAT provides security by obfuscating the network behind the NAT. An attacker cannot determine how many hosts are behind the nat, and it never sees any of their addresses. I'm skeptical that this is a real security benefit, but hiding of internal topology and internal addresses is often cited as a security feature; YMMV. -Jonathan R. -- 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 Wed Apr 05 09:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8RZ-0001RG-Jw; Wed, 05 Apr 2006 09:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8RY-0001R1-UN for speermint@ietf.org; Wed, 05 Apr 2006 09:53:08 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8RV-00075C-Mg for speermint@ietf.org; Wed, 05 Apr 2006 09:53:08 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc11) with SMTP id <20060405135304m110003bt0e>; Wed, 5 Apr 2006 13:53:04 +0000 Message-ID: <077101c658b7$f12103d0$ea087c0a@china.huawei.com> From: "Spencer Dawkins" To: "Patrick Melampy" , References: <027901c658b4$f1809050$9dc8000a@acmepacket.com> Subject: Re: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 08:50:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 As Keith said - this list of functions should have been at least two or three lines long for most SBC products, and there is no standard list offered by all SBCs. This is, of course, WHY we need to avoid using the word "SBC" as if we had agreement on what SBCs do, and do not, provide. Spencer > What should we call the function(s) that an SBC provides? How about... > > Edge Proxy/NAPT/Media Proxy/Security Firewall _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 09:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8XQ-00027C-Ui; Wed, 05 Apr 2006 09:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8XP-000275-K2 for speermint@ietf.org; Wed, 05 Apr 2006 09:59:11 -0400 Received: from smtpout.eastlink.ca ([24.222.0.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8XO-0007EJ-Vs for speermint@ietf.org; Wed, 05 Apr 2006 09:59:11 -0400 Received: from ip03.eastlink.ca ([24.222.10.15]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IX900D4G5I8T0Y0@mta01.eastlink.ca> for speermint@ietf.org; Wed, 05 Apr 2006 10:58:56 -0300 (ADT) Received: from blk-222-186-219.eastlink.ca (HELO IBM-7B137D96EC3.ZDSL.com) ([24.222.186.219]) by ip03.eastlink.ca with ESMTP; Wed, 05 Apr 2006 10:59:09 -0300 Date: Wed, 05 Apr 2006 09:59:00 -0400 From: Peter Macaulay Subject: RE: [Speermint] NATs and Firewalls In-reply-to: <475FF955A05DD411980D00508B6D5FB0129680D2@en0033exch001u.uk.lucent.com> To: "Drage, Keith (Keith)" , speermint@ietf.org Message-id: <7.0.0.16.2.20060405093635.066d1c08@ZDSL.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 (Beta) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= References: <475FF955A05DD411980D00508B6D5FB0129680D2@en0033exch001u.uk.lucent.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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 Agree. Let's avoid the term "SBC" in the speermint area. We don't need the history lesson and the term is still evolving. I just finished a Skype call and did not use a SBC to peer with my one in 6 million users. Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, Security Firewall and NAT/firewall traversal. /PETER MACAULAY At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >And to support Richard on this. > >Please avoid using the term "SBC" in the speermint area. Please >clearly identify the function of these supposed wonder boxes that >you are addressing as an area of concern or advantage. Therefore if >you mean NAT, say NAT, if you mean firewall, say firewall, if you >mean something else, say so. These boxes contain so many features >(in the widest sense of the word) that in the absence of specific >information we get lost. > >regards > >Keith > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: 04 April 2006 18:15 > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > speermint@ietf.org > > Subject: [Speermint] NATs and Firewalls > > > > > > I think some people out there either do not understand > > the difference between NATs and firewalls or are starting > > to believe their own propaganda > > > > NATs are NATs and firewalls are firewalls > > > > The worst misconception here is that a NAT is for providing > > you security > > against the bad Internet > > > > Private adress spaces have been introduced to save a scarce ressource > > (or what some believed are a scarce ressource at some point of time) > > > > You can live very safe behind a properly configured firewall > > using only > > public IP adresses. > > > > The basic idea of IPv6 was to give every device on earth and also > > within the solar system a unique public IP address > > > > But the fake security of NATs was already in the minds of > > most people, that the first things that were implemented > > in IPv6 where NATs for IPv6, which is a perversion > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > Richard > > > > ________________________________ > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Gesendet: Di 04.04.2006 18:22 > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Hi Richard, > > And here we get to the fun stuff. :) > > > > The idea of every serving proxy/registrar/sip-node needing to > > be publicly > > addressable is neither an Internet requirement, nor a > > requirement of the > > IETF. Entire working groups in the IETF concern themselves > > with allowing, > > enabling, and inter-working private address spaces and VPNs. > > What's missing > > is how to join them at the application and transport layer, when that > > application layer embeds addressing in itself. > > > > Most consumers on the planet Earth are in private address > > spaces at this > > point I think (i.e., 192.168.x.x), and many Enterprises are > > as well. Entire > > networks in some countries are privately addressed, yet they > > are members of, > > and use, the Internet. There are also now 2 disjoint address > > groups defined > > by the IETF, as you know: IPv4 and IPv6. There are > > mechanisms to try to > > provide interoperation/migration support for them, but that typically > > requires intermediaries. > > > > So I agree with you there needs to be an entity providing an > > ingress (and > > egress) point(s), either on the public network for it to be > > public, or for > > it to cross into another private address domain. For this > > WG's purpose, I > > recommend we allow either model to work, as well as the model > > of the private > > going to public (and vice-versa) so long as the peering > > element of both > > sides are in the same public or private space. > > > > -Hadriel > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > >The conclusion here -- every endpoint and every serving > > proxy/registrar > > > >needs to be publicly addressable. > > > > > > This was my basic assumption, and I seemed not so clear to > > everybody. > > > This was also why I had a problem with Sohel's presentation > > at the IETF, > > > because I did not see any public adressable entities AT ALL. > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > principles we develop here are used between some entities > > in a private > > > network, > > > but it is not out task to consider this separately. Because > > if it works > > > on the Internet, it also works in a private network > > (extranet in this > > > case) > > > (see DNS). this private network may even use public IP > > adresses, but if > > > the > > > are not routable from the public Internet, they are could as well be > > > private > > > (example IPX) > > > > > > What never can work is a peering between one entity on the > > public network > > > and one on a private network. The private entities need at > > least to have > > > one > > > ingress element on the public network > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Gesendet: Di 04.04.2006 15:29 > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > But I want to ensure everybody understands what your really > > saying here. > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > This means that for carrier to carrier peering models, each > > and every > > > customer of every carrier that wants to inter-connect needs > > to have a > > > 'public NAT binding'. > > > > > > I believe by extension, this means that a serving > > proxy/registrar for the > > > target of a communication must ALSO have either a public > > address or a > > > public > > > NAT binding. > > > > > > The conclusion here -- every endpoint and every serving > > proxy/registrar > > > needs to be publicly addressable. > > > > > > Am I correct? > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > To: Hadriel Kaplan; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hello Hadriel, > > > > > > Comment inline.... > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > To: Reinaldo Penno; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hi Reinaldo, > > > > Comments inline... > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > interested > > > > > only in call routing (E.164 is out of scope), do we > > really need to > > > care > > > > > about that? An AoR in the end will be translated to an > > IP address, > > > and > > > > > IP addresses have a very good definition of public and > > private (in > > > IPv4 > > > > > and IPv6). > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > "translated" > > > > to an IP Address (and really to a contact URI) by the > > AoR's domain. > > > So > > > > what > > > > you're saying is if the AoR's user-part represents a > > consumer behind a > > > > home > > > > NAT (a private IP), then it is a private AoR; but for > > those consumers > > > who > > > > don't use home-NATs then it's a public AoR? > > > [[Reinaldo]] > > > > > > Hello, > > > > > > Actually I'm trying to understand the whole purpose of the > > discussion, > > > that's why I gave that example. I was trying to understand why it > > > matters, before getting knee deep into the classification. > > Can someone > > > refresh that for me? > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > internet, the rules for domains names, DNS resolution, private vs. > > > public IP address, etc should apply, right? > > > > > > I believe the current model of host to host or email > > communication is > > > not different for SIP. We could have the following main > > > situations...(correct me where I'm wrong). > > > > > > 1) The AoR (just like a traditional domain name or email), > > in the end > > > will get resolved into an IP address. Then there are only two > > > situations. > > > > > > a) the IP address is private (RFC 1918). > > > > > > This means the SIP endpoint is unreachable unless you > > are also in the > > > same private network. Actually I believe a private IP address cannot > > > even be provisioned in a public DNS. > > > > > > Before somebody mentions it...for a UA behind a NAT to > > be reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > b) the IP address is public. > > > > > > The SIP endpoint is theoretically reachable. > > > > > > 2) The AoR cannot get translated. Again, just like the > > Internet we have > > > today, this means the domain name/user is private, does not > > exist, etc > > > > > > All this has been happening okay with just a few basic > > rules. If an AoR > > > is very similar to an email address, why it would not work with the > > > current infrastructure/definitions? > > > > > > If somebody says that they have a "private" email address or domain > > > name, what is your interpretation of that? > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > translated > > > > into an IP by a registrar inside a private IP subnet, and > > somehow it > > > later > > > > gets translated into the public IP address space, that's > > also private > > > > because the AoR was translated to a private IP originally? > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > For you to be "SIP reachable", you need to be IP > > reachable first, > > > let's > > > > > not forget about that. And if you are IP reachable, you could > > > > > potentially be SIP reachable by registering to some > > free SIP service > > > (or > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > email/DNS > > > > > model). > > > > > > > > Actually, to be very specific ultimate target of the AoR > > can be "sip > > > > reachable" but not IP reachable. But I think for now we > > should ignore > > > the > > > > implications of that, unless it becomes a problem. > > > > > > > > -hadriel > > > > > > _______________________________________________ > > > 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 Apr 05 10:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9EJ-0002sG-9r; Wed, 05 Apr 2006 10:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9EI-0002rp-BE for speermint@ietf.org; Wed, 05 Apr 2006 10:43:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9EH-0001H8-In for speermint@ietf.org; Wed, 05 Apr 2006 10:43:30 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2006 07:43:29 -0700 X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="1791975610:sNHT36390720" 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 k35EhSYg003202; Wed, 5 Apr 2006 07:43:28 -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.211); Wed, 5 Apr 2006 10:43:28 -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] NATs and Firewalls Date: Wed, 5 Apr 2006 10:43:27 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3014A3EBD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuS24skh+1UW2Ramqir6Erdv/ZwABSc+g From: "Michael Hammer \(mhammer\)" To: "Peter Macaulay" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 05 Apr 2006 14:43:28.0372 (UTC) FILETIME=[4D316B40:01C658BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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 Agree. However, even some of the remaining terms are probably overloaded. =20 Is the term "firewall" really atomic?=20 I would try to get as granular as possible to avoid further confusion. At the previous SBC BoF no one could agree on what an SBC included, but could grasp each of the mechanisms once spelled out. Mike > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com]=20 > Sent: Wednesday, April 05, 2006 9:59 AM > To: Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Agree. Let's avoid the term "SBC" in the speermint area. We=20 > don't need the history lesson and the term is still evolving.=20 > I just finished a Skype call and did not use a SBC to peer=20 > with my one in 6 million users. >=20 > Yes, let's just define the requirements ... Edge Proxy, NAPT,=20 > Media Proxy, Security Firewall and NAT/firewall traversal. >=20 > /PETER MACAULAY >=20 > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >And to support Richard on this. > > > >Please avoid using the term "SBC" in the speermint area.=20 > Please clearly=20 > >identify the function of these supposed wonder boxes that you are=20 > >addressing as an area of concern or advantage. Therefore if you mean=20 > >NAT, say NAT, if you mean firewall, say firewall, if you=20 > mean something=20 > >else, say so. These boxes contain so many features (in the=20 > widest sense=20 > >of the word) that in the absence of specific information we get lost. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: 04 April 2006 18:15 > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;=20 > > > speermint@ietf.org > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > I think some people out there either do not understand the=20 > > > difference between NATs and firewalls or are starting to believe=20 > > > their own propaganda > > > > > > NATs are NATs and firewalls are firewalls > > > > > > The worst misconception here is that a NAT is for providing you=20 > > > security against the bad Internet > > > > > > Private adress spaces have been introduced to save a scarce=20 > > > ressource (or what some believed are a scarce ressource at some=20 > > > point of time) > > > > > > You can live very safe behind a properly configured=20 > firewall using=20 > > > only public IP adresses. > > > > > > The basic idea of IPv6 was to give every device on earth and also=20 > > > within the solar system a unique public IP address > > > > > > But the fake security of NATs was already in the minds of most=20 > > > people, that the first things that were implemented in IPv6 where=20 > > > NATs for IPv6, which is a perversion > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Gesendet: Di 04.04.2006 18:22 > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';=20 > > > speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Richard, > > > And here we get to the fun stuff. :) > > > > > > The idea of every serving proxy/registrar/sip-node needing to be=20 > > > publicly addressable is neither an Internet requirement, nor a=20 > > > requirement of the IETF. Entire working groups in the=20 > IETF concern=20 > > > themselves with allowing, enabling, and inter-working private=20 > > > address spaces and VPNs. > > > What's missing > > > is how to join them at the application and transport layer, when=20 > > > that application layer embeds addressing in itself. > > > > > > Most consumers on the planet Earth are in private address=20 > spaces at=20 > > > this point I think (i.e., 192.168.x.x), and many=20 > Enterprises are as=20 > > > well. Entire networks in some countries are privately addressed,=20 > > > yet they are members of, and use, the Internet. There=20 > are also now=20 > > > 2 disjoint address groups defined by the IETF, as you=20 > know: IPv4 and=20 > > > IPv6. There are mechanisms to try to provide=20 > > > interoperation/migration support for them, but that typically=20 > > > requires intermediaries. > > > > > > So I agree with you there needs to be an entity providing=20 > an ingress=20 > > > (and > > > egress) point(s), either on the public network for it to=20 > be public,=20 > > > or for it to cross into another private address domain. For this=20 > > > WG's purpose, I recommend we allow either model to work,=20 > as well as=20 > > > the model of the private going to public (and vice-versa)=20 > so long as=20 > > > the peering element of both sides are in the same public=20 > or private=20 > > > space. > > > > > > -Hadriel > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > speermint@ietf.org > > > > Subject: Re: [Speermint] Reachability > > > > > > > > >The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > >needs to be publicly addressable. > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > everybody. > > > > This was also why I had a problem with Sohel's presentation > > > at the IETF, > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > For the avoidance of doubt: I have no problem if the=20 > same peering=20 > > > > principles we develop here are used between some entities > > > in a private > > > > network, > > > > but it is not out task to consider this separately. Because > > > if it works > > > > on the Internet, it also works in a private network > > > (extranet in this > > > > case) > > > > (see DNS). this private network may even use public IP > > > adresses, but if > > > > the > > > > are not routable from the public Internet, they are=20 > could as well=20 > > > > be private (example IPX) > > > > > > > > What never can work is a peering between one entity on the > > > public network > > > > and one on a private network. The private entities need at > > > least to have > > > > one > > > > ingress element on the public network > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Gesendet: Di 04.04.2006 15:29 > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > But I want to ensure everybody understands what your really > > > saying here. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > This means that for carrier to carrier peering models, each > > > and every > > > > customer of every carrier that wants to inter-connect needs > > > to have a > > > > 'public NAT binding'. > > > > > > > > I believe by extension, this means that a serving > > > proxy/registrar for the > > > > target of a communication must ALSO have either a public > > > address or a > > > > public > > > > NAT binding. > > > > > > > > The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > needs to be publicly addressable. > > > > > > > > Am I correct? > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hello Hadriel, > > > > > > > > Comment inline.... > > > > > > > > > -----Original Message----- > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hi Reinaldo, > > > > > Comments inline... > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > Maybe I'm missing something, but given that this=20 > workgroup is > > > > interested > > > > > > only in call routing (E.164 is out of scope), do we > > > really need to > > > > care > > > > > > about that? An AoR in the end will be translated to an > > > IP address, > > > > and > > > > > > IP addresses have a very good definition of public and > > > private (in > > > > IPv4 > > > > > > and IPv6). > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > "translated" > > > > > to an IP Address (and really to a contact URI) by the > > > AoR's domain. > > > > So > > > > > what > > > > > you're saying is if the AoR's user-part represents a > > > consumer behind a > > > > > home > > > > > NAT (a private IP), then it is a private AoR; but for > > > those consumers > > > > who > > > > > don't use home-NATs then it's a public AoR? > > > > [[Reinaldo]] > > > > > > > > Hello, > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > discussion, > > > > that's why I gave that example. I was trying to=20 > understand why it=20 > > > > matters, before getting knee deep into the classification. > > > Can someone > > > > refresh that for me? > > > > > > > > So, if SIP peering is going to get woven into the fabric of the=20 > > > > internet, the rules for domains names, DNS resolution,=20 > private vs. > > > > public IP address, etc should apply, right? > > > > > > > > I believe the current model of host to host or email > > > communication is > > > > not different for SIP. We could have the following main=20 > > > > situations...(correct me where I'm wrong). > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > in the end > > > > will get resolved into an IP address. Then there are only two=20 > > > > situations. > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > This means the SIP endpoint is unreachable unless you > > > are also in the > > > > same private network. Actually I believe a private IP address=20 > > > > cannot even be provisioned in a public DNS. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > be reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > b) the IP address is public. > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > Internet we have > > > > today, this means the domain name/user is private, does not > > > exist, etc > > > > > > > > All this has been happening okay with just a few basic > > > rules. If an AoR > > > > is very similar to an email address, why it would not work with=20 > > > > the current infrastructure/definitions? > > > > > > > > If somebody says that they have a "private" email address or=20 > > > > domain name, what is your interpretation of that? > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > translated > > > > > into an IP by a registrar inside a private IP subnet, and > > > somehow it > > > > later > > > > > gets translated into the public IP address space, that's > > > also private > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > reachable first, > > > > let's > > > > > > not forget about that. And if you are IP reachable,=20 > you could=20 > > > > > > potentially be SIP reachable by registering to some > > > free SIP service > > > > (or > > > > > > the SIP "domain" above you in the hierarchy...if=20 > this was the > > > > email/DNS > > > > > > model). > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > can be "sip > > > > > reachable" but not IP reachable. But I think for now we > > > should ignore > > > > the > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > 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 >=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 Apr 05 10:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9HL-000390-LV; Wed, 05 Apr 2006 10:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9HK-00038s-RF for speermint@ietf.org; Wed, 05 Apr 2006 10:46:38 -0400 Received: from outbound-haw.frontbridge.com ([12.129.219.97] helo=outbound3-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9HK-0001Lu-FP for speermint@ietf.org; Wed, 05 Apr 2006 10:46:38 -0400 Received: from outbound3-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound3-haw-R.bigfish.com (Postfix) with ESMTP id 72D3F14D7346 for ; Wed, 5 Apr 2006 14:45:27 +0000 (UTC) Received: from mail22-haw-R.bigfish.com (unknown [192.168.51.1]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound3-haw.bigfish.com (Postfix) with ESMTP id 7135F14D7342 for ; Wed, 5 Apr 2006 14:45:27 +0000 (UTC) Received: from mail22-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail22-haw-R.bigfish.com (Postfix) with ESMTP id 545893B0AE8 for ; Wed, 5 Apr 2006 14:45:27 +0000 (UTC) X-BigFish: V Received: by mail22-haw (MessageSwitch) id 1144248327232511_25906; Wed, 5 Apr 2006 14:45:27 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail22-haw.bigfish.com (Postfix) with ESMTP id 1B51D3AF0C0 for ; Wed, 5 Apr 2006 14:45:27 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k35EjQpu016678 for ; Wed, 5 Apr 2006 09:45:26 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k35EjP022592 for ; Wed, 5 Apr 2006 09:45:25 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 09:45:21 -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] NATs and Firewalls Date: Wed, 5 Apr 2006 09:44:46 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E07310E12@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYrZNcErevBEzxQwCInmm7iLpXeAAENodg From: "Khan, Sohel Q [CTO]" To: X-OriginalArrivalTime: 05 Apr 2006 14:45:21.0926 (UTC) FILETIME=[90E06260:01C658BF] X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 future, SBC functions may be distributed in different network components. (Please review my presentation in IETF-63 Paris VoIP Peering BOF). We need to define peering entities as functions (e.g., Signaling Peering Function, Media Peering Function, ...) (Please review my presentation in IETF-65 Dallas SPEERMINT wg). Thank you. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Wednesday, April 05, 2006 7:34 AM To: speermint@ietf.org Subject: Re: [Speermint] NATs and Firewalls And if people avoided using the term "SBC" anywhere in RAI, that would be lovely, too, for exactly the reasons that Keith cited (we don't get smarter in other RAI working groups :-) Thanks, Spencer From: "Drage, Keith (Keith)" To: Sent: Wednesday, April 05, 2006 4:23 AM Subject: RE: [Speermint] NATs and Firewalls > And to support Richard on this. > > Please avoid using the term "SBC" in the speermint area. Please=20 > clearly identify the function of these supposed wonder boxes that you=20 > are addressing as an area of concern or advantage. Therefore if you=20 > mean NAT, say NAT, if you mean firewall, say firewall, if you mean=20 > something else, say so. These boxes contain so many features (in the=20 > widest sense of the > word) that in the absence of specific information we get lost. > > regards > > Keith _______________________________________________ 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 Apr 05 11:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Us-00009v-Or; Wed, 05 Apr 2006 11:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Us-00009q-52 for speermint@ietf.org; Wed, 05 Apr 2006 11:00:38 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9Uq-0001ne-R3 for speermint@ietf.org; Wed, 05 Apr 2006 11:00:38 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AB930444; Wed, 05 Apr 2006 11:00:35 -0400 From: "Hadriel Kaplan" To: "'Jonathan Rosenberg'" Subject: RE: [Speermint] RE: NATs and Firewalls Date: Wed, 5 Apr 2006 11:00:41 -0400 Message-ID: <068a01c658c1$b537c020$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYtVoQiEH0l+YTRqWGRarcyjxMoAACj9YQ In-Reply-To: <4433C6DE.7000206@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Agreed - the behavior of NATs provide some security properties. But since even the term "NAT" is ambiguous about the actual behavior (ie, flavors of conical vs. symmetric), and their location and the network design impacts that, many security folks prefer to simply not argue about it and move on to actual security devices/rules/architectures. This topic is debated constantly in security forums and it's just not productive IMHO to reproduce it here. -hadriel > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, April 05, 2006 9:32 AM > To: Hadriel Kaplan > Cc: 'Stastny Richard'; 'Patrick Melampy'; 'Reinaldo Penno'; > speermint@ietf.org > Subject: Re: [Speermint] RE: NATs and Firewalls > > > > Hadriel Kaplan wrote: > > > Hi Richard, > > I hope you're not referring to me. > > Who said anything about NATs providing security? They don't, plain and > > simple. > > Well, that is false. > > One of the properties of a NAT (see the behave documents, > draft-ietf-behave-nat-udp and draft-ietf-behave-tcp) is that they have > the notion of a permission, which decides whether a packet from the > outside gets let into the inside. Permissions are established by a NAT > through the transmission of a packet from the inside to the outside. As > a consequence, NATs do in fact block incoming packets unless they > correspond to a permission created from sending a packet out. This is > most definitely a form of firewall. It will, for example, prevent a port > probe from hitting machines behind the NAT. It will prevent a machine on > the outside from sending packets to specific service ports. And so on. > > A firewall will generally have more complex policies about what packets > get let in (and out). Note that a firewall can in fact have the same > permission rules that a NAT implements, without the translation > function, and they will have very similar security properties. > > Folks also claim that NAT provides security by obfuscating the network > behind the NAT. An attacker cannot determine how many hosts are behind > the nat, and it never sees any of their addresses. I'm skeptical that > this is a real security benefit, but hiding of internal topology and > internal addresses is often cited as a security feature; YMMV. > > -Jonathan R. > > -- > 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 Wed Apr 05 11:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Wk-0001ph-SO; Wed, 05 Apr 2006 11:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Wi-0001lZ-Re for speermint@ietf.org; Wed, 05 Apr 2006 11:02:32 -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 1FR9Wi-00020X-OD for speermint@ietf.org; Wed, 05 Apr 2006 11:02:32 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FR9Wg-0002ra-A6 for speermint@ietf.org; Wed, 05 Apr 2006 11:02:32 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k35F1Y6r027041; Wed, 5 Apr 2006 15:01:55 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 7073C12484A; Wed, 5 Apr 2006 15:01:24 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 1193F124820; Wed, 5 Apr 2006 15:01:24 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 09:01:23 -0600 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] NATs and Firewalls Date: Wed, 5 Apr 2006 09:01:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuShs/923AjMUR0aRwYdalHAkgwACDrqg From: "Malas, Daryl" To: "Peter Macaulay" , "Drage, Keith (Keith)" , X-OriginalArrivalTime: 05 Apr 2006 15:01:23.0879 (UTC) FILETIME=[CE3EC370:01C658C1] X-Spam-Score: -0.4 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 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 Well, in IMS terms, the closest stated term is IMS ALG. Since, I do not like that term, because it limits the capability of the element; I commonly refer to the device simply as an IP MG (Media Gateway). This eliminates the need to place a frame work around the function. --Daryl -----Original Message----- From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com]=20 Sent: Wednesday, April 05, 2006 7:59 AM To: Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Agree. Let's avoid the term "SBC" in the speermint area. We don't need the history lesson and the term is still evolving. I just finished a Skype call and did not use a SBC to peer with my one in 6 million users. Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, Security Firewall and NAT/firewall traversal. /PETER MACAULAY At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >And to support Richard on this. > >Please avoid using the term "SBC" in the speermint area. Please=20 >clearly identify the function of these supposed wonder boxes that=20 >you are addressing as an area of concern or advantage. Therefore if=20 >you mean NAT, say NAT, if you mean firewall, say firewall, if you=20 >mean something else, say so. These boxes contain so many features=20 >(in the widest sense of the word) that in the absence of specific=20 >information we get lost. > >regards > >Keith > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: 04 April 2006 18:15 > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > speermint@ietf.org > > Subject: [Speermint] NATs and Firewalls > > > > > > I think some people out there either do not understand > > the difference between NATs and firewalls or are starting > > to believe their own propaganda > > > > NATs are NATs and firewalls are firewalls > > > > The worst misconception here is that a NAT is for providing > > you security > > against the bad Internet > > > > Private adress spaces have been introduced to save a scarce ressource > > (or what some believed are a scarce ressource at some point of time) > > > > You can live very safe behind a properly configured firewall > > using only > > public IP adresses. > > > > The basic idea of IPv6 was to give every device on earth and also > > within the solar system a unique public IP address > > > > But the fake security of NATs was already in the minds of > > most people, that the first things that were implemented > > in IPv6 where NATs for IPv6, which is a perversion > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > Richard > > > > ________________________________ > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Gesendet: Di 04.04.2006 18:22 > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Hi Richard, > > And here we get to the fun stuff. :) > > > > The idea of every serving proxy/registrar/sip-node needing to > > be publicly > > addressable is neither an Internet requirement, nor a > > requirement of the > > IETF. Entire working groups in the IETF concern themselves > > with allowing, > > enabling, and inter-working private address spaces and VPNs. > > What's missing > > is how to join them at the application and transport layer, when that > > application layer embeds addressing in itself. > > > > Most consumers on the planet Earth are in private address > > spaces at this > > point I think (i.e., 192.168.x.x), and many Enterprises are > > as well. Entire > > networks in some countries are privately addressed, yet they > > are members of, > > and use, the Internet. There are also now 2 disjoint address > > groups defined > > by the IETF, as you know: IPv4 and IPv6. There are > > mechanisms to try to > > provide interoperation/migration support for them, but that typically > > requires intermediaries. > > > > So I agree with you there needs to be an entity providing an > > ingress (and > > egress) point(s), either on the public network for it to be > > public, or for > > it to cross into another private address domain. For this > > WG's purpose, I > > recommend we allow either model to work, as well as the model > > of the private > > going to public (and vice-versa) so long as the peering > > element of both > > sides are in the same public or private space. > > > > -Hadriel > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > >The conclusion here -- every endpoint and every serving > > proxy/registrar > > > >needs to be publicly addressable. > > > > > > This was my basic assumption, and I seemed not so clear to > > everybody. > > > This was also why I had a problem with Sohel's presentation > > at the IETF, > > > because I did not see any public adressable entities AT ALL. > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > principles we develop here are used between some entities > > in a private > > > network, > > > but it is not out task to consider this separately. Because > > if it works > > > on the Internet, it also works in a private network > > (extranet in this > > > case) > > > (see DNS). this private network may even use public IP > > adresses, but if > > > the > > > are not routable from the public Internet, they are could as well be > > > private > > > (example IPX) > > > > > > What never can work is a peering between one entity on the > > public network > > > and one on a private network. The private entities need at > > least to have > > > one > > > ingress element on the public network > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Gesendet: Di 04.04.2006 15:29 > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > But I want to ensure everybody understands what your really > > saying here. > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > This means that for carrier to carrier peering models, each > > and every > > > customer of every carrier that wants to inter-connect needs > > to have a > > > 'public NAT binding'. > > > > > > I believe by extension, this means that a serving > > proxy/registrar for the > > > target of a communication must ALSO have either a public > > address or a > > > public > > > NAT binding. > > > > > > The conclusion here -- every endpoint and every serving > > proxy/registrar > > > needs to be publicly addressable. > > > > > > Am I correct? > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > To: Hadriel Kaplan; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hello Hadriel, > > > > > > Comment inline.... > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > To: Reinaldo Penno; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hi Reinaldo, > > > > Comments inline... > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > interested > > > > > only in call routing (E.164 is out of scope), do we > > really need to > > > care > > > > > about that? An AoR in the end will be translated to an > > IP address, > > > and > > > > > IP addresses have a very good definition of public and > > private (in > > > IPv4 > > > > > and IPv6). > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > "translated" > > > > to an IP Address (and really to a contact URI) by the > > AoR's domain. > > > So > > > > what > > > > you're saying is if the AoR's user-part represents a > > consumer behind a > > > > home > > > > NAT (a private IP), then it is a private AoR; but for > > those consumers > > > who > > > > don't use home-NATs then it's a public AoR? > > > [[Reinaldo]] > > > > > > Hello, > > > > > > Actually I'm trying to understand the whole purpose of the > > discussion, > > > that's why I gave that example. I was trying to understand why it > > > matters, before getting knee deep into the classification. > > Can someone > > > refresh that for me? > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > internet, the rules for domains names, DNS resolution, private vs. > > > public IP address, etc should apply, right? > > > > > > I believe the current model of host to host or email > > communication is > > > not different for SIP. We could have the following main > > > situations...(correct me where I'm wrong). > > > > > > 1) The AoR (just like a traditional domain name or email), > > in the end > > > will get resolved into an IP address. Then there are only two > > > situations. > > > > > > a) the IP address is private (RFC 1918). > > > > > > This means the SIP endpoint is unreachable unless you > > are also in the > > > same private network. Actually I believe a private IP address cannot > > > even be provisioned in a public DNS. > > > > > > Before somebody mentions it...for a UA behind a NAT to > > be reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > b) the IP address is public. > > > > > > The SIP endpoint is theoretically reachable. > > > > > > 2) The AoR cannot get translated. Again, just like the > > Internet we have > > > today, this means the domain name/user is private, does not > > exist, etc > > > > > > All this has been happening okay with just a few basic > > rules. If an AoR > > > is very similar to an email address, why it would not work with the > > > current infrastructure/definitions? > > > > > > If somebody says that they have a "private" email address or domain > > > name, what is your interpretation of that? > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > translated > > > > into an IP by a registrar inside a private IP subnet, and > > somehow it > > > later > > > > gets translated into the public IP address space, that's > > also private > > > > because the AoR was translated to a private IP originally? > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > For you to be "SIP reachable", you need to be IP > > reachable first, > > > let's > > > > > not forget about that. And if you are IP reachable, you could > > > > > potentially be SIP reachable by registering to some > > free SIP service > > > (or > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > email/DNS > > > > > model). > > > > > > > > Actually, to be very specific ultimate target of the AoR > > can be "sip > > > > reachable" but not IP reachable. But I think for now we > > should ignore > > > the > > > > implications of that, unless it becomes a problem. > > > > > > > > -hadriel > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > >_______________________________________________ >Speermint mailing list >Speermint@ietf.org >https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 11:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9gI-0004J2-Oc; Wed, 05 Apr 2006 11:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9gH-0004Is-B2 for speermint@ietf.org; Wed, 05 Apr 2006 11:12:25 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FR9gF-0002ae-Ig for speermint@ietf.org; Wed, 05 Apr 2006 11:12:25 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-126.messagelabs.com!1144249926!10804426!4 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30029 invoked from network); 5 Apr 2006 15:12:21 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-13.tower-126.messagelabs.com with SMTP; 5 Apr 2006 15:12:21 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F750029DC89; Wed, 5 Apr 2006 11:12:21 -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: Wed, 5 Apr 2006 11:12:19 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C84651A@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4957@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Background Reading on NGN Interconnect - transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1A From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: Subject: [Speermint] Background Reading on NGN Interconnect - transit vs peering 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 Richard: Thanks for posting this. I recommend it to all. In particular we ought to pay attention to the definition of peering versus transit offered by the US FCC and cited in the Marcus paper: =20 Peering is an agreement between ISPs to carry traffic for each other and for their respective customers. Peering does not include the obligation to carry traffic to third parties. Peering is usually a bilateral business and technical arrangement, where two providers agree to accept traffic from one another, and from one another's customers (and thus from their customers' customers). ... Transit is an agreement where an ISP agrees to carry traffic on behalf of another ISP or end user. In most cases transit will include an obligation to carry traffic to third parties. Transit is usually a bilateral business and technical arrangement, where one provider (the transit provider) agrees to carry traffic to third parties on behalf of another provider or an end user (the customer). In most cases, the transit provider carries traffic to and from its other customers, and to and from every destination on the Internet, as part of the transit arrangement. In a transit agreement, the ISP often also provides ancillary services, such as Service Level Agreements, installation support, local telecom provisioning, and Network Operations Center (NOC) support. While we NEED not accept this definition I think it does reflect the reality of layer 3 peering and it will not be helpful to use a definition for layer 5 that is at odds with layer 3 since that's what people are familiar with. If the will of the WG is to include transit in our charter that's fine - but not an excuse for calling apples and oranges both apples. If, at the end of the day, there are no important differences in how we treat the two cases - which I doubt - then life is good. We also ought to be thinking about how what Speermint is working on relates to what's going on in other bodies, e.g. the ITU. (yes, I said it, we're not alone on the planet :-) Is what we want to do an enabling piece of what NGN folks are looking toward or is it a fundamentally different animal? From the discussion on the list and at the IETF I'm not entirely sure. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, March 31, 2006 3:59 PM To: speermint@ietf.org Subject: [Speermint] Background Reading on NGN Interconnect Folks, =20 Weekend reading =20 Since we obviosly are dealing more with NGN Interconnect in Speermint, I recommend everybody on this this list to read the excellent Background Paper from Scott Marcus - Interconnection in an IP-based NGN Environment http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.p df =20 to his presentation=20 http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-2 006.ppt given at the ITU-T Workshop last week What Rules for Ip-eneabled NGNs? http://www.itu.int/osg/spu/ngn/event-march-2006.phtml =20 The agenda and some other excellent presentations can be downloaded from here: http://www.itu.int/osg/spu/ngn/presentations.html =20 In addition I would also like to point to a CEPT ECC Draft Report on the Future on Numbering, tabled for the next ITU-T SG2 Meeting as TD 198-GEN.=20 https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 2 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 The document is in public consultation and not final yet. It contains also some statements regarding termination rates. =20 The paper from Scott is on-topic regarding the current discussion here and dealing with both the European and US situation Scott Marcus is currently living in Europe, but in his former life he was Senior Advisor to the FCC and also CTO for GTE Interworking, so his knowledge is not only theoretical. =20 In the document also contains a definition on peering and transit from the FCC is given: =20 The two most prevalent forms of Internet interconnection are peering and transit. For a definition of these=20 terms, we turn to a publication of the Network Reliability and Interoperability Council (NRIC), an industry=20 advisory panel to the U.S. FCC:=20 =20 Peering is an agreement between ISPs to carry traffic for each other and for their respective=20 customers. Peering does not include the obligation to carry traffic to third parties. Peering is usually a=20 bilateral business and technical arrangement, where two providers agree to accept traffic from one=20 another, and from one another's customers (and thus from their customers' customers). ...=20 =20 Transit is an agreement where an ISP agrees to carry traffic on behalf of another ISP or end user. In=20 most cases transit will include an obligation to carry traffic to third parties. Transit is usually a=20 bilateral business and technical arrangement, where one provider (the transit provider) agrees to carry=20 traffic to third parties on behalf of another provider or an end user (the customer). In most cases, the=20 transit provider carries traffic to and from its other customers, and to and from every destination on=20 the Internet, as part of the transit arrangement. In a transit agreement, the ISP often also provides=20 ancillary services, such as Service Level Agreements, installation support, local telecom provisioning,=20 and Network Operations Center (NOC) support.=20 =20 Peering thus offers a provider access only to a single provider's customers. Transit, by contrast,=20 usually provides access at a predictable price to the entire Internet. ... Historically, peering has often=20 been done on a bill-and-keep basis, without cash payments. Peering where there is no explicit=20 exchange of money between parties, and where each party supports part of the cost of the=20 interconnect, ... is typically used where both parties perceive a roughly equal exchange of value.=20 Peering therefore is fundamentally a barter relationship =20 Here the Executive Summary of the paper: =20 This report considers the likely evolution of interconnection arrangements in the context of IP-based Next=20 Generation Networks (NGNs).=20 The NGN represents a synthesis of existing world of the "traditional" Public Switched Telephone Network=20 (PSTN) with the world of the Internet. The economic and regulatory arrangements for the two have=20 historically been very different. What should happen when these two worlds collide?=20 Many of the networks created over the past ten years contain most of the key elements of an NGN. Most, if=20 not all, of the technology necessary for IP-based NGN interconnection has been available for five to ten=20 years. Advanced approaches to interconnection have been slow to deploy, even where the technology has=20 been mature or within hailing distance of maturity.=20 The NGN interconnection problem is best understood, not as a problem of technology, but rather as a=20 problem in economics. With that in mind, this report seeks to review what is known about interconnection=20 from an economic perspective, in order to reach conclusions about the prospects for deployment going=20 forward and the corresponding implications for policymakers.=20 A substantial body of economic theory has been developed over the past decade as regards interconnection in=20 the traditional PSTN. A smaller body of solid economic research has emerged in regard to interconnection of=20 IP-based networks. At the level of economic theory, the PSTN and the Internet are not worlds apart.=20 Economics provides the necessary bridge between the two worlds, illuminating both the similarities and the=20 differences in these two environments.=20 This report begins by laying out, for the most part at a non-technical level, the established theory of=20 interconnection, for both the PSTN and the Internet. Wholesale and retail arrangements are considered=20 separately. Most of the observed behavior of these economic networks can be explained in terms of a=20 constellation of known economic effects: market power, the termination monopoly, demand elasticity,=20 network exernalities, transaction costs, service differentiation, price discrimination, and the Coase theorem=20 (which says that private parties can often negotiate arrangements more efficiently than government=20 regulators, provided that necessary preconditions have been met).=20 =20 With this theory in hand, the report considers the implications for the deployment of differentiated Quality of=20 Service, and of universal service. We also consider the implications of IP-based technology - with the=20 layering, and the changes in industry structure that it implies - service providers become independent of the=20 network, but neither is well equipped to measure or to charge for the other's resource consumption.=20 The last section of the report represents a hypothetical scenario, a "thought experiment", where the historic=20 wired and mobile incumbent of European country upgrades its networks to an IP-based NGN. We consider=20 the likely results in terms of regulation of the access network, and of interconnection; likely domestic and=20 international interconnection arrangements; and the implications for ubiquitous support of QoS. Key findings=20 include:=20 * Provided that markets for Internet transit and for consumer broadband Internet access are effectively=20 competitive, a "Coasian" interconnection regime is likely to be more efficient, and more consistent=20 with consumer welfare, than a regulated regime.=20 * Conversely, where these markets are not effectively competitive, mandates for interconnection at the=20 IP level may prove to be unavoidable, particularly once existing PSTN interconnection is withdrawn.=20 The migration to NGN potentially creates new sources of market power, at the same time that it=20 creates new possibilities for competition.=20 * Policymakers might consequently be well advised to focus their attention first on ensuring=20 competitive markets, and only secondarily on interconnection.=20 Current Calling Party's Network Pays (CPNP) arrangements contain a number of implicit subsidies. In the=20 world of the NGN, where services providers and networks operators may be different entities, these=20 subsidies need major re-thinking - call termination payments that were intended to finance the terminating=20 network would, by default, flow to independent VoIP service provides who have no network to support. In=20 the absence of termination fees, independent VoIP providers would tend to compete price levels for=20 telephony service, independent of the network, down to levels not greatly above cost, which would appear to=20 be a societally desirable outcome. =20 The thought experiment does not flatly preclude the possibility that governments might somehow erect a=20 new system of subsidies to replace the old, but it suggests that any subsidy system will be difficult to sustain=20 over time in the face of new forms of competition enabled by the IP-based NGN - all provided, once again,=20 that underlying markets (especially for wholesale Internet transit and for retail Internet broadband access)=20 remain effectively competitive. A system of Coasian private arrangements, in the absence of vertically=20 integrated competitive bottlenecks, seems likely to lead to unsubsidized arrangements at wholesale and retail=20 price levels not greatly in excess of cost.=20 cheer 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 Wed Apr 05 11:21:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9oz-0000Ds-3I; Wed, 05 Apr 2006 11:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9ox-0000Dn-OL for speermint@ietf.org; Wed, 05 Apr 2006 11:21:23 -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 1FR9ov-00030z-5c for speermint@ietf.org; Wed, 05 Apr 2006 11:21:23 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 1289F18997; Wed, 5 Apr 2006 11:15:12 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:15: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 Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 11:15:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuShs/923AjMUR0aRwYdalHAkgwACDrqgAABukcA= From: "Uzelac, Adam" To: "Malas, Daryl" , "Peter Macaulay" , "Drage, Keith (Keith)" , X-OriginalArrivalTime: 05 Apr 2006 15:15:11.0868 (UTC) FILETIME=[BBC3DBC0:01C658C3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 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 one problem that I have with the term IP Media Gateway is the assumption that signaling and media will traverse the element. The focus needs to be on the signaling. I understand the logical evolution of the Media Gateway from it's historical roots, but we have to leave the bearer/media out of this working group's charter. -AU -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Wednesday, April 05, 2006 11:01 AM To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Well, in IMS terms, the closest stated term is IMS ALG. Since, I do not like that term, because it limits the capability of the element; I commonly refer to the device simply as an IP MG (Media Gateway). This eliminates the need to place a frame work around the function. --Daryl -----Original Message----- From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] Sent: Wednesday, April 05, 2006 7:59 AM To: Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Agree. Let's avoid the term "SBC" in the speermint area. We don't need the history lesson and the term is still evolving. I just finished a Skype call and did not use a SBC to peer with my one in 6 million users. Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, Security Firewall and NAT/firewall traversal. /PETER MACAULAY At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >And to support Richard on this. > >Please avoid using the term "SBC" in the speermint area. Please clearly >identify the function of these supposed wonder boxes that you are=20 >addressing as an area of concern or advantage. Therefore if you mean=20 >NAT, say NAT, if you mean firewall, say firewall, if you mean something >else, say so. These boxes contain so many features (in the widest sense >of the word) that in the absence of specific information we get lost. > >regards > >Keith > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: 04 April 2006 18:15 > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;=20 > > speermint@ietf.org > > Subject: [Speermint] NATs and Firewalls > > > > > > I think some people out there either do not understand the=20 > > difference between NATs and firewalls or are starting to believe=20 > > their own propaganda > > > > NATs are NATs and firewalls are firewalls > > > > The worst misconception here is that a NAT is for providing you=20 > > security against the bad Internet > > > > Private adress spaces have been introduced to save a scarce ressource > > (or what some believed are a scarce ressource at some point of time) > > > > You can live very safe behind a properly configured firewall using=20 > > only public IP adresses. > > > > The basic idea of IPv6 was to give every device on earth and also=20 > > within the solar system a unique public IP address > > > > But the fake security of NATs was already in the minds of most=20 > > people, that the first things that were implemented in IPv6 where=20 > > NATs for IPv6, which is a perversion > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > Richard > > > > ________________________________ > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Gesendet: Di 04.04.2006 18:22 > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';=20 > > speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Hi Richard, > > And here we get to the fun stuff. :) > > > > The idea of every serving proxy/registrar/sip-node needing to be=20 > > publicly addressable is neither an Internet requirement, nor a=20 > > requirement of the IETF. Entire working groups in the IETF concern=20 > > themselves with allowing, enabling, and inter-working private=20 > > address spaces and VPNs. > > What's missing > > is how to join them at the application and transport layer, when that > > application layer embeds addressing in itself. > > > > Most consumers on the planet Earth are in private address spaces at=20 > > this point I think (i.e., 192.168.x.x), and many Enterprises are as=20 > > well. Entire networks in some countries are privately addressed,=20 > > yet they are members of, and use, the Internet. There are also now=20 > > 2 disjoint address groups defined by the IETF, as you know: IPv4 and > > IPv6. There are mechanisms to try to provide=20 > > interoperation/migration support for them, but that typically > > requires intermediaries. > > > > So I agree with you there needs to be an entity providing an ingress > > (and > > egress) point(s), either on the public network for it to be public,=20 > > or for it to cross into another private address domain. For this=20 > > WG's purpose, I recommend we allow either model to work, as well as=20 > > the model of the private going to public (and vice-versa) so long as > > the peering element of both sides are in the same public or private=20 > > space. > > > > -Hadriel > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > >The conclusion here -- every endpoint and every serving > > proxy/registrar > > > >needs to be publicly addressable. > > > > > > This was my basic assumption, and I seemed not so clear to > > everybody. > > > This was also why I had a problem with Sohel's presentation > > at the IETF, > > > because I did not see any public adressable entities AT ALL. > > > > > > For the avoidance of doubt: I have no problem if the same peering=20 > > > principles we develop here are used between some entities > > in a private > > > network, > > > but it is not out task to consider this separately. Because > > if it works > > > on the Internet, it also works in a private network > > (extranet in this > > > case) > > > (see DNS). this private network may even use public IP > > adresses, but if > > > the > > > are not routable from the public Internet, they are could as well be > > > private > > > (example IPX) > > > > > > What never can work is a peering between one entity on the > > public network > > > and one on a private network. The private entities need at > > least to have > > > one > > > ingress element on the public network > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Gesendet: Di 04.04.2006 15:29 > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > But I want to ensure everybody understands what your really > > saying here. > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > This means that for carrier to carrier peering models, each > > and every > > > customer of every carrier that wants to inter-connect needs > > to have a > > > 'public NAT binding'. > > > > > > I believe by extension, this means that a serving > > proxy/registrar for the > > > target of a communication must ALSO have either a public > > address or a > > > public > > > NAT binding. > > > > > > The conclusion here -- every endpoint and every serving > > proxy/registrar > > > needs to be publicly addressable. > > > > > > Am I correct? > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > To: Hadriel Kaplan; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hello Hadriel, > > > > > > Comment inline.... > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > To: Reinaldo Penno; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hi Reinaldo, > > > > Comments inline... > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > interested > > > > > only in call routing (E.164 is out of scope), do we > > really need to > > > care > > > > > about that? An AoR in the end will be translated to an > > IP address, > > > and > > > > > IP addresses have a very good definition of public and > > private (in > > > IPv4 > > > > > and IPv6). > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > "translated" > > > > to an IP Address (and really to a contact URI) by the > > AoR's domain. > > > So > > > > what > > > > you're saying is if the AoR's user-part represents a > > consumer behind a > > > > home > > > > NAT (a private IP), then it is a private AoR; but for > > those consumers > > > who > > > > don't use home-NATs then it's a public AoR? > > > [[Reinaldo]] > > > > > > Hello, > > > > > > Actually I'm trying to understand the whole purpose of the > > discussion, > > > that's why I gave that example. I was trying to understand why it=20 > > > matters, before getting knee deep into the classification. > > Can someone > > > refresh that for me? > > > > > > So, if SIP peering is going to get woven into the fabric of the=20 > > > internet, the rules for domains names, DNS resolution, private vs. > > > public IP address, etc should apply, right? > > > > > > I believe the current model of host to host or email > > communication is > > > not different for SIP. We could have the following main=20 > > > situations...(correct me where I'm wrong). > > > > > > 1) The AoR (just like a traditional domain name or email), > > in the end > > > will get resolved into an IP address. Then there are only two=20 > > > situations. > > > > > > a) the IP address is private (RFC 1918). > > > > > > This means the SIP endpoint is unreachable unless you > > are also in the > > > same private network. Actually I believe a private IP address cannot > > > even be provisioned in a public DNS. > > > > > > Before somebody mentions it...for a UA behind a NAT to > > be reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > b) the IP address is public. > > > > > > The SIP endpoint is theoretically reachable. > > > > > > 2) The AoR cannot get translated. Again, just like the > > Internet we have > > > today, this means the domain name/user is private, does not > > exist, etc > > > > > > All this has been happening okay with just a few basic > > rules. If an AoR > > > is very similar to an email address, why it would not work with the > > > current infrastructure/definitions? > > > > > > If somebody says that they have a "private" email address or domain > > > name, what is your interpretation of that? > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > translated > > > > into an IP by a registrar inside a private IP subnet, and > > somehow it > > > later > > > > gets translated into the public IP address space, that's > > also private > > > > because the AoR was translated to a private IP originally? > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > For you to be "SIP reachable", you need to be IP > > reachable first, > > > let's > > > > > not forget about that. And if you are IP reachable, you could=20 > > > > > potentially be SIP reachable by registering to some > > free SIP service > > > (or > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > email/DNS > > > > > model). > > > > > > > > Actually, to be very specific ultimate target of the AoR > > can be "sip > > > > reachable" but not IP reachable. But I think for now we > > should ignore > > > the > > > > implications of that, unless it becomes a problem. > > > > > > > > -hadriel > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > >_______________________________________________ >Speermint mailing list >Speermint@ietf.org >https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint 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 Apr 05 11:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9sS-0001kP-55; Wed, 05 Apr 2006 11:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9sR-0001kK-Hp for speermint@ietf.org; Wed, 05 Apr 2006 11:24:59 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9sQ-0003Cw-VG for speermint@ietf.org; Wed, 05 Apr 2006 11:24:59 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 11:24: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] NATs and Firewalls Date: Wed, 5 Apr 2006 11:24:57 -0400 Message-ID: <8812D8156467224C9E9739E513037EF1518ADB@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls thread-index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQ From: "Medhavi Bhatia" To: "Peter Macaulay" , "Drage, Keith \(Keith\)" , X-OriginalArrivalTime: 05 Apr 2006 15:24:58.0594 (UTC) FILETIME=[197B2420:01C658C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c 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'd agree. Lets focus on requirements of peering based on SIP RFCs/drafts, location and address translation mechanisms. The only things which impact any sort of architecture are the administrative domains, P2P domains and federations where subscribers are. As far as the discussion on SBCs, we have had a lengthy one in SIPPING. It would be fair to say (and I may get flamed for this) that the reason where we are with SBCs today is primarily because some service providers were doing "stuff" differently with SIP. SBCs simply capitalized on open holes in requirements. This will go away with time with more competition, open networks (job of speermint?) and open solutions from IETF. SBCs will change (or follow the money as some would say...).=20 We need to look forward. SBCs and other infrastructure equipment vendors (Edge proxies, core proxies etc) will follow these requirements. We must take care however that we get the right set of SP requirements and form the right solution.=20 -Medhavi. > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > Sent: Wednesday, April 05, 2006 9:59 AM > To: Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Agree. Let's avoid the term "SBC" in the speermint area. We don't > need the history lesson and the term is still evolving. I just finished > a Skype call and did not use a SBC to peer with my one in 6 million users. >=20 > Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, > Security Firewall and NAT/firewall traversal. >=20 > /PETER MACAULAY >=20 > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >And to support Richard on this. > > > >Please avoid using the term "SBC" in the speermint area. Please > >clearly identify the function of these supposed wonder boxes that > >you are addressing as an area of concern or advantage. Therefore if > >you mean NAT, say NAT, if you mean firewall, say firewall, if you > >mean something else, say so. These boxes contain so many features > >(in the widest sense of the word) that in the absence of specific > >information we get lost. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: 04 April 2006 18:15 > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > > speermint@ietf.org > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > I think some people out there either do not understand > > > the difference between NATs and firewalls or are starting > > > to believe their own propaganda > > > > > > NATs are NATs and firewalls are firewalls > > > > > > The worst misconception here is that a NAT is for providing > > > you security > > > against the bad Internet > > > > > > Private adress spaces have been introduced to save a scarce ressource > > > (or what some believed are a scarce ressource at some point of time) > > > > > > You can live very safe behind a properly configured firewall > > > using only > > > public IP adresses. > > > > > > The basic idea of IPv6 was to give every device on earth and also > > > within the solar system a unique public IP address > > > > > > But the fake security of NATs was already in the minds of > > > most people, that the first things that were implemented > > > in IPv6 where NATs for IPv6, which is a perversion > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Gesendet: Di 04.04.2006 18:22 > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > > speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Richard, > > > And here we get to the fun stuff. :) > > > > > > The idea of every serving proxy/registrar/sip-node needing to > > > be publicly > > > addressable is neither an Internet requirement, nor a > > > requirement of the > > > IETF. Entire working groups in the IETF concern themselves > > > with allowing, > > > enabling, and inter-working private address spaces and VPNs. > > > What's missing > > > is how to join them at the application and transport layer, when that > > > application layer embeds addressing in itself. > > > > > > Most consumers on the planet Earth are in private address > > > spaces at this > > > point I think (i.e., 192.168.x.x), and many Enterprises are > > > as well. Entire > > > networks in some countries are privately addressed, yet they > > > are members of, > > > and use, the Internet. There are also now 2 disjoint address > > > groups defined > > > by the IETF, as you know: IPv4 and IPv6. There are > > > mechanisms to try to > > > provide interoperation/migration support for them, but that typically > > > requires intermediaries. > > > > > > So I agree with you there needs to be an entity providing an > > > ingress (and > > > egress) point(s), either on the public network for it to be > > > public, or for > > > it to cross into another private address domain. For this > > > WG's purpose, I > > > recommend we allow either model to work, as well as the model > > > of the private > > > going to public (and vice-versa) so long as the peering > > > element of both > > > sides are in the same public or private space. > > > > > > -Hadriel > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > speermint@ietf.org > > > > Subject: Re: [Speermint] Reachability > > > > > > > > >The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > >needs to be publicly addressable. > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > everybody. > > > > This was also why I had a problem with Sohel's presentation > > > at the IETF, > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > > principles we develop here are used between some entities > > > in a private > > > > network, > > > > but it is not out task to consider this separately. Because > > > if it works > > > > on the Internet, it also works in a private network > > > (extranet in this > > > > case) > > > > (see DNS). this private network may even use public IP > > > adresses, but if > > > > the > > > > are not routable from the public Internet, they are could as well be > > > > private > > > > (example IPX) > > > > > > > > What never can work is a peering between one entity on the > > > public network > > > > and one on a private network. The private entities need at > > > least to have > > > > one > > > > ingress element on the public network > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Gesendet: Di 04.04.2006 15:29 > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > But I want to ensure everybody understands what your really > > > saying here. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > This means that for carrier to carrier peering models, each > > > and every > > > > customer of every carrier that wants to inter-connect needs > > > to have a > > > > 'public NAT binding'. > > > > > > > > I believe by extension, this means that a serving > > > proxy/registrar for the > > > > target of a communication must ALSO have either a public > > > address or a > > > > public > > > > NAT binding. > > > > > > > > The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > needs to be publicly addressable. > > > > > > > > Am I correct? > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hello Hadriel, > > > > > > > > Comment inline.... > > > > > > > > > -----Original Message----- > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hi Reinaldo, > > > > > Comments inline... > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > > interested > > > > > > only in call routing (E.164 is out of scope), do we > > > really need to > > > > care > > > > > > about that? An AoR in the end will be translated to an > > > IP address, > > > > and > > > > > > IP addresses have a very good definition of public and > > > private (in > > > > IPv4 > > > > > > and IPv6). > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > "translated" > > > > > to an IP Address (and really to a contact URI) by the > > > AoR's domain. > > > > So > > > > > what > > > > > you're saying is if the AoR's user-part represents a > > > consumer behind a > > > > > home > > > > > NAT (a private IP), then it is a private AoR; but for > > > those consumers > > > > who > > > > > don't use home-NATs then it's a public AoR? > > > > [[Reinaldo]] > > > > > > > > Hello, > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > discussion, > > > > that's why I gave that example. I was trying to understand why it > > > > matters, before getting knee deep into the classification. > > > Can someone > > > > refresh that for me? > > > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > > internet, the rules for domains names, DNS resolution, private vs. > > > > public IP address, etc should apply, right? > > > > > > > > I believe the current model of host to host or email > > > communication is > > > > not different for SIP. We could have the following main > > > > situations...(correct me where I'm wrong). > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > in the end > > > > will get resolved into an IP address. Then there are only two > > > > situations. > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > This means the SIP endpoint is unreachable unless you > > > are also in the > > > > same private network. Actually I believe a private IP address cannot > > > > even be provisioned in a public DNS. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > be reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > b) the IP address is public. > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > Internet we have > > > > today, this means the domain name/user is private, does not > > > exist, etc > > > > > > > > All this has been happening okay with just a few basic > > > rules. If an AoR > > > > is very similar to an email address, why it would not work with the > > > > current infrastructure/definitions? > > > > > > > > If somebody says that they have a "private" email address or domain > > > > name, what is your interpretation of that? > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > translated > > > > > into an IP by a registrar inside a private IP subnet, and > > > somehow it > > > > later > > > > > gets translated into the public IP address space, that's > > > also private > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > reachable first, > > > > let's > > > > > > not forget about that. And if you are IP reachable, you could > > > > > > potentially be SIP reachable by registering to some > > > free SIP service > > > > (or > > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > > email/DNS > > > > > > model). > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > can be "sip > > > > > reachable" but not IP reachable. But I think for now we > > > should ignore > > > > the > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > 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 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 11:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9yj-0003fC-H2; Wed, 05 Apr 2006 11:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9yi-0003f7-GD for speermint@ietf.org; Wed, 05 Apr 2006 11:31:28 -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 1FR9yh-0003Zk-TN for speermint@ietf.org; Wed, 05 Apr 2006 11:31:28 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k35FVOaK005730; Wed, 5 Apr 2006 15:31:24 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 1122678B4BF; Wed, 5 Apr 2006 15:31:24 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id D23FE78B52E; Wed, 5 Apr 2006 15:31:23 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 09:31:23 -0600 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] NATs and Firewalls Date: Wed, 5 Apr 2006 09:31:22 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuShs/923AjMUR0aRwYdalHAkgwACDrqgAABukcAAAJDZAA== From: "Malas, Daryl" To: "Uzelac, Adam" , "Peter Macaulay" , "Drage, Keith (Keith)" , X-OriginalArrivalTime: 05 Apr 2006 15:31:23.0704 (UTC) FILETIME=[FF064380:01C658C5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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 a good point...technically if we wanted to blow it out, it could be classified as a: I-CSCF, THIG, and IMS ALG. I was trying to simplify the combined functionality into one term. I guess it's not that easy. This is probably more specific: I-CSCF/THIG - Signaling IMS ALG (IP-IP MG) - Bearer Thanks... Daryl M. -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Wednesday, April 05, 2006 9:15 AM To: Malas, Daryl; Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls The one problem that I have with the term IP Media Gateway is the assumption that signaling and media will traverse the element. The focus needs to be on the signaling. I understand the logical evolution of the Media Gateway from it's historical roots, but we have to leave the bearer/media out of this working group's charter. -AU -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Wednesday, April 05, 2006 11:01 AM To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Well, in IMS terms, the closest stated term is IMS ALG. Since, I do not like that term, because it limits the capability of the element; I commonly refer to the device simply as an IP MG (Media Gateway). This eliminates the need to place a frame work around the function. --Daryl -----Original Message----- From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] Sent: Wednesday, April 05, 2006 7:59 AM To: Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Agree. Let's avoid the term "SBC" in the speermint area. We don't need the history lesson and the term is still evolving. I just finished a Skype call and did not use a SBC to peer with my one in 6 million users. Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, Security Firewall and NAT/firewall traversal. /PETER MACAULAY At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >And to support Richard on this. > >Please avoid using the term "SBC" in the speermint area. Please clearly >identify the function of these supposed wonder boxes that you are=20 >addressing as an area of concern or advantage. Therefore if you mean=20 >NAT, say NAT, if you mean firewall, say firewall, if you mean something >else, say so. These boxes contain so many features (in the widest sense >of the word) that in the absence of specific information we get lost. > >regards > >Keith > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: 04 April 2006 18:15 > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;=20 > > speermint@ietf.org > > Subject: [Speermint] NATs and Firewalls > > > > > > I think some people out there either do not understand the=20 > > difference between NATs and firewalls or are starting to believe=20 > > their own propaganda > > > > NATs are NATs and firewalls are firewalls > > > > The worst misconception here is that a NAT is for providing you=20 > > security against the bad Internet > > > > Private adress spaces have been introduced to save a scarce ressource > > (or what some believed are a scarce ressource at some point of time) > > > > You can live very safe behind a properly configured firewall using=20 > > only public IP adresses. > > > > The basic idea of IPv6 was to give every device on earth and also=20 > > within the solar system a unique public IP address > > > > But the fake security of NATs was already in the minds of most=20 > > people, that the first things that were implemented in IPv6 where=20 > > NATs for IPv6, which is a perversion > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > Richard > > > > ________________________________ > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Gesendet: Di 04.04.2006 18:22 > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';=20 > > speermint@ietf.org > > Betreff: RE: [Speermint] Reachability > > > > > > > > Hi Richard, > > And here we get to the fun stuff. :) > > > > The idea of every serving proxy/registrar/sip-node needing to be=20 > > publicly addressable is neither an Internet requirement, nor a=20 > > requirement of the IETF. Entire working groups in the IETF concern=20 > > themselves with allowing, enabling, and inter-working private=20 > > address spaces and VPNs. > > What's missing > > is how to join them at the application and transport layer, when that > > application layer embeds addressing in itself. > > > > Most consumers on the planet Earth are in private address spaces at=20 > > this point I think (i.e., 192.168.x.x), and many Enterprises are as=20 > > well. Entire networks in some countries are privately addressed,=20 > > yet they are members of, and use, the Internet. There are also now=20 > > 2 disjoint address groups defined by the IETF, as you know: IPv4 and > > IPv6. There are mechanisms to try to provide=20 > > interoperation/migration support for them, but that typically > > requires intermediaries. > > > > So I agree with you there needs to be an entity providing an ingress > > (and > > egress) point(s), either on the public network for it to be public,=20 > > or for it to cross into another private address domain. For this=20 > > WG's purpose, I recommend we allow either model to work, as well as=20 > > the model of the private going to public (and vice-versa) so long as > > the peering element of both sides are in the same public or private=20 > > space. > > > > -Hadriel > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > >The conclusion here -- every endpoint and every serving > > proxy/registrar > > > >needs to be publicly addressable. > > > > > > This was my basic assumption, and I seemed not so clear to > > everybody. > > > This was also why I had a problem with Sohel's presentation > > at the IETF, > > > because I did not see any public adressable entities AT ALL. > > > > > > For the avoidance of doubt: I have no problem if the same peering=20 > > > principles we develop here are used between some entities > > in a private > > > network, > > > but it is not out task to consider this separately. Because > > if it works > > > on the Internet, it also works in a private network > > (extranet in this > > > case) > > > (see DNS). this private network may even use public IP > > adresses, but if > > > the > > > are not routable from the public Internet, they are could as well be > > > private > > > (example IPX) > > > > > > What never can work is a peering between one entity on the > > public network > > > and one on a private network. The private entities need at > > least to have > > > one > > > ingress element on the public network > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Gesendet: Di 04.04.2006 15:29 > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > But I want to ensure everybody understands what your really > > saying here. > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > This means that for carrier to carrier peering models, each > > and every > > > customer of every carrier that wants to inter-connect needs > > to have a > > > 'public NAT binding'. > > > > > > I believe by extension, this means that a serving > > proxy/registrar for the > > > target of a communication must ALSO have either a public > > address or a > > > public > > > NAT binding. > > > > > > The conclusion here -- every endpoint and every serving > > proxy/registrar > > > needs to be publicly addressable. > > > > > > Am I correct? > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > To: Hadriel Kaplan; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hello Hadriel, > > > > > > Comment inline.... > > > > > > > -----Original Message----- > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > To: Reinaldo Penno; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hi Reinaldo, > > > > Comments inline... > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > interested > > > > > only in call routing (E.164 is out of scope), do we > > really need to > > > care > > > > > about that? An AoR in the end will be translated to an > > IP address, > > > and > > > > > IP addresses have a very good definition of public and > > private (in > > > IPv4 > > > > > and IPv6). > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > "translated" > > > > to an IP Address (and really to a contact URI) by the > > AoR's domain. > > > So > > > > what > > > > you're saying is if the AoR's user-part represents a > > consumer behind a > > > > home > > > > NAT (a private IP), then it is a private AoR; but for > > those consumers > > > who > > > > don't use home-NATs then it's a public AoR? > > > [[Reinaldo]] > > > > > > Hello, > > > > > > Actually I'm trying to understand the whole purpose of the > > discussion, > > > that's why I gave that example. I was trying to understand why it=20 > > > matters, before getting knee deep into the classification. > > Can someone > > > refresh that for me? > > > > > > So, if SIP peering is going to get woven into the fabric of the=20 > > > internet, the rules for domains names, DNS resolution, private vs. > > > public IP address, etc should apply, right? > > > > > > I believe the current model of host to host or email > > communication is > > > not different for SIP. We could have the following main=20 > > > situations...(correct me where I'm wrong). > > > > > > 1) The AoR (just like a traditional domain name or email), > > in the end > > > will get resolved into an IP address. Then there are only two=20 > > > situations. > > > > > > a) the IP address is private (RFC 1918). > > > > > > This means the SIP endpoint is unreachable unless you > > are also in the > > > same private network. Actually I believe a private IP address cannot > > > even be provisioned in a public DNS. > > > > > > Before somebody mentions it...for a UA behind a NAT to > > be reachable, > > > he/she needs a public NAT binding so that a session > > _initiated_ from the > > > public side can be made to him/her. > > > > > > b) the IP address is public. > > > > > > The SIP endpoint is theoretically reachable. > > > > > > 2) The AoR cannot get translated. Again, just like the > > Internet we have > > > today, this means the domain name/user is private, does not > > exist, etc > > > > > > All this has been happening okay with just a few basic > > rules. If an AoR > > > is very similar to an email address, why it would not work with the > > > current infrastructure/definitions? > > > > > > If somebody says that they have a "private" email address or domain > > > name, what is your interpretation of that? > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > translated > > > > into an IP by a registrar inside a private IP subnet, and > > somehow it > > > later > > > > gets translated into the public IP address space, that's > > also private > > > > because the AoR was translated to a private IP originally? > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > For you to be "SIP reachable", you need to be IP > > reachable first, > > > let's > > > > > not forget about that. And if you are IP reachable, you could=20 > > > > > potentially be SIP reachable by registering to some > > free SIP service > > > (or > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > email/DNS > > > > > model). > > > > > > > > Actually, to be very specific ultimate target of the AoR > > can be "sip > > > > reachable" but not IP reachable. But I think for now we > > should ignore > > > the > > > > implications of that, unless it becomes a problem. > > > > > > > > -hadriel > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > >_______________________________________________ >Speermint mailing list >Speermint@ietf.org >https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint 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 Apr 05 11:37:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRA49-0004H1-L8; Wed, 05 Apr 2006 11:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRA48-0004Gw-Ui for speermint@ietf.org; Wed, 05 Apr 2006 11:37:04 -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 1FR9HF-0001KZ-UG for speermint@ietf.org; Wed, 05 Apr 2006 10:46:33 -0400 Received: from outbound-kan.frontbridge.com ([63.161.60.23] helo=outbound1-kan-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FR95R-0002e1-ON for speermint@ietf.org; Wed, 05 Apr 2006 10:34:22 -0400 Received: from outbound1-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-kan-R.bigfish.com (Postfix) with ESMTP id 03C8648745D; Wed, 5 Apr 2006 14:34:15 +0000 (UTC) Received: from mail37-kan-R.bigfish.com (unknown [172.18.7.1]) by outbound1-kan.bigfish.com (Postfix) with ESMTP id 0205C4871EE; Wed, 5 Apr 2006 14:34:15 +0000 (UTC) Received: from mail37-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail37-kan-R.bigfish.com (Postfix) with ESMTP id E20BF1BBDDE; Wed, 5 Apr 2006 14:34:14 +0000 (UTC) X-BigFish: V Received: by mail37-kan (MessageSwitch) id 1144247654799515_5276; Wed, 5 Apr 2006 14:34:14 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail37-kan.bigfish.com (Postfix) with ESMTP id BDEFA1BB451; Wed, 5 Apr 2006 14:34:14 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k35EXt5l021210; Wed, 5 Apr 2006 09:33:56 -0500 (CDT) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k35EXt010569; Wed, 5 Apr 2006 09:33:55 -0500 (CDT) Received: from PLSWB08C.ad.sprint.com ([208.10.70.244]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 09:33:52 -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] RE: NATs and Firewalls Date: Wed, 5 Apr 2006 09:33:41 -0500 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E07310DD7@PLSWB08C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: NATs and Firewalls Thread-Index: AcZYtWWjOTUwsRURTPmhqqgwJ4opwgACB/gQ From: "Khan, Sohel Q [CTO]" To: "Jonathan Rosenberg" , "Hadriel Kaplan" X-OriginalArrivalTime: 05 Apr 2006 14:33:52.0767 (UTC) FILETIME=[F61B10F0:01C658BD] X-Spam-Score: -2.6 (--) 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 Jonathan Rosenberg wrote:=20 ... >Folks also claim that NAT provides security by obfuscating the network behind the NAT. An attacker cannot=20 >determine how many hosts are behind the nat, and it never sees any of their addresses. I'm skeptical that this is a real > security benefit, but hiding of internal topology and internal addresses is often cited as a security feature; YMMV. I agree that topology hiding is a kind of security feature. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 12:10:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAam-0006iP-Gr; Wed, 05 Apr 2006 12:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAak-0006iK-PA for speermint@ietf.org; Wed, 05 Apr 2006 12:10:46 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRAak-0005sI-EZ for speermint@ietf.org; Wed, 05 Apr 2006 12:10:46 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com for speermint@ietf.org; Wed, 5 Apr 2006 12:10:33 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040512103302794 for ; Wed, 05 Apr 2006 12:10:33 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Apr 2006 12:10:33 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230D7E@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls/Topology Hiding Date: Wed, 5 Apr 2006 12:10:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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="===============0523018338==" Errors-To: speermint-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0523018338== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658CB.72ECF47F" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C658CB.72ECF47F Content-Type: text/plain; charset="iso-8859-1" Folks: I see some interesting discussions related to security. In the last p2p-SIP BoF, it turns out as follows: a. Absolute Security and b. Relative Security. It was opined that it is almost impractical, if not impossible, to devise any schemes that can be termed as Absolute Security. So, out works are falling to a "kind" of Relative Security. I guess, in this context, that NATs/Firewalls that provide topology hiding, as Sohel pointed out, also fall into this category. We can also think that the tremendous popularity of the VPNs is also primarily for the topology hiding. Since this topology hiding feature has come to stay, we have no choice but have to deal with this. The point is this: Let us not debate whether NATs/Firewalls/VPNs provide good security or not. Rather, let us assume that the topology hiding features are there, and how do we deal with this reality? Best regards, Radhika -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org ] On Behalf Of Khan, Sohel Q [CTO] Sent: Wednesday, April 05, 2006 10:34 AM To: Jonathan Rosenberg; Hadriel Kaplan Cc: Stastny Richard; speermint@ietf.org Subject: RE: [Speermint] RE: NATs and Firewalls Jonathan Rosenberg wrote: ... >Folks also claim that NAT provides security by obfuscating the network behind the NAT. An attacker cannot >determine how many hosts are behind the nat, and it never sees any of their addresses. I'm skeptical that this is a real > security benefit, but hiding of internal topology and internal addresses is often cited as a security feature; YMMV. I agree that topology hiding is a kind of security feature. Sohel Khan, Ph.D. Technology Strategist Sprint-Nextel ------_=_NextPart_001_01C658CB.72ECF47F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Speermint] NATs and Firewalls/Topology Hiding

Folks:

I see some = interesting discussions related to security.

In = the = last p2p-SIP BoF, it turns out as follows: a. = Absolute Security and b. Relative Security.

It was opined that = it is almost impractical, if not impossible, to = devise any schemes that can be termed as Absolute = Security.

So, out works are = falling to a "kind" of Relative = Security. I guess, in this context, that = NATs/Firewalls that provide topology hiding, as = Sohel = pointed out, also fall into this = category.

We can also = think = that the tremendous popularity = of the = VPNs is also primarily for the topology = hiding. = Since this topology hiding feature has come to stay, we = have no choice but have to deal with this.

The point is this: = Let us not debate whether NATs/Firewalls/VPNs provide good security or not. Rather, let = us assume that the topology hiding features are = there, and how do we deal with this reality?

Best = regards,

Radhika

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf= .org] On Behalf Of Khan, Sohel Q [CTO]
Sent: Wednesday, April 05, 2006 10:34 AM
To: Jonathan Rosenberg; Hadriel Kaplan
Cc: Stastny Richard; speermint@ietf.org
Subject: RE: [Speermint] RE: NATs and Firewalls

Jonathan Rosenberg wrote:

...

>Folks also claim that NAT provides security by obfuscating = the network

behind the NAT. An attacker cannot

>determine how many hosts are behind the nat, and it never = sees any of

their addresses. I'm skeptical that this is a real > security = benefit,

but hiding of internal topology and internal addresses is often = cited as

a security feature; YMMV.

I agree that topology hiding is a kind of security = feature.

Sohel Khan, Ph.D.

Technology Strategist

Sprint-Nextel


------_=_NextPart_001_01C658CB.72ECF47F-- --===============0523018338== 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 --===============0523018338==-- From speermint-bounces@ietf.org Wed Apr 05 12:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAnX-0005sQ-47; Wed, 05 Apr 2006 12:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRAnW-0005sL-HN for speermint@ietf.org; Wed, 05 Apr 2006 12:23:58 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRAnV-0006W8-IW for speermint@ietf.org; Wed, 05 Apr 2006 12:23:58 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AF1B01CC; Wed, 05 Apr 2006 12:23:55 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 12:24:01 -0400 Message-ID: <06c501c658cd$597026e0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuS24skh+1UW2Ramqir6Erdv/ZwABSc+gAAG1GVA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3014A3EBD@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 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 Totally agree. Neither the term firewall nor NAT is atomic (nor router for that matter). I was trying to avoid defining the specific functions of SBCs because the term is overloaded, but it's apparent not everyone even understands what they generically do, how they do it, and why. I prefer to stick with Brian's recommendation that we treat border nodes as proxies for Speermint's work in general. I merely wanted to point out that we may bump into aspects which make a difference when something other than a strict proxy is used. The easiest way to do this I think in the IETF is to allow for the case where disparate L3 VPNs peer together (in a shared/common address space of course). Nothing more need be defined I think. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, April 05, 2006 10:43 AM > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > Agree. > > However, even some of the remaining terms are probably overloaded. > Is the term "firewall" really atomic? > > I would try to get as granular as possible to avoid further confusion. > At the previous SBC BoF no one could agree on what an SBC included, but > could grasp each of the mechanisms once spelled out. > > Mike > > > > -----Original Message----- > > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > > Sent: Wednesday, April 05, 2006 9:59 AM > > To: Drage, Keith (Keith); speermint@ietf.org > > Subject: RE: [Speermint] NATs and Firewalls > > > > Agree. Let's avoid the term "SBC" in the speermint area. We > > don't need the history lesson and the term is still evolving. > > I just finished a Skype call and did not use a SBC to peer > > with my one in 6 million users. > > > > Yes, let's just define the requirements ... Edge Proxy, NAPT, > > Media Proxy, Security Firewall and NAT/firewall traversal. > > > > /PETER MACAULAY > > > > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > > >And to support Richard on this. > > > > > >Please avoid using the term "SBC" in the speermint area. > > Please clearly > > >identify the function of these supposed wonder boxes that you are > > >addressing as an area of concern or advantage. Therefore if you mean > > >NAT, say NAT, if you mean firewall, say firewall, if you > > mean something > > >else, say so. These boxes contain so many features (in the > > widest sense > > >of the word) that in the absence of specific information we get lost. > > > > > >regards > > > > > >Keith > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: 04 April 2006 18:15 > > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > > > speermint@ietf.org > > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > > > > I think some people out there either do not understand the > > > > difference between NATs and firewalls or are starting to believe > > > > their own propaganda > > > > > > > > NATs are NATs and firewalls are firewalls > > > > > > > > The worst misconception here is that a NAT is for providing you > > > > security against the bad Internet > > > > > > > > Private adress spaces have been introduced to save a scarce > > > > ressource (or what some believed are a scarce ressource at some > > > > point of time) > > > > > > > > You can live very safe behind a properly configured > > firewall using > > > > only public IP adresses. > > > > > > > > The basic idea of IPv6 was to give every device on earth and also > > > > within the solar system a unique public IP address > > > > > > > > But the fake security of NATs was already in the minds of most > > > > people, that the first things that were implemented in IPv6 where > > > > NATs for IPv6, which is a perversion > > > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > Gesendet: Di 04.04.2006 18:22 > > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > > > speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Hi Richard, > > > > And here we get to the fun stuff. :) > > > > > > > > The idea of every serving proxy/registrar/sip-node needing to be > > > > publicly addressable is neither an Internet requirement, nor a > > > > requirement of the IETF. Entire working groups in the > > IETF concern > > > > themselves with allowing, enabling, and inter-working private > > > > address spaces and VPNs. > > > > What's missing > > > > is how to join them at the application and transport layer, when > > > > that application layer embeds addressing in itself. > > > > > > > > Most consumers on the planet Earth are in private address > > spaces at > > > > this point I think (i.e., 192.168.x.x), and many > > Enterprises are as > > > > well. Entire networks in some countries are privately addressed, > > > > yet they are members of, and use, the Internet. There > > are also now > > > > 2 disjoint address groups defined by the IETF, as you > > know: IPv4 and > > > > IPv6. There are mechanisms to try to provide > > > > interoperation/migration support for them, but that typically > > > > requires intermediaries. > > > > > > > > So I agree with you there needs to be an entity providing > > an ingress > > > > (and > > > > egress) point(s), either on the public network for it to > > be public, > > > > or for it to cross into another private address domain. For this > > > > WG's purpose, I recommend we allow either model to work, > > as well as > > > > the model of the private going to public (and vice-versa) > > so long as > > > > the peering element of both sides are in the same public > > or private > > > > space. > > > > > > > > -Hadriel > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > > speermint@ietf.org > > > > > Subject: Re: [Speermint] Reachability > > > > > > > > > > >The conclusion here -- every endpoint and every serving > > > > proxy/registrar > > > > > >needs to be publicly addressable. > > > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > > everybody. > > > > > This was also why I had a problem with Sohel's presentation > > > > at the IETF, > > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > > > For the avoidance of doubt: I have no problem if the > > same peering > > > > > principles we develop here are used between some entities > > > > in a private > > > > > network, > > > > > but it is not out task to consider this separately. Because > > > > if it works > > > > > on the Internet, it also works in a private network > > > > (extranet in this > > > > > case) > > > > > (see DNS). this private network may even use public IP > > > > adresses, but if > > > > > the > > > > > are not routable from the public Internet, they are > > could as well > > > > > be private (example IPX) > > > > > > > > > > What never can work is a peering between one entity on the > > > > public network > > > > > and one on a private network. The private entities need at > > > > least to have > > > > > one > > > > > ingress element on the public network > > > > > > > > > > Richard > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > > Gesendet: Di 04.04.2006 15:29 > > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > > > But I want to ensure everybody understands what your really > > > > saying here. > > > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > > reachable, > > > > > he/she needs a public NAT binding so that a session > > > > _initiated_ from the > > > > > public side can be made to him/her. > > > > > > > > > > This means that for carrier to carrier peering models, each > > > > and every > > > > > customer of every carrier that wants to inter-connect needs > > > > to have a > > > > > 'public NAT binding'. > > > > > > > > > > I believe by extension, this means that a serving > > > > proxy/registrar for the > > > > > target of a communication must ALSO have either a public > > > > address or a > > > > > public > > > > > NAT binding. > > > > > > > > > > The conclusion here -- every endpoint and every serving > > > > proxy/registrar > > > > > needs to be publicly addressable. > > > > > > > > > > Am I correct? > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hello Hadriel, > > > > > > > > > > Comment inline.... > > > > > > > > > > > -----Original Message----- > > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Reinaldo, > > > > > > Comments inline... > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > > > Maybe I'm missing something, but given that this > > workgroup is > > > > > interested > > > > > > > only in call routing (E.164 is out of scope), do we > > > > really need to > > > > > care > > > > > > > about that? An AoR in the end will be translated to an > > > > IP address, > > > > > and > > > > > > > IP addresses have a very good definition of public and > > > > private (in > > > > > IPv4 > > > > > > > and IPv6). > > > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > > "translated" > > > > > > to an IP Address (and really to a contact URI) by the > > > > AoR's domain. > > > > > So > > > > > > what > > > > > > you're saying is if the AoR's user-part represents a > > > > consumer behind a > > > > > > home > > > > > > NAT (a private IP), then it is a private AoR; but for > > > > those consumers > > > > > who > > > > > > don't use home-NATs then it's a public AoR? > > > > > [[Reinaldo]] > > > > > > > > > > Hello, > > > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > > discussion, > > > > > that's why I gave that example. I was trying to > > understand why it > > > > > matters, before getting knee deep into the classification. > > > > Can someone > > > > > refresh that for me? > > > > > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > > > internet, the rules for domains names, DNS resolution, > > private vs. > > > > > public IP address, etc should apply, right? > > > > > > > > > > I believe the current model of host to host or email > > > > communication is > > > > > not different for SIP. We could have the following main > > > > > situations...(correct me where I'm wrong). > > > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > > in the end > > > > > will get resolved into an IP address. Then there are only two > > > > > situations. > > > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > > > This means the SIP endpoint is unreachable unless you > > > > are also in the > > > > > same private network. Actually I believe a private IP address > > > > > cannot even be provisioned in a public DNS. > > > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > > be reachable, > > > > > he/she needs a public NAT binding so that a session > > > > _initiated_ from the > > > > > public side can be made to him/her. > > > > > > > > > > b) the IP address is public. > > > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > > Internet we have > > > > > today, this means the domain name/user is private, does not > > > > exist, etc > > > > > > > > > > All this has been happening okay with just a few basic > > > > rules. If an AoR > > > > > is very similar to an email address, why it would not work with > > > > > the current infrastructure/definitions? > > > > > > > > > > If somebody says that they have a "private" email address or > > > > > domain name, what is your interpretation of that? > > > > > > > > > > Regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > > translated > > > > > > into an IP by a registrar inside a private IP subnet, and > > > > somehow it > > > > > later > > > > > > gets translated into the public IP address space, that's > > > > also private > > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > > reachable first, > > > > > let's > > > > > > > not forget about that. And if you are IP reachable, > > you could > > > > > > > potentially be SIP reachable by registering to some > > > > free SIP service > > > > > (or > > > > > > > the SIP "domain" above you in the hierarchy...if > > this was the > > > > > email/DNS > > > > > > > model). > > > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > > can be "sip > > > > > > reachable" but not IP reachable. But I think for now we > > > > should ignore > > > > > the > > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > > > -hadriel > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > >_______________________________________________ > > >Speermint mailing list > > >Speermint@ietf.org > > >https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint 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 Apr 05 12:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBDT-0006E4-7T; Wed, 05 Apr 2006 12:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRBDR-0006DR-DX for speermint@ietf.org; Wed, 05 Apr 2006 12:50:45 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBDR-0007Yd-4V for speermint@ietf.org; Wed, 05 Apr 2006 12:50:45 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A563017C; Wed, 05 Apr 2006 12:50:43 -0400 From: "Hadriel Kaplan" To: "'Medhavi Bhatia'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 12:50:47 -0400 Message-ID: <06d201c658d1$17d10020$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6A= In-Reply-To: <8812D8156467224C9E9739E513037EF1518ADB@moe.nextone.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) 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 Hi Medhavi, I must say that is a very interesting statement for you to make. ;) Of course boxes and behaviors evolve. But from my perspective, vendors don't do things because they want to or a standard tells them to. They do it because their customers want them to. If they don't do what the customers want, they get replaced with a box that will. This is the fundamental difficulty with mandating how customers should deploy and use equipment, in a use-agnostic/universal standards forum. One can either look at what is done today for legitimate, customer-valued reasons, or one can look at it as "filling a hole". I prefer the former. People thought home-NATs and firewalls were just filling a hole and would go away. :) Regardless, I think this can be accomplished in the IETF if we stick to BCPs which are as broadly applicable as possible, while meeting the requirements. I agree with you the requirements come first, and that is what we should be discussing. One of those requirements, IMO, is joining disparate L3 domains, which is a different issue than joining administrative domains (if by administrative you mean SIP domains). Do you agree? Cheers, -hadriel p.s. that was not meant as a flame whatsoever - simply expressing a different viewpoint. > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, April 05, 2006 11:25 AM > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > I'd agree. Lets focus on requirements of peering based on SIP > RFCs/drafts, location and address translation mechanisms. The only > things which impact any sort of architecture are the administrative > domains, P2P domains and federations where subscribers are. > > As far as the discussion on SBCs, we have had a lengthy one in SIPPING. > It would be fair to say (and I may get flamed for this) that the reason > where we are with SBCs today is primarily because some service providers > were doing "stuff" differently with SIP. SBCs simply capitalized on open > holes in requirements. This will go away with time with more > competition, open networks (job of speermint?) and open solutions from > IETF. SBCs will change (or follow the money as some would say...). > > We need to look forward. SBCs and other infrastructure equipment vendors > (Edge proxies, core proxies etc) will follow these requirements. We must > take care however that we get the right set of SP requirements and form > the right solution. > > -Medhavi. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 13:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRC0n-0006sv-50; Wed, 05 Apr 2006 13:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRC0m-0006sq-7d for speermint@ietf.org; Wed, 05 Apr 2006 13:41:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRC0h-0000eU-NB for speermint@ietf.org; Wed, 05 Apr 2006 13:41:44 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A11D01E4; Wed, 05 Apr 2006 13:40:45 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Medhavi Bhatia'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 13:40:39 -0400 Message-ID: <06e201c658d8$15827810$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AAAgwlZAAAg/Ow In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4971@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Of course, a good vendor has to tell the customer what's in the = customer's best interest. But it's na=EFve to think they can persuade them to do = what they don't agree is in their best-interest. Slippery-slope, here we come... -hadriel > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, April 05, 2006 1:23 PM > To: Hadriel Kaplan; Medhavi Bhatia; speermint@ietf.org > Subject: Re: [Speermint] NATs and Firewalls >=20 > >They do it because their customers want them to. >=20 > Ahem, excuse me, but this is a bit naiv ;-) > Some vendors are even trying to pull my leg by telling > me in confidence: I know this is stupid, but never argaue with your > customers >=20 > I reality a good vendor has to tell the customer what he should want. >=20 > This is the same for consumers (e.g. my dughter) as for telcos ;-) >=20 > Richard >=20 > ________________________________ >=20 > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Gesendet: Mi 05.04.2006 18:50 > An: 'Medhavi Bhatia'; speermint@ietf.org > Betreff: RE: [Speermint] NATs and Firewalls >=20 >=20 >=20 > Hi Medhavi, > I must say that is a very interesting statement for you to make. ;) >=20 > Of course boxes and behaviors evolve. But from my perspective, = vendors > don't do things because they want to or a standard tells them to. = They do > it because their customers want them to. If they don't do what the > customers want, they get replaced with a box that will. This is the > fundamental difficulty with mandating how customers should deploy and = use > equipment, in a use-agnostic/universal standards forum. >=20 > One can either look at what is done today for legitimate, = customer-valued > reasons, or one can look at it as "filling a hole". I prefer the = former. > People thought home-NATs and firewalls were just filling a hole and = would > go > away. :) >=20 > Regardless, I think this can be accomplished in the IETF if we stick = to > BCPs > which are as broadly applicable as possible, while meeting the > requirements. > I agree with you the requirements come first, and that is what we = should > be > discussing. One of those requirements, IMO, is joining disparate L3 > domains, which is a different issue than joining administrative = domains > (if > by administrative you mean SIP domains). Do you agree? >=20 > Cheers, > -hadriel > p.s. that was not meant as a flame whatsoever - simply expressing a > different viewpoint. >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Wednesday, April 05, 2006 11:25 AM > > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > > Subject: RE: [Speermint] NATs and Firewalls > > > > I'd agree. Lets focus on requirements of peering based on SIP > > RFCs/drafts, location and address translation mechanisms. The only > > things which impact any sort of architecture are the administrative > > domains, P2P domains and federations where subscribers are. > > > > As far as the discussion on SBCs, we have had a lengthy one in = SIPPING. > > It would be fair to say (and I may get flamed for this) that the = reason > > where we are with SBCs today is primarily because some service = providers > > were doing "stuff" differently with SIP. SBCs simply capitalized on = open > > holes in requirements. This will go away with time with more > > competition, open networks (job of speermint?) and open solutions = from > > IETF. SBCs will change (or follow the money as some would say...). > > > > We need to look forward. SBCs and other infrastructure equipment = vendors > > (Edge proxies, core proxies etc) will follow these requirements. We = must > > take care however that we get the right set of SP requirements and = form > > the right solution. > > > > -Medhavi. > > >=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 Apr 05 14:46:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRD1m-0002L8-SA; Wed, 05 Apr 2006 14:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRD1m-0002L3-Jc for speermint@ietf.org; Wed, 05 Apr 2006 14:46:50 -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 1FRBws-0000Rd-PJ for speermint@ietf.org; Wed, 05 Apr 2006 13:37:42 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1FRBit-0003yL-0R for speermint@ietf.org; Wed, 05 Apr 2006 13:23:17 -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] NATs and Firewalls Date: Wed, 5 Apr 2006 19:23:04 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4971@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AAAgwlZA== From: "Stastny Richard" To: "Hadriel Kaplan" , "Medhavi Bhatia" , X-Spam-Score: -2.3 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 >They do it because their customers want them to. =20 Ahem, excuse me, but this is a bit naiv ;-) Some vendors are even trying to pull my leg by telling me in confidence: I know this is stupid, but never argaue with your = customers =20 I reality a good vendor has to tell the customer what he should want. =20 This is the same for consumers (e.g. my dughter) as for telcos ;-) =20 Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Mi 05.04.2006 18:50 An: 'Medhavi Bhatia'; speermint@ietf.org Betreff: RE: [Speermint] NATs and Firewalls Hi Medhavi, I must say that is a very interesting statement for you to make. ;) Of course boxes and behaviors evolve. But from my perspective, vendors don't do things because they want to or a standard tells them to. They = do it because their customers want them to. If they don't do what the customers want, they get replaced with a box that will. This is the fundamental difficulty with mandating how customers should deploy and = use equipment, in a use-agnostic/universal standards forum.=20 One can either look at what is done today for legitimate, = customer-valued reasons, or one can look at it as "filling a hole". I prefer the = former. People thought home-NATs and firewalls were just filling a hole and = would go away. :) Regardless, I think this can be accomplished in the IETF if we stick to = BCPs which are as broadly applicable as possible, while meeting the = requirements. I agree with you the requirements come first, and that is what we should = be discussing. One of those requirements, IMO, is joining disparate L3 domains, which is a different issue than joining administrative domains = (if by administrative you mean SIP domains). Do you agree? Cheers, -hadriel p.s. that was not meant as a flame whatsoever - simply expressing a different viewpoint. > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, April 05, 2006 11:25 AM > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > I'd agree. Lets focus on requirements of peering based on SIP > RFCs/drafts, location and address translation mechanisms. The only > things which impact any sort of architecture are the administrative > domains, P2P domains and federations where subscribers are. > > As far as the discussion on SBCs, we have had a lengthy one in = SIPPING. > It would be fair to say (and I may get flamed for this) that the = reason > where we are with SBCs today is primarily because some service = providers > were doing "stuff" differently with SIP. SBCs simply capitalized on = open > holes in requirements. This will go away with time with more > competition, open networks (job of speermint?) and open solutions from > IETF. SBCs will change (or follow the money as some would say...). > > We need to look forward. SBCs and other infrastructure equipment = vendors > (Edge proxies, core proxies etc) will follow these requirements. We = must > take care however that we get the right set of SP requirements and = form > the right solution. > > -Medhavi. > _______________________________________________ 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 Apr 05 15:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDIA-0000Jy-B4; Wed, 05 Apr 2006 15:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDI9-0000Jo-99 for speermint@ietf.org; Wed, 05 Apr 2006 15:03:45 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDI8-0004vV-FU for speermint@ietf.org; Wed, 05 Apr 2006 15:03:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 05 Apr 2006 12:03:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="538021169:sNHT28095360" 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] NATs and Firewalls Date: Wed, 5 Apr 2006 15:03:26 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5EC@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuShs/923AjMUR0aRwYdalHAkgwACDrqgAABukcAAB+wJcA== From: "Reinaldo Penno" To: "Uzelac, Adam" , "Malas, Daryl" , "Peter Macaulay" , "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d 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 Hello Adam,=20 The charter seems pretty clear that media is included.=20 " However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration." As I mentioned in a previous thread, is it any good that the SIP session is established but you cannot hear/talk? We need to keep media in mind so we do not come up with a peering architecture with fundamental problems. I mean, I considered the fact that I cannot hear/talk a fundamental problem. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, April 05, 2006 8:15 AM > To: Malas, Daryl; Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > The one problem that I have with the term IP Media Gateway is the > assumption that signaling and media will traverse the element. The > focus needs to be on the signaling. I understand the logical evolution > of the Media Gateway from it's historical roots, but we have to leave > the bearer/media out of this working group's charter. >=20 > -AU >=20 > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Wednesday, April 05, 2006 11:01 AM > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Well, in IMS terms, the closest stated term is IMS ALG. Since, I do not > like that term, because it limits the capability of the element; I > commonly refer to the device simply as an IP MG (Media Gateway). This > eliminates the need to place a frame work around the function. >=20 > --Daryl >=20 > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > Sent: Wednesday, April 05, 2006 7:59 AM > To: Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Agree. Let's avoid the term "SBC" in the speermint area. We don't need > the history lesson and the term is still evolving. I just finished a > Skype call and did not use a SBC to peer with my one in 6 million users. >=20 > Yes, let's just define the requirements ... Edge Proxy, NAPT, Media > Proxy, Security Firewall and NAT/firewall traversal. >=20 > /PETER MACAULAY >=20 > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >And to support Richard on this. > > > >Please avoid using the term "SBC" in the speermint area. Please clearly >=20 > >identify the function of these supposed wonder boxes that you are > >addressing as an area of concern or advantage. Therefore if you mean > >NAT, say NAT, if you mean firewall, say firewall, if you mean something >=20 > >else, say so. These boxes contain so many features (in the widest sense >=20 > >of the word) that in the absence of specific information we get lost. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: 04 April 2006 18:15 > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > > speermint@ietf.org > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > I think some people out there either do not understand the > > > difference between NATs and firewalls or are starting to believe > > > their own propaganda > > > > > > NATs are NATs and firewalls are firewalls > > > > > > The worst misconception here is that a NAT is for providing you > > > security against the bad Internet > > > > > > Private adress spaces have been introduced to save a scarce > ressource > > > (or what some believed are a scarce ressource at some point of time) > > > > > > You can live very safe behind a properly configured firewall using > > > only public IP adresses. > > > > > > The basic idea of IPv6 was to give every device on earth and also > > > within the solar system a unique public IP address > > > > > > But the fake security of NATs was already in the minds of most > > > people, that the first things that were implemented in IPv6 where > > > NATs for IPv6, which is a perversion > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Gesendet: Di 04.04.2006 18:22 > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > > speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Richard, > > > And here we get to the fun stuff. :) > > > > > > The idea of every serving proxy/registrar/sip-node needing to be > > > publicly addressable is neither an Internet requirement, nor a > > > requirement of the IETF. Entire working groups in the IETF concern > > > themselves with allowing, enabling, and inter-working private > > > address spaces and VPNs. > > > What's missing > > > is how to join them at the application and transport layer, when > that > > > application layer embeds addressing in itself. > > > > > > Most consumers on the planet Earth are in private address spaces at > > > this point I think (i.e., 192.168.x.x), and many Enterprises are as > > > well. Entire networks in some countries are privately addressed, > > > yet they are members of, and use, the Internet. There are also now > > > 2 disjoint address groups defined by the IETF, as you know: IPv4 and >=20 > > > IPv6. There are mechanisms to try to provide > > > interoperation/migration support for them, but that > typically > > > requires intermediaries. > > > > > > So I agree with you there needs to be an entity providing an ingress >=20 > > > (and > > > egress) point(s), either on the public network for it to be public, > > > or for it to cross into another private address domain. For this > > > WG's purpose, I recommend we allow either model to work, as well as > > > the model of the private going to public (and vice-versa) so long as >=20 > > > the peering element of both sides are in the same public or private > > > space. > > > > > > -Hadriel > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > speermint@ietf.org > > > > Subject: Re: [Speermint] Reachability > > > > > > > > >The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > >needs to be publicly addressable. > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > everybody. > > > > This was also why I had a problem with Sohel's presentation > > > at the IETF, > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > > principles we develop here are used between some entities > > > in a private > > > > network, > > > > but it is not out task to consider this separately. Because > > > if it works > > > > on the Internet, it also works in a private network > > > (extranet in this > > > > case) > > > > (see DNS). this private network may even use public IP > > > adresses, but if > > > > the > > > > are not routable from the public Internet, they are could as well > be > > > > private > > > > (example IPX) > > > > > > > > What never can work is a peering between one entity on the > > > public network > > > > and one on a private network. The private entities need at > > > least to have > > > > one > > > > ingress element on the public network > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Gesendet: Di 04.04.2006 15:29 > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > But I want to ensure everybody understands what your really > > > saying here. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > This means that for carrier to carrier peering models, each > > > and every > > > > customer of every carrier that wants to inter-connect needs > > > to have a > > > > 'public NAT binding'. > > > > > > > > I believe by extension, this means that a serving > > > proxy/registrar for the > > > > target of a communication must ALSO have either a public > > > address or a > > > > public > > > > NAT binding. > > > > > > > > The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > needs to be publicly addressable. > > > > > > > > Am I correct? > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hello Hadriel, > > > > > > > > Comment inline.... > > > > > > > > > -----Original Message----- > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hi Reinaldo, > > > > > Comments inline... > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > > interested > > > > > > only in call routing (E.164 is out of scope), do we > > > really need to > > > > care > > > > > > about that? An AoR in the end will be translated to an > > > IP address, > > > > and > > > > > > IP addresses have a very good definition of public and > > > private (in > > > > IPv4 > > > > > > and IPv6). > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > "translated" > > > > > to an IP Address (and really to a contact URI) by the > > > AoR's domain. > > > > So > > > > > what > > > > > you're saying is if the AoR's user-part represents a > > > consumer behind a > > > > > home > > > > > NAT (a private IP), then it is a private AoR; but for > > > those consumers > > > > who > > > > > don't use home-NATs then it's a public AoR? > > > > [[Reinaldo]] > > > > > > > > Hello, > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > discussion, > > > > that's why I gave that example. I was trying to understand why it > > > > matters, before getting knee deep into the classification. > > > Can someone > > > > refresh that for me? > > > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > > internet, the rules for domains names, DNS resolution, private vs. > > > > public IP address, etc should apply, right? > > > > > > > > I believe the current model of host to host or email > > > communication is > > > > not different for SIP. We could have the following main > > > > situations...(correct me where I'm wrong). > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > in the end > > > > will get resolved into an IP address. Then there are only two > > > > situations. > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > This means the SIP endpoint is unreachable unless you > > > are also in the > > > > same private network. Actually I believe a private IP address > cannot > > > > even be provisioned in a public DNS. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > be reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > b) the IP address is public. > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > Internet we have > > > > today, this means the domain name/user is private, does not > > > exist, etc > > > > > > > > All this has been happening okay with just a few basic > > > rules. If an AoR > > > > is very similar to an email address, why it would not work with > the > > > > current infrastructure/definitions? > > > > > > > > If somebody says that they have a "private" email address or > domain > > > > name, what is your interpretation of that? > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > translated > > > > > into an IP by a registrar inside a private IP subnet, and > > > somehow it > > > > later > > > > > gets translated into the public IP address space, that's > > > also private > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > reachable first, > > > > let's > > > > > > not forget about that. And if you are IP reachable, you could > > > > > > potentially be SIP reachable by registering to some > > > free SIP service > > > > (or > > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > > email/DNS > > > > > > model). > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > can be "sip > > > > > reachable" but not IP reachable. But I think for now we > > > should ignore > > > > the > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > 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 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 15:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDNk-0001T7-3o; Wed, 05 Apr 2006 15:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDNi-0001T2-Ov for speermint@ietf.org; Wed, 05 Apr 2006 15:09:30 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDNi-00059F-GV for speermint@ietf.org; Wed, 05 Apr 2006 15:09:30 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 05 Apr 2006 12:09:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="538022105:sNHT22729552" 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] NATs and Firewalls Date: Wed, 5 Apr 2006 15:09:28 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5ED@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuFXWwdWlV9iiROGS3def9NlhDAAK7big From: "Reinaldo Penno" To: "Spencer Dawkins" , "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Hello Spencer,=20 Not even routers that have been around 30-40 years have a "standard" list of functions. In the BGP/VPN area alone you have at least 100 different functions.=20 The only thing all routers do for sure is perform a routing lookup and send a packet out of an interface.=20 Regards, Reinaldo > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, April 05, 2006 6:51 AM > To: Patrick Melampy; speermint@ietf.org > Subject: Re: [Speermint] NATs and Firewalls >=20 > As Keith said - this list of functions should have been at least two or > three lines long for most SBC products, and there is no standard list > offered by all SBCs. This is, of course, WHY we need to avoid using the > word > "SBC" as if we had agreement on what SBCs do, and do not, provide. >=20 > Spencer >=20 >=20 > > What should we call the function(s) that an SBC provides? How about... > > > > Edge Proxy/NAPT/Media Proxy/Security Firewall >=20 >=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 Wed Apr 05 15:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDYw-0006jy-86; Wed, 05 Apr 2006 15:21:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDYu-0006hg-Uw for speermint@ietf.org; Wed, 05 Apr 2006 15:21:04 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRDYu-0005my-LG for speermint@ietf.org; Wed, 05 Apr 2006 15:21:04 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 15:21:04 -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] NATs and Firewalls Date: Wed, 5 Apr 2006 15:21:02 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A06E@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls thread-index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcA== From: "Medhavi Bhatia" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 05 Apr 2006 19:21:04.0331 (UTC) FILETIME=[14EB11B0:01C658E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Hadriel, See below. > Hi Medhavi, > I must say that is a very interesting statement for you to make. ;) >=20 I presume you are talking about "filling the hole" statement?=20 I think there is a vast deal of difference between a requirement and the implementation. First, most SBCs today look like "point solutions" (sometimes unattractive but allowed - holes) for "point" requirements. Second, there is much more awareness and long term vision amongst service providers now than a few years back. For example, there is a good deal of understanding of interconnects in general and how security should be implemented across interconnects in a service agnostic manner (compare with: block this header, change this etc etc). Solutions are looking more cleaner, but the existing installed base may ultimately slow down the opening of networks to new services or other networks. > Of course boxes and behaviors evolve. But from my perspective, vendors > don't do things because they want to or a standard tells them to. They do > it because their customers want them to. If they don't do what the > customers want, they get replaced with a box that will. This is the > fundamental difficulty with mandating how customers should deploy and use > equipment, in a use-agnostic/universal standards forum. >=20 They key is to understand what the right questions and requirements are. If the customer is not asking them, the vendors should. More flames welcome ... :) I need a spearmint... -Medhavi. > One can either look at what is done today for legitimate, customer-valued > reasons, or one can look at it as "filling a hole". I prefer the former. > People thought home-NATs and firewalls were just filling a hole and would go > away. :) >=20 > Regardless, I think this can be accomplished in the IETF if we stick to BCPs > which are as broadly applicable as possible, while meeting the requirements. > I agree with you the requirements come first, and that is what we should be > discussing. One of those requirements, IMO, is joining disparate L3 > domains, which is a different issue than joining administrative domains (if > by administrative you mean SIP domains). Do you agree? >=20 > Cheers, > -hadriel > p.s. that was not meant as a flame whatsoever - simply expressing a > different viewpoint. >=20 >=20 > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Wednesday, April 05, 2006 11:25 AM > > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > > Subject: RE: [Speermint] NATs and Firewalls > > > > I'd agree. Lets focus on requirements of peering based on SIP > > RFCs/drafts, location and address translation mechanisms. The only > > things which impact any sort of architecture are the administrative > > domains, P2P domains and federations where subscribers are. > > > > As far as the discussion on SBCs, we have had a lengthy one in SIPPING. > > It would be fair to say (and I may get flamed for this) that the reason > > where we are with SBCs today is primarily because some service providers > > were doing "stuff" differently with SIP. SBCs simply capitalized on open > > holes in requirements. This will go away with time with more > > competition, open networks (job of speermint?) and open solutions from > > IETF. SBCs will change (or follow the money as some would say...). > > > > We need to look forward. SBCs and other infrastructure equipment vendors > > (Edge proxies, core proxies etc) will follow these requirements. We must > > take care however that we get the right set of SP requirements and form > > the right solution. > > > > -Medhavi. > > >=20 >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 15:39:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDqL-0002gk-Dx; Wed, 05 Apr 2006 15:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRDqK-0002ev-9x for speermint@ietf.org; Wed, 05 Apr 2006 15:39:04 -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 1FRDqH-0006t3-Gg for speermint@ietf.org; Wed, 05 Apr 2006 15:39:04 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 387AB837E; Wed, 5 Apr 2006 15:39:01 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 15:39: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] NATs and Firewalls Date: Wed, 5 Apr 2006 15:38:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuShs/923AjMUR0aRwYdalHAkgwACDrqgAABukcAAB+wJcAAAoxKg From: "Uzelac, Adam" To: "Reinaldo Penno" , "Malas, Daryl" , "Peter Macaulay" , "Drage, Keith (Keith)" , X-OriginalArrivalTime: 05 Apr 2006 19:39:01.0191 (UTC) FILETIME=[96C6DD70:01C658E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 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 Hello Reinaldo, We may be stumbling on some ambiguity?!?! I read this... Session Peering for Multimedia Interconnect focuses on how to identify and route real-time sessions (such as VoIP calls) at the application layer, and it does not (necessarily) involve the exchange of packet routing data or media sessions. http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termin ology-01.txt ...and then compare it to the citation you put forth and get to thinking. I should have been more clear - we should consider, but not assume that signaling and media will follow the same path - that's all I meant. The term 'IP Media Gateway' makes me think that media will be going to it.=20 The path that the session signaling may take could be complete different than the media. I agree that we need to keep media in mind to ensure we do not come up with a problematic peering arch. I know the initial impetus here is voip, but a Session can be anything at the end of the day, so hear/talk might not be meaningful. I know all to well what you are referring to, and what's worse than not being able to hear/talk is uni-directional communications, like I can hear you, but you can't hear me. Holy asymmetric frustration batman! Reinaldo - I am agreeing with you (and the charter), media should be considered. -AU -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Wednesday, April 05, 2006 3:03 PM To: Uzelac, Adam; Malas, Daryl; Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Hello Adam,=20 The charter seems pretty clear that media is included.=20 " However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration." As I mentioned in a previous thread, is it any good that the SIP session is established but you cannot hear/talk? We need to keep media in mind so we do not come up with a peering architecture with fundamental problems. I mean, I considered the fact that I cannot hear/talk a fundamental problem. Regards, Reinaldo > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, April 05, 2006 8:15 AM > To: Malas, Daryl; Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > The one problem that I have with the term IP Media Gateway is the=20 > assumption that signaling and media will traverse the element. The=20 > focus needs to be on the signaling. I understand the logical evolution > of the Media Gateway from it's historical roots, but we have to leave=20 > the bearer/media out of this working group's charter. >=20 > -AU >=20 > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Wednesday, April 05, 2006 11:01 AM > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Well, in IMS terms, the closest stated term is IMS ALG. Since, I do not > like that term, because it limits the capability of the element; I=20 > commonly refer to the device simply as an IP MG (Media Gateway). This > eliminates the need to place a frame work around the function. >=20 > --Daryl >=20 > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > Sent: Wednesday, April 05, 2006 7:59 AM > To: Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Agree. Let's avoid the term "SBC" in the speermint area. We don't need > the history lesson and the term is still evolving. I just finished a=20 > Skype call and did not use a SBC to peer with my one in 6 million users. >=20 > Yes, let's just define the requirements ... Edge Proxy, NAPT, Media=20 > Proxy, Security Firewall and NAT/firewall traversal. >=20 > /PETER MACAULAY >=20 > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >And to support Richard on this. > > > >Please avoid using the term "SBC" in the speermint area. Please clearly >=20 > >identify the function of these supposed wonder boxes that you are=20 > >addressing as an area of concern or advantage. Therefore if you mean=20 > >NAT, say NAT, if you mean firewall, say firewall, if you mean something >=20 > >else, say so. These boxes contain so many features (in the widest sense >=20 > >of the word) that in the absence of specific information we get lost. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: 04 April 2006 18:15 > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;=20 > > > speermint@ietf.org > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > I think some people out there either do not understand the=20 > > > difference between NATs and firewalls or are starting to believe=20 > > > their own propaganda > > > > > > NATs are NATs and firewalls are firewalls > > > > > > The worst misconception here is that a NAT is for providing you=20 > > > security against the bad Internet > > > > > > Private adress spaces have been introduced to save a scarce > ressource > > > (or what some believed are a scarce ressource at some point of time) > > > > > > You can live very safe behind a properly configured firewall using > > > only public IP adresses. > > > > > > The basic idea of IPv6 was to give every device on earth and also=20 > > > within the solar system a unique public IP address > > > > > > But the fake security of NATs was already in the minds of most=20 > > > people, that the first things that were implemented in IPv6 where=20 > > > NATs for IPv6, which is a perversion > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Gesendet: Di 04.04.2006 18:22 > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';=20 > > > speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Richard, > > > And here we get to the fun stuff. :) > > > > > > The idea of every serving proxy/registrar/sip-node needing to be=20 > > > publicly addressable is neither an Internet requirement, nor a=20 > > > requirement of the IETF. Entire working groups in the IETF concern > > > themselves with allowing, enabling, and inter-working private=20 > > > address spaces and VPNs. > > > What's missing > > > is how to join them at the application and transport layer, when > that > > > application layer embeds addressing in itself. > > > > > > Most consumers on the planet Earth are in private address spaces at > > > this point I think (i.e., 192.168.x.x), and many Enterprises are as > > > well. Entire networks in some countries are privately addressed,=20 > > > yet they are members of, and use, the Internet. There are also now > > > 2 disjoint address groups defined by the IETF, as you know: IPv4 and >=20 > > > IPv6. There are mechanisms to try to provide=20 > > > interoperation/migration support for them, but that > typically > > > requires intermediaries. > > > > > > So I agree with you there needs to be an entity providing an ingress >=20 > > > (and > > > egress) point(s), either on the public network for it to be public, > > > or for it to cross into another private address domain. For this=20 > > > WG's purpose, I recommend we allow either model to work, as well as > > > the model of the private going to public (and vice-versa) so long as >=20 > > > the peering element of both sides are in the same public or private > > > space. > > > > > > -Hadriel > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > speermint@ietf.org > > > > Subject: Re: [Speermint] Reachability > > > > > > > > >The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > >needs to be publicly addressable. > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > everybody. > > > > This was also why I had a problem with Sohel's presentation > > > at the IETF, > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > > principles we develop here are used between some entities > > > in a private > > > > network, > > > > but it is not out task to consider this separately. Because > > > if it works > > > > on the Internet, it also works in a private network > > > (extranet in this > > > > case) > > > > (see DNS). this private network may even use public IP > > > adresses, but if > > > > the > > > > are not routable from the public Internet, they are could as well > be > > > > private > > > > (example IPX) > > > > > > > > What never can work is a peering between one entity on the > > > public network > > > > and one on a private network. The private entities need at > > > least to have > > > > one > > > > ingress element on the public network > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Gesendet: Di 04.04.2006 15:29 > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > But I want to ensure everybody understands what your really > > > saying here. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > This means that for carrier to carrier peering models, each > > > and every > > > > customer of every carrier that wants to inter-connect needs > > > to have a > > > > 'public NAT binding'. > > > > > > > > I believe by extension, this means that a serving > > > proxy/registrar for the > > > > target of a communication must ALSO have either a public > > > address or a > > > > public > > > > NAT binding. > > > > > > > > The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > needs to be publicly addressable. > > > > > > > > Am I correct? > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hello Hadriel, > > > > > > > > Comment inline.... > > > > > > > > > -----Original Message----- > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hi Reinaldo, > > > > > Comments inline... > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > > interested > > > > > > only in call routing (E.164 is out of scope), do we > > > really need to > > > > care > > > > > > about that? An AoR in the end will be translated to an > > > IP address, > > > > and > > > > > > IP addresses have a very good definition of public and > > > private (in > > > > IPv4 > > > > > > and IPv6). > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > "translated" > > > > > to an IP Address (and really to a contact URI) by the > > > AoR's domain. > > > > So > > > > > what > > > > > you're saying is if the AoR's user-part represents a > > > consumer behind a > > > > > home > > > > > NAT (a private IP), then it is a private AoR; but for > > > those consumers > > > > who > > > > > don't use home-NATs then it's a public AoR? > > > > [[Reinaldo]] > > > > > > > > Hello, > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > discussion, > > > > that's why I gave that example. I was trying to understand why it > > > > matters, before getting knee deep into the classification. > > > Can someone > > > > refresh that for me? > > > > > > > > So, if SIP peering is going to get woven into the fabric of the=20 > > > > internet, the rules for domains names, DNS resolution, private vs. > > > > public IP address, etc should apply, right? > > > > > > > > I believe the current model of host to host or email > > > communication is > > > > not different for SIP. We could have the following main=20 > > > > situations...(correct me where I'm wrong). > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > in the end > > > > will get resolved into an IP address. Then there are only two=20 > > > > situations. > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > This means the SIP endpoint is unreachable unless you > > > are also in the > > > > same private network. Actually I believe a private IP address > cannot > > > > even be provisioned in a public DNS. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > be reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > b) the IP address is public. > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > Internet we have > > > > today, this means the domain name/user is private, does not > > > exist, etc > > > > > > > > All this has been happening okay with just a few basic > > > rules. If an AoR > > > > is very similar to an email address, why it would not work with > the > > > > current infrastructure/definitions? > > > > > > > > If somebody says that they have a "private" email address or > domain > > > > name, what is your interpretation of that? > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > translated > > > > > into an IP by a registrar inside a private IP subnet, and > > > somehow it > > > > later > > > > > gets translated into the public IP address space, that's > > > also private > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > reachable first, > > > > let's > > > > > > not forget about that. And if you are IP reachable, you could > > > > > > potentially be SIP reachable by registering to some > > > free SIP service > > > > (or > > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > > email/DNS > > > > > > model). > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > can be "sip > > > > > reachable" but not IP reachable. But I think for now we > > > should ignore > > > > the > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > 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 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 16:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREBO-000357-Ol; Wed, 05 Apr 2006 16:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREBN-00034x-JP for speermint@ietf.org; Wed, 05 Apr 2006 16:00:49 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREBM-0001uE-TC for speermint@ietf.org; Wed, 05 Apr 2006 16:00:49 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 05 Apr 2006 13:00:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="541242086:sNHT27956968" 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] NATs and Firewalls Date: Wed, 5 Apr 2006 16:00:46 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F0@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuTHNKW6KBXrBRA6nGJMEHAtj9gAK02KQ From: "Reinaldo Penno" To: "Peter Macaulay" , "Drage, Keith \(Keith\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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 Oh...The "S" word. I thought that was banned or something... Well, Columbia people performed a recent study on Skype. It uses a version of STUN to bypass firewall without the "other" user knowing it is a STUN server. There are other things it does that one would frown upon.=20 On the other hand during the VON conference is San Jose I had the pleasure to participate in the big Pow Wow about P2P SIP. Most of the debate was centered on Skype. The impression I had when I left the room was that skype's success has nothing to do with it being P2P, but its ease of use and ability to overcome NAT/Firewalls. So, making sure our peer arch works well when endpoints in different domains are behind NATs, seems pretty important. Of all the NAT traversal methods, media relay (a typical SBC function) is one of the most foolproof. The call flow and the translation it needs to do are complex but it can overcome legacy NATs without any client modification (maybe symmetric RTP). Of course a SIP traversal method in the client itself bundled with the application software (or OS) would be simpler and have a higher adoption (as in skype). I guess the problem today is that there is no single solution. What you have is a set of methods. I guess others are better suited to talk about this topic in detail. Regards, Reinaldo > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > Sent: Wednesday, April 05, 2006 6:59 AM > To: Drage, Keith (Keith); speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > Agree. Let's avoid the term "SBC" in the speermint area. We don't > need the history lesson and the term is still evolving. I just finished > a Skype call and did not use a SBC to peer with my one in 6 million users. >=20 > Yes, let's just define the requirements ... Edge Proxy, NAPT, Media Proxy, > Security Firewall and NAT/firewall traversal. >=20 > /PETER MACAULAY >=20 > At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >And to support Richard on this. > > > >Please avoid using the term "SBC" in the speermint area. Please > >clearly identify the function of these supposed wonder boxes that > >you are addressing as an area of concern or advantage. Therefore if > >you mean NAT, say NAT, if you mean firewall, say firewall, if you > >mean something else, say so. These boxes contain so many features > >(in the widest sense of the word) that in the absence of specific > >information we get lost. > > > >regards > > > >Keith > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: 04 April 2006 18:15 > > > To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > > > speermint@ietf.org > > > Subject: [Speermint] NATs and Firewalls > > > > > > > > > I think some people out there either do not understand > > > the difference between NATs and firewalls or are starting > > > to believe their own propaganda > > > > > > NATs are NATs and firewalls are firewalls > > > > > > The worst misconception here is that a NAT is for providing > > > you security > > > against the bad Internet > > > > > > Private adress spaces have been introduced to save a scarce ressource > > > (or what some believed are a scarce ressource at some point of time) > > > > > > You can live very safe behind a properly configured firewall > > > using only > > > public IP adresses. > > > > > > The basic idea of IPv6 was to give every device on earth and also > > > within the solar system a unique public IP address > > > > > > But the fake security of NATs was already in the minds of > > > most people, that the first things that were implemented > > > in IPv6 where NATs for IPv6, which is a perversion > > > > > > Geoff Huston had once a nice eleborate on this in an IETF paper > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Gesendet: Di 04.04.2006 18:22 > > > An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > > > speermint@ietf.org > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > Hi Richard, > > > And here we get to the fun stuff. :) > > > > > > The idea of every serving proxy/registrar/sip-node needing to > > > be publicly > > > addressable is neither an Internet requirement, nor a > > > requirement of the > > > IETF. Entire working groups in the IETF concern themselves > > > with allowing, > > > enabling, and inter-working private address spaces and VPNs. > > > What's missing > > > is how to join them at the application and transport layer, when that > > > application layer embeds addressing in itself. > > > > > > Most consumers on the planet Earth are in private address > > > spaces at this > > > point I think (i.e., 192.168.x.x), and many Enterprises are > > > as well. Entire > > > networks in some countries are privately addressed, yet they > > > are members of, > > > and use, the Internet. There are also now 2 disjoint address > > > groups defined > > > by the IETF, as you know: IPv4 and IPv6. There are > > > mechanisms to try to > > > provide interoperation/migration support for them, but that typically > > > requires intermediaries. > > > > > > So I agree with you there needs to be an entity providing an > > > ingress (and > > > egress) point(s), either on the public network for it to be > > > public, or for > > > it to cross into another private address domain. For this > > > WG's purpose, I > > > recommend we allow either model to work, as well as the model > > > of the private > > > going to public (and vice-versa) so long as the peering > > > element of both > > > sides are in the same public or private space. > > > > > > -Hadriel > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Tuesday, April 04, 2006 9:55 AM > > > > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > > > speermint@ietf.org > > > > Subject: Re: [Speermint] Reachability > > > > > > > > >The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > >needs to be publicly addressable. > > > > > > > > This was my basic assumption, and I seemed not so clear to > > > everybody. > > > > This was also why I had a problem with Sohel's presentation > > > at the IETF, > > > > because I did not see any public adressable entities AT ALL. > > > > > > > > For the avoidance of doubt: I have no problem if the same peering > > > > principles we develop here are used between some entities > > > in a private > > > > network, > > > > but it is not out task to consider this separately. Because > > > if it works > > > > on the Internet, it also works in a private network > > > (extranet in this > > > > case) > > > > (see DNS). this private network may even use public IP > > > adresses, but if > > > > the > > > > are not routable from the public Internet, they are could as well be > > > > private > > > > (example IPX) > > > > > > > > What never can work is a peering between one entity on the > > > public network > > > > and one on a private network. The private entities need at > > > least to have > > > > one > > > > ingress element on the public network > > > > > > > > Richard > > > > > > > > ________________________________ > > > > > > > > Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Gesendet: Di 04.04.2006 15:29 > > > > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Reachability > > > > > > > > > > > > > > > > Reinaldo -- I agree with your assertions. > > > > > > > > But I want to ensure everybody understands what your really > > > saying here. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to be > > > reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > This means that for carrier to carrier peering models, each > > > and every > > > > customer of every carrier that wants to inter-connect needs > > > to have a > > > > 'public NAT binding'. > > > > > > > > I believe by extension, this means that a serving > > > proxy/registrar for the > > > > target of a communication must ALSO have either a public > > > address or a > > > > public > > > > NAT binding. > > > > > > > > The conclusion here -- every endpoint and every serving > > > proxy/registrar > > > > needs to be publicly addressable. > > > > > > > > Am I correct? > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Tuesday, April 04, 2006 5:29 AM > > > > To: Hadriel Kaplan; speermint@ietf.org > > > > Subject: RE: [Speermint] Reachability > > > > > > > > Hello Hadriel, > > > > > > > > Comment inline.... > > > > > > > > > -----Original Message----- > > > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > > > Sent: Monday, April 03, 2006 11:01 PM > > > > > To: Reinaldo Penno; speermint@ietf.org > > > > > Subject: RE: [Speermint] Reachability > > > > > > > > > > Hi Reinaldo, > > > > > Comments inline... > > > > > > > > > > > -----Original Message----- > > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > > > > > > > > Maybe I'm missing something, but given that this workgroup is > > > > interested > > > > > > only in call routing (E.164 is out of scope), do we > > > really need to > > > > care > > > > > > about that? An AoR in the end will be translated to an > > > IP address, > > > > and > > > > > > IP addresses have a very good definition of public and > > > private (in > > > > IPv4 > > > > > > and IPv6). > > > > > > > > > > I don't understand fully what you mean. An AoR is only fully > > > > "translated" > > > > > to an IP Address (and really to a contact URI) by the > > > AoR's domain. > > > > So > > > > > what > > > > > you're saying is if the AoR's user-part represents a > > > consumer behind a > > > > > home > > > > > NAT (a private IP), then it is a private AoR; but for > > > those consumers > > > > who > > > > > don't use home-NATs then it's a public AoR? > > > > [[Reinaldo]] > > > > > > > > Hello, > > > > > > > > Actually I'm trying to understand the whole purpose of the > > > discussion, > > > > that's why I gave that example. I was trying to understand why it > > > > matters, before getting knee deep into the classification. > > > Can someone > > > > refresh that for me? > > > > > > > > So, if SIP peering is going to get woven into the fabric of the > > > > internet, the rules for domains names, DNS resolution, private vs. > > > > public IP address, etc should apply, right? > > > > > > > > I believe the current model of host to host or email > > > communication is > > > > not different for SIP. We could have the following main > > > > situations...(correct me where I'm wrong). > > > > > > > > 1) The AoR (just like a traditional domain name or email), > > > in the end > > > > will get resolved into an IP address. Then there are only two > > > > situations. > > > > > > > > a) the IP address is private (RFC 1918). > > > > > > > > This means the SIP endpoint is unreachable unless you > > > are also in the > > > > same private network. Actually I believe a private IP address cannot > > > > even be provisioned in a public DNS. > > > > > > > > Before somebody mentions it...for a UA behind a NAT to > > > be reachable, > > > > he/she needs a public NAT binding so that a session > > > _initiated_ from the > > > > public side can be made to him/her. > > > > > > > > b) the IP address is public. > > > > > > > > The SIP endpoint is theoretically reachable. > > > > > > > > 2) The AoR cannot get translated. Again, just like the > > > Internet we have > > > > today, this means the domain name/user is private, does not > > > exist, etc > > > > > > > > All this has been happening okay with just a few basic > > > rules. If an AoR > > > > is very similar to an email address, why it would not work with the > > > > current infrastructure/definitions? > > > > > > > > If somebody says that they have a "private" email address or domain > > > > name, what is your interpretation of that? > > > > > > > > Regards, > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > > > > > > > > > > > > And if the AoR gets > > > > > translated > > > > > into an IP by a registrar inside a private IP subnet, and > > > somehow it > > > > later > > > > > gets translated into the public IP address space, that's > > > also private > > > > > because the AoR was translated to a private IP originally? > > > > > > > > > > Or maybe you mean what the domain part of the AoR resolves to? > > > > > > > > > > > For you to be "SIP reachable", you need to be IP > > > reachable first, > > > > let's > > > > > > not forget about that. And if you are IP reachable, you could > > > > > > potentially be SIP reachable by registering to some > > > free SIP service > > > > (or > > > > > > the SIP "domain" above you in the hierarchy...if this was the > > > > email/DNS > > > > > > model). > > > > > > > > > > Actually, to be very specific ultimate target of the AoR > > > can be "sip > > > > > reachable" but not IP reachable. But I think for now we > > > should ignore > > > > the > > > > > implications of that, unless it becomes a problem. > > > > > > > > > > -hadriel > > > > > > > > _______________________________________________ > > > > 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 >=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 Apr 05 16:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREcp-0003BH-IG; Wed, 05 Apr 2006 16:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREco-0003B2-4k for speermint@ietf.org; Wed, 05 Apr 2006 16:29:10 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREcm-0003Hu-Ja for speermint@ietf.org; Wed, 05 Apr 2006 16:29:10 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4316278; Wed, 05 Apr 2006 16:28:47 -0400 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F0@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F0@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96DBE81B-1AFE-441C-9123-0332381FE2FD@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 16:29:24 -0400 To: "Reinaldo Penno" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: Peter Macaulay , 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 Apr 5, 2006, at 4:00 PM, Reinaldo Penno wrote: > Oh...The "S" word. I thought that was banned or something... > > Well, Columbia people performed a recent study on Skype. It uses a > version of STUN to bypass firewall without the "other" user knowing it > is a STUN server. There are other things it does that one would frown > upon. Can you give a reference ? I am aware of http://saikat.guha.cc/pub/iptps06-skype.pdf and http://www.brynosaurus.com/pub/net/p2pnat.pdf but no paper from Columbia. Regards Marshall > > On the other hand during the VON conference is San Jose I had the > pleasure to participate in the big Pow Wow about P2P SIP. Most of the > debate was centered on Skype. The impression I had when I left the > room > was that skype's success has nothing to do with it being P2P, but its > ease of use and ability to overcome NAT/Firewalls. So, making sure our > peer arch works well when endpoints in different domains are behind > NATs, seems pretty important. > > Of all the NAT traversal methods, media relay (a typical SBC function) > is one of the most foolproof. The call flow and the translation it > needs > to do are complex but it can overcome legacy NATs without any client > modification (maybe symmetric RTP). > > Of course a SIP traversal method in the client itself bundled with the > application software (or OS) would be simpler and have a higher > adoption > (as in skype). I guess the problem today is that there is no single > solution. What you have is a set of methods. I guess others are better > suited to talk about this topic in detail. > > Regards, > > Reinaldo > >> -----Original Message----- >> From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] >> Sent: Wednesday, April 05, 2006 6:59 AM >> To: Drage, Keith (Keith); speermint@ietf.org >> Subject: RE: [Speermint] NATs and Firewalls >> >> Agree. Let's avoid the term "SBC" in the speermint area. We don't >> need the history lesson and the term is still evolving. I just > finished >> a Skype call and did not use a SBC to peer with my one in 6 million > users. >> >> Yes, let's just define the requirements ... Edge Proxy, NAPT, Media > Proxy, >> Security Firewall and NAT/firewall traversal. >> >> /PETER MACAULAY >> >> At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >>> And to support Richard on this. >>> >>> Please avoid using the term "SBC" in the speermint area. Please >>> clearly identify the function of these supposed wonder boxes that >>> you are addressing as an area of concern or advantage. Therefore if >>> you mean NAT, say NAT, if you mean firewall, say firewall, if you >>> mean something else, say so. These boxes contain so many features >>> (in the widest sense of the word) that in the absence of specific >>> information we get lost. >>> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>> Sent: 04 April 2006 18:15 >>>> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; >>>> speermint@ietf.org >>>> Subject: [Speermint] NATs and Firewalls >>>> >>>> >>>> I think some people out there either do not understand >>>> the difference between NATs and firewalls or are starting >>>> to believe their own propaganda >>>> >>>> NATs are NATs and firewalls are firewalls >>>> >>>> The worst misconception here is that a NAT is for providing >>>> you security >>>> against the bad Internet >>>> >>>> Private adress spaces have been introduced to save a scarce > ressource >>>> (or what some believed are a scarce ressource at some point of > time) >>>> >>>> You can live very safe behind a properly configured firewall >>>> using only >>>> public IP adresses. >>>> >>>> The basic idea of IPv6 was to give every device on earth and also >>>> within the solar system a unique public IP address >>>> >>>> But the fake security of NATs was already in the minds of >>>> most people, that the first things that were implemented >>>> in IPv6 where NATs for IPv6, which is a perversion >>>> >>>> Geoff Huston had once a nice eleborate on this in an IETF paper >>>> >>>> Richard >>>> >>>> ________________________________ >>>> >>>> Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Gesendet: Di 04.04.2006 18:22 >>>> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; >>>> speermint@ietf.org >>>> Betreff: RE: [Speermint] Reachability >>>> >>>> >>>> >>>> Hi Richard, >>>> And here we get to the fun stuff. :) >>>> >>>> The idea of every serving proxy/registrar/sip-node needing to >>>> be publicly >>>> addressable is neither an Internet requirement, nor a >>>> requirement of the >>>> IETF. Entire working groups in the IETF concern themselves >>>> with allowing, >>>> enabling, and inter-working private address spaces and VPNs. >>>> What's missing >>>> is how to join them at the application and transport layer, when > that >>>> application layer embeds addressing in itself. >>>> >>>> Most consumers on the planet Earth are in private address >>>> spaces at this >>>> point I think (i.e., 192.168.x.x), and many Enterprises are >>>> as well. Entire >>>> networks in some countries are privately addressed, yet they >>>> are members of, >>>> and use, the Internet. There are also now 2 disjoint address >>>> groups defined >>>> by the IETF, as you know: IPv4 and IPv6. There are >>>> mechanisms to try to >>>> provide interoperation/migration support for them, but that > typically >>>> requires intermediaries. >>>> >>>> So I agree with you there needs to be an entity providing an >>>> ingress (and >>>> egress) point(s), either on the public network for it to be >>>> public, or for >>>> it to cross into another private address domain. For this >>>> WG's purpose, I >>>> recommend we allow either model to work, as well as the model >>>> of the private >>>> going to public (and vice-versa) so long as the peering >>>> element of both >>>> sides are in the same public or private space. >>>> >>>> -Hadriel >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>> Sent: Tuesday, April 04, 2006 9:55 AM >>>>> To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; >>>> speermint@ietf.org >>>>> Subject: Re: [Speermint] Reachability >>>>> >>>>>> The conclusion here -- every endpoint and every serving >>>> proxy/registrar >>>>>> needs to be publicly addressable. >>>>> >>>>> This was my basic assumption, and I seemed not so clear to >>>> everybody. >>>>> This was also why I had a problem with Sohel's presentation >>>> at the IETF, >>>>> because I did not see any public adressable entities AT ALL. >>>>> >>>>> For the avoidance of doubt: I have no problem if the same > peering >>>>> principles we develop here are used between some entities >>>> in a private >>>>> network, >>>>> but it is not out task to consider this separately. Because >>>> if it works >>>>> on the Internet, it also works in a private network >>>> (extranet in this >>>>> case) >>>>> (see DNS). this private network may even use public IP >>>> adresses, but if >>>>> the >>>>> are not routable from the public Internet, they are could as > well be >>>>> private >>>>> (example IPX) >>>>> >>>>> What never can work is a peering between one entity on the >>>> public network >>>>> and one on a private network. The private entities need at >>>> least to have >>>>> one >>>>> ingress element on the public network >>>>> >>>>> Richard >>>>> >>>>> ________________________________ >>>>> >>>>> Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>>>> Gesendet: Di 04.04.2006 15:29 >>>>> An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org >>>>> Betreff: RE: [Speermint] Reachability >>>>> >>>>> >>>>> >>>>> Reinaldo -- I agree with your assertions. >>>>> >>>>> But I want to ensure everybody understands what your really >>>> saying here. >>>>> >>>>> Before somebody mentions it...for a UA behind a NAT to be >>>> reachable, >>>>> he/she needs a public NAT binding so that a session >>>> _initiated_ from the >>>>> public side can be made to him/her. >>>>> >>>>> This means that for carrier to carrier peering models, each >>>> and every >>>>> customer of every carrier that wants to inter-connect needs >>>> to have a >>>>> 'public NAT binding'. >>>>> >>>>> I believe by extension, this means that a serving >>>> proxy/registrar for the >>>>> target of a communication must ALSO have either a public >>>> address or a >>>>> public >>>>> NAT binding. >>>>> >>>>> The conclusion here -- every endpoint and every serving >>>> proxy/registrar >>>>> needs to be publicly addressable. >>>>> >>>>> Am I correct? >>>>> -----Original Message----- >>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>> Sent: Tuesday, April 04, 2006 5:29 AM >>>>> To: Hadriel Kaplan; speermint@ietf.org >>>>> Subject: RE: [Speermint] Reachability >>>>> >>>>> Hello Hadriel, >>>>> >>>>> Comment inline.... >>>>> >>>>>> -----Original Message----- >>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>> Sent: Monday, April 03, 2006 11:01 PM >>>>>> To: Reinaldo Penno; speermint@ietf.org >>>>>> Subject: RE: [Speermint] Reachability >>>>>> >>>>>> Hi Reinaldo, >>>>>> Comments inline... >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>> >>>>>>> Maybe I'm missing something, but given that this workgroup > is >>>>> interested >>>>>>> only in call routing (E.164 is out of scope), do we >>>> really need to >>>>> care >>>>>>> about that? An AoR in the end will be translated to an >>>> IP address, >>>>> and >>>>>>> IP addresses have a very good definition of public and >>>> private (in >>>>> IPv4 >>>>>>> and IPv6). >>>>>> >>>>>> I don't understand fully what you mean. An AoR is only fully >>>>> "translated" >>>>>> to an IP Address (and really to a contact URI) by the >>>> AoR's domain. >>>>> So >>>>>> what >>>>>> you're saying is if the AoR's user-part represents a >>>> consumer behind a >>>>>> home >>>>>> NAT (a private IP), then it is a private AoR; but for >>>> those consumers >>>>> who >>>>>> don't use home-NATs then it's a public AoR? >>>>> [[Reinaldo]] >>>>> >>>>> Hello, >>>>> >>>>> Actually I'm trying to understand the whole purpose of the >>>> discussion, >>>>> that's why I gave that example. I was trying to understand why > it >>>>> matters, before getting knee deep into the classification. >>>> Can someone >>>>> refresh that for me? >>>>> >>>>> So, if SIP peering is going to get woven into the fabric of the >>>>> internet, the rules for domains names, DNS resolution, private > vs. >>>>> public IP address, etc should apply, right? >>>>> >>>>> I believe the current model of host to host or email >>>> communication is >>>>> not different for SIP. We could have the following main >>>>> situations...(correct me where I'm wrong). >>>>> >>>>> 1) The AoR (just like a traditional domain name or email), >>>> in the end >>>>> will get resolved into an IP address. Then there are only two >>>>> situations. >>>>> >>>>> a) the IP address is private (RFC 1918). >>>>> >>>>> This means the SIP endpoint is unreachable unless you >>>> are also in the >>>>> same private network. Actually I believe a private IP address > cannot >>>>> even be provisioned in a public DNS. >>>>> >>>>> Before somebody mentions it...for a UA behind a NAT to >>>> be reachable, >>>>> he/she needs a public NAT binding so that a session >>>> _initiated_ from the >>>>> public side can be made to him/her. >>>>> >>>>> b) the IP address is public. >>>>> >>>>> The SIP endpoint is theoretically reachable. >>>>> >>>>> 2) The AoR cannot get translated. Again, just like the >>>> Internet we have >>>>> today, this means the domain name/user is private, does not >>>> exist, etc >>>>> >>>>> All this has been happening okay with just a few basic >>>> rules. If an AoR >>>>> is very similar to an email address, why it would not work with > the >>>>> current infrastructure/definitions? >>>>> >>>>> If somebody says that they have a "private" email address or > domain >>>>> name, what is your interpretation of that? >>>>> >>>>> Regards, >>>>> >>>>> Reinaldo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> And if the AoR gets >>>>>> translated >>>>>> into an IP by a registrar inside a private IP subnet, and >>>> somehow it >>>>> later >>>>>> gets translated into the public IP address space, that's >>>> also private >>>>>> because the AoR was translated to a private IP originally? >>>>>> >>>>>> Or maybe you mean what the domain part of the AoR resolves to? >>>>>> >>>>>>> For you to be "SIP reachable", you need to be IP >>>> reachable first, >>>>> let's >>>>>>> not forget about that. And if you are IP reachable, you > could >>>>>>> potentially be SIP reachable by registering to some >>>> free SIP service >>>>> (or >>>>>>> the SIP "domain" above you in the hierarchy...if this was > the >>>>> email/DNS >>>>>>> model). >>>>>> >>>>>> Actually, to be very specific ultimate target of the AoR >>>> can be "sip >>>>>> reachable" but not IP reachable. But I think for now we >>>> should ignore >>>>> the >>>>>> implications of that, unless it becomes a problem. >>>>>> >>>>>> -hadriel >>>>> >>>>> _______________________________________________ >>>>> Speermint mailing list >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>> >>>>> >>>>> _______________________________________________ >>>>> Speermint mailing list >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> >>> >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ > Speermint 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 Apr 05 16:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREh6-0005hA-HS; Wed, 05 Apr 2006 16:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREh5-0005h5-Gu for speermint@ietf.org; Wed, 05 Apr 2006 16:33:35 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREh4-0003dV-LS for speermint@ietf.org; Wed, 05 Apr 2006 16:33:35 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 05 Apr 2006 13:33:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,90,1144047600"; d="scan'208"; a="541248044:sNHT29313676" 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] NATs and Firewalls Date: Wed, 5 Apr 2006 16:33:31 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F1@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZY76KNZWV3urZ5RJWs8nNOMaX6oQAAGSkw From: "Reinaldo Penno" To: "Marshall Eubanks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: Peter Macaulay , 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 An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol Salman A. Baset and Henning Schulzrinne Department of Computer Science Columbia University, New York NY 10027 {salman,hgs}@cs.columbia.edu September 15, 2004 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Wednesday, April 05, 2006 1:29 PM > To: Reinaldo Penno > Cc: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > Subject: Re: [Speermint] NATs and Firewalls >=20 >=20 > On Apr 5, 2006, at 4:00 PM, Reinaldo Penno wrote: >=20 > > Oh...The "S" word. I thought that was banned or something... > > > > Well, Columbia people performed a recent study on Skype. It uses a > > version of STUN to bypass firewall without the "other" user knowing it > > is a STUN server. There are other things it does that one would frown > > upon. >=20 > Can you give a reference ? I am aware of >=20 > http://saikat.guha.cc/pub/iptps06-skype.pdf and > http://www.brynosaurus.com/pub/net/p2pnat.pdf >=20 > but no paper from Columbia. >=20 > Regards > Marshall >=20 > > > > On the other hand during the VON conference is San Jose I had the > > pleasure to participate in the big Pow Wow about P2P SIP. Most of the > > debate was centered on Skype. The impression I had when I left the > > room > > was that skype's success has nothing to do with it being P2P, but its > > ease of use and ability to overcome NAT/Firewalls. So, making sure our > > peer arch works well when endpoints in different domains are behind > > NATs, seems pretty important. > > > > Of all the NAT traversal methods, media relay (a typical SBC function) > > is one of the most foolproof. The call flow and the translation it > > needs > > to do are complex but it can overcome legacy NATs without any client > > modification (maybe symmetric RTP). > > > > Of course a SIP traversal method in the client itself bundled with the > > application software (or OS) would be simpler and have a higher > > adoption > > (as in skype). I guess the problem today is that there is no single > > solution. What you have is a set of methods. I guess others are better > > suited to talk about this topic in detail. > > > > Regards, > > > > Reinaldo > > > >> -----Original Message----- > >> From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > >> Sent: Wednesday, April 05, 2006 6:59 AM > >> To: Drage, Keith (Keith); speermint@ietf.org > >> Subject: RE: [Speermint] NATs and Firewalls > >> > >> Agree. Let's avoid the term "SBC" in the speermint area. We don't > >> need the history lesson and the term is still evolving. I just > > finished > >> a Skype call and did not use a SBC to peer with my one in 6 million > > users. > >> > >> Yes, let's just define the requirements ... Edge Proxy, NAPT, Media > > Proxy, > >> Security Firewall and NAT/firewall traversal. > >> > >> /PETER MACAULAY > >> > >> At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: > >>> And to support Richard on this. > >>> > >>> Please avoid using the term "SBC" in the speermint area. Please > >>> clearly identify the function of these supposed wonder boxes that > >>> you are addressing as an area of concern or advantage. Therefore if > >>> you mean NAT, say NAT, if you mean firewall, say firewall, if you > >>> mean something else, say so. These boxes contain so many features > >>> (in the widest sense of the word) that in the absence of specific > >>> information we get lost. > >>> > >>> regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >>>> Sent: 04 April 2006 18:15 > >>>> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; > >>>> speermint@ietf.org > >>>> Subject: [Speermint] NATs and Firewalls > >>>> > >>>> > >>>> I think some people out there either do not understand > >>>> the difference between NATs and firewalls or are starting > >>>> to believe their own propaganda > >>>> > >>>> NATs are NATs and firewalls are firewalls > >>>> > >>>> The worst misconception here is that a NAT is for providing > >>>> you security > >>>> against the bad Internet > >>>> > >>>> Private adress spaces have been introduced to save a scarce > > ressource > >>>> (or what some believed are a scarce ressource at some point of > > time) > >>>> > >>>> You can live very safe behind a properly configured firewall > >>>> using only > >>>> public IP adresses. > >>>> > >>>> The basic idea of IPv6 was to give every device on earth and also > >>>> within the solar system a unique public IP address > >>>> > >>>> But the fake security of NATs was already in the minds of > >>>> most people, that the first things that were implemented > >>>> in IPv6 where NATs for IPv6, which is a perversion > >>>> > >>>> Geoff Huston had once a nice eleborate on this in an IETF paper > >>>> > >>>> Richard > >>>> > >>>> ________________________________ > >>>> > >>>> Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >>>> Gesendet: Di 04.04.2006 18:22 > >>>> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; > >>>> speermint@ietf.org > >>>> Betreff: RE: [Speermint] Reachability > >>>> > >>>> > >>>> > >>>> Hi Richard, > >>>> And here we get to the fun stuff. :) > >>>> > >>>> The idea of every serving proxy/registrar/sip-node needing to > >>>> be publicly > >>>> addressable is neither an Internet requirement, nor a > >>>> requirement of the > >>>> IETF. Entire working groups in the IETF concern themselves > >>>> with allowing, > >>>> enabling, and inter-working private address spaces and VPNs. > >>>> What's missing > >>>> is how to join them at the application and transport layer, when > > that > >>>> application layer embeds addressing in itself. > >>>> > >>>> Most consumers on the planet Earth are in private address > >>>> spaces at this > >>>> point I think (i.e., 192.168.x.x), and many Enterprises are > >>>> as well. Entire > >>>> networks in some countries are privately addressed, yet they > >>>> are members of, > >>>> and use, the Internet. There are also now 2 disjoint address > >>>> groups defined > >>>> by the IETF, as you know: IPv4 and IPv6. There are > >>>> mechanisms to try to > >>>> provide interoperation/migration support for them, but that > > typically > >>>> requires intermediaries. > >>>> > >>>> So I agree with you there needs to be an entity providing an > >>>> ingress (and > >>>> egress) point(s), either on the public network for it to be > >>>> public, or for > >>>> it to cross into another private address domain. For this > >>>> WG's purpose, I > >>>> recommend we allow either model to work, as well as the model > >>>> of the private > >>>> going to public (and vice-versa) so long as the peering > >>>> element of both > >>>> sides are in the same public or private space. > >>>> > >>>> -Hadriel > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >>>>> Sent: Tuesday, April 04, 2006 9:55 AM > >>>>> To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; > >>>> speermint@ietf.org > >>>>> Subject: Re: [Speermint] Reachability > >>>>> > >>>>>> The conclusion here -- every endpoint and every serving > >>>> proxy/registrar > >>>>>> needs to be publicly addressable. > >>>>> > >>>>> This was my basic assumption, and I seemed not so clear to > >>>> everybody. > >>>>> This was also why I had a problem with Sohel's presentation > >>>> at the IETF, > >>>>> because I did not see any public adressable entities AT ALL. > >>>>> > >>>>> For the avoidance of doubt: I have no problem if the same > > peering > >>>>> principles we develop here are used between some entities > >>>> in a private > >>>>> network, > >>>>> but it is not out task to consider this separately. Because > >>>> if it works > >>>>> on the Internet, it also works in a private network > >>>> (extranet in this > >>>>> case) > >>>>> (see DNS). this private network may even use public IP > >>>> adresses, but if > >>>>> the > >>>>> are not routable from the public Internet, they are could as > > well be > >>>>> private > >>>>> (example IPX) > >>>>> > >>>>> What never can work is a peering between one entity on the > >>>> public network > >>>>> and one on a private network. The private entities need at > >>>> least to have > >>>>> one > >>>>> ingress element on the public network > >>>>> > >>>>> Richard > >>>>> > >>>>> ________________________________ > >>>>> > >>>>> Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] > >>>>> Gesendet: Di 04.04.2006 15:29 > >>>>> An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org > >>>>> Betreff: RE: [Speermint] Reachability > >>>>> > >>>>> > >>>>> > >>>>> Reinaldo -- I agree with your assertions. > >>>>> > >>>>> But I want to ensure everybody understands what your really > >>>> saying here. > >>>>> > >>>>> Before somebody mentions it...for a UA behind a NAT to be > >>>> reachable, > >>>>> he/she needs a public NAT binding so that a session > >>>> _initiated_ from the > >>>>> public side can be made to him/her. > >>>>> > >>>>> This means that for carrier to carrier peering models, each > >>>> and every > >>>>> customer of every carrier that wants to inter-connect needs > >>>> to have a > >>>>> 'public NAT binding'. > >>>>> > >>>>> I believe by extension, this means that a serving > >>>> proxy/registrar for the > >>>>> target of a communication must ALSO have either a public > >>>> address or a > >>>>> public > >>>>> NAT binding. > >>>>> > >>>>> The conclusion here -- every endpoint and every serving > >>>> proxy/registrar > >>>>> needs to be publicly addressable. > >>>>> > >>>>> Am I correct? > >>>>> -----Original Message----- > >>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>>> Sent: Tuesday, April 04, 2006 5:29 AM > >>>>> To: Hadriel Kaplan; speermint@ietf.org > >>>>> Subject: RE: [Speermint] Reachability > >>>>> > >>>>> Hello Hadriel, > >>>>> > >>>>> Comment inline.... > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >>>>>> Sent: Monday, April 03, 2006 11:01 PM > >>>>>> To: Reinaldo Penno; speermint@ietf.org > >>>>>> Subject: RE: [Speermint] Reachability > >>>>>> > >>>>>> Hi Reinaldo, > >>>>>> Comments inline... > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] > >>>>>>> > >>>>>>> Maybe I'm missing something, but given that this workgroup > > is > >>>>> interested > >>>>>>> only in call routing (E.164 is out of scope), do we > >>>> really need to > >>>>> care > >>>>>>> about that? An AoR in the end will be translated to an > >>>> IP address, > >>>>> and > >>>>>>> IP addresses have a very good definition of public and > >>>> private (in > >>>>> IPv4 > >>>>>>> and IPv6). > >>>>>> > >>>>>> I don't understand fully what you mean. An AoR is only fully > >>>>> "translated" > >>>>>> to an IP Address (and really to a contact URI) by the > >>>> AoR's domain. > >>>>> So > >>>>>> what > >>>>>> you're saying is if the AoR's user-part represents a > >>>> consumer behind a > >>>>>> home > >>>>>> NAT (a private IP), then it is a private AoR; but for > >>>> those consumers > >>>>> who > >>>>>> don't use home-NATs then it's a public AoR? > >>>>> [[Reinaldo]] > >>>>> > >>>>> Hello, > >>>>> > >>>>> Actually I'm trying to understand the whole purpose of the > >>>> discussion, > >>>>> that's why I gave that example. I was trying to understand why > > it > >>>>> matters, before getting knee deep into the classification. > >>>> Can someone > >>>>> refresh that for me? > >>>>> > >>>>> So, if SIP peering is going to get woven into the fabric of the > >>>>> internet, the rules for domains names, DNS resolution, private > > vs. > >>>>> public IP address, etc should apply, right? > >>>>> > >>>>> I believe the current model of host to host or email > >>>> communication is > >>>>> not different for SIP. We could have the following main > >>>>> situations...(correct me where I'm wrong). > >>>>> > >>>>> 1) The AoR (just like a traditional domain name or email), > >>>> in the end > >>>>> will get resolved into an IP address. Then there are only two > >>>>> situations. > >>>>> > >>>>> a) the IP address is private (RFC 1918). > >>>>> > >>>>> This means the SIP endpoint is unreachable unless you > >>>> are also in the > >>>>> same private network. Actually I believe a private IP address > > cannot > >>>>> even be provisioned in a public DNS. > >>>>> > >>>>> Before somebody mentions it...for a UA behind a NAT to > >>>> be reachable, > >>>>> he/she needs a public NAT binding so that a session > >>>> _initiated_ from the > >>>>> public side can be made to him/her. > >>>>> > >>>>> b) the IP address is public. > >>>>> > >>>>> The SIP endpoint is theoretically reachable. > >>>>> > >>>>> 2) The AoR cannot get translated. Again, just like the > >>>> Internet we have > >>>>> today, this means the domain name/user is private, does not > >>>> exist, etc > >>>>> > >>>>> All this has been happening okay with just a few basic > >>>> rules. If an AoR > >>>>> is very similar to an email address, why it would not work with > > the > >>>>> current infrastructure/definitions? > >>>>> > >>>>> If somebody says that they have a "private" email address or > > domain > >>>>> name, what is your interpretation of that? > >>>>> > >>>>> Regards, > >>>>> > >>>>> Reinaldo > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> And if the AoR gets > >>>>>> translated > >>>>>> into an IP by a registrar inside a private IP subnet, and > >>>> somehow it > >>>>> later > >>>>>> gets translated into the public IP address space, that's > >>>> also private > >>>>>> because the AoR was translated to a private IP originally? > >>>>>> > >>>>>> Or maybe you mean what the domain part of the AoR resolves to? > >>>>>> > >>>>>>> For you to be "SIP reachable", you need to be IP > >>>> reachable first, > >>>>> let's > >>>>>>> not forget about that. And if you are IP reachable, you > > could > >>>>>>> potentially be SIP reachable by registering to some > >>>> free SIP service > >>>>> (or > >>>>>>> the SIP "domain" above you in the hierarchy...if this was > > the > >>>>> email/DNS > >>>>>>> model). > >>>>>> > >>>>>> Actually, to be very specific ultimate target of the AoR > >>>> can be "sip > >>>>>> reachable" but not IP reachable. But I think for now we > >>>> should ignore > >>>>> the > >>>>>> implications of that, unless it becomes a problem. > >>>>>> > >>>>>> -hadriel > >>>>> > >>>>> _______________________________________________ > >>>>> Speermint mailing list > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Speermint mailing list > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> > >>> > >>> _______________________________________________ > >>> Speermint mailing list > >>> Speermint@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speermint > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint 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 Apr 05 16:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREtl-0002vr-R1; Wed, 05 Apr 2006 16:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREtk-0002vh-4z for speermint@ietf.org; Wed, 05 Apr 2006 16:46:40 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREti-0003wY-I8 for speermint@ietf.org; Wed, 05 Apr 2006 16:46:40 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4316886; Wed, 05 Apr 2006 16:46:17 -0400 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F1@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F1@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66F1B4DE-03FE-442F-9CF8-D9FECE286C29@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 16:46:52 -0400 To: "Reinaldo Penno" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: Peter Macaulay , 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 - btw, at http://www1.cs.columbia.edu/~library/TR-repository/reports/ reports-2004/cucs-039-04.pdf On Apr 5, 2006, at 4:33 PM, Reinaldo Penno wrote: > An Analysis of the Skype Peer-to-Peer Internet Telephony > Protocol > Salman A. Baset and Henning Schulzrinne > Department of Computer Science > Columbia University, New York NY 10027 > {salman,hgs}@cs.columbia.edu > September 15, 2004 > >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme@multicasttech.com] >> Sent: Wednesday, April 05, 2006 1:29 PM >> To: Reinaldo Penno >> Cc: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org >> Subject: Re: [Speermint] NATs and Firewalls >> >> >> On Apr 5, 2006, at 4:00 PM, Reinaldo Penno wrote: >> >>> Oh...The "S" word. I thought that was banned or something... >>> >>> Well, Columbia people performed a recent study on Skype. It uses a >>> version of STUN to bypass firewall without the "other" user knowing > it >>> is a STUN server. There are other things it does that one would > frown >>> upon. >> >> Can you give a reference ? I am aware of >> >> http://saikat.guha.cc/pub/iptps06-skype.pdf and >> http://www.brynosaurus.com/pub/net/p2pnat.pdf >> >> but no paper from Columbia. >> >> Regards >> Marshall >> >>> >>> On the other hand during the VON conference is San Jose I had the >>> pleasure to participate in the big Pow Wow about P2P SIP. Most of > the >>> debate was centered on Skype. The impression I had when I left the >>> room >>> was that skype's success has nothing to do with it being P2P, but > its >>> ease of use and ability to overcome NAT/Firewalls. So, making sure > our >>> peer arch works well when endpoints in different domains are behind >>> NATs, seems pretty important. >>> >>> Of all the NAT traversal methods, media relay (a typical SBC > function) >>> is one of the most foolproof. The call flow and the translation it >>> needs >>> to do are complex but it can overcome legacy NATs without any client >>> modification (maybe symmetric RTP). >>> >>> Of course a SIP traversal method in the client itself bundled with > the >>> application software (or OS) would be simpler and have a higher >>> adoption >>> (as in skype). I guess the problem today is that there is no single >>> solution. What you have is a set of methods. I guess others are > better >>> suited to talk about this topic in detail. >>> >>> Regards, >>> >>> Reinaldo >>> >>>> -----Original Message----- >>>> From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] >>>> Sent: Wednesday, April 05, 2006 6:59 AM >>>> To: Drage, Keith (Keith); speermint@ietf.org >>>> Subject: RE: [Speermint] NATs and Firewalls >>>> >>>> Agree. Let's avoid the term "SBC" in the speermint area. We don't >>>> need the history lesson and the term is still evolving. I just >>> finished >>>> a Skype call and did not use a SBC to peer with my one in 6 million >>> users. >>>> >>>> Yes, let's just define the requirements ... Edge Proxy, NAPT, Media >>> Proxy, >>>> Security Firewall and NAT/firewall traversal. >>>> >>>> /PETER MACAULAY >>>> >>>> At 05:23 AM 4/5/2006, Drage, Keith (Keith) wrote: >>>>> And to support Richard on this. >>>>> >>>>> Please avoid using the term "SBC" in the speermint area. Please >>>>> clearly identify the function of these supposed wonder boxes that >>>>> you are addressing as an area of concern or advantage. Therefore > if >>>>> you mean NAT, say NAT, if you mean firewall, say firewall, if you >>>>> mean something else, say so. These boxes contain so many features >>>>> (in the widest sense of the word) that in the absence of specific >>>>> information we get lost. >>>>> >>>>> regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>>> Sent: 04 April 2006 18:15 >>>>>> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; >>>>>> speermint@ietf.org >>>>>> Subject: [Speermint] NATs and Firewalls >>>>>> >>>>>> >>>>>> I think some people out there either do not understand >>>>>> the difference between NATs and firewalls or are starting >>>>>> to believe their own propaganda >>>>>> >>>>>> NATs are NATs and firewalls are firewalls >>>>>> >>>>>> The worst misconception here is that a NAT is for providing >>>>>> you security >>>>>> against the bad Internet >>>>>> >>>>>> Private adress spaces have been introduced to save a scarce >>> ressource >>>>>> (or what some believed are a scarce ressource at some point of >>> time) >>>>>> >>>>>> You can live very safe behind a properly configured firewall >>>>>> using only >>>>>> public IP adresses. >>>>>> >>>>>> The basic idea of IPv6 was to give every device on earth and also >>>>>> within the solar system a unique public IP address >>>>>> >>>>>> But the fake security of NATs was already in the minds of >>>>>> most people, that the first things that were implemented >>>>>> in IPv6 where NATs for IPv6, which is a perversion >>>>>> >>>>>> Geoff Huston had once a nice eleborate on this in an IETF paper >>>>>> >>>>>> Richard >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>> Gesendet: Di 04.04.2006 18:22 >>>>>> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno'; >>>>>> speermint@ietf.org >>>>>> Betreff: RE: [Speermint] Reachability >>>>>> >>>>>> >>>>>> >>>>>> Hi Richard, >>>>>> And here we get to the fun stuff. :) >>>>>> >>>>>> The idea of every serving proxy/registrar/sip-node needing to >>>>>> be publicly >>>>>> addressable is neither an Internet requirement, nor a >>>>>> requirement of the >>>>>> IETF. Entire working groups in the IETF concern themselves >>>>>> with allowing, >>>>>> enabling, and inter-working private address spaces and VPNs. >>>>>> What's missing >>>>>> is how to join them at the application and transport layer, when >>> that >>>>>> application layer embeds addressing in itself. >>>>>> >>>>>> Most consumers on the planet Earth are in private address >>>>>> spaces at this >>>>>> point I think (i.e., 192.168.x.x), and many Enterprises are >>>>>> as well. Entire >>>>>> networks in some countries are privately addressed, yet they >>>>>> are members of, >>>>>> and use, the Internet. There are also now 2 disjoint address >>>>>> groups defined >>>>>> by the IETF, as you know: IPv4 and IPv6. There are >>>>>> mechanisms to try to >>>>>> provide interoperation/migration support for them, but that >>> typically >>>>>> requires intermediaries. >>>>>> >>>>>> So I agree with you there needs to be an entity providing an >>>>>> ingress (and >>>>>> egress) point(s), either on the public network for it to be >>>>>> public, or for >>>>>> it to cross into another private address domain. For this >>>>>> WG's purpose, I >>>>>> recommend we allow either model to work, as well as the model >>>>>> of the private >>>>>> going to public (and vice-versa) so long as the peering >>>>>> element of both >>>>>> sides are in the same public or private space. >>>>>> >>>>>> -Hadriel >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>>>> Sent: Tuesday, April 04, 2006 9:55 AM >>>>>>> To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan; >>>>>> speermint@ietf.org >>>>>>> Subject: Re: [Speermint] Reachability >>>>>>> >>>>>>>> The conclusion here -- every endpoint and every serving >>>>>> proxy/registrar >>>>>>>> needs to be publicly addressable. >>>>>>> >>>>>>> This was my basic assumption, and I seemed not so clear to >>>>>> everybody. >>>>>>> This was also why I had a problem with Sohel's presentation >>>>>> at the IETF, >>>>>>> because I did not see any public adressable entities AT ALL. >>>>>>> >>>>>>> For the avoidance of doubt: I have no problem if the same >>> peering >>>>>>> principles we develop here are used between some entities >>>>>> in a private >>>>>>> network, >>>>>>> but it is not out task to consider this separately. Because >>>>>> if it works >>>>>>> on the Internet, it also works in a private network >>>>>> (extranet in this >>>>>>> case) >>>>>>> (see DNS). this private network may even use public IP >>>>>> adresses, but if >>>>>>> the >>>>>>> are not routable from the public Internet, they are could as >>> well be >>>>>>> private >>>>>>> (example IPX) >>>>>>> >>>>>>> What never can work is a peering between one entity on the >>>>>> public network >>>>>>> and one on a private network. The private entities need at >>>>>> least to have >>>>>>> one >>>>>>> ingress element on the public network >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] >>>>>>> Gesendet: Di 04.04.2006 15:29 >>>>>>> An: 'Reinaldo Penno'; 'Hadriel Kaplan'; speermint@ietf.org >>>>>>> Betreff: RE: [Speermint] Reachability >>>>>>> >>>>>>> >>>>>>> >>>>>>> Reinaldo -- I agree with your assertions. >>>>>>> >>>>>>> But I want to ensure everybody understands what your really >>>>>> saying here. >>>>>>> >>>>>>> Before somebody mentions it...for a UA behind a NAT to be >>>>>> reachable, >>>>>>> he/she needs a public NAT binding so that a session >>>>>> _initiated_ from the >>>>>>> public side can be made to him/her. >>>>>>> >>>>>>> This means that for carrier to carrier peering models, each >>>>>> and every >>>>>>> customer of every carrier that wants to inter-connect needs >>>>>> to have a >>>>>>> 'public NAT binding'. >>>>>>> >>>>>>> I believe by extension, this means that a serving >>>>>> proxy/registrar for the >>>>>>> target of a communication must ALSO have either a public >>>>>> address or a >>>>>>> public >>>>>>> NAT binding. >>>>>>> >>>>>>> The conclusion here -- every endpoint and every serving >>>>>> proxy/registrar >>>>>>> needs to be publicly addressable. >>>>>>> >>>>>>> Am I correct? >>>>>>> -----Original Message----- >>>>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>> Sent: Tuesday, April 04, 2006 5:29 AM >>>>>>> To: Hadriel Kaplan; speermint@ietf.org >>>>>>> Subject: RE: [Speermint] Reachability >>>>>>> >>>>>>> Hello Hadriel, >>>>>>> >>>>>>> Comment inline.... >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>>>>> Sent: Monday, April 03, 2006 11:01 PM >>>>>>>> To: Reinaldo Penno; speermint@ietf.org >>>>>>>> Subject: RE: [Speermint] Reachability >>>>>>>> >>>>>>>> Hi Reinaldo, >>>>>>>> Comments inline... >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Reinaldo Penno [mailto:rpenno@juniper.net] >>>>>>>>> >>>>>>>>> Maybe I'm missing something, but given that this workgroup >>> is >>>>>>> interested >>>>>>>>> only in call routing (E.164 is out of scope), do we >>>>>> really need to >>>>>>> care >>>>>>>>> about that? An AoR in the end will be translated to an >>>>>> IP address, >>>>>>> and >>>>>>>>> IP addresses have a very good definition of public and >>>>>> private (in >>>>>>> IPv4 >>>>>>>>> and IPv6). >>>>>>>> >>>>>>>> I don't understand fully what you mean. An AoR is only fully >>>>>>> "translated" >>>>>>>> to an IP Address (and really to a contact URI) by the >>>>>> AoR's domain. >>>>>>> So >>>>>>>> what >>>>>>>> you're saying is if the AoR's user-part represents a >>>>>> consumer behind a >>>>>>>> home >>>>>>>> NAT (a private IP), then it is a private AoR; but for >>>>>> those consumers >>>>>>> who >>>>>>>> don't use home-NATs then it's a public AoR? >>>>>>> [[Reinaldo]] >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Actually I'm trying to understand the whole purpose of the >>>>>> discussion, >>>>>>> that's why I gave that example. I was trying to understand why >>> it >>>>>>> matters, before getting knee deep into the classification. >>>>>> Can someone >>>>>>> refresh that for me? >>>>>>> >>>>>>> So, if SIP peering is going to get woven into the fabric of the >>>>>>> internet, the rules for domains names, DNS resolution, private >>> vs. >>>>>>> public IP address, etc should apply, right? >>>>>>> >>>>>>> I believe the current model of host to host or email >>>>>> communication is >>>>>>> not different for SIP. We could have the following main >>>>>>> situations...(correct me where I'm wrong). >>>>>>> >>>>>>> 1) The AoR (just like a traditional domain name or email), >>>>>> in the end >>>>>>> will get resolved into an IP address. Then there are only two >>>>>>> situations. >>>>>>> >>>>>>> a) the IP address is private (RFC 1918). >>>>>>> >>>>>>> This means the SIP endpoint is unreachable unless you >>>>>> are also in the >>>>>>> same private network. Actually I believe a private IP address >>> cannot >>>>>>> even be provisioned in a public DNS. >>>>>>> >>>>>>> Before somebody mentions it...for a UA behind a NAT to >>>>>> be reachable, >>>>>>> he/she needs a public NAT binding so that a session >>>>>> _initiated_ from the >>>>>>> public side can be made to him/her. >>>>>>> >>>>>>> b) the IP address is public. >>>>>>> >>>>>>> The SIP endpoint is theoretically reachable. >>>>>>> >>>>>>> 2) The AoR cannot get translated. Again, just like the >>>>>> Internet we have >>>>>>> today, this means the domain name/user is private, does not >>>>>> exist, etc >>>>>>> >>>>>>> All this has been happening okay with just a few basic >>>>>> rules. If an AoR >>>>>>> is very similar to an email address, why it would not work with >>> the >>>>>>> current infrastructure/definitions? >>>>>>> >>>>>>> If somebody says that they have a "private" email address or >>> domain >>>>>>> name, what is your interpretation of that? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Reinaldo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> And if the AoR gets >>>>>>>> translated >>>>>>>> into an IP by a registrar inside a private IP subnet, and >>>>>> somehow it >>>>>>> later >>>>>>>> gets translated into the public IP address space, that's >>>>>> also private >>>>>>>> because the AoR was translated to a private IP originally? >>>>>>>> >>>>>>>> Or maybe you mean what the domain part of the AoR resolves to? >>>>>>>> >>>>>>>>> For you to be "SIP reachable", you need to be IP >>>>>> reachable first, >>>>>>> let's >>>>>>>>> not forget about that. And if you are IP reachable, you >>> could >>>>>>>>> potentially be SIP reachable by registering to some >>>>>> free SIP service >>>>>>> (or >>>>>>>>> the SIP "domain" above you in the hierarchy...if this was >>> the >>>>>>> email/DNS >>>>>>>>> model). >>>>>>>> >>>>>>>> Actually, to be very specific ultimate target of the AoR >>>>>> can be "sip >>>>>>>> reachable" but not IP reachable. But I think for now we >>>>>> should ignore >>>>>>> the >>>>>>>> implications of that, unless it becomes a problem. >>>>>>>> >>>>>>>> -hadriel >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Speermint mailing list >>>>>>> Speermint@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Speermint mailing list >>>>>>> Speermint@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Speermint mailing list >>>>>> Speermint@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Speermint mailing list >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint >>> >>> _______________________________________________ >>> Speermint 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 Apr 05 17:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRF7w-0002zj-Ix; Wed, 05 Apr 2006 17:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRF7u-0002ze-KC for speermint@ietf.org; Wed, 05 Apr 2006 17:01:18 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRF7u-0004oK-8p for speermint@ietf.org; Wed, 05 Apr 2006 17:01:18 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k35L1GI5009574; Wed, 5 Apr 2006 14:01:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k35L1CPc009563; Wed, 5 Apr 2006 14:01:12 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 5 Apr 2006 14:01:12 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] Reachability Message-ID: <20060405210112.GA9551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C4964@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4964@oefeg-s04.oefeg.loc> 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: 0ddefe323dd869ab027dbfff7eff0465 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="===============0891954402==" Errors-To: speermint-bounces@ietf.org --===============0891954402== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 04, 2006 at 03:54:51PM +0200, Stastny Richard wrote: > >The conclusion here -- every endpoint and every serving proxy/registrar > >needs to be publicly addressable. >=20 > This was my basic assumption, and I seemed not so clear to everybody. > This was also why I had a problem with Sohel's presentation at the IETF, > because I did not see any public adressable entities AT ALL. > =20 > For the avoidance of doubt: I have no problem if the same peering > principles we develop here are used between some entities in a private ne= twork, > but it is not out task to consider this separately. Because if it works > on the Internet, it also works in a private network (extranet in this cas= e) > (see DNS). this private network may even use public IP adresses, but if t= he > are not routable from the public Internet, they are could as well be priv= ate > (example IPX) Exactly. And it is the IETF after all. > What never can work is a peering between one entity on the public network > and one on a private network. The private entities need at least to have = one > ingress element on the public network Yep. Dave --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFENDAYORgD1qCZ2KcRAhUyAJ4meA+HioPOvtsDsmNx1tQVX5czvACfcq+j L4rJP7VIlGVlfTWiFtUYzAQ= =R/ON -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- --===============0891954402== 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 --===============0891954402==-- From speermint-bounces@ietf.org Wed Apr 05 17:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFAF-0003Dh-WD; Wed, 05 Apr 2006 17:03:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFAE-0003Dc-I7 for speermint@ietf.org; Wed, 05 Apr 2006 17:03:42 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFAE-0004v5-2h for speermint@ietf.org; Wed, 05 Apr 2006 17:03:42 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A0AC027C; Wed, 05 Apr 2006 17:03:40 -0400 From: "Hadriel Kaplan" To: "'Medhavi Bhatia'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 17:03:46 -0400 Message-ID: <073a01c658f4$6dcffe90$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQ In-Reply-To: <8812D8156467224C9E9739E513037EF155A06E@moe.nextone.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 Medhavi, Yes I said interesting "filling the hole" statement, because I thought your company also makes SBCs. :) (I mean that in a good way, BTW) But I don't mean to tread too deeply into marketing or business views. I think what may be the issue is our definition of SBCs may simply not be the same. Maybe you feel all the functions of modern SBCs are all implemented in a single physical box, which is not the case from my view at all. The functions can be broken up, or not. It does not matter from the context of this working group, because the peering partner is a single logical entity and it's the requirements that must be covered, not the implementations meeting those requirements. (as pointed out to me earlier! :) My only point relative to what should be "required", is applicability to as broad a spectrum of providers as possible, where covering the case of L3 VPNs is probably the broadest approach, and within the IETF's domain. Or maybe you feel the definition of "SBC" _requires_ media relaying somewhere? That is not the case for any of the current physical implementations of SBCs that I know of in the service-provider market. It happens to be that many providers enable them to do that, for many reasons way beyond "point" requirements. For example, I consider media-relaying for the purpose of hosted-nat-traversal a "point" requirement. Someday it will fix itself. But that's not why many providers relay media, and certainly not in peering applications; and some providers don't relay media with their SBCs. Regardless, in my view even if the SBC does not relay media it's still an SBC if it performs other functions related to security, inter-working, policies, etc. Some of those functions are described in draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped author. Clearly at some point as you remove those functions it ends up being just a proxy. But since a large group of providers appear to want some or all of those functions (and more) today, at peering points, then a peering BCP for peering providers would be most successful if it "worked" within the constraints of those wants while providing BCPs to enable new services or applications. I think the simplest way to do it is to simply also cover the case of L3 VPNs peering with each other. Do you disagree with that? Any "services" or applications which cannot be met by peering L3 VPNs, may be documented as such in the BCPs, as far as I care. That's not to say things won't change. Whether SBCs continue to perform their role, or all their functions, for ever or not: I don't have a crystal ball. (else I would be in Kauai right now... ;) Cheers, -hadriel As always, these are the views of me personally and not necessarily those of my company, in case anyone forgot. > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Wednesday, April 05, 2006 3:21 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > Hi Hadriel, > > See below. > > > Hi Medhavi, > > I must say that is a very interesting statement for you to make. ;) > > > I presume you are talking about "filling the hole" statement? > > I think there is a vast deal of difference between a requirement and the > implementation. First, most SBCs today look like "point solutions" > (sometimes unattractive but allowed - holes) for "point" requirements. > Second, there is much more awareness and long term vision amongst > service providers now than a few years back. For example, there is a > good deal of understanding of interconnects in general and how security > should be implemented across interconnects in a service agnostic manner > (compare with: block this header, change this etc etc). Solutions are > looking more cleaner, but the existing installed base may ultimately > slow down the opening of networks to new services or other networks. > > > > Of course boxes and behaviors evolve. But from my perspective, > vendors > > don't do things because they want to or a standard tells them to. > They do > > it because their customers want them to. If they don't do what the > > customers want, they get replaced with a box that will. This is the > > fundamental difficulty with mandating how customers should deploy and > use > > equipment, in a use-agnostic/universal standards forum. > > > > They key is to understand what the right questions and requirements are. > If the customer is not asking them, the vendors should. > > More flames welcome ... :) I need a spearmint... > > -Medhavi. > > > One can either look at what is done today for legitimate, > customer-valued > > reasons, or one can look at it as "filling a hole". I prefer the > former. > > People thought home-NATs and firewalls were just filling a hole and > would go > > away. :) > > > > Regardless, I think this can be accomplished in the IETF if we stick > to BCPs > > which are as broadly applicable as possible, while meeting the > requirements. > > I agree with you the requirements come first, and that is what we > should be > > discussing. One of those requirements, IMO, is joining disparate L3 > > domains, which is a different issue than joining administrative > domains (if > > by administrative you mean SIP domains). Do you agree? > > > > Cheers, > > -hadriel > > p.s. that was not meant as a flame whatsoever - simply expressing a > > different viewpoint. > > > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Wednesday, April 05, 2006 11:25 AM > > > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > > > Subject: RE: [Speermint] NATs and Firewalls > > > > > > I'd agree. Lets focus on requirements of peering based on SIP > > > RFCs/drafts, location and address translation mechanisms. The only > > > things which impact any sort of architecture are the administrative > > > domains, P2P domains and federations where subscribers are. > > > > > > As far as the discussion on SBCs, we have had a lengthy one in > SIPPING. > > > It would be fair to say (and I may get flamed for this) that the > reason > > > where we are with SBCs today is primarily because some service > providers > > > were doing "stuff" differently with SIP. SBCs simply capitalized on > open > > > holes in requirements. This will go away with time with more > > > competition, open networks (job of speermint?) and open solutions > from > > > IETF. SBCs will change (or follow the money as some would say...). > > > > > > We need to look forward. SBCs and other infrastructure equipment > vendors > > > (Edge proxies, core proxies etc) will follow these requirements. We > must > > > take care however that we get the right set of SP requirements and > form > > > the right solution. > > > > > > -Medhavi. > > > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: > 4/4/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 17:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFH7-0000Yn-8J; Wed, 05 Apr 2006 17:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFH5-0000Yi-S1 for speermint@ietf.org; Wed, 05 Apr 2006 17:10:47 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFH5-0005C0-Fm for speermint@ietf.org; Wed, 05 Apr 2006 17:10:47 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k35LAj15009683; Wed, 5 Apr 2006 14:10:45 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k35LAfMu009682; Wed, 5 Apr 2006 14:10:41 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 5 Apr 2006 14:10:41 -0700 From: David Meyer To: "Malas, Daryl" Subject: Re: [Speermint] Reachability Message-ID: <20060405211041.GB9551@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: 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: d185fa790257f526fedfd5d01ed9c976 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: , Content-Type: multipart/mixed; boundary="===============0966876899==" Errors-To: speermint-bounces@ietf.org --===============0966876899== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Daryl, On Tue, Apr 04, 2006 at 11:09:19AM -0600, Malas, Daryl wrote: > Okay, I apologize for jumping into the middle of this, but I wanted to > add my two cents.=20 No worries, and please do :-) > I think by now it should be generally understood, if > you want to interconnect with non-RFC1918 address spaces; you need to > utilize a method (any number of options, such as STUN, B2BUA, > etc...etc...)in order to be addressable and routable on the public > registered address space. This being said, I think peering will be > applicable in 3 different environments: >=20 > 1. Public peering (somehow connected and routable by the public > internet) > a. Public addressable space > b. Routed across the public internet > c. Media and signaling accessible from the public internet > 1. May be encrypted for privacy reasons > 2. Authentication mechanisms likely in place Ok. > 2. Private peering (either public addresses (non-routable to the > internet) or RFC1918 address space) > a. Public address space -- not routed via the Internet > b. RFC1918 address space -- non-NAT req'd > c. Little or no security likely implemented > d. Not accessible from the public internet (may be accomplished > by private tunnels l2TP, PPTP, IPSEC, etc.) So Private Peering might be an ambigious term. From your discription it seems you mean "not routed on the public Internet" (even though you might use routable (non-1918) space). Corrent? > 3. Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918 > or non-RFC1918 address space as necessary) > a. Utilizes public or private addresses > b. Intended capabilities such as l2vpn or l3vpn for > interconnection Not sure why b. Can you elaborate? > c. Media and signaling are not accessible from the public > internet But may be, correct? > d. Primarily intended for peering between carriers as opposed > to enterprises (this might include "Federations" depending on > def.). >=20 > Does it make sense to break up the issues/requirements based on these 3 > different environments? Might. Personally I need to think about it a bit more. Dave --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFENDJRORgD1qCZ2KcRAnwqAJ9TnHKuftcf1gEdl0mXfe4UNyOuvQCgkAnd 2Emzx14uSd/a2BmfnDL+xNI= =bk8o -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- --===============0966876899== 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 --===============0966876899==-- From speermint-bounces@ietf.org Wed Apr 05 17:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFMa-0004Cz-Ij; Wed, 05 Apr 2006 17:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFMY-0004Cu-Vw for speermint@ietf.org; Wed, 05 Apr 2006 17:16:26 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFMX-0005Vj-JN for speermint@ietf.org; Wed, 05 Apr 2006 17:16:26 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k35LGOuA009750; Wed, 5 Apr 2006 14:16:24 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k35LGO3U009749; Wed, 5 Apr 2006 14:16:24 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 5 Apr 2006 14:16:24 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] Reachability Message-ID: <20060405211624.GD9551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C496C@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C496C@oefeg-s04.oefeg.loc> 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Malas, Daryl" , 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="===============1511182985==" Errors-To: speermint-bounces@ietf.org --===============1511182985== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F8dlzb82+Fcn6AgP" Content-Disposition: inline --F8dlzb82+Fcn6AgP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 04, 2006 at 09:39:58PM +0200, Stastny Richard wrote: > ENUM is out-of-scope in speermint, it is only providing eventaully inter alia the call routing data Yep. > speermint is using the call routing data and IMHO it is not defined yet > what is used to locate the next hop. Yes, and that is part of our work... > OTOH, since sip and sip standards are to be used, > RFC3263 implies somewhat the DNS Again, yes. Dave --F8dlzb82+Fcn6AgP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFENDOoORgD1qCZ2KcRAtVrAJsEmEHUkdm5pXm+jjtYjknCaRLcMQCgirPd ch6ddQTY8XQeSmBCJD1erqE= =hqmr -----END PGP SIGNATURE----- --F8dlzb82+Fcn6AgP-- --===============1511182985== 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 --===============1511182985==-- From speermint-bounces@ietf.org Wed Apr 05 17:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFRE-0006dj-9j; Wed, 05 Apr 2006 17:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFRD-0006de-0d for speermint@ietf.org; Wed, 05 Apr 2006 17:21:15 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFRC-0005pz-Ke for speermint@ietf.org; Wed, 05 Apr 2006 17:21:14 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k35LLCiC009822; Wed, 5 Apr 2006 14:21:12 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k35LLC6k009821; Wed, 5 Apr 2006 14:21:12 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 5 Apr 2006 14:21:12 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] Reachability Message-ID: <20060405212112.GE9551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C4970@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4970@oefeg-s04.oefeg.loc> 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: speermint@ietf.org, "Malas, Daryl" 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="===============1044239180==" Errors-To: speermint-bounces@ietf.org --===============1044239180== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnaWdueM1EBWVRzC" Content-Disposition: inline --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 04, 2006 at 11:12:57PM +0200, Stastny Richard wrote: > >You can call it "l3 routing" or "packet routing" and "l5" or "sip routin= g" > >or "call routing" if you want > =20 > This could work, at least in documents where there may arise ambiguity > we may use the terms "packet routing" and "session setip routing"(to be m= ore general ;-) > to distinguish > =20 > Dave? Well, I'm rereading the thread. I don't mind "session setup routing" (I think that's what you meant). I suppose this is distingush from "session media routing"? (and hence we can't use just "session routing"). Dave --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFENDTIORgD1qCZ2KcRAnhYAJ4rxA4fsPpYX+b05IoxkaMgTKTgagCeLlee 9d/OUlnQn5k7r9909pQqVoU= =02zP -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC-- --===============1044239180== 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 --===============1044239180==-- From speermint-bounces@ietf.org Wed Apr 05 18:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGtw-0000ET-Hr; Wed, 05 Apr 2006 18:55:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGtv-0000EO-MO for speermint@ietf.org; Wed, 05 Apr 2006 18:54:59 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGtv-0001mF-6u for speermint@ietf.org; Wed, 05 Apr 2006 18:54:59 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id AAC10244; Wed, 05 Apr 2006 18:54:57 -0400 From: "Hadriel Kaplan" To: "'Hadriel Kaplan'" , "'Medhavi Bhatia'" , Subject: RE: [Speermint] NATs and Firewalls Date: Wed, 5 Apr 2006 18:55:02 -0400 Message-ID: <07c801c65903$f9604e10$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQAAal+VA= In-Reply-To: <073a01c658f4$6dcffe90$6501a8c0@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 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 Hmmm... Sorry for going down that rat-hole. Let me re-focus the question to a requirements topic: I think the we should also cover the case of L3 VPN peering with providers in the public Internet. As others have pointed out, this may not need any special attention. Does anyone disagree with that? Any "services" or applications which cannot be met by peering L3 VPNs, may be documented as such in the BCPs, as far as I'm concerned. -hadriel > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Wednesday, April 05, 2006 5:04 PM > To: 'Medhavi Bhatia'; speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > Hi Medhavi, > Yes I said interesting "filling the hole" statement, because > I thought your company also makes SBCs. :) (I mean that in > a good way, BTW) But I don't mean to tread too deeply into > marketing or business views. > > I think what may be the issue is our definition of SBCs may > simply not be the same. Maybe you feel all the functions of > modern SBCs are all implemented in a single physical box, > which is not the case from my view at all. The functions can > be broken up, or not. It does not matter from the context of > this working group, because the peering partner is a single > logical entity and it's the requirements that must be > covered, not the implementations meeting those requirements. > (as pointed out to me earlier! > :) My only point relative to what should be "required", is > applicability to as broad a spectrum of providers as > possible, where covering the case of L3 VPNs is probably the > broadest approach, and within the IETF's domain. > > Or maybe you feel the definition of "SBC" _requires_ media > relaying somewhere? That is not the case for any of the > current physical implementations of SBCs that I know of in > the service-provider market. It happens to be that many > providers enable them to do that, for many reasons way beyond > "point" requirements. For example, I consider media-relaying > for the purpose of hosted-nat-traversal a "point" > requirement. Someday it will fix itself. But that's not why > many providers relay media, and certainly not in peering > applications; and some providers don't relay media with their SBCs. > > Regardless, in my view even if the SBC does not relay media > it's still an SBC if it performs other functions related to > security, inter-working, policies, etc. Some of those > functions are described in > draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you > helped author. > Clearly at some point as you remove those functions it ends > up being just a proxy. But since a large group of providers > appear to want some or all of those functions (and more) > today, at peering points, then a peering BCP for peering > providers would be most successful if it "worked" within the > constraints of those wants while providing BCPs to enable new > services or applications. > > I think the simplest way to do it is to simply also cover the > case of L3 VPNs peering with each other. Do you disagree > with that? Any "services" or applications which cannot be > met by peering L3 VPNs, may be documented as such in the > BCPs, as far as I care. > > That's not to say things won't change. Whether SBCs continue > to perform their role, or all their functions, for ever or > not: I don't have a crystal ball. (else I would be in Kauai > right now... ;) > > Cheers, > -hadriel > > As always, these are the views of me personally and not > necessarily those of my company, in case anyone forgot. > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Wednesday, April 05, 2006 3:21 PM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] NATs and Firewalls > > > > Hi Hadriel, > > > > See below. > > > > > Hi Medhavi, > > > I must say that is a very interesting statement for you > to make. ;) > > > > > I presume you are talking about "filling the hole" statement? > > > > I think there is a vast deal of difference between a > requirement and > > the implementation. First, most SBCs today look like "point > solutions" > > (sometimes unattractive but allowed - holes) for "point" > requirements. > > Second, there is much more awareness and long term vision amongst > > service providers now than a few years back. For example, > there is a > > good deal of understanding of interconnects in general and how > > security should be implemented across interconnects in a service > > agnostic manner (compare with: block this header, change this etc > > etc). Solutions are looking more cleaner, but the existing > installed > > base may ultimately slow down the opening of networks to > new services or other networks. > > > > > > > Of course boxes and behaviors evolve. But from my perspective, > > vendors > > > don't do things because they want to or a standard tells them to. > > They do > > > it because their customers want them to. If they don't > do what the > > > customers want, they get replaced with a box that will. > This is the > > > fundamental difficulty with mandating how customers should deploy > > > and > > use > > > equipment, in a use-agnostic/universal standards forum. > > > > > > > They key is to understand what the right questions and > requirements are. > > If the customer is not asking them, the vendors should. > > > > More flames welcome ... :) I need a spearmint... > > > > -Medhavi. > > > > > One can either look at what is done today for legitimate, > > customer-valued > > > reasons, or one can look at it as "filling a hole". I prefer the > > former. > > > People thought home-NATs and firewalls were just filling > a hole and > > would go > > > away. :) > > > > > > Regardless, I think this can be accomplished in the IETF > if we stick > > to BCPs > > > which are as broadly applicable as possible, while meeting the > > requirements. > > > I agree with you the requirements come first, and that is what we > > should be > > > discussing. One of those requirements, IMO, is joining > disparate L3 > > > domains, which is a different issue than joining administrative > > domains (if > > > by administrative you mean SIP domains). Do you agree? > > > > > > Cheers, > > > -hadriel > > > p.s. that was not meant as a flame whatsoever - simply > expressing a > > > different viewpoint. > > > > > > > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Wednesday, April 05, 2006 11:25 AM > > > > To: Peter Macaulay; Drage, Keith (Keith); speermint@ietf.org > > > > Subject: RE: [Speermint] NATs and Firewalls > > > > > > > > I'd agree. Lets focus on requirements of peering based on SIP > > > > RFCs/drafts, location and address translation > mechanisms. The only > > > > things which impact any sort of architecture are the > > > > administrative domains, P2P domains and federations > where subscribers are. > > > > > > > > As far as the discussion on SBCs, we have had a lengthy one in > > SIPPING. > > > > It would be fair to say (and I may get flamed for this) that the > > reason > > > > where we are with SBCs today is primarily because some service > > providers > > > > were doing "stuff" differently with SIP. SBCs simply > capitalized > > > > on > > open > > > > holes in requirements. This will go away with time with more > > > > competition, open networks (job of speermint?) and open > solutions > > from > > > > IETF. SBCs will change (or follow the money as some > would say...). > > > > > > > > We need to look forward. SBCs and other infrastructure equipment > > vendors > > > > (Edge proxies, core proxies etc) will follow these > requirements. > > > > We > > must > > > > take care however that we get the right set of SP > requirements and > > form > > > > the right solution. > > > > > > > > -Medhavi. > > > > > > > > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: > > 4/4/2006 > > > > > > _______________________________________________ > 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 Apr 05 19:24:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHML-0005AU-FZ; Wed, 05 Apr 2006 19:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHMK-0005AP-Lt for speermint@ietf.org; Wed, 05 Apr 2006 19:24:20 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHMI-0002a3-C7 for speermint@ietf.org; Wed, 05 Apr 2006 19:24:20 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.18274714; Wed, 05 Apr 2006 19:24:02 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 19:24:01 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Wed, 5 Apr 2006 19:21:50 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C730540DE42@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVA= From: "Lee, Yiu" To: "Hadriel Kaplan" , "Stastny Richard" , X-OriginalArrivalTime: 05 Apr 2006 23:24:01.0915 (UTC) FILETIME=[05D5DCB0:01C65908] X-Spam-Score: 0.0 (/) 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 This is an interesting thread especially for the scenario A-B-C where B is providing transit services. In near term , I don't see any operator will like to provide transit services since I don't smell money in this area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN to do the work (at least working for the voice service). The complication of providing transit services is to guarantee service delivery. In theory, the SIP proxy in B doesn't need to record-route itself so that it can leave the signaling path as soon as A & C establish the session. Reality is B must stay in the signaling path because A signed a peering agreement with B and B signed a peering agreement with C, there is no agreement between A & C and the agreement is not transitive. If A sends a mid-dialog request directly to C, C's policy may probably reject it. For the media flow, I also argue that even if A & C have directly IP peering connectivity, A's media traffic should flow through B's IP network then to C's IP network. The reason is B signed QoS agreement with A & C, but A & C may not have any, so C won't prioritize the media traffic coming directly from A's IP peering interface. If the link is congested, the service quality will degrade. I think peering is above policy. I assume that this WG will take the lead to define and standardize the peering policy as well as the protocol distributing the policy. Yiu -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Sunday, April 02, 2006 9:48 PM To: 'Stastny Richard'; speermint@ietf.org Subject: RE: [Speermint] Reachability Hi Richard, comments inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, April 01, 2006 2:46 PM > To: speermint@ietf.org > Subject: [Speermint] Reachability >=20 > after reading the document from Scott Markus on NGN Interconnect I=20 > referenced for weekend reading in my last posting=20 > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > .pdf Indeed that was an interesting paper - thanks for the pointer! (not that I agree with everything in it) > and second we always started naturally at provider A in direction of=20 > call set-up and not at provider B Personally, I think the bigger "problem" is the provider C, the one after B. :) C trying to be reachable by A through B. But that's out of scope I guess. It's too bad, because that's when BGP got interesting, for example. > Provider B has now (currently only for Public User Identities in the=20 > form of E.164 numbers) the OBLIGATION making this PUI reachable for=20 > the public by interconnecting with the public network (in this case at > least via the PSTN) [snipped] So IMHO we can assume that provider B=20 > hosting a Public User Identity (a SIP URI) MUST make this PUI=20 > reachable in principle. I would think that would only be true if you define the AoR to be a public identity in the public domain, and such regulation was to be created for AoRs. E.164 numbers are by definition such numbers, I think. But if, for example, I build a private enterprise network - there's no way I'm obligated to do so just because I use the same SIP fields AoRs are used in. Having said that, I would think most providers _want_ to make them reachable, because that increases their value. But as the paper pointed out, peering is difficult to manage beyond a few hundred peers, nor do IP or PSTN providers peer with everyone directly to achieve universal reachability. That's why, for me, the more complex problem is the peer(s) between. But documenting A-B/B-A is a good start. > The NRA normally sets the limits to such an offer. The power of the national rifle association is staggering. ;) -hadriel _______________________________________________ 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 Apr 05 19:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHid-0005q5-1B; Wed, 05 Apr 2006 19:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHib-0005q0-2a for speermint@ietf.org; Wed, 05 Apr 2006 19:47:21 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHiZ-0003FF-Hr for speermint@ietf.org; Wed, 05 Apr 2006 19:47:21 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id A701017C; Wed, 05 Apr 2006 19:47:13 -0400 From: "Patrick Melampy" To: "'Lee, Yiu'" , "'Hadriel Kaplan'" , "'Stastny Richard'" , Subject: RE: [Speermint] Reachability Date: Wed, 5 Apr 2006 19:47:14 -0400 Message-ID: <037c01c6590b$443e6550$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAAW9PYA== In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C730540DE42@PACDCEXCMB01.cable.comcast.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 You bring up a very interesting point. Would A pay B to get to C if B didn't deliver the media flows also? I would love to go into business where I can do the signaling and have no further role in the management of the resultant media session, but I fear the business has no value. I figure A won't pay B unless the whole session is handled. Which brings up your point...will anybody take on the role of B? Why? I'm guessing there are examples with bilateral agreements that involve user mobility that closely mirror your example. Imagine a user whose home is B moving to network C. Now the service path passes through network B. Does network B care to have the session managed? Also note that A and C could establish a bilateral agreement, but they may be competitors and thus may desire not to. Imagine Comcast and Verizon trying to work out a bilateral agreement. They may decide to use B. Who would be B? I think there will always be networks between -- and the real work of this group is to figure out the requirements for signaling and media to make these kinds of session paths work to the benefit of all participants. -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Wednesday, April 05, 2006 7:22 PM To: Hadriel Kaplan; Stastny Richard; speermint@ietf.org Subject: RE: [Speermint] Reachability This is an interesting thread especially for the scenario A-B-C where B is providing transit services. In near term , I don't see any operator will like to provide transit services since I don't smell money in this area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN to do the work (at least working for the voice service). The complication of providing transit services is to guarantee service delivery. In theory, the SIP proxy in B doesn't need to record-route itself so that it can leave the signaling path as soon as A & C establish the session. Reality is B must stay in the signaling path because A signed a peering agreement with B and B signed a peering agreement with C, there is no agreement between A & C and the agreement is not transitive. If A sends a mid-dialog request directly to C, C's policy may probably reject it. For the media flow, I also argue that even if A & C have directly IP peering connectivity, A's media traffic should flow through B's IP network then to C's IP network. The reason is B signed QoS agreement with A & C, but A & C may not have any, so C won't prioritize the media traffic coming directly from A's IP peering interface. If the link is congested, the service quality will degrade. I think peering is above policy. I assume that this WG will take the lead to define and standardize the peering policy as well as the protocol distributing the policy. Yiu -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Sunday, April 02, 2006 9:48 PM To: 'Stastny Richard'; speermint@ietf.org Subject: RE: [Speermint] Reachability Hi Richard, comments inline... > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, April 01, 2006 2:46 PM > To: speermint@ietf.org > Subject: [Speermint] Reachability > > after reading the document from Scott Markus on NGN Interconnect I > referenced for weekend reading in my last posting > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > .pdf Indeed that was an interesting paper - thanks for the pointer! (not that I agree with everything in it) > and second we always started naturally at provider A in direction of > call set-up and not at provider B Personally, I think the bigger "problem" is the provider C, the one after B. :) C trying to be reachable by A through B. But that's out of scope I guess. It's too bad, because that's when BGP got interesting, for example. > Provider B has now (currently only for Public User Identities in the > form of E.164 numbers) the OBLIGATION making this PUI reachable for > the public by interconnecting with the public network (in this case at > least via the PSTN) [snipped] So IMHO we can assume that provider B > hosting a Public User Identity (a SIP URI) MUST make this PUI > reachable in principle. I would think that would only be true if you define the AoR to be a public identity in the public domain, and such regulation was to be created for AoRs. E.164 numbers are by definition such numbers, I think. But if, for example, I build a private enterprise network - there's no way I'm obligated to do so just because I use the same SIP fields AoRs are used in. Having said that, I would think most providers _want_ to make them reachable, because that increases their value. But as the paper pointed out, peering is difficult to manage beyond a few hundred peers, nor do IP or PSTN providers peer with everyone directly to achieve universal reachability. That's why, for me, the more complex problem is the peer(s) between. But documenting A-B/B-A is a good start. > The NRA normally sets the limits to such an offer. The power of the national rifle association is staggering. ;) -hadriel _______________________________________________ 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 Apr 05 20:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHxT-0003kA-Dm; Wed, 05 Apr 2006 20:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHxS-0003ix-4L for speermint@ietf.org; Wed, 05 Apr 2006 20:02:42 -0400 Received: from smtpout.eastlink.ca ([24.222.0.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHxQ-0003iG-Ma for speermint@ietf.org; Wed, 05 Apr 2006 20:02:42 -0400 Received: from ip03.eastlink.ca ([24.222.10.15]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IX9006UUXGJE1X0@mta01.eastlink.ca> for speermint@ietf.org; Wed, 05 Apr 2006 21:02:43 -0300 (ADT) Received: from blk-222-186-219.eastlink.ca (HELO IBM-7B137D96EC3.ZDSL.com) ([24.222.186.219]) by ip03.eastlink.ca with ESMTP; Wed, 05 Apr 2006 21:02:11 -0300 Date: Wed, 05 Apr 2006 20:02:00 -0400 From: Peter Macaulay Subject: RE: [Speermint] Reachability In-reply-to: <6EEEACD9D7F52940BEE26F5467C02C730540DE42@PACDCEXCMB01.cabl e.comcast.com> To: "Lee, Yiu" , speermint@ietf.org Message-id: <7.0.0.16.2.20060405194303.06406db0@ZDSL.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 (Beta) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= References: <6EEEACD9D7F52940BEE26F5467C02C730540DE42@PACDCEXCMB01.cable.comcast.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Yiu Lee. Thank you. You have quickly taken us to the design issue: Does peering need to include the A-B-C model where A-C may have a trust relationship, but not A-B nor B-C? So do we allow; (1) A-B-C peering signaling path with no media-relay (do your own) (2) A-B-C peering signaling path with media-relay. Variations will break some security models! As Melampy says there will always be "networks between" -- so let's not avoid the real A-B-C world. As mentioned earlier, solving the relay issue has been part of Skype's success. /PETER MACAULAY At 07:21 PM 4/5/2006, Lee, Yiu wrote: >This is an interesting thread especially for the scenario A-B-C where B >is providing transit services. In near term , I don't see any operator >will like to provide transit services since I don't smell money in this >area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN >to do the work (at least working for the voice service). The >complication of providing transit services is to guarantee service >delivery. In theory, the SIP proxy in B doesn't need to record-route >itself so that it can leave the signaling path as soon as A & C >establish the session. Reality is B must stay in the signaling path >because A signed a peering agreement with B and B signed a peering >agreement with C, there is no agreement between A & C and the agreement >is not transitive. If A sends a mid-dialog request directly to C, C's >policy may probably reject it. For the media flow, I also argue that >even if A & C have directly IP peering connectivity, A's media traffic >should flow through B's IP network then to C's IP network. The reason is >B signed QoS agreement with A & C, but A & C may not have any, so C >won't prioritize the media traffic coming directly from A's IP peering >interface. If the link is congested, the service quality will degrade. > >I think peering is above policy. I assume that this WG will take the >lead to define and standardize the peering policy as well as the >protocol distributing the policy. > >Yiu > > >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Sunday, April 02, 2006 9:48 PM >To: 'Stastny Richard'; speermint@ietf.org >Subject: RE: [Speermint] Reachability > >Hi Richard, comments inline... > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, April 01, 2006 2:46 PM > > To: speermint@ietf.org > > Subject: [Speermint] Reachability > > > > after reading the document from Scott Markus on NGN Interconnect I > > referenced for weekend reading in my last posting > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > .pdf > >Indeed that was an interesting paper - thanks for the pointer! (not that >I agree with everything in it) > > > and second we always started naturally at provider A in direction of > > call set-up and not at provider B > >Personally, I think the bigger "problem" is the provider C, the one >after B. >:) C trying to be reachable by A through B. But that's out of scope I >guess. It's too bad, because that's when BGP got interesting, for >example. > > > Provider B has now (currently only for Public User Identities in the > > form of E.164 numbers) the OBLIGATION making this PUI reachable for > > the public by interconnecting with the public network (in this case at > > > least via the PSTN) [snipped] So IMHO we can assume that provider B > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > reachable in principle. > >I would think that would only be true if you define the AoR to be a >public identity in the public domain, and such regulation was to be >created for AoRs. E.164 numbers are by definition such numbers, I >think. But if, for example, I build a private enterprise network - >there's no way I'm obligated to do so just because I use the same SIP >fields AoRs are used in. > >Having said that, I would think most providers _want_ to make them >reachable, because that increases their value. But as the paper pointed >out, peering is difficult to manage beyond a few hundred peers, nor do >IP or PSTN providers peer with everyone directly to achieve universal >reachability. That's why, for me, the more complex problem is the >peer(s) between. But documenting A-B/B-A is a good start. > > > The NRA normally sets the limits to such an offer. > >The power of the national rifle association is staggering. ;) > >-hadriel > > > >_______________________________________________ >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 Apr 05 20:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIhd-0006vg-Rw; Wed, 05 Apr 2006 20:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIhc-0006vb-LT for speermint@ietf.org; Wed, 05 Apr 2006 20:50:24 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRIhc-0006CT-Cx for speermint@ietf.org; Wed, 05 Apr 2006 20:50:24 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 20:50: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] NATs and Firewalls Date: Wed, 5 Apr 2006 20:50:20 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A1B6@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls thread-index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQAAkOs+A= From: "Medhavi Bhatia" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 06 Apr 2006 00:50:23.0910 (UTC) FILETIME=[168B8C60:01C65914] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 >=20 Hi Hadriel, See below. > I think what may be the issue is our definition of SBCs may simply not be > the same. Maybe you feel all the functions of modern SBCs are all > implemented in a single physical box, which is not the case from my view at > all. The functions can be broken up, or not. It does not matter from the > context of this working group, because the peering partner is a single > logical entity and it's the requirements that must be covered, not the > implementations meeting those requirements. (as pointed out to me earlier! > :) =20 I think that is the problem today. There are too many SBC definitions and behaviors. This is the result of different point solutions for similar requirements given by service providers in different circumstances (fixed, mobile etc). Clearly something this under-defined cannot be taken into account by the WG when making choices. That's what I essentially said in an earlier thread on WG scope. We need to get all the requirements on the table and be practical about them. SBCs are out of scope... > My only point relative to what should be "required", is applicability to > as broad a spectrum of providers as possible, where covering the case of L3 > VPNs is probably the broadest approach, and within the IETF's domain. >=20 > Or maybe you feel the definition of "SBC" _requires_ media relaying > somewhere? That is not the case for any of the current physical > implementations of SBCs that I know of in the service-provider market. It > happens to be that many providers enable them to do that, for many reasons > way beyond "point" requirements. For example, I consider media-relaying for > the purpose of hosted-nat-traversal a "point" requirement. Someday it will > fix itself. But that's not why many providers relay media, and certainly > not in peering applications; and some providers don't relay media with their > SBCs. >=20 I think in the speermint we should look at the problem of peering during session setup. After the setup phase, the service providers may decide to do media peering or not. We should tackle those requirements later on. > Regardless, in my view even if the SBC does not relay media it's still an > SBC if it performs other functions related to security, inter-working, > policies, etc. Some of those functions are described in > draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped author. > Clearly at some point as you remove those functions it ends up being just a > proxy. =20 B2BUA to be precise. If I remove those functions, I will still be left with a lot more functions! (it is not easy to document all SBC functions, especially since there is no clear definition or requirements out there on functions or expected behavior. We only mention some in that draft). But since a large group of providers appear to want some or all of > those functions (and more) today, at peering points, then a peering BCP for > peering providers would be most successful if it "worked" within the > constraints of those wants while providing BCPs to enable new services or > applications. >=20 I think the problem we are trying to solve in the WG is definition of a specific SIP signaling profile (as defined by this WG at some point I guess) and location mechanism for next hop (again TBD from this WG) which will enable successful hand-off of the call between domains. This is clearly my interpretation and the chairs may think o/w. We should not be taking the SBC functions as defined somewhere (especially since they are incomplete) and try to write BCPs on them. We should be defining interfaces in this WG, not elements, architecture etc. > I think the simplest way to do it is to simply also cover the case of L3 > VPNs peering with each other. Do you disagree with that? Any "services" or > applications which cannot be met by peering L3 VPNs, may be documented as > such in the BCPs, as far as I care. >=20 L3 is out of scope... I think that I am pretty sure of. I am not sure what you mean by peering L3 VPNs in speermint's context. -Medhavi. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 05 20:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIn5-000309-Ad; Wed, 05 Apr 2006 20:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRIn4-000304-V4 for speermint@ietf.org; Wed, 05 Apr 2006 20:56:02 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRIn3-0006V8-Jn for speermint@ietf.org; Wed, 05 Apr 2006 20:56:02 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 20:56: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] Reachability Date: Wed, 5 Apr 2006 20:55:58 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A1BB@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability thread-index: AcZZDcttwPx7pzvYQge34zzEoZcc2QABt9LA From: "Medhavi Bhatia" To: "Peter Macaulay" , "Lee, Yiu" , X-OriginalArrivalTime: 06 Apr 2006 00:56:01.0386 (UTC) FILETIME=[DFB24CA0:01C65914] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Peter, In the A-B-C model, isn't B going to map to the IXP (or interconnect) as discussed in the WG discussions? -Medhavi. > -----Original Message----- > From: Peter Macaulay [mailto:peter.macaulay@ZDSL.com] > Sent: Wednesday, April 05, 2006 8:02 PM > To: Lee, Yiu; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Yiu Lee. Thank you. You have quickly taken us to the design > issue: Does peering need to include the A-B-C model where A-C > may have a trust relationship, but not A-B nor B-C? >=20 > So do we allow; >=20 > (1) A-B-C peering signaling path with no media-relay (do your own) > (2) A-B-C peering signaling path with media-relay. >=20 > Variations will break some security models! As Melampy says > there will always be "networks between" -- so let's not avoid the > real A-B-C world. As mentioned earlier, solving the relay issue > has been part of Skype's success. >=20 > /PETER MACAULAY >=20 > At 07:21 PM 4/5/2006, Lee, Yiu wrote: > >This is an interesting thread especially for the scenario A-B-C where B > >is providing transit services. In near term , I don't see any operator > >will like to provide transit services since I don't smell money in this > >area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN > >to do the work (at least working for the voice service). The > >complication of providing transit services is to guarantee service > >delivery. In theory, the SIP proxy in B doesn't need to record-route > >itself so that it can leave the signaling path as soon as A & C > >establish the session. Reality is B must stay in the signaling path > >because A signed a peering agreement with B and B signed a peering > >agreement with C, there is no agreement between A & C and the agreement > >is not transitive. If A sends a mid-dialog request directly to C, C's > >policy may probably reject it. For the media flow, I also argue that > >even if A & C have directly IP peering connectivity, A's media traffic > >should flow through B's IP network then to C's IP network. The reason is > >B signed QoS agreement with A & C, but A & C may not have any, so C > >won't prioritize the media traffic coming directly from A's IP peering > >interface. If the link is congested, the service quality will degrade. > > > >I think peering is above policy. I assume that this WG will take the > >lead to define and standardize the peering policy as well as the > >protocol distributing the policy. > > > >Yiu > > > > > >-----Original Message----- > >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >Sent: Sunday, April 02, 2006 9:48 PM > >To: 'Stastny Richard'; speermint@ietf.org > >Subject: RE: [Speermint] Reachability > > > >Hi Richard, comments inline... > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, April 01, 2006 2:46 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Reachability > > > > > > after reading the document from Scott Markus on NGN Interconnect I > > > referenced for weekend reading in my last posting > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > > .pdf > > > >Indeed that was an interesting paper - thanks for the pointer! (not that > >I agree with everything in it) > > > > > and second we always started naturally at provider A in direction of > > > call set-up and not at provider B > > > >Personally, I think the bigger "problem" is the provider C, the one > >after B. > >:) C trying to be reachable by A through B. But that's out of scope I > >guess. It's too bad, because that's when BGP got interesting, for > >example. > > > > > Provider B has now (currently only for Public User Identities in the > > > form of E.164 numbers) the OBLIGATION making this PUI reachable for > > > the public by interconnecting with the public network (in this case at > > > > > least via the PSTN) [snipped] So IMHO we can assume that provider B > > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > > reachable in principle. > > > >I would think that would only be true if you define the AoR to be a > >public identity in the public domain, and such regulation was to be > >created for AoRs. E.164 numbers are by definition such numbers, I > >think. But if, for example, I build a private enterprise network - > >there's no way I'm obligated to do so just because I use the same SIP > >fields AoRs are used in. > > > >Having said that, I would think most providers _want_ to make them > >reachable, because that increases their value. But as the paper pointed > >out, peering is difficult to manage beyond a few hundred peers, nor do > >IP or PSTN providers peer with everyone directly to achieve universal > >reachability. That's why, for me, the more complex problem is the > >peer(s) between. But documenting A-B/B-A is a good start. > > > > > The NRA normally sets the limits to such an offer. > > > >The power of the national rifle association is staggering. ;) > > > >-hadriel > > > > > > > >_______________________________________________ > >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 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/301 - Release Date: 4/4/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 03:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROUk-0002pQ-ET; Thu, 06 Apr 2006 03:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROUj-0002p9-3W for speermint@ietf.org; Thu, 06 Apr 2006 03:01:29 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FROUf-0002qE-G2 for speermint@ietf.org; Thu, 06 Apr 2006 03:01:29 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Thu, 6 Apr 2006 09:05:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwA== From: "Stastny Richard" To: "Lee, Yiu" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > Sent: Thursday, April 06, 2006 1:22 AM > To: Hadriel Kaplan; Stastny Richard; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > This is an interesting thread especially for the scenario A-B-C where B > is providing transit services. In near term , I don't see any operator > will like to provide transit services since I don't smell money in this > area ;-) Also, if A doesn't peer C directly, we have our old friend PSTN > to do the work (at least working for the voice service).=20 No, you do NOT have the Good old PSTN to do the work in SPEERMIND SPEERMINT (peering, interreconnect; whatever) is not E.164 aware, so the PSTN is NOT an Option > The > complication of providing transit services is to guarantee service > delivery. In theory, the SIP proxy in B doesn't need to record-route > itself so that it can leave the signaling path as soon as A & C > establish the session. Reality is B must stay in the signaling path > because A signed a peering agreement with B and B signed a peering > agreement with C, there is no agreement between A & C and the agreement > is not transitive. If A sends a mid-dialog request directly to C, C's > policy may probably reject it. For the media flow, I also argue that > even if A & C have directly IP peering connectivity, A's media traffic > should flow through B's IP network then to C's IP network.=20 You are implying L3 peering is atomatically with L5 peering,=20 I thought we had this one > The reason is > B signed QoS agreement with A & C, but A & C may not have any, so C > won't prioritize the media traffic coming directly from A's IP peering > interface. If the link is congested, the service quality will degrade. Implying there is an unneccessary Qos agreement in the core. As the Scott Marcus paper points out, this is unnecessary in most cases and=20 also not controllable. QoS, if at all, is only required in the access. We should not waste our time with unimplementable issues. >=20 > I think peering is above policy. I assume that this WG will take the > lead to define and standardize the peering policy as well as the > protocol distributing the policy. >=20 > Yiu >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sunday, April 02, 2006 9:48 PM > To: 'Stastny Richard'; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Hi Richard, comments inline... >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Saturday, April 01, 2006 2:46 PM > > To: speermint@ietf.org > > Subject: [Speermint] Reachability > > > > after reading the document from Scott Markus on NGN Interconnect I > > referenced for weekend reading in my last posting > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > .pdf >=20 > Indeed that was an interesting paper - thanks for the pointer! (not that > I agree with everything in it) >=20 > > and second we always started naturally at provider A in direction of > > call set-up and not at provider B >=20 > Personally, I think the bigger "problem" is the provider C, the one > after B. > :) C trying to be reachable by A through B. But that's out of scope I > guess. It's too bad, because that's when BGP got interesting, for > example. >=20 > > Provider B has now (currently only for Public User Identities in the > > form of E.164 numbers) the OBLIGATION making this PUI reachable for > > the public by interconnecting with the public network (in this case at >=20 > > least via the PSTN) [snipped] So IMHO we can assume that provider B > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > reachable in principle. >=20 > I would think that would only be true if you define the AoR to be a > public identity in the public domain, and such regulation was to be > created for AoRs. E.164 numbers are by definition such numbers, I > think. But if, for example, I build a private enterprise network - > there's no way I'm obligated to do so just because I use the same SIP > fields AoRs are used in. >=20 > Having said that, I would think most providers _want_ to make them > reachable, because that increases their value. But as the paper pointed > out, peering is difficult to manage beyond a few hundred peers, nor do > IP or PSTN providers peer with everyone directly to achieve universal > reachability. That's why, for me, the more complex problem is the > peer(s) between. But documenting A-B/B-A is a good start. >=20 > > The NRA normally sets the limits to such an offer. >=20 > The power of the national rifle association is staggering. ;) >=20 > -hadriel >=20 >=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 Apr 06 03:08:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRObS-0005o9-Ps; Thu, 06 Apr 2006 03:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROaz-0005R4-TN for speermint@ietf.org; Thu, 06 Apr 2006 03:07:57 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FROay-0002v9-4D for speermint@ietf.org; Thu, 06 Apr 2006 03:07:57 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] NATs and Firewalls Date: Thu, 6 Apr 2006 09:11:57 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQAAkOs+AADv7RAA== From: "Stastny Richard" To: "Medhavi Bhatia" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 the problem we are trying to solve in the WG is definition of a > specific SIP signaling profile (as defined by this WG at some point I > guess) and location mechanism for next hop (again TBD from this WG) > which will enable successful hand-off of the call between domains. This > is clearly my interpretation and the chairs may think o/w. We should not > be taking the SBC functions as defined somewhere (especially since they > are incomplete) and try to write BCPs on them. We should be defining > interfaces in this WG, not elements, architecture etc. Yep, at least this should be our first priority > L3 is out of scope... I think that I am pretty sure of. I am not sure > what you mean by peering L3 VPNs in speermint's context. Also, yes, again L5 is first priority Richard > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 2:50 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > > > Hi Hadriel, >=20 > See below. >=20 >=20 > > I think what may be the issue is our definition of SBCs may simply not > be > > the same. Maybe you feel all the functions of modern SBCs are all > > implemented in a single physical box, which is not the case from my > view at > > all. The functions can be broken up, or not. It does not matter from > the > > context of this working group, because the peering partner is a single > > logical entity and it's the requirements that must be covered, not the > > implementations meeting those requirements. (as pointed out to me > earlier! > > :) >=20 > I think that is the problem today. There are too many SBC definitions > and behaviors. This is the result of different point solutions for > similar requirements given by service providers in different > circumstances (fixed, mobile etc). Clearly something this under-defined > cannot be taken into account by the WG when making choices. That's what > I essentially said in an earlier thread on WG scope. We need to get all > the requirements on the table and be practical about them. SBCs are out > of scope... >=20 >=20 > > My only point relative to what should be "required", is applicability > to > > as broad a spectrum of providers as possible, where covering the case > of L3 > > VPNs is probably the broadest approach, and within the IETF's domain. > > > > Or maybe you feel the definition of "SBC" _requires_ media relaying > > somewhere? That is not the case for any of the current physical > > implementations of SBCs that I know of in the service-provider market. > It > > happens to be that many providers enable them to do that, for many > reasons > > way beyond "point" requirements. For example, I consider > media-relaying for > > the purpose of hosted-nat-traversal a "point" requirement. Someday it > will > > fix itself. But that's not why many providers relay media, and > certainly > > not in peering applications; and some providers don't relay media with > their > > SBCs. > > >=20 > I think in the speermint we should look at the problem of peering during > session setup. After the setup phase, the service providers may decide > to do media peering or not. We should tackle those requirements later > on. >=20 > > Regardless, in my view even if the SBC does not relay media it's still > an > > SBC if it performs other functions related to security, inter-working, > > policies, etc. Some of those functions are described in > > draft-camarillo-sipping-sbc-funcs-03.txt, which I believe you helped > author. > > Clearly at some point as you remove those functions it ends up being > just a > > proxy. >=20 > B2BUA to be precise. If I remove those functions, I will still be left > with a lot more functions! (it is not easy to document all SBC > functions, especially since there is no clear definition or requirements > out there on functions or expected behavior. We only mention some in > that draft). >=20 > But since a large group of providers appear to want some or all of > > those functions (and more) today, at peering points, then a peering > BCP for > > peering providers would be most successful if it "worked" within the > > constraints of those wants while providing BCPs to enable new services > or > > applications. > > >=20 > I think the problem we are trying to solve in the WG is definition of a > specific SIP signaling profile (as defined by this WG at some point I > guess) and location mechanism for next hop (again TBD from this WG) > which will enable successful hand-off of the call between domains. This > is clearly my interpretation and the chairs may think o/w. We should not > be taking the SBC functions as defined somewhere (especially since they > are incomplete) and try to write BCPs on them. We should be defining > interfaces in this WG, not elements, architecture etc. >=20 > > I think the simplest way to do it is to simply also cover the case of > L3 > > VPNs peering with each other. Do you disagree with that? Any > "services" or > > applications which cannot be met by peering L3 VPNs, may be documented > as > > such in the BCPs, as far as I care. > > >=20 > L3 is out of scope... I think that I am pretty sure of. I am not sure > what you mean by peering L3 VPNs in speermint's context. >=20 > -Medhavi. >=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 Apr 06 03:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROrJ-0002zv-Om; Thu, 06 Apr 2006 03:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROrD-0002xJ-IS for speermint@ietf.org; Thu, 06 Apr 2006 03:24:43 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FROr8-0003ME-D3 for speermint@ietf.org; Thu, 06 Apr 2006 03:24:43 -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" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Apr 2006 09:28:40 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Background Reading on NGN Interconnect - transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+A= From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: Subject: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering 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 the FCC definition is that is states that peering is always bi-lateral The major reason for setting up SPEERMINT was that everybody seems at least to agree that bi-lateral peering does not scale globally. And our real goal is to achieve global connectivity and reachability. Maybe the name of the WG is wrong in this context I still believe that the task of SPEERMINT is to show a way forward to overcome these bi-lateral peering. Away forward in this direction are federations, but finally we should lay the framework for a global IP Interconnect regime, at least protocol wise It is obvious that this cannot be done only by protocols in a vacuum, so I fully agree that co-operation with other standard bodies e.g. ITU-T and national authorities=20 will be required. If all communication networks are finally migrated to IP, an IP Interconnect regime is required. The problem here is that currently there are national interconnect regimes and the international regime on top (hierarchical) as default. The new regime allows global direct interconnect, mixing up the current national and international regimes. In many countries national forums are popping up (e.g. in UK and Germany) talking=20 about IP-based interconnect (with or without L3 peering). But=20 they still need to recognize that this is only half of the picture. Some of these discussions are going around in circles (like the discussions here? ;-). Maybe one task of SPEERMINT could also be to make scenarios and BCP, showing what works and what not and why not, saving these other bodies some time on useless discussions on not implementable or non-scalable models. Richard > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Wednesday, April 05, 2006 5:12 PM > To: Stastny Richard; speermint@ietf.org > Subject: Background Reading on NGN Interconnect - transit vs peering >=20 > Richard: > Thanks for posting this. I recommend it to all. In particular we ought > to pay attention to the definition of peering versus transit offered by > the US FCC and cited in the Marcus paper: >=20 > Peering is an agreement between ISPs to carry traffic for each > other and for their respective > customers. Peering does not include the obligation to carry > traffic to third parties. Peering is usually a > bilateral business and technical arrangement, where two > providers agree to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... >=20 > Transit is an agreement where an ISP agrees to carry traffic on > behalf of another ISP or end user. In > most cases transit will include an obligation to carry traffic > to third parties. Transit is usually a > bilateral business and technical arrangement, where one provider > (the transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end > user (the customer). In most cases, the > transit provider carries traffic to and from its other > customers, and to and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, > installation support, local telecom provisioning, > and Network Operations Center (NOC) support. >=20 > While we NEED not accept this definition I think it does reflect the > reality of layer 3 peering and it will not be helpful to use a > definition for layer 5 that is at odds with layer 3 since that's what > people are familiar with. > If the will of the WG is to include transit in our charter that's fine - > but not an excuse for calling apples and oranges both apples. If, at the > end of the day, there are no important differences in how we treat the > two cases - which I doubt - then life is good. >=20 > We also ought to be thinking about how what Speermint is working on > relates to what's going on in other bodies, e.g. the ITU. (yes, I said > it, we're not alone on the planet :-) Is what we want to do an enabling > piece of what NGN folks are looking toward or is it a fundamentally > different animal? From the discussion on the list and at the IETF I'm > not entirely sure. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 31, 2006 3:59 PM > To: speermint@ietf.org > Subject: [Speermint] Background Reading on NGN Interconnect >=20 > Folks, >=20 > Weekend reading >=20 > Since we obviosly are dealing more with NGN Interconnect in Speermint, > I recommend everybody on this this list to read the excellent Background > Paper > from Scott Marcus - Interconnection in an IP-based NGN Environment > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.p > df >=20 > to his presentation > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-2 > 006.ppt > given at the ITU-T Workshop last week > What Rules for Ip-eneabled NGNs? > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml >=20 > The agenda and some other excellent presentations can be downloaded from > here: > http://www.itu.int/osg/spu/ngn/presentations.html >=20 > In addition I would also like to point to a CEPT ECC Draft Report > on the Future on Numbering, tabled for the next ITU-T SG2 Meeting > as TD 198-GEN. > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 2 > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > The document is in public consultation and not final yet. > It contains also some statements regarding termination rates. >=20 > The paper from Scott is on-topic regarding the current discussion here > and dealing with both the European and US situation >=20 > Scott Marcus is currently living in Europe, but in his former life > he was Senior Advisor to the FCC and also CTO for GTE Interworking, > so his knowledge is not only theoretical. >=20 > In the document also contains a definition on peering and transit from > the FCC is given: >=20 > The two most prevalent forms of Internet interconnection are peering and > transit. For a definition of these > terms, we turn to a publication of the Network Reliability and > Interoperability Council (NRIC), an industry > advisory panel to the U.S. FCC: >=20 > Peering is an agreement between ISPs to carry traffic for each other and > for their respective > customers. Peering does not include the obligation to carry traffic to > third parties. Peering is usually a > bilateral business and technical arrangement, where two providers agree > to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... >=20 > Transit is an agreement where an ISP agrees to carry traffic on behalf > of another ISP or end user. In > most cases transit will include an obligation to carry traffic to third > parties. Transit is usually a > bilateral business and technical arrangement, where one provider (the > transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end user > (the customer). In most cases, the > transit provider carries traffic to and from its other customers, and to > and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, installation > support, local telecom provisioning, > and Network Operations Center (NOC) support. >=20 > Peering thus offers a provider access only to a single provider's > customers. Transit, by contrast, > usually provides access at a predictable price to the entire Internet. > ... Historically, peering has often > been done on a bill-and-keep basis, without cash payments. Peering where > there is no explicit > exchange of money between parties, and where each party supports part of > the cost of the > interconnect, ... is typically used where both parties perceive a > roughly equal exchange of value. > Peering therefore is fundamentally a barter relationship >=20 > Here the Executive Summary of the paper: >=20 > This report considers the likely evolution of interconnection > arrangements in the context of IP-based Next > Generation Networks (NGNs). >=20 > The NGN represents a synthesis of existing world of the "traditional" > Public Switched Telephone Network > (PSTN) with the world of the Internet. The economic and regulatory > arrangements for the two have > historically been very different. What should happen when these two > worlds collide? >=20 > Many of the networks created over the past ten years contain most of the > key elements of an NGN. Most, if > not all, of the technology necessary for IP-based NGN interconnection > has been available for five to ten > years. Advanced approaches to interconnection have been slow to deploy, > even where the technology has > been mature or within hailing distance of maturity. >=20 > The NGN interconnection problem is best understood, not as a problem of > technology, but rather as a > problem in economics. With that in mind, this report seeks to review > what is known about interconnection > from an economic perspective, in order to reach conclusions about the > prospects for deployment going > forward and the corresponding implications for policymakers. >=20 > A substantial body of economic theory has been developed over the past > decade as regards interconnection in > the traditional PSTN. A smaller body of solid economic research has > emerged in regard to interconnection of > IP-based networks. At the level of economic theory, the PSTN and the > Internet are not worlds apart. > Economics provides the necessary bridge between the two worlds, > illuminating both the similarities and the > differences in these two environments. >=20 > This report begins by laying out, for the most part at a non-technical > level, the established theory of > interconnection, for both the PSTN and the Internet. Wholesale and > retail arrangements are considered > separately. Most of the observed behavior of these economic networks can > be explained in terms of a > constellation of known economic effects: market power, the termination > monopoly, demand elasticity, > network exernalities, transaction costs, service differentiation, price > discrimination, and the Coase theorem > (which says that private parties can often negotiate arrangements more > efficiently than government > regulators, provided that necessary preconditions have been met). >=20 > With this theory in hand, the report considers the implications for the > deployment of differentiated Quality of > Service, and of universal service. We also consider the implications of > IP-based technology - with the > layering, and the changes in industry structure that it implies - > service providers become independent of the > network, but neither is well equipped to measure or to charge for the > other's resource consumption. > The last section of the report represents a hypothetical scenario, a > "thought experiment", where the historic > wired and mobile incumbent of European country upgrades its networks to > an IP-based NGN. We consider > the likely results in terms of regulation of the access network, and of > interconnection; likely domestic and > international interconnection arrangements; and the implications for > ubiquitous support of QoS. Key findings > include: > * Provided that markets for Internet transit and for consumer broadband > Internet access are effectively > competitive, a "Coasian" interconnection regime is likely to be more > efficient, and more consistent > with consumer welfare, than a regulated regime. > * Conversely, where these markets are not effectively competitive, > mandates for interconnection at the > IP level may prove to be unavoidable, particularly once existing PSTN > interconnection is withdrawn. > The migration to NGN potentially creates new sources of market power, at > the same time that it > creates new possibilities for competition. > * Policymakers might consequently be well advised to focus their > attention first on ensuring > competitive markets, and only secondarily on interconnection. >=20 > Current Calling Party's Network Pays (CPNP) arrangements contain a > number of implicit subsidies. In the > world of the NGN, where services providers and networks operators may be > different entities, these > subsidies need major re-thinking - call termination payments that were > intended to finance the terminating > network would, by default, flow to independent VoIP service provides who > have no network to support. In > the absence of termination fees, independent VoIP providers would tend > to compete price levels for > telephony service, independent of the network, down to levels not > greatly above cost, which would appear to > be a societally desirable outcome. >=20 > The thought experiment does not flatly preclude the possibility that > governments might somehow erect a > new system of subsidies to replace the old, but it suggests that any > subsidy system will be difficult to sustain > over time in the face of new forms of competition enabled by the > IP-based NGN - all provided, once again, > that underlying markets (especially for wholesale Internet transit and > for retail Internet broadband access) > remain effectively competitive. A system of Coasian private > arrangements, in the absence of vertically > integrated competitive bottlenecks, seems likely to lead to unsubsidized > arrangements at wholesale and retail > price levels not greatly in excess of cost. >=20 > cheer > Richard >=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 Apr 06 03:55:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPKd-0006pI-JS; Thu, 06 Apr 2006 03:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPKa-0006kk-RP for speermint@ietf.org; Thu, 06 Apr 2006 03:55:04 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRPKX-0004Lh-8G for speermint@ietf.org; Thu, 06 Apr 2006 03:55:04 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 00:54:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,92,1144047600"; d="scan'208"; a="538130017:sNHT25514544" 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] Reachability Date: Thu, 6 Apr 2006 03:54:58 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F4@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQ From: "Reinaldo Penno" To: "Stastny Richard" , "Lee, Yiu" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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'm having a hard time understanding the complications...Sorry but I'm going to ask basic questions again before we dwell in many (more) discussions. It _seems_ to me we are overly complicating each topic.=20 Are A and C paying B to carry _IP_ packets (which includes signaling and media)? Can A send and receive packets from C? So, unless A and C want something special done to their signaling traffic I wonder what B has to do with it... Why would I pay B to be a proxy hop if I can send packets directly? Are A and C concerned with security, or wondering how to peer directly? Well, then peer directly over a TLS connection.=20 Also, I do not understand "transit services" in this context. This is not the PSTN. We are talking IP backbones, right? I'm assuming A has DNS access and so has C. They can figure out by themselves the "sip route" of the signaling services. There is nothing SIP related that B can provide that A and C cannot figure out. The endpoints are in A and C; B does not have control over the E.164 numbers, ENUM, SIP URIS, etc. =20 I can have a SIP TLS connection from my house over 5 different backbones and peer with another proxy server in Japan. That's the fundamental of Layer 5 peering, no? It is an overlay network over IP. Unless some carrier/provider has some access list, I wonder what the problem is.=20 Now, maybe I'm missing something, maybe we need to hash out this example further.=20 Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 12:05 AM > To: Lee, Yiu; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Inline >=20 > > -----Original Message----- > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > Sent: Thursday, April 06, 2006 1:22 AM > > To: Hadriel Kaplan; Stastny Richard; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > This is an interesting thread especially for the scenario A-B-C where > B > > is providing transit services. In near term , I don't see any operator > > will like to provide transit services since I don't smell money in > this > > area ;-) Also, if A doesn't peer C directly, we have our old friend > PSTN > > to do the work (at least working for the voice service). >=20 > No, you do NOT have the Good old PSTN to do the work in SPEERMIND > SPEERMINT (peering, interreconnect; whatever) is not E.164 aware, > so the PSTN is NOT an Option >=20 > > The > > complication of providing transit services is to guarantee service > > delivery. In theory, the SIP proxy in B doesn't need to record-route > > itself so that it can leave the signaling path as soon as A & C > > establish the session. Reality is B must stay in the signaling path > > because A signed a peering agreement with B and B signed a peering > > agreement with C, there is no agreement between A & C and the > agreement > > is not transitive. If A sends a mid-dialog request directly to C, C's > > policy may probably reject it. For the media flow, I also argue that > > even if A & C have directly IP peering connectivity, A's media traffic > > should flow through B's IP network then to C's IP network. >=20 > You are implying L3 peering is atomatically with L5 peering, > I thought we had this one >=20 > > The reason is > > B signed QoS agreement with A & C, but A & C may not have any, so C > > won't prioritize the media traffic coming directly from A's IP peering > > interface. If the link is congested, the service quality will degrade. >=20 > Implying there is an unneccessary Qos agreement in the core. As the > Scott > Marcus paper points out, this is unnecessary in most cases and > also not controllable. QoS, if at all, is only required in the access. >=20 > We should not waste our time with unimplementable issues. >=20 > > > > I think peering is above policy. I assume that this WG will take the > > lead to define and standardize the peering policy as well as the > > protocol distributing the policy. > > > > Yiu > > > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Sunday, April 02, 2006 9:48 PM > > To: 'Stastny Richard'; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Hi Richard, comments inline... > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Saturday, April 01, 2006 2:46 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Reachability > > > > > > after reading the document from Scott Markus on NGN Interconnect I > > > referenced for weekend reading in my last posting > > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > > .pdf > > > > Indeed that was an interesting paper - thanks for the pointer! (not > that > > I agree with everything in it) > > > > > and second we always started naturally at provider A in direction of > > > call set-up and not at provider B > > > > Personally, I think the bigger "problem" is the provider C, the one > > after B. > > :) C trying to be reachable by A through B. But that's out of scope > I > > guess. It's too bad, because that's when BGP got interesting, for > > example. > > > > > Provider B has now (currently only for Public User Identities in the > > > form of E.164 numbers) the OBLIGATION making this PUI reachable for > > > the public by interconnecting with the public network (in this case > at > > > > > least via the PSTN) [snipped] So IMHO we can assume that provider B > > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > > reachable in principle. > > > > I would think that would only be true if you define the AoR to be a > > public identity in the public domain, and such regulation was to be > > created for AoRs. E.164 numbers are by definition such numbers, I > > think. But if, for example, I build a private enterprise network - > > there's no way I'm obligated to do so just because I use the same SIP > > fields AoRs are used in. > > > > Having said that, I would think most providers _want_ to make them > > reachable, because that increases their value. But as the paper > pointed > > out, peering is difficult to manage beyond a few hundred peers, nor do > > IP or PSTN providers peer with everyone directly to achieve universal > > reachability. That's why, for me, the more complex problem is the > > peer(s) between. But documenting A-B/B-A is a good start. > > > > > The NRA normally sets the limits to such an offer. > > > > The power of the national rifle association is staggering. ;) > > > > -hadriel > > > > > > > > _______________________________________________ > > 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 Thu Apr 06 04:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPU0-0002RF-Nl; Thu, 06 Apr 2006 04:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPTy-0002RA-Lw for speermint@ietf.org; Thu, 06 Apr 2006 04:04:46 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRPTw-000594-VV for speermint@ietf.org; Thu, 06 Apr 2006 04:04:46 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 06 Apr 2006 01:04:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,92,1144047600"; d="scan'208"; a="541348926:sNHT28736072" 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] Reachability Date: Thu, 6 Apr 2006 04:04:42 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F5@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAFFQmA= From: "Reinaldo Penno" To: "Reinaldo Penno" , "Stastny Richard" , "Lee, Yiu" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 Let me take this further. If A performs only _VoIP peering_ with B, there is nothing precluding it from peering with C directly too, unless we have a totally segregated network. So, physically it would look something like this ------- -------- ------- | A |=3D=3D=3D=3D=3D=3D=3D=3D=3D| B | | C | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= | | ------- -------- ------- But logically it would be like this A =3D=3D=3D=3D=3D B \ \=20 \ C Sorry for the text graphics. > -----Original Message----- > From: Reinaldo Penno > Sent: Thursday, April 06, 2006 12:55 AM > To: Stastny Richard; Lee, Yiu; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > I'm having a hard time understanding the complications...Sorry but I'm > going to ask basic questions again before we dwell in many (more) > discussions. It _seems_ to me we are overly complicating each topic. >=20 > Are A and C paying B to carry _IP_ packets (which includes signaling and > media)? Can A send and receive packets from C? So, unless A and C want > something special done to their signaling traffic I wonder what B has to > do with it... Why would I pay B to be a proxy hop if I can send packets > directly? Are A and C concerned with security, or wondering how to peer > directly? Well, then peer directly over a TLS connection. >=20 > Also, I do not understand "transit services" in this context. This is > not the PSTN. We are talking IP backbones, right? >=20 > I'm assuming A has DNS access and so has C. They can figure out by > themselves the "sip route" of the signaling services. There is nothing > SIP related that B can provide that A and C cannot figure out. The > endpoints are in A and C; B does not have control over the E.164 > numbers, ENUM, SIP URIS, etc. >=20 > I can have a SIP TLS connection from my house over 5 different backbones > and peer with another proxy server in Japan. That's the fundamental of > Layer 5 peering, no? It is an overlay network over IP. Unless some > carrier/provider has some access list, I wonder what the problem is. >=20 > Now, maybe I'm missing something, maybe we need to hash out this example > further. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, April 06, 2006 12:05 AM > > To: Lee, Yiu; Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Inline > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, April 06, 2006 1:22 AM > > > To: Hadriel Kaplan; Stastny Richard; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > This is an interesting thread especially for the scenario A-B-C > where > > B > > > is providing transit services. In near term , I don't see any > operator > > > will like to provide transit services since I don't smell money in > > this > > > area ;-) Also, if A doesn't peer C directly, we have our old friend > > PSTN > > > to do the work (at least working for the voice service). > > > > No, you do NOT have the Good old PSTN to do the work in SPEERMIND > > SPEERMINT (peering, interreconnect; whatever) is not E.164 aware, > > so the PSTN is NOT an Option > > > > > The > > > complication of providing transit services is to guarantee service > > > delivery. In theory, the SIP proxy in B doesn't need to record-route > > > itself so that it can leave the signaling path as soon as A & C > > > establish the session. Reality is B must stay in the signaling path > > > because A signed a peering agreement with B and B signed a peering > > > agreement with C, there is no agreement between A & C and the > > agreement > > > is not transitive. If A sends a mid-dialog request directly to C, > C's > > > policy may probably reject it. For the media flow, I also argue that > > > even if A & C have directly IP peering connectivity, A's media > traffic > > > should flow through B's IP network then to C's IP network. > > > > You are implying L3 peering is atomatically with L5 peering, > > I thought we had this one > > > > > The reason is > > > B signed QoS agreement with A & C, but A & C may not have any, so C > > > won't prioritize the media traffic coming directly from A's IP > peering > > > interface. If the link is congested, the service quality will > degrade. > > > > Implying there is an unneccessary Qos agreement in the core. As the > > Scott > > Marcus paper points out, this is unnecessary in most cases and > > also not controllable. QoS, if at all, is only required in the access. > > > > We should not waste our time with unimplementable issues. > > > > > > > > I think peering is above policy. I assume that this WG will take the > > > lead to define and standardize the peering policy as well as the > > > protocol distributing the policy. > > > > > > Yiu > > > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Sunday, April 02, 2006 9:48 PM > > > To: 'Stastny Richard'; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Richard, comments inline... > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Saturday, April 01, 2006 2:46 PM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Reachability > > > > > > > > after reading the document from Scott Markus on NGN Interconnect I > > > > referenced for weekend reading in my last posting > > > > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > > > .pdf > > > > > > Indeed that was an interesting paper - thanks for the pointer! (not > > that > > > I agree with everything in it) > > > > > > > and second we always started naturally at provider A in direction > of > > > > call set-up and not at provider B > > > > > > Personally, I think the bigger "problem" is the provider C, the one > > > after B. > > > :) C trying to be reachable by A through B. But that's out of > scope > > I > > > guess. It's too bad, because that's when BGP got interesting, for > > > example. > > > > > > > Provider B has now (currently only for Public User Identities in > the > > > > form of E.164 numbers) the OBLIGATION making this PUI reachable > for > > > > the public by interconnecting with the public network (in this > case > > at > > > > > > > least via the PSTN) [snipped] So IMHO we can assume that provider > B > > > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > > > reachable in principle. > > > > > > I would think that would only be true if you define the AoR to be a > > > public identity in the public domain, and such regulation was to be > > > created for AoRs. E.164 numbers are by definition such numbers, I > > > think. But if, for example, I build a private enterprise network - > > > there's no way I'm obligated to do so just because I use the same > SIP > > > fields AoRs are used in. > > > > > > Having said that, I would think most providers _want_ to make them > > > reachable, because that increases their value. But as the paper > > pointed > > > out, peering is difficult to manage beyond a few hundred peers, nor > do > > > IP or PSTN providers peer with everyone directly to achieve > universal > > > reachability. That's why, for me, the more complex problem is the > > > peer(s) between. But documenting A-B/B-A is a good start. > > > > > > > The NRA normally sets the limits to such an offer. > > > > > > The power of the national rifle association is staggering. ;) > > > > > > -hadriel > > > > > > > > > > > > _______________________________________________ > > > 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 From speermint-bounces@ietf.org Thu Apr 06 04:33:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPvH-0006W4-VZ; Thu, 06 Apr 2006 04:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPvH-0006Vz-GC for speermint@ietf.org; Thu, 06 Apr 2006 04:32:59 -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 1FRPvG-0006cf-7R for speermint@ietf.org; Thu, 06 Apr 2006 04:32:59 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B55241A3C8; Thu, 6 Apr 2006 10:32:55 +0200 (CEST) Date: Thu, 6 Apr 2006 10:32:55 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Reachability Message-ID: <20060406083255.GD12968@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F4@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F4@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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/04/06 09:04, Reinaldo Penno wrote: > > I can have a SIP TLS connection from my house over 5 different backbones > and peer with another proxy server in Japan. That's the fundamental of > Layer 5 peering, no? It is an overlay network over IP. Unless some > carrier/provider has some access list, I wonder what the problem is. > Indeed. If all providers ran open SIP proxies, SPEERMINT would hardly be needed. (Some details on SIP message formats perhaps, but nothing more.) As I see it, the real challenge for SPERRMINT is to find a peering solution in a world where (at least the big) providers run heavily firewalled SIP proxies. /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 Thu Apr 06 04:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPy7-0007tc-Af; Thu, 06 Apr 2006 04:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPy6-0007rQ-JG for speermint@ietf.org; Thu, 06 Apr 2006 04:35:54 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRPy6-0006ju-BF for speermint@ietf.org; Thu, 06 Apr 2006 04:35:54 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 01:35:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,92,1144047600"; d="scan'208"; a="538135779:sNHT23247920" 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] Reachability Date: Thu, 6 Apr 2006 04:35:52 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F6@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZZVMIcz1sL9cnmTIaiN1LPwMOBqwAAErvQ From: "Reinaldo Penno" To: "Otmar Lendl" , 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: , Errors-To: speermint-bounces@ietf.org I understand, but in this specific example A and C _wants_ to peer. Their firewalls would allow such connection. Are you saying B would block it? > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, April 06, 2006 1:33 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > On 2006/04/06 09:04, Reinaldo Penno wrote: > > > > I can have a SIP TLS connection from my house over 5 different backbones > > and peer with another proxy server in Japan. That's the fundamental of > > Layer 5 peering, no? It is an overlay network over IP. Unless some > > carrier/provider has some access list, I wonder what the problem is. > > >=20 > Indeed. >=20 > If all providers ran open SIP proxies, SPEERMINT would hardly be needed. > (Some details on SIP message formats perhaps, but nothing more.) >=20 > As I see it, the real challenge for SPERRMINT is to find a peering > solution in a world where (at least the big) providers run heavily > firewalled SIP proxies. >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 04:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQ46-00011k-Ce; Thu, 06 Apr 2006 04:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQ44-00011f-9X for speermint@ietf.org; Thu, 06 Apr 2006 04:42:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRQ3z-00071K-J7 for speermint@ietf.org; Thu, 06 Apr 2006 04:42:04 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Reachability Date: Thu, 6 Apr 2006 10:45:38 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAIVMxA= From: "Stastny Richard" To: "Reinaldo Penno" , "Lee, Yiu" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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 Reinaldo, > I'm having a hard time understanding the complications...Sorry but I'm > going to ask basic questions again before we dwell in many (more) > discussions. It _seems_ to me we are overly complicating each topic. Yes, yes ;-) My two cents: IMHO we have two basic options in the A-B-C scenario: Assuming that A-B-C are all in the same IP address space (and leaving out for the moment that A and C are in different IP address spaces and B is doing some fancy NAT/MediaGW/SBC ;-) stuff having connections to both spaces.) Option 1: B is only involved in signalling, mediastream is direct A-C Option 2: B is also involved in media stream Option 1: The only task of B is to provide transit of TRUST C is not trusting A, so a cannot place a call directly to C, but B is trusting A and C is trusting B. This is basically what all these "peering" fabrics such as SIPIX and XConnect provide. One should also keep in mind that in most cases the mediastream is not even going A-C, it is going O-UA to T-UA and may not even touch the A and C "networks". This is the case if A and C are only "administrative domains" IMHO this is the first priority case of SPEERMINT to be solved Option 2 implies by definition that the mediastream is going through A and C "networks" in the first place. To do so, the mediastream from O-UA and T-UA has first to be brought into the A and C "networks". This can be done either that they are connected directly or tunnelled into these networks This also implies that they are not by definition in the same address space, but in a private address space of A or C. Reason is of course walled garden, QoS and charging. A and C have first to gateway now the media and signalling from the UAs into a common address space where also B lives. We see, Option 2 is getting quite complicated very fast.=20 (and BTW this is the IMS model solved somewhere else anyway) This is why I want to get Option 1 done first Cheers Richard > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 9:55 AM > To: Stastny Richard; Lee, Yiu; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > I'm having a hard time understanding the complications...Sorry but I'm > going to ask basic questions again before we dwell in many (more) > discussions. It _seems_ to me we are overly complicating each topic. >=20 > Are A and C paying B to carry _IP_ packets (which includes signaling and > media)? Can A send and receive packets from C? So, unless A and C want > something special done to their signaling traffic I wonder what B has to > do with it... Why would I pay B to be a proxy hop if I can send packets > directly? Are A and C concerned with security, or wondering how to peer > directly? Well, then peer directly over a TLS connection. >=20 > Also, I do not understand "transit services" in this context. This is > not the PSTN. We are talking IP backbones, right? >=20 > I'm assuming A has DNS access and so has C. They can figure out by > themselves the "sip route" of the signaling services. There is nothing > SIP related that B can provide that A and C cannot figure out. The > endpoints are in A and C; B does not have control over the E.164 > numbers, ENUM, SIP URIS, etc. >=20 > I can have a SIP TLS connection from my house over 5 different backbones > and peer with another proxy server in Japan. That's the fundamental of > Layer 5 peering, no? It is an overlay network over IP. Unless some > carrier/provider has some access list, I wonder what the problem is. >=20 > Now, maybe I'm missing something, maybe we need to hash out this example > further. >=20 > Regards, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, April 06, 2006 12:05 AM > > To: Lee, Yiu; Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > > > > Inline > > > > > -----Original Message----- > > > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] > > > Sent: Thursday, April 06, 2006 1:22 AM > > > To: Hadriel Kaplan; Stastny Richard; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > This is an interesting thread especially for the scenario A-B-C > where > > B > > > is providing transit services. In near term , I don't see any > operator > > > will like to provide transit services since I don't smell money in > > this > > > area ;-) Also, if A doesn't peer C directly, we have our old friend > > PSTN > > > to do the work (at least working for the voice service). > > > > No, you do NOT have the Good old PSTN to do the work in SPEERMIND > > SPEERMINT (peering, interreconnect; whatever) is not E.164 aware, > > so the PSTN is NOT an Option > > > > > The > > > complication of providing transit services is to guarantee service > > > delivery. In theory, the SIP proxy in B doesn't need to record-route > > > itself so that it can leave the signaling path as soon as A & C > > > establish the session. Reality is B must stay in the signaling path > > > because A signed a peering agreement with B and B signed a peering > > > agreement with C, there is no agreement between A & C and the > > agreement > > > is not transitive. If A sends a mid-dialog request directly to C, > C's > > > policy may probably reject it. For the media flow, I also argue that > > > even if A & C have directly IP peering connectivity, A's media > traffic > > > should flow through B's IP network then to C's IP network. > > > > You are implying L3 peering is atomatically with L5 peering, > > I thought we had this one > > > > > The reason is > > > B signed QoS agreement with A & C, but A & C may not have any, so C > > > won't prioritize the media traffic coming directly from A's IP > peering > > > interface. If the link is congested, the service quality will > degrade. > > > > Implying there is an unneccessary Qos agreement in the core. As the > > Scott > > Marcus paper points out, this is unnecessary in most cases and > > also not controllable. QoS, if at all, is only required in the access. > > > > We should not waste our time with unimplementable issues. > > > > > > > > I think peering is above policy. I assume that this WG will take the > > > lead to define and standardize the peering policy as well as the > > > protocol distributing the policy. > > > > > > Yiu > > > > > > > > > -----Original Message----- > > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > Sent: Sunday, April 02, 2006 9:48 PM > > > To: 'Stastny Richard'; speermint@ietf.org > > > Subject: RE: [Speermint] Reachability > > > > > > Hi Richard, comments inline... > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Saturday, April 01, 2006 2:46 PM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Reachability > > > > > > > > after reading the document from Scott Markus on NGN Interconnect I > > > > referenced for weekend reading in my last posting > > > > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1 > > > > .pdf > > > > > > Indeed that was an interesting paper - thanks for the pointer! (not > > that > > > I agree with everything in it) > > > > > > > and second we always started naturally at provider A in direction > of > > > > call set-up and not at provider B > > > > > > Personally, I think the bigger "problem" is the provider C, the one > > > after B. > > > :) C trying to be reachable by A through B. But that's out of > scope > > I > > > guess. It's too bad, because that's when BGP got interesting, for > > > example. > > > > > > > Provider B has now (currently only for Public User Identities in > the > > > > form of E.164 numbers) the OBLIGATION making this PUI reachable > for > > > > the public by interconnecting with the public network (in this > case > > at > > > > > > > least via the PSTN) [snipped] So IMHO we can assume that provider > B > > > > hosting a Public User Identity (a SIP URI) MUST make this PUI > > > > reachable in principle. > > > > > > I would think that would only be true if you define the AoR to be a > > > public identity in the public domain, and such regulation was to be > > > created for AoRs. E.164 numbers are by definition such numbers, I > > > think. But if, for example, I build a private enterprise network - > > > there's no way I'm obligated to do so just because I use the same > SIP > > > fields AoRs are used in. > > > > > > Having said that, I would think most providers _want_ to make them > > > reachable, because that increases their value. But as the paper > > pointed > > > out, peering is difficult to manage beyond a few hundred peers, nor > do > > > IP or PSTN providers peer with everyone directly to achieve > universal > > > reachability. That's why, for me, the more complex problem is the > > > peer(s) between. But documenting A-B/B-A is a good start. > > > > > > > The NRA normally sets the limits to such an offer. > > > > > > The power of the national rifle association is staggering. ;) > > > > > > -hadriel > > > > > > > > > > > > _______________________________________________ > > > 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 Apr 06 05:08:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQTu-0005NS-4J; Thu, 06 Apr 2006 05:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQTs-0005M1-Vf for speermint@ietf.org; Thu, 06 Apr 2006 05:08: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 1FRQTr-0007qh-MK for speermint@ietf.org; Thu, 06 Apr 2006 05:08:44 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B02181A3C8; Thu, 6 Apr 2006 11:08:42 +0200 (CEST) Date: Thu, 6 Apr 2006 11:08:42 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Reachability Message-ID: <20060406090842.GW28504@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F6@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F6@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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/04/06 10:04, Reinaldo Penno wrote: > I understand, but in this specific example A and C _wants_ to peer. > Their firewalls would allow such connection. Are you saying B would > block it? No, quite the contrary. First of all, I read the A-B-C as a SIP layer diagram. How the actual L3 connectivity is established does not matter. It could be A | B-X-C where X is your favorite L3 provider. (the likes of Level3, Interoute, Sprint, Eurorings, Telia, ...) It may well be that A wants to peer with C and vice versa. But these two might also want to peer with D, E, F, G, ... These set of providers might come to the conclusion that it is more convenient for them to * just open up their firewalls to allow their SIP proxies to talk to B * use B quasi as outbound proxy for calls amoungst each other * pay B some money for that service than to * maintain the firewall settings suitable to enable direct SIP messages. The first option scales with O(n), the second with O(n*n). Linear complexity always wins vs. quadratic as the cardinality of the problem increases. /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 Thu Apr 06 05:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQgB-0007vU-PD; Thu, 06 Apr 2006 05:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRQgA-0007vP-Ks for speermint@ietf.org; Thu, 06 Apr 2006 05:21:26 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRQg9-0008Ob-Bc for speermint@ietf.org; Thu, 06 Apr 2006 05:21:26 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 02:21:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,92,1144047600"; d="scan'208"; a="538141999:sNHT23678982" 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] Reachability Date: Thu, 6 Apr 2006 05:21:23 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F7@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZZWcBpIZiYgHDUTUO5ILACxbQReQAAPxZg From: "Reinaldo Penno" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, your explanation seems quite different than the original question. This seems a quite different ball game, although a valid one. You are talking about a kind of "SIP route reflector". The purpose of the route reflector as you states is to reduce the number of peers.=20 The original question seemed to me related to the one of _trust_. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, April 06, 2006 2:09 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > On 2006/04/06 10:04, Reinaldo Penno wrote: > > I understand, but in this specific example A and C _wants_ to peer. > > Their firewalls would allow such connection. Are you saying B would > > block it? >=20 > No, quite the contrary. >=20 > First of all, I read the A-B-C as a SIP layer diagram. How the > actual L3 connectivity is established does not matter. It could be >=20 > A > | > B-X-C >=20 > where X is your favorite L3 provider. (the likes of Level3, Interoute, > Sprint, Eurorings, Telia, ...) >=20 > It may well be that A wants to peer with C and vice versa. But these > two might also want to peer with D, E, F, G, ... > These set of providers might come to the conclusion that it is more > convenient for them to >=20 > * just open up their firewalls to allow their SIP proxies to talk to B > * use B quasi as outbound proxy for calls amoungst each other > * pay B some money for that service >=20 > than to >=20 > * maintain the firewall settings suitable to enable direct SIP messages. >=20 > The first option scales with O(n), the second with O(n*n). >=20 > Linear complexity always wins vs. quadratic as the cardinality of > the problem increases. >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 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 1FRRGl-0000yA-HF; Thu, 06 Apr 2006 05:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRRGk-0000y5-2C for speermint@ietf.org; Thu, 06 Apr 2006 05:59: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 1FRRGi-0001HD-PK for speermint@ietf.org; Thu, 06 Apr 2006 05:59:14 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 74C551A3C8; Thu, 6 Apr 2006 11:59:11 +0200 (CEST) Date: Thu, 6 Apr 2006 11:59:11 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Reachability Message-ID: <20060406095911.GX28504@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F7@proton.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F7@proton.jnpr.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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/04/06 11:04, Reinaldo Penno wrote: > Okay, your explanation seems quite different than the original question. > This seems a quite different ball game, although a valid one. You are > talking about a kind of "SIP route reflector". The purpose of the route > reflector as you states is to reduce the number of peers. I like the term "SIP route reflector". > The original question seemed to me related to the one of _trust_. Well, in this setting A trusts B to relay only calls from valid providers. So does C. Thus we have trust relationships A-B and B-C. Bbridges the trust such that A and C can talk to each other. /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 Thu Apr 06 07:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRShP-0004GV-3i; Thu, 06 Apr 2006 07:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRShM-0004GQ-U7 for speermint@ietf.org; Thu, 06 Apr 2006 07:30:48 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRShL-0004ie-Le for speermint@ietf.org; Thu, 06 Apr 2006 07:30:48 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id ABE603FC; Thu, 06 Apr 2006 07:30:46 -0400 From: "Patrick Melampy" To: "'Otmar Lendl'" , Subject: RE: [Speermint] Reachability Date: Thu, 6 Apr 2006 07:30:47 -0400 Message-ID: <03d501c6596d$8cf9b440$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZZWbbF0vOGnk3qQiSfmjx7QWNcYgAEs11A In-Reply-To: <20060406090842.GW28504@nic.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Continuing with your example --- A | B-X-C This is very useful. So you're suggesting that B could be paid to help establish a SIP connection between A and C. This of course is what we are trying to figure out in this working group. However, why would anybody with a brain pay B for this service when it is apparent that the media and thus whole purpose of the communication is going from A-X-C? _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 07:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRSzO-0000Ds-Jz; Thu, 06 Apr 2006 07:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRSzN-0000A8-Q8 for speermint@ietf.org; Thu, 06 Apr 2006 07:49: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 1FRSzL-00050y-GT for speermint@ietf.org; Thu, 06 Apr 2006 07:49:25 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8666C1A3C8; Thu, 6 Apr 2006 13:49:22 +0200 (CEST) Date: Thu, 6 Apr 2006 13:49:22 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Reachability Message-ID: <20060406114922.GA28504@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20060406090842.GW28504@nic.at> <03d501c6596d$8cf9b440$9dc8000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03d501c6596d$8cf9b440$9dc8000a@acmepacket.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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/04/06 13:04, Patrick Melampy wrote: > > Continuing with your example --- > A > | > B-X-C > > This is very useful. So you're suggesting that B could be paid to help > establish a SIP connection between A and C. This of course is what we are > trying to figure out in this working group. However, why would anybody with > a brain pay B for this service when it is apparent that the media and thus > whole purpose of the communication is going from A-X-C? In this case, X is just doing layer3 work. X just provides basic IP connectivity between A, B, and C. It is completely ignorant to anything that happens above layer 3. It doesn't even matter whether the picture is in fact A | B-X-Y-C or A |\ B-X-Y-C or even A |\ B-X-C In other words, X could be the public Internet. But going back to you question on why pay B and not just X: X fulfills the role of supplying the L3 connectivity between A and C. B fulfills the role of managing the SIP-layer connectivity between A and C. Those two roles could be played by a single company. I do not rule that out. But when designing any framework it is vitally important to keep the roles separate. Collapsing them in practice is simple. Divvying up a role into separate entities later on is difficult. /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 Thu Apr 06 07:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT2N-00055B-2a; Thu, 06 Apr 2006 07:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT2L-00050q-Ll for speermint@ietf.org; Thu, 06 Apr 2006 07:52:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRT2L-000551-CP for speermint@ietf.org; Thu, 06 Apr 2006 07:52:29 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id A0FB03FC; Thu, 06 Apr 2006 07:52:27 -0400 From: "Patrick Melampy" To: "'Reinaldo Penno'" , "'Stastny Richard'" , "'Lee, Yiu'" , "'Hadriel Kaplan'" , Subject: RE: [Speermint] Reachability Date: Thu, 6 Apr 2006 07:52:28 -0400 Message-ID: <03d601c65970$94d05bd0$9dc8000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAisd/A= In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE5F4@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Reinaldo -- you wrote >Are A and C paying B to carry _IP_ packets (which includes signaling and >media)? I think that a communication with media packets is like a day without sunshine... I think the media packets are what the service is all about. Guarantees, reliability, trust, signaling systems, bi-lateral agreements, service level agreements are all about delivery of media. Nobody would ever pay B if B doesn't carry the communication request. If B only provided a location service, then this business model is very close to what Nuestar is doing with their public ENUM. People do pay for this, but this is not what SPEERMINT is about. >Can A send and receive packets from C? So, unless A and C want >something special done to their signaling traffic I wonder what B has to >do with it... Why would I pay B to be a proxy hop if I can send packets >directly? This is exactly why managing the media flows is so important to these business models. The media must follow the signaling when a communication request goes from A to B to C for B to have any value to A and C. If A and C can interconnect with quality for free (A.K.A. the internet), why would A and C use B? Well -- it is likely because they are unaware of each other -- or B has some special attributes (such as QoS, routing or aggregation) that the internet doesn't have. I also believe that A and C may be telephone companies where the telephone traffic might originate from PSTN phones alongside IP originated calls. These operators have real expenses associated with receiving and terminating a communication request. A and C could not afford to connect to the internet and offer termination services to just anybody. They would rather NOT do this. This is the reason for the bi-lateral agreements. Since they can't have infinity agreements, there is room for aggregating carriers (B in this example). B aggregates signaling, media, and business agreements. If we got rid of the PSTN completely, and all of the regulations in the world, then we can stop worrying about these minor economic issues. I think this is unlikely. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 07:59:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT9R-00082x-T5; Thu, 06 Apr 2006 07:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRT9P-00082s-NE for speermint@ietf.org; Thu, 06 Apr 2006 07:59:47 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRT9M-0005OT-SJ for speermint@ietf.org; Thu, 06 Apr 2006 07:59:47 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1144324783!10464371!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 10373 invoked from network); 6 Apr 2006 11:59:43 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 6 Apr 2006 11:59:43 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F75002C2950; Thu, 6 Apr 2006 07:59: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 Date: Thu, 6 Apr 2006 07:59:42 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C8744B9@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+AACaRd8A== From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Cc: Subject: [Speermint] transit vs peering 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 Richard: I think you are taking "bi-lateral" to mean something more restrictive than I intend. The aspect of concern to me is that traffic is being exchanged between the originating provider and the terminating provider. Whether federations etc are used to establish whatever relationship the parties require is a business issue. In either case this is different from paying a transit provider. Transit is just wholesale. I'm not necessarily against it but it's not peering. The global IP interconnect regime could still be bi-lateral. The scaling issue is not a technical one. What you want to avoid is negotiating interconnection agreements between all possible pairs of parties.=20 Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, April 06, 2006 3:29 AM To: Pfautz, Penn L, NEO; speermint@ietf.org Subject: RE: Background Reading on NGN Interconnect - transit vs peering The problem I have with the FCC definition is that is states that peering is always bi-lateral The major reason for setting up SPEERMINT was that everybody seems at least to agree that bi-lateral peering does not scale globally. And our real goal is to achieve global connectivity and reachability. Maybe the name of the WG is wrong in this context I still believe that the task of SPEERMINT is to show a way forward to overcome these bi-lateral peering. Away forward in this direction are federations, but finally we should lay the framework for a global IP Interconnect regime, at least protocol wise It is obvious that this cannot be done only by protocols in a vacuum, so I fully agree that co-operation with other standard bodies e.g. ITU-T and national authorities=20 will be required. If all communication networks are finally migrated to IP, an IP Interconnect regime is required. The problem here is that currently there are national interconnect regimes and the international regime on top (hierarchical) as default. The new regime allows global direct interconnect, mixing up the current national and international regimes. In many countries national forums are popping up (e.g. in UK and Germany) talking=20 about IP-based interconnect (with or without L3 peering). But=20 they still need to recognize that this is only half of the picture. Some of these discussions are going around in circles (like the discussions here? ;-). Maybe one task of SPEERMINT could also be to make scenarios and BCP, showing what works and what not and why not, saving these other bodies some time on useless discussions on not implementable or non-scalable models. Richard > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Wednesday, April 05, 2006 5:12 PM > To: Stastny Richard; speermint@ietf.org > Subject: Background Reading on NGN Interconnect - transit vs peering >=20 > Richard: > Thanks for posting this. I recommend it to all. In particular we ought > to pay attention to the definition of peering versus transit offered by > the US FCC and cited in the Marcus paper: >=20 > Peering is an agreement between ISPs to carry traffic for each > other and for their respective > customers. Peering does not include the obligation to carry > traffic to third parties. Peering is usually a > bilateral business and technical arrangement, where two > providers agree to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... >=20 > Transit is an agreement where an ISP agrees to carry traffic on > behalf of another ISP or end user. In > most cases transit will include an obligation to carry traffic > to third parties. Transit is usually a > bilateral business and technical arrangement, where one provider > (the transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end > user (the customer). In most cases, the > transit provider carries traffic to and from its other > customers, and to and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, > installation support, local telecom provisioning, > and Network Operations Center (NOC) support. >=20 > While we NEED not accept this definition I think it does reflect the > reality of layer 3 peering and it will not be helpful to use a > definition for layer 5 that is at odds with layer 3 since that's what > people are familiar with. > If the will of the WG is to include transit in our charter that's fine - > but not an excuse for calling apples and oranges both apples. If, at the > end of the day, there are no important differences in how we treat the > two cases - which I doubt - then life is good. >=20 > We also ought to be thinking about how what Speermint is working on > relates to what's going on in other bodies, e.g. the ITU. (yes, I said > it, we're not alone on the planet :-) Is what we want to do an enabling > piece of what NGN folks are looking toward or is it a fundamentally > different animal? From the discussion on the list and at the IETF I'm > not entirely sure. >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 31, 2006 3:59 PM > To: speermint@ietf.org > Subject: [Speermint] Background Reading on NGN Interconnect >=20 > Folks, >=20 > Weekend reading >=20 > Since we obviosly are dealing more with NGN Interconnect in Speermint, > I recommend everybody on this this list to read the excellent Background > Paper > from Scott Marcus - Interconnection in an IP-based NGN Environment > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.p > df >=20 > to his presentation > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-2 > 006.ppt > given at the ITU-T Workshop last week > What Rules for Ip-eneabled NGNs? > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml >=20 > The agenda and some other excellent presentations can be downloaded from > here: > http://www.itu.int/osg/spu/ngn/presentations.html >=20 > In addition I would also like to point to a CEPT ECC Draft Report > on the Future on Numbering, tabled for the next ITU-T SG2 Meeting > as TD 198-GEN. > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 2 > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > The document is in public consultation and not final yet. > It contains also some statements regarding termination rates. >=20 > The paper from Scott is on-topic regarding the current discussion here > and dealing with both the European and US situation >=20 > Scott Marcus is currently living in Europe, but in his former life > he was Senior Advisor to the FCC and also CTO for GTE Interworking, > so his knowledge is not only theoretical. >=20 > In the document also contains a definition on peering and transit from > the FCC is given: >=20 > The two most prevalent forms of Internet interconnection are peering and > transit. For a definition of these > terms, we turn to a publication of the Network Reliability and > Interoperability Council (NRIC), an industry > advisory panel to the U.S. FCC: >=20 > Peering is an agreement between ISPs to carry traffic for each other and > for their respective > customers. Peering does not include the obligation to carry traffic to > third parties. Peering is usually a > bilateral business and technical arrangement, where two providers agree > to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... >=20 > Transit is an agreement where an ISP agrees to carry traffic on behalf > of another ISP or end user. In > most cases transit will include an obligation to carry traffic to third > parties. Transit is usually a > bilateral business and technical arrangement, where one provider (the > transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end user > (the customer). In most cases, the > transit provider carries traffic to and from its other customers, and to > and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, installation > support, local telecom provisioning, > and Network Operations Center (NOC) support. >=20 > Peering thus offers a provider access only to a single provider's > customers. Transit, by contrast, > usually provides access at a predictable price to the entire Internet. > ... Historically, peering has often > been done on a bill-and-keep basis, without cash payments. Peering where > there is no explicit > exchange of money between parties, and where each party supports part of > the cost of the > interconnect, ... is typically used where both parties perceive a > roughly equal exchange of value. > Peering therefore is fundamentally a barter relationship >=20 > Here the Executive Summary of the paper: >=20 > This report considers the likely evolution of interconnection > arrangements in the context of IP-based Next > Generation Networks (NGNs). >=20 > The NGN represents a synthesis of existing world of the "traditional" > Public Switched Telephone Network > (PSTN) with the world of the Internet. The economic and regulatory > arrangements for the two have > historically been very different. What should happen when these two > worlds collide? >=20 > Many of the networks created over the past ten years contain most of the > key elements of an NGN. Most, if > not all, of the technology necessary for IP-based NGN interconnection > has been available for five to ten > years. Advanced approaches to interconnection have been slow to deploy, > even where the technology has > been mature or within hailing distance of maturity. >=20 > The NGN interconnection problem is best understood, not as a problem of > technology, but rather as a > problem in economics. With that in mind, this report seeks to review > what is known about interconnection > from an economic perspective, in order to reach conclusions about the > prospects for deployment going > forward and the corresponding implications for policymakers. >=20 > A substantial body of economic theory has been developed over the past > decade as regards interconnection in > the traditional PSTN. A smaller body of solid economic research has > emerged in regard to interconnection of > IP-based networks. At the level of economic theory, the PSTN and the > Internet are not worlds apart. > Economics provides the necessary bridge between the two worlds, > illuminating both the similarities and the > differences in these two environments. >=20 > This report begins by laying out, for the most part at a non-technical > level, the established theory of > interconnection, for both the PSTN and the Internet. Wholesale and > retail arrangements are considered > separately. Most of the observed behavior of these economic networks can > be explained in terms of a > constellation of known economic effects: market power, the termination > monopoly, demand elasticity, > network exernalities, transaction costs, service differentiation, price > discrimination, and the Coase theorem > (which says that private parties can often negotiate arrangements more > efficiently than government > regulators, provided that necessary preconditions have been met). >=20 > With this theory in hand, the report considers the implications for the > deployment of differentiated Quality of > Service, and of universal service. We also consider the implications of > IP-based technology - with the > layering, and the changes in industry structure that it implies - > service providers become independent of the > network, but neither is well equipped to measure or to charge for the > other's resource consumption. > The last section of the report represents a hypothetical scenario, a > "thought experiment", where the historic > wired and mobile incumbent of European country upgrades its networks to > an IP-based NGN. We consider > the likely results in terms of regulation of the access network, and of > interconnection; likely domestic and > international interconnection arrangements; and the implications for > ubiquitous support of QoS. Key findings > include: > * Provided that markets for Internet transit and for consumer broadband > Internet access are effectively > competitive, a "Coasian" interconnection regime is likely to be more > efficient, and more consistent > with consumer welfare, than a regulated regime. > * Conversely, where these markets are not effectively competitive, > mandates for interconnection at the > IP level may prove to be unavoidable, particularly once existing PSTN > interconnection is withdrawn. > The migration to NGN potentially creates new sources of market power, at > the same time that it > creates new possibilities for competition. > * Policymakers might consequently be well advised to focus their > attention first on ensuring > competitive markets, and only secondarily on interconnection. >=20 > Current Calling Party's Network Pays (CPNP) arrangements contain a > number of implicit subsidies. In the > world of the NGN, where services providers and networks operators may be > different entities, these > subsidies need major re-thinking - call termination payments that were > intended to finance the terminating > network would, by default, flow to independent VoIP service provides who > have no network to support. In > the absence of termination fees, independent VoIP providers would tend > to compete price levels for > telephony service, independent of the network, down to levels not > greatly above cost, which would appear to > be a societally desirable outcome. >=20 > The thought experiment does not flatly preclude the possibility that > governments might somehow erect a > new system of subsidies to replace the old, but it suggests that any > subsidy system will be difficult to sustain > over time in the face of new forms of competition enabled by the > IP-based NGN - all provided, once again, > that underlying markets (especially for wholesale Internet transit and > for retail Internet broadband access) > remain effectively competitive. A system of Coasian private > arrangements, in the absence of vertically > integrated competitive bottlenecks, seems likely to lead to unsubsidized > arrangements at wholesale and retail > price levels not greatly in excess of cost. >=20 > cheer > Richard >=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 Apr 06 08:17:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTQO-0005Qj-I2; Thu, 06 Apr 2006 08:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTQN-0005Qe-5Q for speermint@ietf.org; Thu, 06 Apr 2006 08:17:19 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRTQJ-0006iE-Sc for speermint@ietf.org; Thu, 06 Apr 2006 08:17:19 -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 Date: Thu, 6 Apr 2006 14:21:17 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4974@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+AACaRd8AAA0Eq2 From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Cc: Subject: [Speermint] Re: transit vs peering 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, =20 I think we should start from even one step further back: =20 I always hear here that there is "traffic" exchanged between "Provider A" or Provider "B", which requires some kind of settlement This implies IMHO "bulk traffic" i.e. media, which in turn implies the media is also touching "entites" of the providers In the Internet model the bulk traffic is exchanged between the UA. =20 In L5 peering the only traffic exchanged is signalling traffic and I do not think there is any volume to cause settlement for "traffic" =20 There is always an intrinsic mix-up of L5 and L3 peering IMHO we should be very careful in our wording =20 Within the scope of SPEERMINT we should never user the term "traffic" standalone, only in context with signalling (L5) traffic or media (L3) traffic. and we should also make clear where these "traffics" originate and terminate. =20 Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.04.2006 13:59 An: Stastny Richard; speermint@ietf.org Betreff: transit vs peering Richard: I think you are taking "bi-lateral" to mean something more restrictive than I intend. The aspect of concern to me is that traffic is being exchanged between the originating provider and the terminating provider. Whether federations etc are used to establish whatever relationship the parties require is a business issue. In either case this is different from paying a transit provider. Transit is just wholesale. I'm not necessarily against it but it's not peering. The global IP interconnect regime could still be bi-lateral. The scaling issue is not a technical one. What you want to avoid is negotiating interconnection agreements between all possible pairs of parties. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, April 06, 2006 3:29 AM To: Pfautz, Penn L, NEO; speermint@ietf.org Subject: RE: Background Reading on NGN Interconnect - transit vs peering The problem I have with the FCC definition is that is states that peering is always bi-lateral The major reason for setting up SPEERMINT was that everybody seems at least to agree that bi-lateral peering does not scale globally. And our real goal is to achieve global connectivity and reachability. Maybe the name of the WG is wrong in this context I still believe that the task of SPEERMINT is to show a way forward to overcome these bi-lateral peering. Away forward in this direction are federations, but finally we should lay the framework for a global IP Interconnect regime, at least protocol wise It is obvious that this cannot be done only by protocols in a vacuum, so I fully agree that co-operation with other standard bodies e.g. ITU-T and national authorities will be required. If all communication networks are finally migrated to IP, an IP Interconnect regime is required. The problem here is that currently there are national interconnect regimes and the international regime on top (hierarchical) as default. The new regime allows global direct interconnect, mixing up the current national and international regimes. In many countries national forums are popping up (e.g. in UK and Germany) talking about IP-based interconnect (with or without L3 peering). But they still need to recognize that this is only half of the picture. Some of these discussions are going around in circles (like the discussions here? ;-). Maybe one task of SPEERMINT could also be to make scenarios and BCP, showing what works and what not and why not, saving these other bodies some time on useless discussions on not implementable or non-scalable models. Richard > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Wednesday, April 05, 2006 5:12 PM > To: Stastny Richard; speermint@ietf.org > Subject: Background Reading on NGN Interconnect - transit vs peering > > Richard: > Thanks for posting this. I recommend it to all. In particular we ought > to pay attention to the definition of peering versus transit offered by > the US FCC and cited in the Marcus paper: > > Peering is an agreement between ISPs to carry traffic for each > other and for their respective > customers. Peering does not include the obligation to carry > traffic to third parties. Peering is usually a > bilateral business and technical arrangement, where two > providers agree to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... > > Transit is an agreement where an ISP agrees to carry traffic on > behalf of another ISP or end user. In > most cases transit will include an obligation to carry traffic > to third parties. Transit is usually a > bilateral business and technical arrangement, where one provider > (the transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end > user (the customer). In most cases, the > transit provider carries traffic to and from its other > customers, and to and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, > installation support, local telecom provisioning, > and Network Operations Center (NOC) support. > > While we NEED not accept this definition I think it does reflect the > reality of layer 3 peering and it will not be helpful to use a > definition for layer 5 that is at odds with layer 3 since that's what > people are familiar with. > If the will of the WG is to include transit in our charter that's fine - > but not an excuse for calling apples and oranges both apples. If, at the > end of the day, there are no important differences in how we treat the > two cases - which I doubt - then life is good. > > We also ought to be thinking about how what Speermint is working on > relates to what's going on in other bodies, e.g. the ITU. (yes, I said > it, we're not alone on the planet :-) Is what we want to do an enabling > piece of what NGN folks are looking toward or is it a fundamentally > different animal? From the discussion on the list and at the IETF I'm > not entirely sure. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 31, 2006 3:59 PM > To: speermint@ietf.org > Subject: [Speermint] Background Reading on NGN Interconnect > > Folks, > > Weekend reading > > Since we obviosly are dealing more with NGN Interconnect in Speermint, > I recommend everybody on this this list to read the excellent Background > Paper > from Scott Marcus - Interconnection in an IP-based NGN Environment > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.p > df > > to his presentation > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-2 > 006.ppt > given at the ITU-T Workshop last week > What Rules for Ip-eneabled NGNs? > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml > > The agenda and some other excellent presentations can be downloaded from > here: > http://www.itu.int/osg/spu/ngn/presentations.html > > In addition I would also like to point to a CEPT ECC Draft Report > on the Future on Numbering, tabled for the next ITU-T SG2 Meeting > as TD 198-GEN. > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 2 > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > The document is in public consultation and not final yet. > It contains also some statements regarding termination rates. > > The paper from Scott is on-topic regarding the current discussion here > and dealing with both the European and US situation > > Scott Marcus is currently living in Europe, but in his former life > he was Senior Advisor to the FCC and also CTO for GTE Interworking, > so his knowledge is not only theoretical. > > In the document also contains a definition on peering and transit from > the FCC is given: > > The two most prevalent forms of Internet interconnection are peering and > transit. For a definition of these > terms, we turn to a publication of the Network Reliability and > Interoperability Council (NRIC), an industry > advisory panel to the U.S. FCC: > > Peering is an agreement between ISPs to carry traffic for each other and > for their respective > customers. Peering does not include the obligation to carry traffic to > third parties. Peering is usually a > bilateral business and technical arrangement, where two providers agree > to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... > > Transit is an agreement where an ISP agrees to carry traffic on behalf > of another ISP or end user. In > most cases transit will include an obligation to carry traffic to third > parties. Transit is usually a > bilateral business and technical arrangement, where one provider (the > transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end user > (the customer). In most cases, the > transit provider carries traffic to and from its other customers, and to > and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, installation > support, local telecom provisioning, > and Network Operations Center (NOC) support. > > Peering thus offers a provider access only to a single provider's > customers. Transit, by contrast, > usually provides access at a predictable price to the entire Internet. > ... Historically, peering has often > been done on a bill-and-keep basis, without cash payments. Peering where > there is no explicit > exchange of money between parties, and where each party supports part of > the cost of the > interconnect, ... is typically used where both parties perceive a > roughly equal exchange of value. > Peering therefore is fundamentally a barter relationship > > Here the Executive Summary of the paper: > > This report considers the likely evolution of interconnection > arrangements in the context of IP-based Next > Generation Networks (NGNs). > > The NGN represents a synthesis of existing world of the "traditional" > Public Switched Telephone Network > (PSTN) with the world of the Internet. The economic and regulatory > arrangements for the two have > historically been very different. What should happen when these two > worlds collide? > > Many of the networks created over the past ten years contain most of the > key elements of an NGN. Most, if > not all, of the technology necessary for IP-based NGN interconnection > has been available for five to ten > years. Advanced approaches to interconnection have been slow to deploy, > even where the technology has > been mature or within hailing distance of maturity. > > The NGN interconnection problem is best understood, not as a problem of > technology, but rather as a > problem in economics. With that in mind, this report seeks to review > what is known about interconnection > from an economic perspective, in order to reach conclusions about the > prospects for deployment going > forward and the corresponding implications for policymakers. > > A substantial body of economic theory has been developed over the past > decade as regards interconnection in > the traditional PSTN. A smaller body of solid economic research has > emerged in regard to interconnection of > IP-based networks. At the level of economic theory, the PSTN and the > Internet are not worlds apart. > Economics provides the necessary bridge between the two worlds, > illuminating both the similarities and the > differences in these two environments. > > This report begins by laying out, for the most part at a non-technical > level, the established theory of > interconnection, for both the PSTN and the Internet. Wholesale and > retail arrangements are considered > separately. Most of the observed behavior of these economic networks can > be explained in terms of a > constellation of known economic effects: market power, the termination > monopoly, demand elasticity, > network exernalities, transaction costs, service differentiation, price > discrimination, and the Coase theorem > (which says that private parties can often negotiate arrangements more > efficiently than government > regulators, provided that necessary preconditions have been met). > > With this theory in hand, the report considers the implications for the > deployment of differentiated Quality of > Service, and of universal service. We also consider the implications of > IP-based technology - with the > layering, and the changes in industry structure that it implies - > service providers become independent of the > network, but neither is well equipped to measure or to charge for the > other's resource consumption. > The last section of the report represents a hypothetical scenario, a > "thought experiment", where the historic > wired and mobile incumbent of European country upgrades its networks to > an IP-based NGN. We consider > the likely results in terms of regulation of the access network, and of > interconnection; likely domestic and > international interconnection arrangements; and the implications for > ubiquitous support of QoS. Key findings > include: > * Provided that markets for Internet transit and for consumer broadband > Internet access are effectively > competitive, a "Coasian" interconnection regime is likely to be more > efficient, and more consistent > with consumer welfare, than a regulated regime. > * Conversely, where these markets are not effectively competitive, > mandates for interconnection at the > IP level may prove to be unavoidable, particularly once existing PSTN > interconnection is withdrawn. > The migration to NGN potentially creates new sources of market power, at > the same time that it > creates new possibilities for competition. > * Policymakers might consequently be well advised to focus their > attention first on ensuring > competitive markets, and only secondarily on interconnection. > > Current Calling Party's Network Pays (CPNP) arrangements contain a > number of implicit subsidies. In the > world of the NGN, where services providers and networks operators may be > different entities, these > subsidies need major re-thinking - call termination payments that were > intended to finance the terminating > network would, by default, flow to independent VoIP service provides who > have no network to support. In > the absence of termination fees, independent VoIP providers would tend > to compete price levels for > telephony service, independent of the network, down to levels not > greatly above cost, which would appear to > be a societally desirable outcome. > > The thought experiment does not flatly preclude the possibility that > governments might somehow erect a > new system of subsidies to replace the old, but it suggests that any > subsidy system will be difficult to sustain > over time in the face of new forms of competition enabled by the > IP-based NGN - all provided, once again, > that underlying markets (especially for wholesale Internet transit and > for retail Internet broadband access) > remain effectively competitive. A system of Coasian private > arrangements, in the absence of vertically > integrated competitive bottlenecks, seems likely to lead to unsubsidized > arrangements at wholesale and retail > price levels not greatly in excess of cost. > > cheer > 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 Apr 06 08:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTXm-0001Ch-2z; Thu, 06 Apr 2006 08:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTXj-0001Cc-Vw for speermint@ietf.org; Thu, 06 Apr 2006 08:24:55 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRTXj-0006os-Ar for speermint@ietf.org; Thu, 06 Apr 2006 08:24:55 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-8.tower-121.messagelabs.com!1144326165!8895141!33 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26866 invoked from network); 6 Apr 2006 12:24:54 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-8.tower-121.messagelabs.com with SMTP; 6 Apr 2006 12:24:54 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F75002C3710; Thu, 6 Apr 2006 08:24:54 -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: Thu, 6 Apr 2006 08:24:52 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C8744F8@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4974@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+AACaRd8AAA0Eq2AABK6lA= From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Cc: Subject: [Speermint] RE: transit vs peering 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 heartily agree with the need to keep layer 3 and layer 5 clear in our discussions. But I don't think they necessarily correspond to media versus signaling. Also, although I personally, think intercarrier compensation is a swamp that I 'd like to stay out of, in the US carriers do charge each other for signaling traffic under certain circumstances. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Thursday, April 06, 2006 8:21 AM To: Pfautz, Penn L, NEO; speermint@ietf.org Subject: Re: transit vs peering Penn, =20 I think we should start from even one step further back: =20 I always hear here that there is "traffic" exchanged between "Provider A" or Provider "B", which requires some kind of settlement This implies IMHO "bulk traffic" i.e. media, which in turn implies the media is also touching "entites" of the providers In the Internet model the bulk traffic is exchanged between the UA. =20 In L5 peering the only traffic exchanged is signalling traffic and I do not think there is any volume to cause settlement for "traffic" =20 There is always an intrinsic mix-up of L5 and L3 peering IMHO we should be very careful in our wording =20 Within the scope of SPEERMINT we should never user the term "traffic" standalone, only in context with signalling (L5) traffic or media (L3) traffic. and we should also make clear where these "traffics" originate and terminate. =20 Richard ________________________________ Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Gesendet: Do 06.04.2006 13:59 An: Stastny Richard; speermint@ietf.org Betreff: transit vs peering Richard: I think you are taking "bi-lateral" to mean something more restrictive than I intend. The aspect of concern to me is that traffic is being exchanged between the originating provider and the terminating provider. Whether federations etc are used to establish whatever relationship the parties require is a business issue. In either case this is different from paying a transit provider. Transit is just wholesale. I'm not necessarily against it but it's not peering. The global IP interconnect regime could still be bi-lateral. The scaling issue is not a technical one. What you want to avoid is negotiating interconnection agreements between all possible pairs of parties. Penn -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Thursday, April 06, 2006 3:29 AM To: Pfautz, Penn L, NEO; speermint@ietf.org Subject: RE: Background Reading on NGN Interconnect - transit vs peering The problem I have with the FCC definition is that is states that peering is always bi-lateral The major reason for setting up SPEERMINT was that everybody seems at least to agree that bi-lateral peering does not scale globally. And our real goal is to achieve global connectivity and reachability. Maybe the name of the WG is wrong in this context I still believe that the task of SPEERMINT is to show a way forward to overcome these bi-lateral peering. Away forward in this direction are federations, but finally we should lay the framework for a global IP Interconnect regime, at least protocol wise It is obvious that this cannot be done only by protocols in a vacuum, so I fully agree that co-operation with other standard bodies e.g. ITU-T and national authorities will be required. If all communication networks are finally migrated to IP, an IP Interconnect regime is required. The problem here is that currently there are national interconnect regimes and the international regime on top (hierarchical) as default. The new regime allows global direct interconnect, mixing up the current national and international regimes. In many countries national forums are popping up (e.g. in UK and Germany) talking about IP-based interconnect (with or without L3 peering). But they still need to recognize that this is only half of the picture. Some of these discussions are going around in circles (like the discussions here? ;-). Maybe one task of SPEERMINT could also be to make scenarios and BCP, showing what works and what not and why not, saving these other bodies some time on useless discussions on not implementable or non-scalable models. Richard > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Wednesday, April 05, 2006 5:12 PM > To: Stastny Richard; speermint@ietf.org > Subject: Background Reading on NGN Interconnect - transit vs peering > > Richard: > Thanks for posting this. I recommend it to all. In particular we ought > to pay attention to the definition of peering versus transit offered by > the US FCC and cited in the Marcus paper: > > Peering is an agreement between ISPs to carry traffic for each > other and for their respective > customers. Peering does not include the obligation to carry > traffic to third parties. Peering is usually a > bilateral business and technical arrangement, where two > providers agree to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... > > Transit is an agreement where an ISP agrees to carry traffic on > behalf of another ISP or end user. In > most cases transit will include an obligation to carry traffic > to third parties. Transit is usually a > bilateral business and technical arrangement, where one provider > (the transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end > user (the customer). In most cases, the > transit provider carries traffic to and from its other > customers, and to and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, > installation support, local telecom provisioning, > and Network Operations Center (NOC) support. > > While we NEED not accept this definition I think it does reflect the > reality of layer 3 peering and it will not be helpful to use a > definition for layer 5 that is at odds with layer 3 since that's what > people are familiar with. > If the will of the WG is to include transit in our charter that's fine - > but not an excuse for calling apples and oranges both apples. If, at the > end of the day, there are no important differences in how we treat the > two cases - which I doubt - then life is good. > > We also ought to be thinking about how what Speermint is working on > relates to what's going on in other bodies, e.g. the ITU. (yes, I said > it, we're not alone on the planet :-) Is what we want to do an enabling > piece of what NGN folks are looking toward or is it a fundamentally > different animal? From the discussion on the list and at the IETF I'm > not entirely sure. > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, March 31, 2006 3:59 PM > To: speermint@ietf.org > Subject: [Speermint] Background Reading on NGN Interconnect > > Folks, > > Weekend reading > > Since we obviosly are dealing more with NGN Interconnect in Speermint, > I recommend everybody on this this list to read the excellent Background > Paper > from Scott Marcus - Interconnection in an IP-based NGN Environment > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1.p > df > > to his presentation > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus-23-march-2 > 006.ppt > given at the ITU-T Workshop last week > What Rules for Ip-eneabled NGNs? > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml > > The agenda and some other excellent presentations can be downloaded from > here: > http://www.itu.int/osg/spu/ngn/presentations.html > > In addition I would also like to point to a CEPT ECC Draft Report > on the Future on Numbering, tabled for the next ITU-T SG2 Meeting > as TD 198-GEN. > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero.dk/27132= 2 > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > The document is in public consultation and not final yet. > It contains also some statements regarding termination rates. > > The paper from Scott is on-topic regarding the current discussion here > and dealing with both the European and US situation > > Scott Marcus is currently living in Europe, but in his former life > he was Senior Advisor to the FCC and also CTO for GTE Interworking, > so his knowledge is not only theoretical. > > In the document also contains a definition on peering and transit from > the FCC is given: > > The two most prevalent forms of Internet interconnection are peering and > transit. For a definition of these > terms, we turn to a publication of the Network Reliability and > Interoperability Council (NRIC), an industry > advisory panel to the U.S. FCC: > > Peering is an agreement between ISPs to carry traffic for each other and > for their respective > customers. Peering does not include the obligation to carry traffic to > third parties. Peering is usually a > bilateral business and technical arrangement, where two providers agree > to accept traffic from one > another, and from one another's customers (and thus from their > customers' customers). ... > > Transit is an agreement where an ISP agrees to carry traffic on behalf > of another ISP or end user. In > most cases transit will include an obligation to carry traffic to third > parties. Transit is usually a > bilateral business and technical arrangement, where one provider (the > transit provider) agrees to carry > traffic to third parties on behalf of another provider or an end user > (the customer). In most cases, the > transit provider carries traffic to and from its other customers, and to > and from every destination on > the Internet, as part of the transit arrangement. In a transit > agreement, the ISP often also provides > ancillary services, such as Service Level Agreements, installation > support, local telecom provisioning, > and Network Operations Center (NOC) support. > > Peering thus offers a provider access only to a single provider's > customers. Transit, by contrast, > usually provides access at a predictable price to the entire Internet. > ... Historically, peering has often > been done on a bill-and-keep basis, without cash payments. Peering where > there is no explicit > exchange of money between parties, and where each party supports part of > the cost of the > interconnect, ... is typically used where both parties perceive a > roughly equal exchange of value. > Peering therefore is fundamentally a barter relationship > > Here the Executive Summary of the paper: > > This report considers the likely evolution of interconnection > arrangements in the context of IP-based Next > Generation Networks (NGNs). > > The NGN represents a synthesis of existing world of the "traditional" > Public Switched Telephone Network > (PSTN) with the world of the Internet. The economic and regulatory > arrangements for the two have > historically been very different. What should happen when these two > worlds collide? > > Many of the networks created over the past ten years contain most of the > key elements of an NGN. Most, if > not all, of the technology necessary for IP-based NGN interconnection > has been available for five to ten > years. Advanced approaches to interconnection have been slow to deploy, > even where the technology has > been mature or within hailing distance of maturity. > > The NGN interconnection problem is best understood, not as a problem of > technology, but rather as a > problem in economics. With that in mind, this report seeks to review > what is known about interconnection > from an economic perspective, in order to reach conclusions about the > prospects for deployment going > forward and the corresponding implications for policymakers. > > A substantial body of economic theory has been developed over the past > decade as regards interconnection in > the traditional PSTN. A smaller body of solid economic research has > emerged in regard to interconnection of > IP-based networks. At the level of economic theory, the PSTN and the > Internet are not worlds apart. > Economics provides the necessary bridge between the two worlds, > illuminating both the similarities and the > differences in these two environments. > > This report begins by laying out, for the most part at a non-technical > level, the established theory of > interconnection, for both the PSTN and the Internet. Wholesale and > retail arrangements are considered > separately. Most of the observed behavior of these economic networks can > be explained in terms of a > constellation of known economic effects: market power, the termination > monopoly, demand elasticity, > network exernalities, transaction costs, service differentiation, price > discrimination, and the Coase theorem > (which says that private parties can often negotiate arrangements more > efficiently than government > regulators, provided that necessary preconditions have been met). > > With this theory in hand, the report considers the implications for the > deployment of differentiated Quality of > Service, and of universal service. We also consider the implications of > IP-based technology - with the > layering, and the changes in industry structure that it implies - > service providers become independent of the > network, but neither is well equipped to measure or to charge for the > other's resource consumption. > The last section of the report represents a hypothetical scenario, a > "thought experiment", where the historic > wired and mobile incumbent of European country upgrades its networks to > an IP-based NGN. We consider > the likely results in terms of regulation of the access network, and of > interconnection; likely domestic and > international interconnection arrangements; and the implications for > ubiquitous support of QoS. Key findings > include: > * Provided that markets for Internet transit and for consumer broadband > Internet access are effectively > competitive, a "Coasian" interconnection regime is likely to be more > efficient, and more consistent > with consumer welfare, than a regulated regime. > * Conversely, where these markets are not effectively competitive, > mandates for interconnection at the > IP level may prove to be unavoidable, particularly once existing PSTN > interconnection is withdrawn. > The migration to NGN potentially creates new sources of market power, at > the same time that it > creates new possibilities for competition. > * Policymakers might consequently be well advised to focus their > attention first on ensuring > competitive markets, and only secondarily on interconnection. > > Current Calling Party's Network Pays (CPNP) arrangements contain a > number of implicit subsidies. In the > world of the NGN, where services providers and networks operators may be > different entities, these > subsidies need major re-thinking - call termination payments that were > intended to finance the terminating > network would, by default, flow to independent VoIP service provides who > have no network to support. In > the absence of termination fees, independent VoIP providers would tend > to compete price levels for > telephony service, independent of the network, down to levels not > greatly above cost, which would appear to > be a societally desirable outcome. > > The thought experiment does not flatly preclude the possibility that > governments might somehow erect a > new system of subsidies to replace the old, but it suggests that any > subsidy system will be difficult to sustain > over time in the face of new forms of competition enabled by the > IP-based NGN - all provided, once again, > that underlying markets (especially for wholesale Internet transit and > for retail Internet broadband access) > remain effectively competitive. A system of Coasian private > arrangements, in the absence of vertically > integrated competitive bottlenecks, seems likely to lead to unsubsidized > arrangements at wholesale and retail > price levels not greatly in excess of cost. > > cheer > 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 Apr 06 10:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVlr-0003WW-Bp; Thu, 06 Apr 2006 10:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVlp-0003WR-V9 for speermint@ietf.org; Thu, 06 Apr 2006 10:47:37 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRVlm-00028z-2m for speermint@ietf.org; Thu, 06 Apr 2006 10:47:37 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 10:47:33 -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] Notation? Date: Thu, 6 Apr 2006 10:47:33 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A432@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Notation? thread-index: AcZZcIWwToso1IqzSQSeBYyPa0I9BwAEbeIw From: "Medhavi Bhatia" To: "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 14:47:33.0423 (UTC) FILETIME=[09AAFBF0:01C65989] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 need to formalize the notation for L5 peering and L3 peering. For example, when we write: A | B-X-C It is not obvious to me who are the L5 peers and who are the L3 peers. X could be an internet provider for B/C and there could be many of those. Signaling between B and C could be going through a different provider (say Y, which may or may not be L5 aware). Also interconnect SPs may sit in the middle (and frankly I think it is not worthwhile the debate how they get paid. They exist today because of market/regulatory reasons and disregarding them could be fatal in my opinion). Another thing we can do is to place the IXP in []. So it looks like as follows: A--[B]--C | X Any thoughts/comments?=20 -Medhavi. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, April 06, 2006 7:49 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > On 2006/04/06 13:04, Patrick Melampy wrote: > > > > Continuing with your example --- > > A > > | > > B-X-C > > > > This is very useful. So you're suggesting that B could be paid to help > > establish a SIP connection between A and C. This of course is what we are > > trying to figure out in this working group. However, why would anybody with > > a brain pay B for this service when it is apparent that the media and thus > > whole purpose of the communication is going from A-X-C? >=20 > In this case, X is just doing layer3 work. X just provides basic IP > connectivity between A, B, and C. It is completely ignorant to anything > that happens above layer 3. >=20 > It doesn't even matter whether the picture is in fact >=20 > A > | > B-X-Y-C >=20 > or > A > |\ > B-X-Y-C >=20 > or even >=20 > A > |\ > B-X-C >=20 > In other words, X could be the public Internet. >=20 > But going back to you question on why pay B and not just X: >=20 > X fulfills the role of supplying the L3 connectivity between A and C. > B fulfills the role of managing the SIP-layer connectivity between A and C. >=20 > Those two roles could be played by a single company. I do not > rule that out. >=20 > But when designing any framework it is vitally important to keep > the roles separate. Collapsing them in practice is simple. Divvying > up a role into separate entities later on is difficult. >=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 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 10:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVpH-0005Or-Ko; Thu, 06 Apr 2006 10:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVpG-0005Om-I3 for speermint@ietf.org; Thu, 06 Apr 2006 10:51:10 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRVpG-0002D1-9I for speermint@ietf.org; Thu, 06 Apr 2006 10:51:10 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1144335008!8994326!12 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14709 invoked from network); 6 Apr 2006 14:51:06 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-7.tower-121.messagelabs.com with SMTP; 6 Apr 2006 14:51:06 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F75002CB1C9; Thu, 6 Apr 2006 10:51: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] Notation? Date: Thu, 6 Apr 2006 10:51:04 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C874789@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <8812D8156467224C9E9739E513037EF155A432@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Notation? Thread-Index: AcZZcIWwToso1IqzSQSeBYyPa0I9BwAEbeIwAAHOmtA= From: "Pfautz, Penn L, NEO" To: "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Can you define what you mean by IXP in this case? This seems to be another term that gets tossed around. -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com]=20 Sent: Thursday, April 06, 2006 10:48 AM To: Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] Notation? I think we need to formalize the notation for L5 peering and L3 peering. For example, when we write: A | B-X-C It is not obvious to me who are the L5 peers and who are the L3 peers. X could be an internet provider for B/C and there could be many of those. Signaling between B and C could be going through a different provider (say Y, which may or may not be L5 aware). Also interconnect SPs may sit in the middle (and frankly I think it is not worthwhile the debate how they get paid. They exist today because of market/regulatory reasons and disregarding them could be fatal in my opinion). Another thing we can do is to place the IXP in []. So it looks like as follows: A--[B]--C | X Any thoughts/comments?=20 -Medhavi. > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, April 06, 2006 7:49 AM > To: speermint@ietf.org > Subject: Re: [Speermint] Reachability >=20 > On 2006/04/06 13:04, Patrick Melampy wrote: > > > > Continuing with your example --- > > A > > | > > B-X-C > > > > This is very useful. So you're suggesting that B could be paid to help > > establish a SIP connection between A and C. This of course is what we are > > trying to figure out in this working group. However, why would anybody with > > a brain pay B for this service when it is apparent that the media and thus > > whole purpose of the communication is going from A-X-C? >=20 > In this case, X is just doing layer3 work. X just provides basic IP > connectivity between A, B, and C. It is completely ignorant to anything > that happens above layer 3. >=20 > It doesn't even matter whether the picture is in fact >=20 > A > | > B-X-Y-C >=20 > or > A > |\ > B-X-Y-C >=20 > or even >=20 > A > |\ > B-X-C >=20 > In other words, X could be the public Internet. >=20 > But going back to you question on why pay B and not just X: >=20 > X fulfills the role of supplying the L3 connectivity between A and C. > B fulfills the role of managing the SIP-layer connectivity between A and C. >=20 > Those two roles could be played by a single company. I do not > rule that out. >=20 > But when designing any framework it is vitally important to keep > the roles separate. Collapsing them in practice is simple. Divvying > up a role into separate entities later on is difficult. >=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 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 >=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 Apr 06 11:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVyx-0007Bf-PZ; Thu, 06 Apr 2006 11:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRVyv-0007BS-Ui for speermint@ietf.org; Thu, 06 Apr 2006 11:01:09 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRVyv-0002lr-KD for speermint@ietf.org; Thu, 06 Apr 2006 11:01:09 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:01: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] Notation? Date: Thu, 6 Apr 2006 11:01:10 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A459@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Notation? thread-index: AcZZcIWwToso1IqzSQSeBYyPa0I9BwAEbeIwAAHOmtAAABJcIA== From: "Medhavi Bhatia" To: "Pfautz, Penn L, NEO" , "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 15:01:09.0309 (UTC) FILETIME=[EFF94ED0:01C6598A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 IXP =3D L5 SP which sits for the duration of the complete call between Core-O and Core-T (from my draft). It may do just signaling or both signaling and media. This is different from a Federation or DNS Registry which may be involved only for lookups. So there is some form of SIP profile terminated to the IXP (we can deal with media later on). Location of IXPs seems to be a problem today: How does Core-O locate the IXP required to get to Core-T if it exists. It is almost like the SIP next hop required to get to the administrative domain of choice. Why IXPs exist? Because of commercial, regulatory or market reasons. Sometimes they will exist even though they make no profit out of the business (consider few of the GRXs in the GSMA peering case). These are just my thoughts. There may be more informed people on the list (who interact with IXPs or have the IXP business) who can speak to this... -Medhavi. > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Thursday, April 06, 2006 10:51 AM > To: Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Notation? >=20 > Can you define what you mean by IXP in this case? This seems to be > another term that gets tossed around. >=20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 10:48 AM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Notation? >=20 > I think we need to formalize the notation for L5 peering and L3 peering. > For example, when we write: >=20 > A > | > B-X-C >=20 > It is not obvious to me who are the L5 peers and who are the L3 peers. X > could be an internet provider for B/C and there could be many of those. > Signaling between B and C could be going through a different provider > (say Y, which may or may not be L5 aware). >=20 > Also interconnect SPs may sit in the middle (and frankly I think it is > not worthwhile the debate how they get paid. They exist today because of > market/regulatory reasons and disregarding them could be fatal in my > opinion). Another thing we can do is to place the IXP in []. So it looks > like as follows: >=20 > A--[B]--C > | > X >=20 > Any thoughts/comments? >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Thursday, April 06, 2006 7:49 AM > > To: speermint@ietf.org > > Subject: Re: [Speermint] Reachability > > > > On 2006/04/06 13:04, Patrick Melampy wrote: > > > > > > Continuing with your example --- > > > A > > > | > > > B-X-C > > > > > > This is very useful. So you're suggesting that B could be paid to > help > > > establish a SIP connection between A and C. This of course is what > we are > > > trying to figure out in this working group. However, why would > anybody with > > > a brain pay B for this service when it is apparent that the media > and thus > > > whole purpose of the communication is going from A-X-C? > > > > In this case, X is just doing layer3 work. X just provides basic IP > > connectivity between A, B, and C. It is completely ignorant to > anything > > that happens above layer 3. > > > > It doesn't even matter whether the picture is in fact > > > > A > > | > > B-X-Y-C > > > > or > > A > > |\ > > B-X-Y-C > > > > or even > > > > A > > |\ > > B-X-C > > > > In other words, X could be the public Internet. > > > > But going back to you question on why pay B and not just X: > > > > X fulfills the role of supplying the L3 connectivity between A and C. > > B fulfills the role of managing the SIP-layer connectivity between A > and C. > > > > Those two roles could be played by a single company. I do not > > rule that out. > > > > But when designing any framework it is vitally important to keep > > the roles separate. Collapsing them in practice is simple. Divvying > > up a role into separate entities later on is difficult. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 11:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRW0F-0007fg-PF; Thu, 06 Apr 2006 11:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRW0E-0007fT-Du for speermint@ietf.org; Thu, 06 Apr 2006 11:02:30 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRW0E-0002sQ-0J for speermint@ietf.org; Thu, 06 Apr 2006 11:02:30 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:02: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] Notation? Date: Thu, 6 Apr 2006 11:02:27 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A45D@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Notation? thread-index: AcZZcIWwToso1IqzSQSeBYyPa0I9BwAEbeIwAAHOmtAAABJcIAAAUlPA From: "Medhavi Bhatia" To: "Pfautz, Penn L, NEO" , "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 15:02:26.0214 (UTC) FILETIME=[1DD01460:01C6598B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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 IXP=3DInterconnect SP as well. > -----Original Message----- > From: Medhavi Bhatia > Sent: Thursday, April 06, 2006 11:01 AM > To: 'Pfautz, Penn L, NEO'; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Notation? >=20 > IXP =3D L5 SP which sits for the duration of the complete call between Core-O and Core-T > (from my draft). It may do just signaling or both signaling and media. >=20 > This is different from a Federation or DNS Registry which may be involved only for > lookups. So there is some form of SIP profile terminated to the IXP (we can deal with > media later on). >=20 > Location of IXPs seems to be a problem today: How does Core-O locate the IXP required to > get to Core-T if it exists. It is almost like the SIP next hop required to get to the > administrative domain of choice. >=20 > Why IXPs exist? Because of commercial, regulatory or market reasons. Sometimes they > will exist even though they make no profit out of the business (consider few of the GRXs in > the GSMA peering case). These are just my thoughts. There may be more informed people > on the list (who interact with IXPs or have the IXP business) who can speak to this... >=20 > -Medhavi. >=20 >=20 > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Thursday, April 06, 2006 10:51 AM > > To: Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Notation? > > > > Can you define what you mean by IXP in this case? This seems to be > > another term that gets tossed around. > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 10:48 AM > > To: Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Notation? > > > > I think we need to formalize the notation for L5 peering and L3 peering. > > For example, when we write: > > > > A > > | > > B-X-C > > > > It is not obvious to me who are the L5 peers and who are the L3 peers. X > > could be an internet provider for B/C and there could be many of those. > > Signaling between B and C could be going through a different provider > > (say Y, which may or may not be L5 aware). > > > > Also interconnect SPs may sit in the middle (and frankly I think it is > > not worthwhile the debate how they get paid. They exist today because of > > market/regulatory reasons and disregarding them could be fatal in my > > opinion). Another thing we can do is to place the IXP in []. So it looks > > like as follows: > > > > A--[B]--C > > | > > X > > > > Any thoughts/comments? > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Thursday, April 06, 2006 7:49 AM > > > To: speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > On 2006/04/06 13:04, Patrick Melampy wrote: > > > > > > > > Continuing with your example --- > > > > A > > > > | > > > > B-X-C > > > > > > > > This is very useful. So you're suggesting that B could be paid to > > help > > > > establish a SIP connection between A and C. This of course is what > > we are > > > > trying to figure out in this working group. However, why would > > anybody with > > > > a brain pay B for this service when it is apparent that the media > > and thus > > > > whole purpose of the communication is going from A-X-C? > > > > > > In this case, X is just doing layer3 work. X just provides basic IP > > > connectivity between A, B, and C. It is completely ignorant to > > anything > > > that happens above layer 3. > > > > > > It doesn't even matter whether the picture is in fact > > > > > > A > > > | > > > B-X-Y-C > > > > > > or > > > A > > > |\ > > > B-X-Y-C > > > > > > or even > > > > > > A > > > |\ > > > B-X-C > > > > > > In other words, X could be the public Internet. > > > > > > But going back to you question on why pay B and not just X: > > > > > > X fulfills the role of supplying the L3 connectivity between A and C. > > > B fulfills the role of managing the SIP-layer connectivity between A > > and C. > > > > > > Those two roles could be played by a single company. I do not > > > rule that out. > > > > > > But when designing any framework it is vitally important to keep > > > the roles separate. Collapsing them in practice is simple. Divvying > > > up a role into separate entities later on is difficult. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 11:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWAT-0007oN-IT; Thu, 06 Apr 2006 11:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWAS-0007oI-0l for speermint@ietf.org; Thu, 06 Apr 2006 11:13:04 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRWAR-0003Sb-CM for speermint@ietf.org; Thu, 06 Apr 2006 11:13:04 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Notation? Date: Thu, 6 Apr 2006 17:16:57 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC6@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Notation? Thread-Index: AcZZcIWwToso1IqzSQSeBYyPa0I9BwAEbeIwAAHOmtAAABJcIAAAk8ng From: "Stastny Richard" To: "Medhavi Bhatia" , "Pfautz, Penn L, NEO" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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 Medhavi, inline > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 5:01 PM > To: Pfautz, Penn L, NEO; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Notation? >=20 > IXP =3D L5 SP which sits for the duration of the complete call between > Core-O and Core-T (from my draft). It may do just signaling or both > signaling and media. As far as I know there exist more types of IXP today, some offer proxy services (which is L5 signaling in your model, some offer also L3 media transit, and some offer just redirect services (covered below - i.e. a location service), and some offer=20 both proxy and redirect >=20 > This is different from a Federation or DNS Registry which may be > involved only for lookups. So there is some form of SIP profile > terminated to the IXP (we can deal with media later on). Not necessarily, see below >=20 > Location of IXPs seems to be a problem today: How does Core-O locate the > IXP required to get to Core-T if it exists. It is almost like the SIP > next hop required to get to the administrative domain of choice. This is partially covered with the lendl I-D: you may derive from the federation name the proxy servers if the federation is operated via a an IXP maybe Otmar could add some additional information such as NAPTRs and SRVs (or pointers to) if the federation is operated via on IXPs. Richard >=20 > Why IXPs exist? Because of commercial, regulatory or market reasons. > Sometimes they will exist even though they make no profit out of the > business (consider few of the GRXs in the GSMA peering case). These are > just my thoughts. There may be more informed people on the list (who > interact with IXPs or have the IXP business) who can speak to this... >=20 > -Medhavi. >=20 >=20 > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Thursday, April 06, 2006 10:51 AM > > To: Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Notation? > > > > Can you define what you mean by IXP in this case? This seems to be > > another term that gets tossed around. > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 10:48 AM > > To: Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Notation? > > > > I think we need to formalize the notation for L5 peering and L3 > peering. > > For example, when we write: > > > > A > > | > > B-X-C > > > > It is not obvious to me who are the L5 peers and who are the L3 peers. > X > > could be an internet provider for B/C and there could be many of > those. > > Signaling between B and C could be going through a different provider > > (say Y, which may or may not be L5 aware). > > > > Also interconnect SPs may sit in the middle (and frankly I think it is > > not worthwhile the debate how they get paid. They exist today because > of > > market/regulatory reasons and disregarding them could be fatal in my > > opinion). Another thing we can do is to place the IXP in []. So it > looks > > like as follows: > > > > A--[B]--C > > | > > X > > > > Any thoughts/comments? > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Thursday, April 06, 2006 7:49 AM > > > To: speermint@ietf.org > > > Subject: Re: [Speermint] Reachability > > > > > > On 2006/04/06 13:04, Patrick Melampy > wrote: > > > > > > > > Continuing with your example --- > > > > A > > > > | > > > > B-X-C > > > > > > > > This is very useful. So you're suggesting that B could be paid to > > help > > > > establish a SIP connection between A and C. This of course is what > > we are > > > > trying to figure out in this working group. However, why would > > anybody with > > > > a brain pay B for this service when it is apparent that the media > > and thus > > > > whole purpose of the communication is going from A-X-C? > > > > > > In this case, X is just doing layer3 work. X just provides basic IP > > > connectivity between A, B, and C. It is completely ignorant to > > anything > > > that happens above layer 3. > > > > > > It doesn't even matter whether the picture is in fact > > > > > > A > > > | > > > B-X-Y-C > > > > > > or > > > A > > > |\ > > > B-X-Y-C > > > > > > or even > > > > > > A > > > |\ > > > B-X-C > > > > > > In other words, X could be the public Internet. > > > > > > But going back to you question on why pay B and not just X: > > > > > > X fulfills the role of supplying the L3 connectivity between A and > C. > > > B fulfills the role of managing the SIP-layer connectivity between A > > and C. > > > > > > Those two roles could be played by a single company. I do not > > > rule that out. > > > > > > But when designing any framework it is vitally important to keep > > > the roles separate. Collapsing them in practice is simple. Divvying > > > up a role into separate entities later on is difficult. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > >=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 Apr 06 11:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWNc-0005TI-TG; Thu, 06 Apr 2006 11:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWNb-0005TC-CU for speermint@ietf.org; Thu, 06 Apr 2006 11:26:39 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWNa-0004DH-03 for speermint@ietf.org; Thu, 06 Apr 2006 11:26:39 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k36FR2s4027229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 08:27:05 -0700 Message-ID: <44353325.5080802@shockey.us> Date: Thu, 06 Apr 2006 11:26:29 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering References: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) 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 Stastny Richard wrote: > The problem I have with the FCC definition is that > is states that peering is always bi-lateral > > The major reason for setting up SPEERMINT was that > everybody seems at least to agree that bi-lateral > peering does not scale globally. Really bi-lateral roaming agreements seems to work for GSM operators pretty well. All peering arrangements among IP backbones are bi-lateral and the Internet seems to have scaled reasonably well. It a lot of work for lawyers but its simply SOP. > > And our real goal is to achieve global connectivity > and reachability. > > Maybe the name of the WG is wrong in this context > > I still believe that the task of SPEERMINT is > to show a way forward to overcome these bi-lateral > peering. Away forward in this direction are federations, > but finally we should lay the framework for a global > IP Interconnect regime, at least protocol wise I think you are going down the gian rat hole of the western world if you believe you can possibly convince global PTT and carriers to engage in business transactions in some other way than bi lateral. > > It is obvious that this cannot be done only by protocols > in a vacuum, so I fully agree that co-operation with > other standard bodies e.g. ITU-T and national authorities > will be required. > > If all communication networks are finally migrated to IP, > an IP Interconnect regime is required. Why do you believe that VoIP interconection agreements will be any different than general IP transit/peering agreements. I simply dont see the point. BT will see that it is in its interest to peer its SIP traffic with FT and enter into an agreement to peer. You may see multi-lateral agreeements but the basics are the same. A lot of lawyers and lot of paper and some simple CAT6 cable. > The new regime allows global direct interconnect, mixing up > the current national and international regimes. In many countries > national forums are popping up (e.g. in UK and Germany) talking > about IP-based interconnect (with or without L3 peering). But > they still need to recognize that this is only half of the picture. > > Some of these discussions are going around in circles (like the > discussions here? ;-). Maybe one task of SPEERMINT could also be > to make scenarios and BCP, showing what works and what not and why not, > saving these other bodies some time on useless discussions on > not implementable or non-scalable models. > > Richard > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 11:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWRA-0007eo-UJ; Thu, 06 Apr 2006 11:30:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWR9-0007ej-Ud for speermint@ietf.org; Thu, 06 Apr 2006 11:30:19 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWR9-0004NU-GV for speermint@ietf.org; Thu, 06 Apr 2006 11:30:19 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k36FUjFw027892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 08:30:46 -0700 Message-ID: <44353405.5080709@shockey.us> Date: Thu, 06 Apr 2006 11:30:13 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" Subject: Re: [Speermint] Notation? References: <34DA635B184A644DA4588E260EC0A25A0C874789@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C874789@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Pfautz, Penn L, NEO wrote: > Can you define what you mean by IXP in this case? This seems to be > another term that gets tossed around. Internet Exchange Points ... aka Telehouse, Equinix, AMSIX, LINX, Torx, JPIX, the points of physical interconnection between IP networks. > > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 10:48 AM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Notation? > > I think we need to formalize the notation for L5 peering and L3 peering. > For example, when we write: > > A > | > B-X-C > > It is not obvious to me who are the L5 peers and who are the L3 peers. X > could be an internet provider for B/C and there could be many of those. > Signaling between B and C could be going through a different provider > (say Y, which may or may not be L5 aware). > > Also interconnect SPs may sit in the middle (and frankly I think it is > not worthwhile the debate how they get paid. They exist today because of > market/regulatory reasons and disregarding them could be fatal in my > opinion). Another thing we can do is to place the IXP in []. So it looks > like as follows: > > A--[B]--C > | > X > > Any thoughts/comments? > > -Medhavi. > >> -----Original Message----- >> From: Otmar Lendl [mailto:lendl@nic.at] >> Sent: Thursday, April 06, 2006 7:49 AM >> To: speermint@ietf.org >> Subject: Re: [Speermint] Reachability >> >> On 2006/04/06 13:04, Patrick Melampy wrote: >>> Continuing with your example --- >>> A >>> | >>> B-X-C >>> >>> This is very useful. So you're suggesting that B could be paid to > help >>> establish a SIP connection between A and C. This of course is what > we are >>> trying to figure out in this working group. However, why would > anybody with >>> a brain pay B for this service when it is apparent that the media > and thus >>> whole purpose of the communication is going from A-X-C? >> In this case, X is just doing layer3 work. X just provides basic IP >> connectivity between A, B, and C. It is completely ignorant to > anything >> that happens above layer 3. >> >> It doesn't even matter whether the picture is in fact >> >> A >> | >> B-X-Y-C >> >> or >> A >> |\ >> B-X-Y-C >> >> or even >> >> A >> |\ >> B-X-C >> >> In other words, X could be the public Internet. >> >> But going back to you question on why pay B and not just X: >> >> X fulfills the role of supplying the L3 connectivity between A and C. >> B fulfills the role of managing the SIP-layer connectivity between A > and C. >> Those two roles could be played by a single company. I do not >> rule that out. >> >> But when designing any framework it is vitally important to keep >> the roles separate. Collapsing them in practice is simple. Divvying >> up a role into separate entities later on is difficult. >> >> /ol >> -- >> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > _______________________________________________ > 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 > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 11:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWa3-0003qu-LL; Thu, 06 Apr 2006 11:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWa1-0003qp-Sg for speermint@ietf.org; Thu, 06 Apr 2006 11:39:29 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWa1-0004nA-G5 for speermint@ietf.org; Thu, 06 Apr 2006 11:39:29 -0400 Received: from [10.31.13.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k36FdvIG029614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2006 08:39:59 -0700 Message-ID: <4435362F.2060206@shockey.us> Date: Thu, 06 Apr 2006 11:39:27 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] Notation? References: <32755D354E6B65498C3BD9FD496C7D463C4EC6@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EC6@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Stastny Richard wrote: > Hi Medhavi, > inline > >> -----Original Message----- >> From: Medhavi Bhatia [mailto:mbhatia@nextone.com] >> Sent: Thursday, April 06, 2006 5:01 PM >> To: Pfautz, Penn L, NEO; Otmar Lendl; speermint@ietf.org >> Subject: RE: [Speermint] Notation? >> >> IXP = L5 SP which sits for the duration of the complete call between >> Core-O and Core-T (from my draft). It may do just signaling or both >> signaling and media. > > As far as I know there exist more types of IXP today, some offer > proxy services (which is L5 signaling in your model, some offer > also L3 media transit, and some offer just redirect services > (covered below - i.e. a location service), and some offer > both proxy and redirect Use of the term IXP in this context is incorrect and misleading. You need to come up with something specific to the SPEERMINT context. IXP means some thing in Internet Terminoogy. Now peering arrangements can be organized at an IXP such as LINX / Equinix if two service providers choose to match their L3 and L5 traffic at those points and share access to common signaling databases such as ENUM or SIP Redirect. >> This is different from a Federation or DNS Registry which may be >> involved only for lookups. So there is some form of SIP profile >> terminated to the IXP (we can deal with media later on). > > Not necessarily, see below >> Location of IXPs seems to be a problem today: How does Core-O locate > the IXP required to get to Core-T if it exists. It is almost like the SIP >> next hop required to get to the administrative domain of choice. No not necessarily each domain should have internal knowledge of its bilateral agreements and make decisions based at call origination as to what is the optimal point of transit interconnection. > > This is partially covered with the lendl I-D: you may derive from > the federation name the proxy servers if the federation is operated > via a an IXP > > maybe Otmar could add some additional information such as > NAPTRs and SRVs (or pointers to) if the federation is operated > via on IXPs. > > Richard >> Why IXPs exist? Because of commercial, regulatory or market reasons. market reasons ... money is the answer what is the question? >> Sometimes they will exist even though they make no profit out of the >> business (consider few of the GRXs in the GSMA peering case). These > are just my thoughts. There may be more informed people on the list (who >> interact with IXPs or have the IXP business) who can speak to this. >> >> -Medhavi. >> >> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 11:44:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWec-0005jm-V3; Thu, 06 Apr 2006 11:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWeb-0005jh-6p for speermint@ietf.org; Thu, 06 Apr 2006 11:44:13 -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 1FRWeX-0004zt-Sz for speermint@ietf.org; Thu, 06 Apr 2006 11:44:13 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 982711A3C8; Thu, 6 Apr 2006 17:44:08 +0200 (CEST) Date: Thu, 6 Apr 2006 17:44:08 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering Message-ID: <20060406154408.GE12968@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> <44353325.5080802@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44353325.5080802@shockey.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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/04/06 17:04, Richard Shockey wrote: > Stastny Richard wrote: > >The problem I have with the FCC definition is that > >is states that peering is always bi-lateral > > > >The major reason for setting up SPEERMINT was that > >everybody seems at least to agree that bi-lateral > >peering does not scale globally. > > All peering arrangements among IP backbones are bi-lateral and the Internet > seems to have scaled reasonably well. The reason for that is "transit". It is thus not necessary that any Autonomous Systems peers with all other AS. I think we should define the difference between "Peering" and "Interconnection" (which in my mind also allows for transit). Bi-lateral peering alone will definitly not solve the world-wide reachability problem. /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 Thu Apr 06 13:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXrg-0007R5-Ip; Thu, 06 Apr 2006 13:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXrf-0007N8-GJ for speermint@ietf.org; Thu, 06 Apr 2006 13:01:47 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRXrd-0007f7-6r for speermint@ietf.org; Thu, 06 Apr 2006 13:01:47 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 10:01:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="538219153:sNHT22550240" 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] RE: Background Reading on NGN Interconnect - transitvs peering Date: Thu, 6 Apr 2006 13:01:43 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5FA@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pA From: "Reinaldo Penno" To: "Otmar Lendl" , 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 Okay, so when coming up with these terms we cannot forget about media. So, when somebody provides "peering" and/or "transit" services, we need to specify in the context of speermint if that means: a) all IP packets (which includes media) b) only signaling ... Well, you get the idea... > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Thursday, April 06, 2006 8:44 AM > To: speermint@ietf.org > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - > transitvs peering >=20 > On 2006/04/06 17:04, Richard Shockey wrote: > > Stastny Richard wrote: > > >The problem I have with the FCC definition is that > > >is states that peering is always bi-lateral > > > > > >The major reason for setting up SPEERMINT was that > > >everybody seems at least to agree that bi-lateral > > >peering does not scale globally. > > > > All peering arrangements among IP backbones are bi-lateral and the > Internet > > seems to have scaled reasonably well. >=20 > The reason for that is "transit". It is thus not necessary that > any Autonomous Systems peers with all other AS. >=20 > I think we should define the difference between "Peering" and > "Interconnection" (which in my mind also allows for transit). >=20 > Bi-lateral peering alone will definitly not solve the world-wide > reachability problem. >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 13:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYQs-0008N9-II; Thu, 06 Apr 2006 13:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRYQr-0008N3-EI for speermint@ietf.org; Thu, 06 Apr 2006 13:38:09 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRYQr-0000gB-6N for speermint@ietf.org; Thu, 06 Apr 2006 13:38:09 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 13:38: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] RE: Background Reading on NGN Interconnect -transitvs peering Date: Thu, 6 Apr 2006 13:38:07 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A596@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect -transitvs peering thread-index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOA= From: "Medhavi Bhatia" To: "Reinaldo Penno" , "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 17:38:08.0887 (UTC) FILETIME=[DE7AD870:01C659A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Reinaldo, Do you have an example of an operator doing just media but is not an L3 carrier (e.g ISP/Transit)? If not, we can just talk about signaling only or signaling and media. -Medhavi. > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 1:02 PM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect -transitvs peering >=20 > Okay, so when coming up with these terms we cannot forget about media. > So, when somebody provides "peering" and/or "transit" services, we need > to specify in the context of speermint if that means: >=20 > a) all IP packets (which includes media) > b) only signaling > ... >=20 > Well, you get the idea... >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Thursday, April 06, 2006 8:44 AM > > To: speermint@ietf.org > > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - > > transitvs peering > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > Stastny Richard wrote: > > > >The problem I have with the FCC definition is that > > > >is states that peering is always bi-lateral > > > > > > > >The major reason for setting up SPEERMINT was that > > > >everybody seems at least to agree that bi-lateral > > > >peering does not scale globally. > > > > > > All peering arrangements among IP backbones are bi-lateral and the > > Internet > > > seems to have scaled reasonably well. > > > > The reason for that is "transit". It is thus not necessary that > > any Autonomous Systems peers with all other AS. > > > > I think we should define the difference between "Peering" and > > "Interconnection" (which in my mind also allows for transit). > > > > Bi-lateral peering alone will definitly not solve the world-wide > > reachability problem. > > > > /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 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 14:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZGy-0008OX-KH; Thu, 06 Apr 2006 14:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZGy-0008OS-44 for speermint@ietf.org; Thu, 06 Apr 2006 14:32:00 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZGx-0002hg-R0 for speermint@ietf.org; Thu, 06 Apr 2006 14:32:00 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 06 Apr 2006 11:31:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="541466497:sNHT23870812" 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] RE: Background Reading on NGN Interconnect -transitvs peering Date: Thu, 6 Apr 2006 14:31:56 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE5FF@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect -transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAeS+4A== From: "Reinaldo Penno" To: "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) 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 Well, I also do not know anybody paying only for signaling and not for media.=20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 10:38 AM > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect - > transitvs peering >=20 > Reinaldo, >=20 > Do you have an example of an operator doing just media but is not an L3 > carrier (e.g ISP/Transit)? If not, we can just talk about signaling only > or signaling and media. >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 1:02 PM > > To: Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > -transitvs peering > > > > Okay, so when coming up with these terms we cannot forget about media. > > So, when somebody provides "peering" and/or "transit" services, we > need > > to specify in the context of speermint if that means: > > > > a) all IP packets (which includes media) > > b) only signaling > > ... > > > > Well, you get the idea... > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Thursday, April 06, 2006 8:44 AM > > > To: speermint@ietf.org > > > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect > - > > > transitvs peering > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > Stastny Richard wrote: > > > > >The problem I have with the FCC definition is that > > > > >is states that peering is always bi-lateral > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > >everybody seems at least to agree that bi-lateral > > > > >peering does not scale globally. > > > > > > > > All peering arrangements among IP backbones are bi-lateral and the > > > Internet > > > > seems to have scaled reasonably well. > > > > > > The reason for that is "transit". It is thus not necessary that > > > any Autonomous Systems peers with all other AS. > > > > > > I think we should define the difference between "Peering" and > > > "Interconnection" (which in my mind also allows for transit). > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > reachability problem. > > > > > > /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 > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 14:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZfq-0002Z1-Qx; Thu, 06 Apr 2006 14:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZfp-0002Yt-2O for speermint@ietf.org; Thu, 06 Apr 2006 14:57:41 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZfo-0003Aq-Lh for speermint@ietf.org; Thu, 06 Apr 2006 14:57:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRZfc-0002IM-Cq; Thu, 06 Apr 2006 13:57:28 -0500 From: "Brian Rosen" To: "'Medhavi Bhatia'" , "'Reinaldo Penno'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 14:57:30 -0400 Message-ID: <023e01c659ab$f79f9bf0$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 In-Reply-To: <8812D8156467224C9E9739E513037EF155A596@moe.nextone.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEA== X-PopBeforeSMTPSenders: br@brianrosen.net 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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 sorry to be on a campaign to stop arguments that may be interesting and amusing to us all, but could someone come up with a scenario in which any of our anticipated documents would somehow differentiate between a peering mechanism that had media relays and one that did not? I think this whole line of discussion is interesting, but irrelevant to the task at hand. Peering occurs when a SIP INVITE, most often with an offer SDP body, which contains some IP addresses and ports for it's desired media connections, is presented to some proxy (a peering proxy which could be within the O network, or could be in some special peering network) who is going to determine a proxy in the T network to send the INVITE to. The resulting 200 OK message, which most often will have an answer SDP with its own media addresses and ports may traverse said proxies (if they Record Routed). WHO CARES what the media address/ports are? WHO is going to do anything different if they are the endpoint's, an SBC in the O-network, T-network or anything else. Who in the O or T network would care if they were in an SBC inside a peering service? We need to think about media, because we have to deal with pinhole firewalls, we have to deal with NAT traversal, and we could imagine dealing with ancillary functions like transcoders, but really folks, whether there are media relays anywhere just doesn't seem to matter; you can't tell if there are or there aren't and you don't do anything differently. Should anyone care, I personally think if systems are properly designed, the only media relays in the path pretty that much have to be there are for legal intercept, and if we did that correctly (at L3 or below) then even they would not be needed and we could get back to the original idea that media flows direct between the UAs. That does not obviate any firewall needs. I am under no illusions that "properly designed" is often achieved. That having been said, lots of folks seem to like media relays, I hope they don't screw up when emergency calls are sent through, and we have to accept that they may be all over the place. But, again, who cares? Brian -----Original Message----- From: Medhavi Bhatia [mailto:mbhatia@nextone.com] Sent: Thursday, April 06, 2006 1:38 PM To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Reinaldo, Do you have an example of an operator doing just media but is not an L3 carrier (e.g ISP/Transit)? If not, we can just talk about signaling only or signaling and media. -Medhavi. > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 1:02 PM > To: Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect -transitvs peering > > Okay, so when coming up with these terms we cannot forget about media. > So, when somebody provides "peering" and/or "transit" services, we need > to specify in the context of speermint if that means: > > a) all IP packets (which includes media) > b) only signaling > ... > > Well, you get the idea... > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Thursday, April 06, 2006 8:44 AM > > To: speermint@ietf.org > > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - > > transitvs peering > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > Stastny Richard wrote: > > > >The problem I have with the FCC definition is that > > > >is states that peering is always bi-lateral > > > > > > > >The major reason for setting up SPEERMINT was that > > > >everybody seems at least to agree that bi-lateral > > > >peering does not scale globally. > > > > > > All peering arrangements among IP backbones are bi-lateral and the > > Internet > > > seems to have scaled reasonably well. > > > > The reason for that is "transit". It is thus not necessary that > > any Autonomous Systems peers with all other AS. > > > > I think we should define the difference between "Peering" and > > "Interconnection" (which in my mind also allows for transit). > > > > Bi-lateral peering alone will definitly not solve the world-wide > > reachability problem. > > > > /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 > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 4/5/2006 > _______________________________________________ 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 Apr 06 15:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZkK-0004fx-2M; Thu, 06 Apr 2006 15:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZkI-0004YB-Q8 for speermint@ietf.org; Thu, 06 Apr 2006 15:02:18 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZkG-0003OL-Fs for speermint@ietf.org; Thu, 06 Apr 2006 15:02:18 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A5B70364; Thu, 06 Apr 2006 15:02:15 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Lee, Yiu'" , Subject: RE: [Speermint] Reachability Date: Thu, 6 Apr 2006 15:02:21 -0400 Message-ID: <088c01c659ac$a25711e0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAVUrkw In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EC0@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Richard, Comments inline... (this list is getting busy! :) > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > area ;-) Also, if A doesn't peer C directly, we have our old friend > PSTN > > to do the work (at least working for the voice service). > > No, you do NOT have the Good old PSTN to do the work in > SPEERMIND SPEERMINT (peering, interreconnect; whatever) is > not E.164 aware, so the PSTN is NOT an Option I believe Yiu was being sarcastic - the idea is exactly that we don't want to use the PSTN if we don't have to. :) Having said that, it seems ludicrous to me that we don't want to allow for reaching 99.9% of the planet Earth's communication devices, simply because part of the path may have a TDM transport without 40 bytes of wrapping above it and not cross routers from a few vendors the entire way. Don't ya think? ;) If you want to create a change, providing maximal basic reach with advanced/free ip-only-reach will win more converts than forcing pstn-celibacy. > Implying there is an unneccessary Qos agreement in the core. > As the Scott Marcus paper points out, this is unnecessary in > most cases and also not controllable. QoS, if at all, is only > required in the access. That is not how I read his paper: although it was the conclusion, the conclusion was based on premises which actually tend to make one think doing QoS for VoIP may have value. But I am not concerned with what his views are. We can have a lengthy discussion of why it has value if you wish, but I'm not sure it will help because my guess is we will not come to agreement. The interesting thing is, paid VoIP service may actually be the revenue and demand driver which gets it over the adoption hump. There is no question it will not happen overnight, and neither will Speermint adoption, nor VoIP. But those are based on market forces, and a standards body rarely can predict such things. What an open standards body should do is provide several options which can be chosen based on one's needs/wants, and let the market decide the rest. If you're right, we will have wasted some time. If you're wrong, we will have squandered an opportunity. I am willing to dedicate time to it, and you may ignore it as you wish. To the point of whether it is "controllable": it is, and it is done today. > We should not waste our time with unimplementable issues. I'm not sure how one can say that, when the possible solutions to it have not even been discussed (nor even really the problem). I thought the whole idea here is determine the requirements, then figure out how they can be met, and if they can't then determine if it is a further study/work-area. Is that not part of the charter? -Hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 15:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZsy-0008Gf-6G; Thu, 06 Apr 2006 15:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRZsw-0008Ga-Ar for speermint@ietf.org; Thu, 06 Apr 2006 15:11:14 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRZsv-0003jX-Sb for speermint@ietf.org; Thu, 06 Apr 2006 15:11:14 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 12:11:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="538244213:sNHT24843784" 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] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 15:11:11 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE600@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiw From: "Reinaldo Penno" To: , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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'm not sure the discussion was about media relays. Was it? The impression I had was that the discussion was about the path taken by media when flowing between endpoints.=20 >From my point of view I see many discussions on SIP signaling and "signaling only providers" and I worry that we are forgetting to take media into account. Regards, Reinaldo > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 11:58 AM > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > I am sorry to be on a campaign to stop arguments that may be interesting > and > amusing to us all, but could someone come up with a scenario in which any > of > our anticipated documents would somehow differentiate between a peering > mechanism that had media relays and one that did not? >=20 > I think this whole line of discussion is interesting, but irrelevant to > the > task at hand. >=20 > Peering occurs when a SIP INVITE, most often with an offer SDP body, which > contains some IP addresses and ports for it's desired media connections, > is > presented to some proxy (a peering proxy which could be within the O > network, or could be in some special peering network) who is going to > determine a proxy in the T network to send the INVITE to. The resulting > 200 > OK message, which most often will have an answer SDP with its own media > addresses and ports may traverse said proxies (if they Record Routed). >=20 > WHO CARES what the media address/ports are? >=20 > WHO is going to do anything different if they are the endpoint's, an SBC > in > the O-network, T-network or anything else. >=20 > Who in the O or T network would care if they were in an SBC inside a > peering > service? >=20 > We need to think about media, because we have to deal with pinhole > firewalls, we have to deal with NAT traversal, and we could imagine > dealing > with ancillary functions like transcoders, but really folks, whether there > are media relays anywhere just doesn't seem to matter; you can't tell if > there are or there aren't and you don't do anything differently. >=20 > Should anyone care, I personally think if systems are properly designed, > the > only media relays in the path pretty that much have to be there are for > legal intercept, and if we did that correctly (at L3 or below) then even > they would not be needed and we could get back to the original idea that > media flows direct between the UAs. That does not obviate any firewall > needs. I am under no illusions that "properly designed" is often > achieved. > That having been said, lots of folks seem to like media relays, I hope > they > don't screw up when emergency calls are sent through, and we have to > accept > that they may be all over the place. But, again, who cares? >=20 > Brian >=20 > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 1:38 PM > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 > Reinaldo, >=20 > Do you have an example of an operator doing just media but is not an L3 > carrier (e.g ISP/Transit)? If not, we can just talk about signaling only > or signaling and media. >=20 > -Medhavi. >=20 > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 1:02 PM > > To: Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > -transitvs peering > > > > Okay, so when coming up with these terms we cannot forget about media. > > So, when somebody provides "peering" and/or "transit" services, we > need > > to specify in the context of speermint if that means: > > > > a) all IP packets (which includes media) > > b) only signaling > > ... > > > > Well, you get the idea... > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Thursday, April 06, 2006 8:44 AM > > > To: speermint@ietf.org > > > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect > - > > > transitvs peering > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > Stastny Richard wrote: > > > > >The problem I have with the FCC definition is that > > > > >is states that peering is always bi-lateral > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > >everybody seems at least to agree that bi-lateral > > > > >peering does not scale globally. > > > > > > > > All peering arrangements among IP backbones are bi-lateral and the > > > Internet > > > > seems to have scaled reasonably well. > > > > > > The reason for that is "transit". It is thus not necessary that > > > any Autonomous Systems peers with all other AS. > > > > > > I think we should define the difference between "Peering" and > > > "Interconnection" (which in my mind also allows for transit). > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > reachability problem. > > > > > > /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 > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > >=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 Apr 06 15:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa8t-0001KH-1r; Thu, 06 Apr 2006 15:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRa8s-0001KC-8e for speermint@ietf.org; Thu, 06 Apr 2006 15:27:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRa8r-0004JD-QP for speermint@ietf.org; Thu, 06 Apr 2006 15:27:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRa8h-0004Gp-EU; Thu, 06 Apr 2006 14:27:31 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 15:27:34 -0400 Message-ID: <024901c659b0$2a9371e0$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 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE600@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: ff0adf256e4dd459cc25215cfa732ac1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 The path taken by media either flows from one endpoint to the other directly, or it goes through one or more media relays. The path media takes is defined by which media relays it must traverse. I don't think L3 considerations apply to our work. I do think there are likely to be pin-hole firewalls that enable media flows, although I don't think we need to discuss these either. What in any of our documents would offer different advice depending on the path the media takes? What do we have to take into account? I can imagine a discussion of marking of media. That could happen. I can imagine a discussion of security of media across a peering point which would deal with key exchange although I'm not sure there is much we could agree on that subject yet. I don't see much else we need to cover. Do you? Brian -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, April 06, 2006 3:11 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering I'm not sure the discussion was about media relays. Was it? The impression I had was that the discussion was about the path taken by media when flowing between endpoints. >From my point of view I see many discussions on SIP signaling and "signaling only providers" and I worry that we are forgetting to take media into account. Regards, Reinaldo > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 11:58 AM > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering > > I am sorry to be on a campaign to stop arguments that may be interesting > and > amusing to us all, but could someone come up with a scenario in which any > of > our anticipated documents would somehow differentiate between a peering > mechanism that had media relays and one that did not? > > I think this whole line of discussion is interesting, but irrelevant to > the > task at hand. > > Peering occurs when a SIP INVITE, most often with an offer SDP body, which > contains some IP addresses and ports for it's desired media connections, > is > presented to some proxy (a peering proxy which could be within the O > network, or could be in some special peering network) who is going to > determine a proxy in the T network to send the INVITE to. The resulting > 200 > OK message, which most often will have an answer SDP with its own media > addresses and ports may traverse said proxies (if they Record Routed). > > WHO CARES what the media address/ports are? > > WHO is going to do anything different if they are the endpoint's, an SBC > in > the O-network, T-network or anything else. > > Who in the O or T network would care if they were in an SBC inside a > peering > service? > > We need to think about media, because we have to deal with pinhole > firewalls, we have to deal with NAT traversal, and we could imagine > dealing > with ancillary functions like transcoders, but really folks, whether there > are media relays anywhere just doesn't seem to matter; you can't tell if > there are or there aren't and you don't do anything differently. > > Should anyone care, I personally think if systems are properly designed, > the > only media relays in the path pretty that much have to be there are for > legal intercept, and if we did that correctly (at L3 or below) then even > they would not be needed and we could get back to the original idea that > media flows direct between the UAs. That does not obviate any firewall > needs. I am under no illusions that "properly designed" is often > achieved. > That having been said, lots of folks seem to like media relays, I hope > they > don't screw up when emergency calls are sent through, and we have to > accept > that they may be all over the place. But, again, who cares? > > Brian > > -----Original Message----- > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > Sent: Thursday, April 06, 2006 1:38 PM > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering > > Reinaldo, > > Do you have an example of an operator doing just media but is not an L3 > carrier (e.g ISP/Transit)? If not, we can just talk about signaling only > or signaling and media. > > -Medhavi. > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 1:02 PM > > To: Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > -transitvs peering > > > > Okay, so when coming up with these terms we cannot forget about media. > > So, when somebody provides "peering" and/or "transit" services, we > need > > to specify in the context of speermint if that means: > > > > a) all IP packets (which includes media) > > b) only signaling > > ... > > > > Well, you get the idea... > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Thursday, April 06, 2006 8:44 AM > > > To: speermint@ietf.org > > > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect > - > > > transitvs peering > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > Stastny Richard wrote: > > > > >The problem I have with the FCC definition is that > > > > >is states that peering is always bi-lateral > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > >everybody seems at least to agree that bi-lateral > > > > >peering does not scale globally. > > > > > > > > All peering arrangements among IP backbones are bi-lateral and the > > > Internet > > > > seems to have scaled reasonably well. > > > > > > The reason for that is "transit". It is thus not necessary that > > > any Autonomous Systems peers with all other AS. > > > > > > I think we should define the difference between "Peering" and > > > "Interconnection" (which in my mind also allows for transit). > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > reachability problem. > > > > > > /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 > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > 4/5/2006 > > > > _______________________________________________ > 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 Apr 06 15:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaNE-0000WC-Sq; Thu, 06 Apr 2006 15:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaNE-0000W7-5C for speermint@ietf.org; Thu, 06 Apr 2006 15:42:32 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaND-0004zI-Ib for speermint@ietf.org; Thu, 06 Apr 2006 15:42:32 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 06 Apr 2006 12:42:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="541480610:sNHT26820040" 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] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 15:42:29 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE602@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0A== From: "Reinaldo Penno" To: , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 12:28 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > Reinaldo >=20 > The path taken by media either flows from one endpoint to the other > directly, or it goes through one or more media relays. The path media > takes > is defined by which media relays it must traverse. I don't think L3 > considerations apply to our work. [[Reinaldo]]=20 Is it? The charter states that=20 "In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers," Potentially media could follow a different route than signaling by tunneling (read VPNs) or MPLS. No media relays needed. If these interactions are out of scope, fine. >=20 > I do think there are likely to be pin-hole firewalls that enable media > flows, although I don't think we need to discuss these either. >=20 > What in any of our documents would offer different advice depending on the > path the media takes? >=20 > What do we have to take into account? [[Reinaldo]]=20 See above. >=20 > I can imagine a discussion of marking of media. That could happen. > I can imagine a discussion of security of media across a peering point > which > would deal with key exchange although I'm not sure there is much we could > agree on that subject yet. [[Reinaldo]]=20 Well, all this related to the path the media will take. If your "voip peer" will not provide QoS (or even carry media), then you might want to send your media through some other path. Will this the stated in the "peering policy" we will define? But, as I stated, if such interactions are out of scope, I will drop the subject. Thanks, Reinaldo >=20 > I don't see much else we need to cover. Do you? >=20 > Brian >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:11 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 > I'm not sure the discussion was about media relays. Was it? The > impression I had was that the discussion was about the path taken by > media when flowing between endpoints. >=20 > From my point of view I see many discussions on SIP signaling and > "signaling only providers" and I worry that we are forgetting to take > media into account. >=20 > Regards, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 11:58 AM > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I am sorry to be on a campaign to stop arguments that may be > interesting > > and > > amusing to us all, but could someone come up with a scenario in which > any > > of > > our anticipated documents would somehow differentiate between a > peering > > mechanism that had media relays and one that did not? > > > > I think this whole line of discussion is interesting, but irrelevant > to > > the > > task at hand. > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > which > > contains some IP addresses and ports for it's desired media > connections, > > is > > presented to some proxy (a peering proxy which could be within the O > > network, or could be in some special peering network) who is going to > > determine a proxy in the T network to send the INVITE to. The > resulting > > 200 > > OK message, which most often will have an answer SDP with its own > media > > addresses and ports may traverse said proxies (if they Record Routed). > > > > WHO CARES what the media address/ports are? > > > > WHO is going to do anything different if they are the endpoint's, an > SBC > > in > > the O-network, T-network or anything else. > > > > Who in the O or T network would care if they were in an SBC inside a > > peering > > service? > > > > We need to think about media, because we have to deal with pinhole > > firewalls, we have to deal with NAT traversal, and we could imagine > > dealing > > with ancillary functions like transcoders, but really folks, whether > there > > are media relays anywhere just doesn't seem to matter; you can't tell > if > > there are or there aren't and you don't do anything differently. > > > > Should anyone care, I personally think if systems are properly > designed, > > the > > only media relays in the path pretty that much have to be there are > for > > legal intercept, and if we did that correctly (at L3 or below) then > even > > they would not be needed and we could get back to the original idea > that > > media flows direct between the UAs. That does not obviate any > firewall > > needs. I am under no illusions that "properly designed" is often > > achieved. > > That having been said, lots of folks seem to like media relays, I hope > > they > > don't screw up when emergency calls are sent through, and we have to > > accept > > that they may be all over the place. But, again, who cares? > > > > Brian > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 1:38 PM > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > Reinaldo, > > > > Do you have an example of an operator doing just media but is not an > L3 > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > only > > or signaling and media. > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 1:02 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > > -transitvs peering > > > > > > Okay, so when coming up with these terms we cannot forget about > media. > > > So, when somebody provides "peering" and/or "transit" services, we > > need > > > to specify in the context of speermint if that means: > > > > > > a) all IP packets (which includes media) > > > b) only signaling > > > ... > > > > > > Well, you get the idea... > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > To: speermint@ietf.org > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > Interconnect > > - > > > > transitvs peering > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > Stastny Richard wrote: > > > > > >The problem I have with the FCC definition is that > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > >everybody seems at least to agree that bi-lateral > > > > > >peering does not scale globally. > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > the > > > > Internet > > > > > seems to have scaled reasonably well. > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > any Autonomous Systems peers with all other AS. > > > > > > > > I think we should define the difference between "Peering" and > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > reachability problem. > > > > > > > > /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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > 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 Apr 06 15:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaUt-0004O7-NA; Thu, 06 Apr 2006 15:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaUr-0004Lo-Nm for speermint@ietf.org; Thu, 06 Apr 2006 15:50:25 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaUr-00054M-A4 for speermint@ietf.org; Thu, 06 Apr 2006 15:50:25 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k36Jn96r020849; Thu, 6 Apr 2006 19:49:30 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 1207878B434; Thu, 6 Apr 2006 19:48:54 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id D01A678B437; Thu, 6 Apr 2006 19:48:53 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 13:48:53 -0600 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] RE: Background Reading on NGNInterconnect-transitvspeering Date: Thu, 6 Apr 2006 13:48:52 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAWzRw From: "Malas, Daryl" To: "Reinaldo Penno" , , "Medhavi Bhatia" , "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 19:48:53.0711 (UTC) FILETIME=[225BFDF0:01C659B3] X-Spam-Score: 1.2 (+) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 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 can simplify these discussions by specifying the policies relative to unique peering environments. As I discussed before, can we classify the peering environments into categories such as: Public peering -=20 1. Create Definition 2. Define policies 3. Develop use cases Private peering - 1. Carrier peering - 1. Any others??? - I think the majority of the ambiguity is created from the varying perspectives on peering. The 3 categories listed above are simply my guess to the most common perspectives in this WG. With each, we can tackle the various L3 and L5 issues, but at least we can maintain the conversation within the framework of the specified peering environment. I think this will eliminate some of the ambiguity. Make sense? --Daryl M. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, April 06, 2006 1:42 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 12:28 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > Reinaldo >=20 > The path taken by media either flows from one endpoint to the other > directly, or it goes through one or more media relays. The path media > takes > is defined by which media relays it must traverse. I don't think L3 > considerations apply to our work. [[Reinaldo]]=20 Is it? The charter states that=20 "In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers," Potentially media could follow a different route than signaling by tunneling (read VPNs) or MPLS. No media relays needed. If these interactions are out of scope, fine. >=20 > I do think there are likely to be pin-hole firewalls that enable media > flows, although I don't think we need to discuss these either. >=20 > What in any of our documents would offer different advice depending on the > path the media takes? >=20 > What do we have to take into account? [[Reinaldo]]=20 See above. >=20 > I can imagine a discussion of marking of media. That could happen. > I can imagine a discussion of security of media across a peering point > which > would deal with key exchange although I'm not sure there is much we could > agree on that subject yet. [[Reinaldo]]=20 Well, all this related to the path the media will take. If your "voip peer" will not provide QoS (or even carry media), then you might want to send your media through some other path. Will this the stated in the "peering policy" we will define? But, as I stated, if such interactions are out of scope, I will drop the subject. Thanks, Reinaldo >=20 > I don't see much else we need to cover. Do you? >=20 > Brian >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:11 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 > I'm not sure the discussion was about media relays. Was it? The > impression I had was that the discussion was about the path taken by > media when flowing between endpoints. >=20 > From my point of view I see many discussions on SIP signaling and > "signaling only providers" and I worry that we are forgetting to take > media into account. >=20 > Regards, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 11:58 AM > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I am sorry to be on a campaign to stop arguments that may be > interesting > > and > > amusing to us all, but could someone come up with a scenario in which > any > > of > > our anticipated documents would somehow differentiate between a > peering > > mechanism that had media relays and one that did not? > > > > I think this whole line of discussion is interesting, but irrelevant > to > > the > > task at hand. > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > which > > contains some IP addresses and ports for it's desired media > connections, > > is > > presented to some proxy (a peering proxy which could be within the O > > network, or could be in some special peering network) who is going to > > determine a proxy in the T network to send the INVITE to. The > resulting > > 200 > > OK message, which most often will have an answer SDP with its own > media > > addresses and ports may traverse said proxies (if they Record Routed). > > > > WHO CARES what the media address/ports are? > > > > WHO is going to do anything different if they are the endpoint's, an > SBC > > in > > the O-network, T-network or anything else. > > > > Who in the O or T network would care if they were in an SBC inside a > > peering > > service? > > > > We need to think about media, because we have to deal with pinhole > > firewalls, we have to deal with NAT traversal, and we could imagine > > dealing > > with ancillary functions like transcoders, but really folks, whether > there > > are media relays anywhere just doesn't seem to matter; you can't tell > if > > there are or there aren't and you don't do anything differently. > > > > Should anyone care, I personally think if systems are properly > designed, > > the > > only media relays in the path pretty that much have to be there are > for > > legal intercept, and if we did that correctly (at L3 or below) then > even > > they would not be needed and we could get back to the original idea > that > > media flows direct between the UAs. That does not obviate any > firewall > > needs. I am under no illusions that "properly designed" is often > > achieved. > > That having been said, lots of folks seem to like media relays, I hope > > they > > don't screw up when emergency calls are sent through, and we have to > > accept > > that they may be all over the place. But, again, who cares? > > > > Brian > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 1:38 PM > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > Reinaldo, > > > > Do you have an example of an operator doing just media but is not an > L3 > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > only > > or signaling and media. > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 1:02 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > > -transitvs peering > > > > > > Okay, so when coming up with these terms we cannot forget about > media. > > > So, when somebody provides "peering" and/or "transit" services, we > > need > > > to specify in the context of speermint if that means: > > > > > > a) all IP packets (which includes media) > > > b) only signaling > > > ... > > > > > > Well, you get the idea... > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > To: speermint@ietf.org > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > Interconnect > > - > > > > transitvs peering > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > Stastny Richard wrote: > > > > > >The problem I have with the FCC definition is that > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > >everybody seems at least to agree that bi-lateral > > > > > >peering does not scale globally. > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > the > > > > Internet > > > > > seems to have scaled reasonably well. > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > any Autonomous Systems peers with all other AS. > > > > > > > > I think we should define the difference between "Peering" and > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > reachability problem. > > > > > > > > /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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > 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 Apr 06 15:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaZe-0006S5-FF; Thu, 06 Apr 2006 15:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaZc-0006S0-MI for speermint@ietf.org; Thu, 06 Apr 2006 15:55:20 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaZc-000587-Da for speermint@ietf.org; Thu, 06 Apr 2006 15:55:20 -0400 Received: from HKaplan [216.41.24.2] by acmepacket.com with ESMTP (SMTPD-9.02) id A227046C; Thu, 06 Apr 2006 15:55:19 -0400 From: "Hadriel Kaplan" To: "'Stastny Richard'" , "'Medhavi Bhatia'" , Subject: RE: [Speermint] NATs and Firewalls Date: Thu, 6 Apr 2006 15:55:25 -0400 Message-ID: <089301c659b4$0c1efaa0$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQAAkOs+AADv7RAAAY9lmg In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4EC1@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Richard and Medhavi, Comments inline. > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 3:12 AM > To: Medhavi Bhatia; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls > > We should > not > > be taking the SBC functions as defined somewhere (especially since > they > > are incomplete) and try to write BCPs on them. We should be > defining > > interfaces in this WG, not elements, architecture etc. And no one said we should. (at least I never intended to) I have said, again and again, I am not proposing we mandate nor even mention SBCs in any documents. The entire conversation started because someone asked "does it matter if it crosses them" and I said it may. If some of the market uses them to do things for peering reasons, then perhaps we should address the needs of that part of the market as well, by not excluding them. Not by definining SBCs, not by requiring SBCs. At this point I regret having mentioned the term "SBC" because it's provided a lightning rod of hysteria and confusion when the point of my response was simply to suggest the requirements should be as open and broad as possible to achieve the goals of the WG. As I said, I think the best way to describe them, is if you imagine a peer's voip network is in it's own L3 VPN, which is an IETF-acceptable concept based on the work of other WGs. What that means, essentially, is of course there are one or more entry/exit peering points from/to that peer. (ie, proxies) And of course the peering proxy(s) points must share the same address space as the partner peer's exit/entry proxies. Both at a L3 IP level and at a L5 SIP level. What it does NOT mean, however, is that any nodes inside the L3-VPN peer's network are directly addressable at an L3 IP-Address level (FQDN is another matter). And naturally if we care about media (as the charter and I think most people using SIP today do), then we'll need to take into consideration the L3-VPN issues. How, or even IF, we fix them or address them or not I am NOT proposing, and I don't think we'll need to in the end. It's merely the recognition of such networks as legitimate peering partners that I request be considered. As several people have said, this whole concept may not make one bit of difference in the end. Or it may. I don't know until the requirements are done and the BCP ideas/mechanisms are discussed. Yeesh. :) -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 06 16:00:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaeE-0001Hv-Sv; Thu, 06 Apr 2006 16:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaeD-0001Ho-CU for speermint@ietf.org; Thu, 06 Apr 2006 16:00:05 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaeC-0005TB-Qn for speermint@ietf.org; Thu, 06 Apr 2006 16:00:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRady-00067b-IC; Thu, 06 Apr 2006 14:59:51 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 15:59:54 -0400 Message-ID: <025601c659b4$ae66b5f0$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 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE602@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQ X-PopBeforeSMTPSenders: br@brianrosen.net 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: 3f2cf88677bfbdeff30feb2c80e2257d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 remember that bit of the charter, but so far, I don't see how it applies. Sure, the media could take a different L3 path, which might involve different VPN tunnels than the signaling takes. Why would we care? Routers do this without any assistance. The signaling layer is unaware of any of this. What would be the use case that requires us to focus on the interactions between the application layer and the lower layers? It's not that it's out of scope, it's that the differences don't matter to SPEERMINT, at least I don't see anything that matters. I can see having peering policy take QoS capability into account. What I cannot see is having the peering system itself decide to use a mechanism (what mechanism could it be?) to send the media a particular way through the underlying network based on it. That means you may have more than one way to get from A to B, and your choice may depend on what QoS you can maintain across those ways, but not some mechanism that I don't even know exists that somehow influences the underlying network to take a particular path for the media. That is a really serious layer violation ("yeah, I know you can take this MPLS tunnel or that MPLS tunnel for any packets from A to B, but I want these here media packets to be sent on that tunnel"). That is WAY beyond anything I would want to touch any time soon, if at all, not to mention there isn't any way I know to do it at all. But then, I'm just one hummer here. Brian -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, April 06, 2006 3:42 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 12:28 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering > > Reinaldo > > The path taken by media either flows from one endpoint to the other > directly, or it goes through one or more media relays. The path media > takes > is defined by which media relays it must traverse. I don't think L3 > considerations apply to our work. [[Reinaldo]] Is it? The charter states that "In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers," Potentially media could follow a different route than signaling by tunneling (read VPNs) or MPLS. No media relays needed. If these interactions are out of scope, fine. > > I do think there are likely to be pin-hole firewalls that enable media > flows, although I don't think we need to discuss these either. > > What in any of our documents would offer different advice depending on the > path the media takes? > > What do we have to take into account? [[Reinaldo]] See above. > > I can imagine a discussion of marking of media. That could happen. > I can imagine a discussion of security of media across a peering point > which > would deal with key exchange although I'm not sure there is much we could > agree on that subject yet. [[Reinaldo]] Well, all this related to the path the media will take. If your "voip peer" will not provide QoS (or even carry media), then you might want to send your media through some other path. Will this the stated in the "peering policy" we will define? But, as I stated, if such interactions are out of scope, I will drop the subject. Thanks, Reinaldo > > I don't see much else we need to cover. Do you? > > Brian > > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:11 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering > > I'm not sure the discussion was about media relays. Was it? The > impression I had was that the discussion was about the path taken by > media when flowing between endpoints. > > From my point of view I see many discussions on SIP signaling and > "signaling only providers" and I worry that we are forgetting to take > media into account. > > Regards, > > Reinaldo > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 11:58 AM > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I am sorry to be on a campaign to stop arguments that may be > interesting > > and > > amusing to us all, but could someone come up with a scenario in which > any > > of > > our anticipated documents would somehow differentiate between a > peering > > mechanism that had media relays and one that did not? > > > > I think this whole line of discussion is interesting, but irrelevant > to > > the > > task at hand. > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > which > > contains some IP addresses and ports for it's desired media > connections, > > is > > presented to some proxy (a peering proxy which could be within the O > > network, or could be in some special peering network) who is going to > > determine a proxy in the T network to send the INVITE to. The > resulting > > 200 > > OK message, which most often will have an answer SDP with its own > media > > addresses and ports may traverse said proxies (if they Record Routed). > > > > WHO CARES what the media address/ports are? > > > > WHO is going to do anything different if they are the endpoint's, an > SBC > > in > > the O-network, T-network or anything else. > > > > Who in the O or T network would care if they were in an SBC inside a > > peering > > service? > > > > We need to think about media, because we have to deal with pinhole > > firewalls, we have to deal with NAT traversal, and we could imagine > > dealing > > with ancillary functions like transcoders, but really folks, whether > there > > are media relays anywhere just doesn't seem to matter; you can't tell > if > > there are or there aren't and you don't do anything differently. > > > > Should anyone care, I personally think if systems are properly > designed, > > the > > only media relays in the path pretty that much have to be there are > for > > legal intercept, and if we did that correctly (at L3 or below) then > even > > they would not be needed and we could get back to the original idea > that > > media flows direct between the UAs. That does not obviate any > firewall > > needs. I am under no illusions that "properly designed" is often > > achieved. > > That having been said, lots of folks seem to like media relays, I hope > > they > > don't screw up when emergency calls are sent through, and we have to > > accept > > that they may be all over the place. But, again, who cares? > > > > Brian > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 1:38 PM > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > Reinaldo, > > > > Do you have an example of an operator doing just media but is not an > L3 > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > only > > or signaling and media. > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 1:02 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > > -transitvs peering > > > > > > Okay, so when coming up with these terms we cannot forget about > media. > > > So, when somebody provides "peering" and/or "transit" services, we > > need > > > to specify in the context of speermint if that means: > > > > > > a) all IP packets (which includes media) > > > b) only signaling > > > ... > > > > > > Well, you get the idea... > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > To: speermint@ietf.org > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > Interconnect > > - > > > > transitvs peering > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > Stastny Richard wrote: > > > > > >The problem I have with the FCC definition is that > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > >everybody seems at least to agree that bi-lateral > > > > > >peering does not scale globally. > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > the > > > > Internet > > > > > seems to have scaled reasonably well. > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > any Autonomous Systems peers with all other AS. > > > > > > > > I think we should define the difference between "Peering" and > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > reachability problem. > > > > > > > > /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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > 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 Apr 06 16:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaiE-0002il-HN; Thu, 06 Apr 2006 16:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaiD-0002ig-95 for speermint@ietf.org; Thu, 06 Apr 2006 16:04:13 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaiC-0005ak-NP for speermint@ietf.org; Thu, 06 Apr 2006 16:04:13 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRahk-0006Ml-8j; Thu, 06 Apr 2006 15:03:44 -0500 From: "Brian Rosen" To: "'Malas, Daryl'" , "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering Date: Thu, 6 Apr 2006 16:03:45 -0400 Message-ID: <025a01c659b5$39bc4430$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAWzRwAACSjxA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: 1.1 (+) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 doesn't make sense to me is listing categories of peering that don't have any different behavior specified in our documents. It's all nice and warm to note that there are public and private peering arrangements, but unless we do something different for them, why do we need to even define them? I'd hate to try to define the difference between "Carrier Peering" and "Private Peering" for example. The easiest thing to do is to not differentiate! Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Sent: Thursday, April 06, 2006 3:49 PM To: Reinaldo Penno; br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering I think we can simplify these discussions by specifying the policies relative to unique peering environments. As I discussed before, can we classify the peering environments into categories such as: Public peering - 1. Create Definition 2. Define policies 3. Develop use cases Private peering - 1. Carrier peering - 1. Any others??? - I think the majority of the ambiguity is created from the varying perspectives on peering. The 3 categories listed above are simply my guess to the most common perspectives in this WG. With each, we can tackle the various L3 and L5 issues, but at least we can maintain the conversation within the framework of the specified peering environment. I think this will eliminate some of the ambiguity. Make sense? --Daryl M. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, April 06, 2006 1:42 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 12:28 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering > > Reinaldo > > The path taken by media either flows from one endpoint to the other > directly, or it goes through one or more media relays. The path media > takes > is defined by which media relays it must traverse. I don't think L3 > considerations apply to our work. [[Reinaldo]] Is it? The charter states that "In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers," Potentially media could follow a different route than signaling by tunneling (read VPNs) or MPLS. No media relays needed. If these interactions are out of scope, fine. > > I do think there are likely to be pin-hole firewalls that enable media > flows, although I don't think we need to discuss these either. > > What in any of our documents would offer different advice depending on the > path the media takes? > > What do we have to take into account? [[Reinaldo]] See above. > > I can imagine a discussion of marking of media. That could happen. > I can imagine a discussion of security of media across a peering point > which > would deal with key exchange although I'm not sure there is much we could > agree on that subject yet. [[Reinaldo]] Well, all this related to the path the media will take. If your "voip peer" will not provide QoS (or even carry media), then you might want to send your media through some other path. Will this the stated in the "peering policy" we will define? But, as I stated, if such interactions are out of scope, I will drop the subject. Thanks, Reinaldo > > I don't see much else we need to cover. Do you? > > Brian > > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:11 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering > > I'm not sure the discussion was about media relays. Was it? The > impression I had was that the discussion was about the path taken by > media when flowing between endpoints. > > From my point of view I see many discussions on SIP signaling and > "signaling only providers" and I worry that we are forgetting to take > media into account. > > Regards, > > Reinaldo > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 11:58 AM > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I am sorry to be on a campaign to stop arguments that may be > interesting > > and > > amusing to us all, but could someone come up with a scenario in which > any > > of > > our anticipated documents would somehow differentiate between a > peering > > mechanism that had media relays and one that did not? > > > > I think this whole line of discussion is interesting, but irrelevant > to > > the > > task at hand. > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > which > > contains some IP addresses and ports for it's desired media > connections, > > is > > presented to some proxy (a peering proxy which could be within the O > > network, or could be in some special peering network) who is going to > > determine a proxy in the T network to send the INVITE to. The > resulting > > 200 > > OK message, which most often will have an answer SDP with its own > media > > addresses and ports may traverse said proxies (if they Record Routed). > > > > WHO CARES what the media address/ports are? > > > > WHO is going to do anything different if they are the endpoint's, an > SBC > > in > > the O-network, T-network or anything else. > > > > Who in the O or T network would care if they were in an SBC inside a > > peering > > service? > > > > We need to think about media, because we have to deal with pinhole > > firewalls, we have to deal with NAT traversal, and we could imagine > > dealing > > with ancillary functions like transcoders, but really folks, whether > there > > are media relays anywhere just doesn't seem to matter; you can't tell > if > > there are or there aren't and you don't do anything differently. > > > > Should anyone care, I personally think if systems are properly > designed, > > the > > only media relays in the path pretty that much have to be there are > for > > legal intercept, and if we did that correctly (at L3 or below) then > even > > they would not be needed and we could get back to the original idea > that > > media flows direct between the UAs. That does not obviate any > firewall > > needs. I am under no illusions that "properly designed" is often > > achieved. > > That having been said, lots of folks seem to like media relays, I hope > > they > > don't screw up when emergency calls are sent through, and we have to > > accept > > that they may be all over the place. But, again, who cares? > > > > Brian > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 1:38 PM > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > Reinaldo, > > > > Do you have an example of an operator doing just media but is not an > L3 > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > only > > or signaling and media. > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 1:02 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > > -transitvs peering > > > > > > Okay, so when coming up with these terms we cannot forget about > media. > > > So, when somebody provides "peering" and/or "transit" services, we > > need > > > to specify in the context of speermint if that means: > > > > > > a) all IP packets (which includes media) > > > b) only signaling > > > ... > > > > > > Well, you get the idea... > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > To: speermint@ietf.org > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > Interconnect > > - > > > > transitvs peering > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > Stastny Richard wrote: > > > > > >The problem I have with the FCC definition is that > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > >everybody seems at least to agree that bi-lateral > > > > > >peering does not scale globally. > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > the > > > > Internet > > > > > seems to have scaled reasonably well. > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > any Autonomous Systems peers with all other AS. > > > > > > > > I think we should define the difference between "Peering" and > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > reachability problem. > > > > > > > > /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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > 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 Apr 06 16:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRanL-0005C9-OD; Thu, 06 Apr 2006 16:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRanK-0005C4-H7 for speermint@ietf.org; Thu, 06 Apr 2006 16:09:30 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRanJ-0005uY-P0 for speermint@ietf.org; Thu, 06 Apr 2006 16:09:30 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:09: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] RE: Background Reading on NGN Interconnect - transit vs peering Date: Thu, 6 Apr 2006 16:09:31 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A6B5@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering thread-index: AcZZkVGSW7RUIQ45RKquz9/QqtlCTgAIjkOg From: "Bob Natale" To: "Otmar Lendl" X-OriginalArrivalTime: 06 Apr 2006 20:09:26.0344 (UTC) FILETIME=[0110DC80:01C659B6] 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 Hi Otmar, everyone: In my presentation in Dallas dealing with the Requirements BCP milestone, I noted that our charter seems to present the differences between "interconnection" and "peering" thusly: "Scope: Interconnection versus Peering? Interconnection (for SPEERMINT -- from the charter text): - Both signaling and media flows must be taken into consideration=20 - Use cases that include the interaction between the application layer and lower network layers - or the dependence of specific application layer use cases on lower layers=20 Peering (for SPEERMINT -- from the charter text): - The interconnection between application layer entities such as SIP servers - as opposed to interconnection at the IP network layer" Assuming the charter text says what it intended to say (which might be questionable at this point): - Peering is a form of interconnection with the following characteristics: - is not concerned with use cases below L5 - is not concerned with media flows - is not concerned with L5 dependencies on lower layers We can (and possibly should) broaden our scope beyond that, but we should also ensure that the charter text then says what we mean. Cheers, BobN -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Thursday, April 06, 2006 11:44 AM To: speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering On 2006/04/06 17:04, Richard Shockey wrote: > Stastny Richard wrote: > >The problem I have with the FCC definition is that is states that > >peering is always bi-lateral > > > >The major reason for setting up SPEERMINT was that everybody seems at > >least to agree that bi-lateral peering does not scale globally. > > All peering arrangements among IP backbones are bi-lateral and the > Internet seems to have scaled reasonably well. The reason for that is "transit". It is thus not necessary that any Autonomous Systems peers with all other AS. I think we should define the difference between "Peering" and "Interconnection" (which in my mind also allows for transit). Bi-lateral peering alone will definitly not solve the world-wide reachability problem. /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 Thu Apr 06 16:19:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaxC-0002RY-MX; Thu, 06 Apr 2006 16:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRaxB-0002RT-Ck for speermint@ietf.org; Thu, 06 Apr 2006 16:19:41 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRaxA-0006MN-O9 for speermint@ietf.org; Thu, 06 Apr 2006 16:19:41 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 06 Apr 2006 13:19:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,93,1144047600"; d="scan'208"; a="538256374:sNHT27198284" 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] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 16:19:38 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE605@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8A= From: "Reinaldo Penno" To: , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 1:00 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > I remember that bit of the charter, but so far, I don't see how it > applies. > Sure, the media could take a different L3 path, which might involve > different VPN tunnels than the signaling takes. >=20 > Why would we care? Routers do this without any assistance. The signaling > layer is unaware of any of this. >=20 > What would be the use case that requires us to focus on the interactions > between the application layer and the lower layers? >=20 > It's not that it's out of scope, it's that the differences don't matter to > SPEERMINT, at least I don't see anything that matters. >=20 > I can see having peering policy take QoS capability into account. What I > cannot see is having the peering system itself decide to use a mechanism > (what mechanism could it be?) [[Reinaldo]]=20 Is this a decision based on the policies announced by various peers and taken by one device or all devices need to be included in the decision? What is the "peering system"? to send the media a particular way through > the > underlying network based on it. That means you may have more than one way > to get from A to B, and your choice may depend on what QoS you can > maintain > across those ways,=20 [[Reinaldo]]=20 Okay so far. but not some mechanism that I don't even know exists > that > somehow influences the underlying network to take a particular path for > the > media. =20 [[Reinaldo]] Not sure I follow you here.=20 That is a really serious layer violation ("yeah, I know you can > take > this MPLS tunnel or that MPLS tunnel for any packets from A to B, but I > want > these here media packets to be sent on that tunnel"). =20 [[Reinaldo]]=20 I definitely do not follow you here. A routing table can be populated by peering with others routers, management systems, as a result of off-line TE tools, manual configuration ("I know that path is better, let me direct packets there". Is that human performing a layer violation?) Can you elaborate on who is performing the layer violation? =20 That is WAY beyond > anything I would want to touch any time soon, if at all, not to mention > there isn't any way I know to do it at all. >=20 > But then, I'm just one hummer here. >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:42 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 12:28 PM > > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > Reinaldo > > > > The path taken by media either flows from one endpoint to the other > > directly, or it goes through one or more media relays. The path media > > takes > > is defined by which media relays it must traverse. I don't think L3 > > considerations apply to our work. > [[Reinaldo]] >=20 > Is it? The charter states that >=20 > "In addition, the working group recognizes that > there will be use cases that require SPEERMINT to focus on the > interaction between the application layer and lower network > layers," >=20 > Potentially media could follow a different route than signaling by > tunneling (read VPNs) or MPLS. No media relays needed. If these > interactions are out of scope, fine. >=20 > > > > I do think there are likely to be pin-hole firewalls that enable media > > flows, although I don't think we need to discuss these either. > > > > What in any of our documents would offer different advice depending on > the > > path the media takes? > > > > What do we have to take into account? > [[Reinaldo]] >=20 > See above. >=20 > > > > I can imagine a discussion of marking of media. That could happen. > > I can imagine a discussion of security of media across a peering point > > which > > would deal with key exchange although I'm not sure there is much we > could > > agree on that subject yet. > [[Reinaldo]] >=20 > Well, all this related to the path the media will take. If your "voip > peer" will not provide QoS (or even carry media), then you might want to > send your media through some other path. Will this the stated in the > "peering policy" we will define? >=20 > But, as I stated, if such interactions are out of scope, I will drop the > subject. >=20 > Thanks, >=20 > Reinaldo >=20 > > > > I don't see much else we need to cover. Do you? > > > > Brian > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 3:11 PM > > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > I'm not sure the discussion was about media relays. Was it? The > > impression I had was that the discussion was about the path taken by > > media when flowing between endpoints. > > > > From my point of view I see many discussions on SIP signaling and > > "signaling only providers" and I worry that we are forgetting to take > > media into account. > > > > Regards, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, April 06, 2006 11:58 AM > > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > > transitvs peering > > > > > > I am sorry to be on a campaign to stop arguments that may be > > interesting > > > and > > > amusing to us all, but could someone come up with a scenario in > which > > any > > > of > > > our anticipated documents would somehow differentiate between a > > peering > > > mechanism that had media relays and one that did not? > > > > > > I think this whole line of discussion is interesting, but irrelevant > > to > > > the > > > task at hand. > > > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > > which > > > contains some IP addresses and ports for it's desired media > > connections, > > > is > > > presented to some proxy (a peering proxy which could be within the O > > > network, or could be in some special peering network) who is going > to > > > determine a proxy in the T network to send the INVITE to. The > > resulting > > > 200 > > > OK message, which most often will have an answer SDP with its own > > media > > > addresses and ports may traverse said proxies (if they Record > Routed). > > > > > > WHO CARES what the media address/ports are? > > > > > > WHO is going to do anything different if they are the endpoint's, an > > SBC > > > in > > > the O-network, T-network or anything else. > > > > > > Who in the O or T network would care if they were in an SBC inside a > > > peering > > > service? > > > > > > We need to think about media, because we have to deal with pinhole > > > firewalls, we have to deal with NAT traversal, and we could imagine > > > dealing > > > with ancillary functions like transcoders, but really folks, whether > > there > > > are media relays anywhere just doesn't seem to matter; you can't > tell > > if > > > there are or there aren't and you don't do anything differently. > > > > > > Should anyone care, I personally think if systems are properly > > designed, > > > the > > > only media relays in the path pretty that much have to be there are > > for > > > legal intercept, and if we did that correctly (at L3 or below) then > > even > > > they would not be needed and we could get back to the original idea > > that > > > media flows direct between the UAs. That does not obviate any > > firewall > > > needs. I am under no illusions that "properly designed" is often > > > achieved. > > > That having been said, lots of folks seem to like media relays, I > hope > > > they > > > don't screw up when emergency calls are sent through, and we have to > > > accept > > > that they may be all over the place. But, again, who cares? > > > > > > Brian > > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Thursday, April 06, 2006 1:38 PM > > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN > > > Interconnect-transitvs peering > > > > > > Reinaldo, > > > > > > Do you have an example of an operator doing just media but is not an > > L3 > > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > > only > > > or signaling and media. > > > > > > -Medhavi. > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Thursday, April 06, 2006 1:02 PM > > > > To: Otmar Lendl; speermint@ietf.org > > > > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect > > > -transitvs peering > > > > > > > > Okay, so when coming up with these terms we cannot forget about > > media. > > > > So, when somebody provides "peering" and/or "transit" services, we > > > need > > > > to specify in the context of speermint if that means: > > > > > > > > a) all IP packets (which includes media) > > > > b) only signaling > > > > ... > > > > > > > > Well, you get the idea... > > > > > > > > > -----Original Message----- > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > > To: speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > > Interconnect > > > - > > > > > transitvs peering > > > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > > Stastny Richard wrote: > > > > > > >The problem I have with the FCC definition is that > > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > > >everybody seems at least to agree that bi-lateral > > > > > > >peering does not scale globally. > > > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > > the > > > > > Internet > > > > > > seems to have scaled reasonably well. > > > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > > any Autonomous Systems peers with all other AS. > > > > > > > > > > I think we should define the difference between "Peering" and > > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > > reachability problem. > > > > > > > > > > /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 > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > > 4/5/2006 > > > > > > > > > > _______________________________________________ > > > 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 Apr 06 16:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbGw-0004KG-6m; Thu, 06 Apr 2006 16:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbGu-0004Jo-HK for speermint@ietf.org; Thu, 06 Apr 2006 16:40:04 -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 1FRbGu-0006qf-0f for speermint@ietf.org; Thu, 06 Apr 2006 16:40:04 -0400 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k36KdwaK000854; Thu, 6 Apr 2006 20:39:59 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id A6CAD78B444; Thu, 6 Apr 2006 20:39:58 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 722F878B438; Thu, 6 Apr 2006 20:39:58 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 14:39:58 -0600 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] RE: Background Reading on NGNInterconnect-transitvspeering Date: Thu, 6 Apr 2006 14:39:57 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAWzRwAACSjxAAAVd2UA== From: "Malas, Daryl" To: , "Reinaldo Penno" , "Medhavi Bhatia" , "Otmar Lendl" , X-OriginalArrivalTime: 06 Apr 2006 20:39:58.0261 (UTC) FILETIME=[44F93650:01C659BA] X-Spam-Score: 1.2 (+) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d 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 So, if we don't differentiate, then we need to simplify; otherwise, I think we will have a difficult time ever reaching consensus. --Daryl M. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, April 06, 2006 2:04 PM To: Malas, Daryl; 'Reinaldo Penno'; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering What doesn't make sense to me is listing categories of peering that don't have any different behavior specified in our documents. It's all nice and warm to note that there are public and private peering arrangements, but unless we do something different for them, why do we need to even define them? I'd hate to try to define the difference between "Carrier Peering" and "Private Peering" for example.=20 The easiest thing to do is to not differentiate!=20 Brian -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Thursday, April 06, 2006 3:49 PM To: Reinaldo Penno; br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvspeering I think we can simplify these discussions by specifying the policies relative to unique peering environments. As I discussed before, can we classify the peering environments into categories such as: Public peering -=20 1. Create Definition 2. Define policies 3. Develop use cases Private peering - 1. Carrier peering - 1. Any others??? - I think the majority of the ambiguity is created from the varying perspectives on peering. The 3 categories listed above are simply my guess to the most common perspectives in this WG. With each, we can tackle the various L3 and L5 issues, but at least we can maintain the conversation within the framework of the specified peering environment. I think this will eliminate some of the ambiguity. Make sense? --Daryl M. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Thursday, April 06, 2006 1:42 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 12:28 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > Reinaldo >=20 > The path taken by media either flows from one endpoint to the other > directly, or it goes through one or more media relays. The path media > takes > is defined by which media relays it must traverse. I don't think L3 > considerations apply to our work. [[Reinaldo]]=20 Is it? The charter states that=20 "In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers," Potentially media could follow a different route than signaling by tunneling (read VPNs) or MPLS. No media relays needed. If these interactions are out of scope, fine. >=20 > I do think there are likely to be pin-hole firewalls that enable media > flows, although I don't think we need to discuss these either. >=20 > What in any of our documents would offer different advice depending on the > path the media takes? >=20 > What do we have to take into account? [[Reinaldo]]=20 See above. >=20 > I can imagine a discussion of marking of media. That could happen. > I can imagine a discussion of security of media across a peering point > which > would deal with key exchange although I'm not sure there is much we could > agree on that subject yet. [[Reinaldo]]=20 Well, all this related to the path the media will take. If your "voip peer" will not provide QoS (or even carry media), then you might want to send your media through some other path. Will this the stated in the "peering policy" we will define? But, as I stated, if such interactions are out of scope, I will drop the subject. Thanks, Reinaldo >=20 > I don't see much else we need to cover. Do you? >=20 > Brian >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:11 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 > I'm not sure the discussion was about media relays. Was it? The > impression I had was that the discussion was about the path taken by > media when flowing between endpoints. >=20 > From my point of view I see many discussions on SIP signaling and > "signaling only providers" and I worry that we are forgetting to take > media into account. >=20 > Regards, >=20 > Reinaldo >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 11:58 AM > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I am sorry to be on a campaign to stop arguments that may be > interesting > > and > > amusing to us all, but could someone come up with a scenario in which > any > > of > > our anticipated documents would somehow differentiate between a > peering > > mechanism that had media relays and one that did not? > > > > I think this whole line of discussion is interesting, but irrelevant > to > > the > > task at hand. > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > which > > contains some IP addresses and ports for it's desired media > connections, > > is > > presented to some proxy (a peering proxy which could be within the O > > network, or could be in some special peering network) who is going to > > determine a proxy in the T network to send the INVITE to. The > resulting > > 200 > > OK message, which most often will have an answer SDP with its own > media > > addresses and ports may traverse said proxies (if they Record Routed). > > > > WHO CARES what the media address/ports are? > > > > WHO is going to do anything different if they are the endpoint's, an > SBC > > in > > the O-network, T-network or anything else. > > > > Who in the O or T network would care if they were in an SBC inside a > > peering > > service? > > > > We need to think about media, because we have to deal with pinhole > > firewalls, we have to deal with NAT traversal, and we could imagine > > dealing > > with ancillary functions like transcoders, but really folks, whether > there > > are media relays anywhere just doesn't seem to matter; you can't tell > if > > there are or there aren't and you don't do anything differently. > > > > Should anyone care, I personally think if systems are properly > designed, > > the > > only media relays in the path pretty that much have to be there are > for > > legal intercept, and if we did that correctly (at L3 or below) then > even > > they would not be needed and we could get back to the original idea > that > > media flows direct between the UAs. That does not obviate any > firewall > > needs. I am under no illusions that "properly designed" is often > > achieved. > > That having been said, lots of folks seem to like media relays, I hope > > they > > don't screw up when emergency calls are sent through, and we have to > > accept > > that they may be all over the place. But, again, who cares? > > > > Brian > > > > -----Original Message----- > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > Sent: Thursday, April 06, 2006 1:38 PM > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > Reinaldo, > > > > Do you have an example of an operator doing just media but is not an > L3 > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > only > > or signaling and media. > > > > -Medhavi. > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 1:02 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect > > -transitvs peering > > > > > > Okay, so when coming up with these terms we cannot forget about > media. > > > So, when somebody provides "peering" and/or "transit" services, we > > need > > > to specify in the context of speermint if that means: > > > > > > a) all IP packets (which includes media) > > > b) only signaling > > > ... > > > > > > Well, you get the idea... > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > To: speermint@ietf.org > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > Interconnect > > - > > > > transitvs peering > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > Stastny Richard wrote: > > > > > >The problem I have with the FCC definition is that > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > >everybody seems at least to agree that bi-lateral > > > > > >peering does not scale globally. > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > the > > > > Internet > > > > > seems to have scaled reasonably well. > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > any Autonomous Systems peers with all other AS. > > > > > > > > I think we should define the difference between "Peering" and > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > reachability problem. > > > > > > > > /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 > > > > > > -- > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > 4/5/2006 > > > > > > > _______________________________________________ > > 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 Apr 06 16:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbK8-00060a-Dd; Thu, 06 Apr 2006 16:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbK6-00060V-ST for speermint@ietf.org; Thu, 06 Apr 2006 16:43:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRbK6-0006sv-8F for speermint@ietf.org; Thu, 06 Apr 2006 16:43:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRbJu-0000NP-SP; Thu, 06 Apr 2006 15:43:11 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 16:43:15 -0400 Message-ID: <025c01c659ba$bc806cc0$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 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE605@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIA== X-PopBeforeSMTPSenders: br@brianrosen.net 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: 94962611154c8404498b19f744990308 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Somehow, we're not communicating. Maybe we have to take a step back and see if we agree on the real basics. I believe that when we get right down to it, SPEERMINT is going to define in a BCP what a SIP proxy server does to get a call from one domain to another which is harder than just the normal 3261 interdomain routing mechanism. That's about all we are doing. It's that simple, but, we all know, it is NOT at all simple. If you think we are doing something way beyond that, what is it? If you agree with that, then "peering system" is just the proxy server(s) that do what the BCPs say to get the call from one domain to another. So the SIP proxy is at L7. If that L7 entity tells a router how to route a flow (at L3 or worse, sub IP), then you have a layer violation. If the SIP proxy server isn't telling the router, what is, and why is it in scope? This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any other kind of links down in the router. This doesn't say you can't mark media packets in some way that sends them down some specific tunnels. This doesn't say you can't create any kind of static routing mechanisms you like for any set of flows you can identify. It does say that SPEERMINT is defining what goes on in the proxy servers that make the L7 call routing decisions. Brian -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, April 06, 2006 4:20 PM To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 1:00 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering > > I remember that bit of the charter, but so far, I don't see how it > applies. > Sure, the media could take a different L3 path, which might involve > different VPN tunnels than the signaling takes. > > Why would we care? Routers do this without any assistance. The signaling > layer is unaware of any of this. > > What would be the use case that requires us to focus on the interactions > between the application layer and the lower layers? > > It's not that it's out of scope, it's that the differences don't matter to > SPEERMINT, at least I don't see anything that matters. > > I can see having peering policy take QoS capability into account. What I > cannot see is having the peering system itself decide to use a mechanism > (what mechanism could it be?) [[Reinaldo]] Is this a decision based on the policies announced by various peers and taken by one device or all devices need to be included in the decision? What is the "peering system"? to send the media a particular way through > the > underlying network based on it. That means you may have more than one way > to get from A to B, and your choice may depend on what QoS you can > maintain > across those ways, [[Reinaldo]] Okay so far. but not some mechanism that I don't even know exists > that > somehow influences the underlying network to take a particular path for > the > media. [[Reinaldo]] Not sure I follow you here. That is a really serious layer violation ("yeah, I know you can > take > this MPLS tunnel or that MPLS tunnel for any packets from A to B, but I > want > these here media packets to be sent on that tunnel"). [[Reinaldo]] I definitely do not follow you here. A routing table can be populated by peering with others routers, management systems, as a result of off-line TE tools, manual configuration ("I know that path is better, let me direct packets there". Is that human performing a layer violation?) Can you elaborate on who is performing the layer violation? That is WAY beyond > anything I would want to touch any time soon, if at all, not to mention > there isn't any way I know to do it at all. > > But then, I'm just one hummer here. > > Brian > > > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 3:42 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 12:28 PM > > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > Reinaldo > > > > The path taken by media either flows from one endpoint to the other > > directly, or it goes through one or more media relays. The path media > > takes > > is defined by which media relays it must traverse. I don't think L3 > > considerations apply to our work. > [[Reinaldo]] > > Is it? The charter states that > > "In addition, the working group recognizes that > there will be use cases that require SPEERMINT to focus on the > interaction between the application layer and lower network > layers," > > Potentially media could follow a different route than signaling by > tunneling (read VPNs) or MPLS. No media relays needed. If these > interactions are out of scope, fine. > > > > > I do think there are likely to be pin-hole firewalls that enable media > > flows, although I don't think we need to discuss these either. > > > > What in any of our documents would offer different advice depending on > the > > path the media takes? > > > > What do we have to take into account? > [[Reinaldo]] > > See above. > > > > > I can imagine a discussion of marking of media. That could happen. > > I can imagine a discussion of security of media across a peering point > > which > > would deal with key exchange although I'm not sure there is much we > could > > agree on that subject yet. > [[Reinaldo]] > > Well, all this related to the path the media will take. If your "voip > peer" will not provide QoS (or even carry media), then you might want to > send your media through some other path. Will this the stated in the > "peering policy" we will define? > > But, as I stated, if such interactions are out of scope, I will drop the > subject. > > Thanks, > > Reinaldo > > > > > I don't see much else we need to cover. Do you? > > > > Brian > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 3:11 PM > > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > I'm not sure the discussion was about media relays. Was it? The > > impression I had was that the discussion was about the path taken by > > media when flowing between endpoints. > > > > From my point of view I see many discussions on SIP signaling and > > "signaling only providers" and I worry that we are forgetting to take > > media into account. > > > > Regards, > > > > Reinaldo > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, April 06, 2006 11:58 AM > > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > > transitvs peering > > > > > > I am sorry to be on a campaign to stop arguments that may be > > interesting > > > and > > > amusing to us all, but could someone come up with a scenario in > which > > any > > > of > > > our anticipated documents would somehow differentiate between a > > peering > > > mechanism that had media relays and one that did not? > > > > > > I think this whole line of discussion is interesting, but irrelevant > > to > > > the > > > task at hand. > > > > > > Peering occurs when a SIP INVITE, most often with an offer SDP body, > > which > > > contains some IP addresses and ports for it's desired media > > connections, > > > is > > > presented to some proxy (a peering proxy which could be within the O > > > network, or could be in some special peering network) who is going > to > > > determine a proxy in the T network to send the INVITE to. The > > resulting > > > 200 > > > OK message, which most often will have an answer SDP with its own > > media > > > addresses and ports may traverse said proxies (if they Record > Routed). > > > > > > WHO CARES what the media address/ports are? > > > > > > WHO is going to do anything different if they are the endpoint's, an > > SBC > > > in > > > the O-network, T-network or anything else. > > > > > > Who in the O or T network would care if they were in an SBC inside a > > > peering > > > service? > > > > > > We need to think about media, because we have to deal with pinhole > > > firewalls, we have to deal with NAT traversal, and we could imagine > > > dealing > > > with ancillary functions like transcoders, but really folks, whether > > there > > > are media relays anywhere just doesn't seem to matter; you can't > tell > > if > > > there are or there aren't and you don't do anything differently. > > > > > > Should anyone care, I personally think if systems are properly > > designed, > > > the > > > only media relays in the path pretty that much have to be there are > > for > > > legal intercept, and if we did that correctly (at L3 or below) then > > even > > > they would not be needed and we could get back to the original idea > > that > > > media flows direct between the UAs. That does not obviate any > > firewall > > > needs. I am under no illusions that "properly designed" is often > > > achieved. > > > That having been said, lots of folks seem to like media relays, I > hope > > > they > > > don't screw up when emergency calls are sent through, and we have to > > > accept > > > that they may be all over the place. But, again, who cares? > > > > > > Brian > > > > > > -----Original Message----- > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > Sent: Thursday, April 06, 2006 1:38 PM > > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN > > > Interconnect-transitvs peering > > > > > > Reinaldo, > > > > > > Do you have an example of an operator doing just media but is not an > > L3 > > > carrier (e.g ISP/Transit)? If not, we can just talk about signaling > > only > > > or signaling and media. > > > > > > -Medhavi. > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Thursday, April 06, 2006 1:02 PM > > > > To: Otmar Lendl; speermint@ietf.org > > > > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect > > > -transitvs peering > > > > > > > > Okay, so when coming up with these terms we cannot forget about > > media. > > > > So, when somebody provides "peering" and/or "transit" services, we > > > need > > > > to specify in the context of speermint if that means: > > > > > > > > a) all IP packets (which includes media) > > > > b) only signaling > > > > ... > > > > > > > > Well, you get the idea... > > > > > > > > > -----Original Message----- > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > > To: speermint@ietf.org > > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > > Interconnect > > > - > > > > > transitvs peering > > > > > > > > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > > > Stastny Richard wrote: > > > > > > >The problem I have with the FCC definition is that > > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > > >everybody seems at least to agree that bi-lateral > > > > > > >peering does not scale globally. > > > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral and > > the > > > > > Internet > > > > > > seems to have scaled reasonably well. > > > > > > > > > > The reason for that is "transit". It is thus not necessary that > > > > > any Autonomous Systems peers with all other AS. > > > > > > > > > > I think we should define the difference between "Peering" and > > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > > > Bi-lateral peering alone will definitly not solve the world-wide > > > > > reachability problem. > > > > > > > > > > /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 > > > > > > > > -- > > > > No virus found in this incoming message. > > > > Checked by AVG Free Edition. > > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > > 4/5/2006 > > > > > > > > > > _______________________________________________ > > > 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 Apr 06 16:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbMq-00072g-91; Thu, 06 Apr 2006 16:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbMp-00072a-41 for speermint@ietf.org; Thu, 06 Apr 2006 16:46:11 -0400 Received: from mail2.nextone.com ([209.125.86.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRbMo-0006uq-Qs for speermint@ietf.org; Thu, 06 Apr 2006 16:46:11 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:46:10 -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] NATs and Firewalls -- scope of requirements Date: Thu, 6 Apr 2006 16:46:20 -0400 Message-ID: <8812D8156467224C9E9739E513037EF155A704@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] NATs and Firewalls -- scope of requirements thread-index: AcZYuXyi5X4kMntWQ7CCMmoxP2btVAAB2tNQAAMgH6AABGzpcAACaXJQAAkOs+AADv7RAAAY9lmgAANiyHA= From: "Bob Natale" To: "Hadriel Kaplan" X-OriginalArrivalTime: 06 Apr 2006 20:46:10.0354 (UTC) FILETIME=[22C21920:01C659BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Hadriel, Just one clarification concerning your suggestion that "the requirements should be as open and broad as _possible_ to achieve the goals of the WG". I understand and in some ways sympathize with that statement. I just want to point out that our charter calls for the Requirements BCP milestone to address "the minimum set" of such requirements. I interpret that to mean something like "only as open and broad as _necessary_" [to achieve whatever we end up deciding are the interoperable aspects of "session peering for multimedia interconnect"]. Cheers, BobN -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Thursday, April 06, 2006 3:55 PM To: 'Stastny Richard'; Medhavi Bhatia; speermint@ietf.org Subject: RE: [Speermint] NATs and Firewalls Hi Richard and Medhavi, Comments inline.=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 3:12 AM > To: Medhavi Bhatia; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] NATs and Firewalls >=20 > We should > not > > be taking the SBC functions as defined somewhere (especially since > they > > are incomplete) and try to write BCPs on them. We should be > defining > > interfaces in this WG, not elements, architecture etc. And no one said we should. (at least I never intended to) I have said, again and again, I am not proposing we mandate nor even mention SBCs in any documents. The entire conversation started because someone asked "does it matter if it crosses them" and I said it may. If some of the market uses them to do things for peering reasons, then perhaps we should address the needs of that part of the market as well, by not excluding them. Not by definining SBCs, not by requiring SBCs. =20 At this point I regret having mentioned the term "SBC" because it's provided a lightning rod of hysteria and confusion when the point of my response was simply to suggest the requirements should be as open and broad as possible to achieve the goals of the WG. As I said, I think the best way to describe them, is if you imagine a peer's voip network is in it's own L3 VPN, which is an IETF-acceptable concept based on the work of other WGs. What that means, essentially, is of course there are one or more entry/exit peering points from/to that peer. (ie, proxies) And of course the peering proxy(s) points must share the same address space as the partner peer's exit/entry proxies. Both at a L3 IP level and at a L5 SIP level. What it does NOT mean, however, is that any nodes inside the L3-VPN peer's network are directly addressable at an L3 IP-Address level (FQDN is another matter). And naturally if we care about media (as the charter and I think most people using SIP today do), then we'll need to take into consideration the L3-VPN issues. How, or even IF, we fix them or address them or not I am NOT proposing, and I don't think we'll need to in the end. It's merely the recognition of such networks as legitimate peering partners that I request be considered. As several people have said, this whole concept may not make one bit of difference in the end. Or it may. I don't know until the requirements are done and the BCP ideas/mechanisms are discussed. =20 Yeesh. :) -hadriel _______________________________________________ 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 Apr 06 18:00:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRcWY-0007uR-Hl; Thu, 06 Apr 2006 18:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRcWY-0007uM-3z for speermint@ietf.org; Thu, 06 Apr 2006 18:00:18 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRcWW-0000db-9Q for speermint@ietf.org; Thu, 06 Apr 2006 18:00:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 06 Apr 2006 15:00:15 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,94,1144047600"; d="scan'208"; a="541509812:sNHT31172232" 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] RE: Background Reading on NGN Interconnect-transitvs peering Date: Thu, 6 Apr 2006 18:00:13 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE607@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAACJnEw From: "Reinaldo Penno" To: , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 06, 2006 1:43 PM > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > transitvs peering >=20 > Somehow, we're not communicating. >=20 > Maybe we have to take a step back and see if we agree on the real basics. >=20 > I believe that when we get right down to it, SPEERMINT is going to define > in > a BCP what a SIP proxy server does to get a call from one domain to > another > which is harder than just the normal 3261 interdomain routing mechanism. >=20 > That's about all we are doing. It's that simple, but, we all know, it is > NOT at all simple. >=20 > If you think we are doing something way beyond that, what is it? [[Reinaldo]]=20 As you said, I think it is NOT that simple. >=20 > If you agree with that, then "peering system" is just the proxy server(s) > that do what the BCPs say to get the call from one domain to another. >=20 > So the SIP proxy is at L7. If that L7 entity tells a router how to route > a > flow (at L3 or worse, sub IP), then you have a layer violation. [[Reinaldo]]=20 I believe this is where we part ways. I see what you mean, but I interpret it differently. I think routing of the media associated with a L7 SIP routing decision is also a L7 routing decision since it is all part of the same call. >=20 > If the SIP proxy server isn't telling the router, what is, and why is it > in > scope? [[Reinaldo]]=20 What I mentioned above is not necessarily in scope. It is also different from the purpose of the thread which was to make sure architecturally we keep media in mind. >=20 > This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any other > kind of links down in the router. >=20 > This doesn't say you can't mark media packets in some way that sends them > down some specific tunnels. >=20 > This doesn't say you can't create any kind of static routing mechanisms > you > like for any set of flows you can identify. >=20 [[Reinaldo]]=20 Okay. Identifying flows dynamically and entering static routes by hand it's not very scalable, thus dynamic decisions based on CRD. > It does say that SPEERMINT is defining what goes on in the proxy servers > that make the L7 call routing decisions. [[Reinaldo]]=20 Anyway, I believe we stretched this topic as much as it goes. You can have the last word. regards, Reinaldo >=20 > Brian >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 06, 2006 4:20 PM > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect-transitvs peering >=20 >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 06, 2006 1:00 PM > > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > transitvs peering > > > > I remember that bit of the charter, but so far, I don't see how it > > applies. > > Sure, the media could take a different L3 path, which might involve > > different VPN tunnels than the signaling takes. > > > > Why would we care? Routers do this without any assistance. The > signaling > > layer is unaware of any of this. > > > > What would be the use case that requires us to focus on the > interactions > > between the application layer and the lower layers? > > > > It's not that it's out of scope, it's that the differences don't > matter to > > SPEERMINT, at least I don't see anything that matters. > > > > I can see having peering policy take QoS capability into account. > What I > > cannot see is having the peering system itself decide to use a > mechanism > > (what mechanism could it be?) > [[Reinaldo]] >=20 > Is this a decision based on the policies announced by various peers and > taken by one device or all devices need to be included in the decision? >=20 > What is the "peering system"? >=20 > to send the media a particular way through > > the > > underlying network based on it. That means you may have more than one > way > > to get from A to B, and your choice may depend on what QoS you can > > maintain > > across those ways, > [[Reinaldo]] >=20 > Okay so far. >=20 > but not some mechanism that I don't even know exists > > that > > somehow influences the underlying network to take a particular path > for > > the > > media. > [[Reinaldo]] >=20 > Not sure I follow you here. >=20 > That is a really serious layer violation ("yeah, I know you can > > take > > this MPLS tunnel or that MPLS tunnel for any packets from A to B, but > I > > want > > these here media packets to be sent on that tunnel"). > [[Reinaldo]] >=20 > I definitely do not follow you here. A routing table can be populated by > peering with others routers, management systems, as a result of off-line > TE tools, manual configuration ("I know that path is better, let me > direct packets there". Is that human performing a layer violation?) >=20 > Can you elaborate on who is performing the layer violation? >=20 >=20 > That is WAY beyond > > anything I would want to touch any time soon, if at all, not to > mention > > there isn't any way I know to do it at all. > > > > But then, I'm just one hummer here. > > > > Brian > > > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Thursday, April 06, 2006 3:42 PM > > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect-transitvs peering > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, April 06, 2006 12:28 PM > > > To: Reinaldo Penno; 'Medhavi Bhatia'; 'Otmar Lendl'; > > speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect- > > > transitvs peering > > > > > > Reinaldo > > > > > > The path taken by media either flows from one endpoint to the other > > > directly, or it goes through one or more media relays. The path > media > > > takes > > > is defined by which media relays it must traverse. I don't think L3 > > > considerations apply to our work. > > [[Reinaldo]] > > > > Is it? The charter states that > > > > "In addition, the working group recognizes that > > there will be use cases that require SPEERMINT to focus on the > > interaction between the application layer and lower network > > layers," > > > > Potentially media could follow a different route than signaling by > > tunneling (read VPNs) or MPLS. No media relays needed. If these > > interactions are out of scope, fine. > > > > > > > > I do think there are likely to be pin-hole firewalls that enable > media > > > flows, although I don't think we need to discuss these either. > > > > > > What in any of our documents would offer different advice depending > on > > the > > > path the media takes? > > > > > > What do we have to take into account? > > [[Reinaldo]] > > > > See above. > > > > > > > > I can imagine a discussion of marking of media. That could happen. > > > I can imagine a discussion of security of media across a peering > point > > > which > > > would deal with key exchange although I'm not sure there is much we > > could > > > agree on that subject yet. > > [[Reinaldo]] > > > > Well, all this related to the path the media will take. If your "voip > > peer" will not provide QoS (or even carry media), then you might want > to > > send your media through some other path. Will this the stated in the > > "peering policy" we will define? > > > > But, as I stated, if such interactions are out of scope, I will drop > the > > subject. > > > > Thanks, > > > > Reinaldo > > > > > > > > I don't see much else we need to cover. Do you? > > > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Thursday, April 06, 2006 3:11 PM > > > To: br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; > speermint@ietf.org > > > Subject: RE: [Speermint] RE: Background Reading on NGN > > > Interconnect-transitvs peering > > > > > > I'm not sure the discussion was about media relays. Was it? The > > > impression I had was that the discussion was about the path taken by > > > media when flowing between endpoints. > > > > > > From my point of view I see many discussions on SIP signaling and > > > "signaling only providers" and I worry that we are forgetting to > take > > > media into account. > > > > > > Regards, > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, April 06, 2006 11:58 AM > > > > To: 'Medhavi Bhatia'; Reinaldo Penno; 'Otmar Lendl'; > > > speermint@ietf.org > > > > Subject: RE: [Speermint] RE: Background Reading on NGN > Interconnect- > > > > transitvs peering > > > > > > > > I am sorry to be on a campaign to stop arguments that may be > > > interesting > > > > and > > > > amusing to us all, but could someone come up with a scenario in > > which > > > any > > > > of > > > > our anticipated documents would somehow differentiate between a > > > peering > > > > mechanism that had media relays and one that did not? > > > > > > > > I think this whole line of discussion is interesting, but > irrelevant > > > to > > > > the > > > > task at hand. > > > > > > > > Peering occurs when a SIP INVITE, most often with an offer SDP > body, > > > which > > > > contains some IP addresses and ports for it's desired media > > > connections, > > > > is > > > > presented to some proxy (a peering proxy which could be within the > O > > > > network, or could be in some special peering network) who is going > > to > > > > determine a proxy in the T network to send the INVITE to. The > > > resulting > > > > 200 > > > > OK message, which most often will have an answer SDP with its own > > > media > > > > addresses and ports may traverse said proxies (if they Record > > Routed). > > > > > > > > WHO CARES what the media address/ports are? > > > > > > > > WHO is going to do anything different if they are the endpoint's, > an > > > SBC > > > > in > > > > the O-network, T-network or anything else. > > > > > > > > Who in the O or T network would care if they were in an SBC inside > a > > > > peering > > > > service? > > > > > > > > We need to think about media, because we have to deal with pinhole > > > > firewalls, we have to deal with NAT traversal, and we could > imagine > > > > dealing > > > > with ancillary functions like transcoders, but really folks, > whether > > > there > > > > are media relays anywhere just doesn't seem to matter; you can't > > tell > > > if > > > > there are or there aren't and you don't do anything differently. > > > > > > > > Should anyone care, I personally think if systems are properly > > > designed, > > > > the > > > > only media relays in the path pretty that much have to be there > are > > > for > > > > legal intercept, and if we did that correctly (at L3 or below) > then > > > even > > > > they would not be needed and we could get back to the original > idea > > > that > > > > media flows direct between the UAs. That does not obviate any > > > firewall > > > > needs. I am under no illusions that "properly designed" is often > > > > achieved. > > > > That having been said, lots of folks seem to like media relays, I > > hope > > > > they > > > > don't screw up when emergency calls are sent through, and we have > to > > > > accept > > > > that they may be all over the place. But, again, who cares? > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > > > > Sent: Thursday, April 06, 2006 1:38 PM > > > > To: Reinaldo Penno; Otmar Lendl; speermint@ietf.org > > > > Subject: RE: [Speermint] RE: Background Reading on NGN > > > > Interconnect-transitvs peering > > > > > > > > Reinaldo, > > > > > > > > Do you have an example of an operator doing just media but is not > an > > > L3 > > > > carrier (e.g ISP/Transit)? If not, we can just talk about > signaling > > > only > > > > or signaling and media. > > > > > > > > -Medhavi. > > > > > > > > > -----Original Message----- > > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > > Sent: Thursday, April 06, 2006 1:02 PM > > > > > To: Otmar Lendl; speermint@ietf.org > > > > > Subject: RE: [Speermint] RE: Background Reading on NGN > > Interconnect > > > > -transitvs peering > > > > > > > > > > Okay, so when coming up with these terms we cannot forget about > > > media. > > > > > So, when somebody provides "peering" and/or "transit" services, > we > > > > need > > > > > to specify in the context of speermint if that means: > > > > > > > > > > a) all IP packets (which includes media) > > > > > b) only signaling > > > > > ... > > > > > > > > > > Well, you get the idea... > > > > > > > > > > > -----Original Message----- > > > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > > > Sent: Thursday, April 06, 2006 8:44 AM > > > > > > To: speermint@ietf.org > > > > > > Subject: Re: [Speermint] RE: Background Reading on NGN > > > Interconnect > > > > - > > > > > > transitvs peering > > > > > > > > > > > > On 2006/04/06 17:04, Richard Shockey > wrote: > > > > > > > Stastny Richard wrote: > > > > > > > >The problem I have with the FCC definition is that > > > > > > > >is states that peering is always bi-lateral > > > > > > > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > > > > >everybody seems at least to agree that bi-lateral > > > > > > > >peering does not scale globally. > > > > > > > > > > > > > > All peering arrangements among IP backbones are bi-lateral > and > > > the > > > > > > Internet > > > > > > > seems to have scaled reasonably well. > > > > > > > > > > > > The reason for that is "transit". It is thus not necessary > that > > > > > > any Autonomous Systems peers with all other AS. > > > > > > > > > > > > I think we should define the difference between "Peering" and > > > > > > "Interconnection" (which in my mind also allows for transit). > > > > > > > > > > > > Bi-lateral peering alone will definitly not solve the > world-wide > > > > > > reachability problem. > > > > > > > > > > > > /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 > > > > > > > > > > -- > > > > > No virus found in this incoming message. > > > > > Checked by AVG Free Edition. > > > > > Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: > > > > 4/5/2006 > > > > > > > > > > > > > _______________________________________________ > > > > 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 Apr 06 18:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRd8d-0001k8-IU; Thu, 06 Apr 2006 18:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRd8c-0001k3-6F for speermint@ietf.org; Thu, 06 Apr 2006 18:39:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRd8a-0001jq-Dg for speermint@ietf.org; Thu, 06 Apr 2006 18:39:38 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2006 15:39:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,94,1144047600"; d="scan'208"; a="25365955:sNHT30253564" 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 k36MdYVU003387; Thu, 6 Apr 2006 18:39: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.211); Thu, 6 Apr 2006 18:39:34 -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] RE: transit vs peering Date: Thu, 6 Apr 2006 18:39:33 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30150A53F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+AACaRd8AAA0Eq2AABK6lAAFSWhAA== From: "Michael Hammer \(mhammer\)" To: "Pfautz, Penn L, NEO" , "Stastny Richard" , X-OriginalArrivalTime: 06 Apr 2006 22:39:34.0457 (UTC) FILETIME=[FA51D290:01C659CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 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 association of media to L3 struck me as odd as well. Last I checked RTP was a L5 protocol up there with SIP. I think some of the questions floating on the list relate to folks differing topology perspectives. I think that the three questions that ground us are: What is needed for peers to discover each other and exchange SIP signaling? What is needed for peers to exchange media packets? What is the relationship between the signaling peering point and the media peering point for a given call? I also happen to agree with Brian Rosen's posts that despite the variety of contextual aspects (like addressability) that make a given peering public or private, the technical process might just be the same. So, rather than spin wheels defining all the contextual variations, best to define the basic interaction first assuming just one context and split out deltas later, if other contexts requires that. Mike > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20 > Sent: Thursday, April 06, 2006 8:25 AM > To: Stastny Richard; speermint@ietf.org > Subject: [Speermint] RE: transit vs peering >=20 > I heartily agree with the need to keep layer 3 and layer 5=20 > clear in our discussions. But I don't think they necessarily=20 > correspond to media versus signaling. Also, although I=20 > personally, think intercarrier compensation is a swamp that I=20 > 'd like to stay out of, in the US carriers do charge each=20 > other for signaling traffic under certain circumstances. >=20 > Penn >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 8:21 AM > To: Pfautz, Penn L, NEO; speermint@ietf.org > Subject: Re: transit vs peering >=20 > Penn, > =20 > I think we should start from even one step further back: > =20 > I always hear here that there is "traffic" exchanged between=20 > "Provider A" or Provider "B", which requires some kind of=20 > settlement This implies IMHO "bulk traffic" i.e. media, which=20 > in turn implies the media is also touching "entites" of the=20 > providers In the Internet model the bulk traffic is exchanged=20 > between the UA. > =20 > In L5 peering the only traffic exchanged is signalling=20 > traffic and I do not think there is any volume to cause=20 > settlement for "traffic" > =20 > There is always an intrinsic mix-up of L5 and L3 peering IMHO=20 > we should be very careful in our wording > =20 > Within the scope of SPEERMINT we should never user the term=20 > "traffic" standalone, only in context with signalling (L5)=20 > traffic or media (L3) traffic. and we should also make clear=20 > where these "traffics" originate and terminate. > =20 > Richard >=20 > ________________________________ >=20 > Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Gesendet: Do 06.04.2006 13:59 > An: Stastny Richard; speermint@ietf.org > Betreff: transit vs peering >=20 >=20 >=20 > Richard: > I think you are taking "bi-lateral" to mean something more=20 > restrictive than I intend. The aspect of concern to me is=20 > that traffic is being exchanged between the originating=20 > provider and the terminating provider. > Whether federations etc are used to establish whatever=20 > relationship the parties require is a business issue. In=20 > either case this is different from paying a transit provider.=20 > Transit is just wholesale. I'm not necessarily against it but=20 > it's not peering. > The global IP interconnect regime could still be bi-lateral.=20 > The scaling issue is not a technical one. What you want to=20 > avoid is negotiating interconnection agreements between all=20 > possible pairs of parties. >=20 > Penn >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 06, 2006 3:29 AM > To: Pfautz, Penn L, NEO; speermint@ietf.org > Subject: RE: Background Reading on NGN Interconnect - transit=20 > vs peering >=20 >=20 > The problem I have with the FCC definition is that is states=20 > that peering is always bi-lateral >=20 > The major reason for setting up SPEERMINT was that everybody=20 > seems at least to agree that bi-lateral peering does not=20 > scale globally. >=20 > And our real goal is to achieve global connectivity and reachability. >=20 > Maybe the name of the WG is wrong in this context >=20 > I still believe that the task of SPEERMINT is to show a way=20 > forward to overcome these bi-lateral peering. Away forward in=20 > this direction are federations, but finally we should lay the=20 > framework for a global IP Interconnect regime, at least protocol wise >=20 > It is obvious that this cannot be done only by protocols in a=20 > vacuum, so I fully agree that co-operation with other=20 > standard bodies e.g. ITU-T and national authorities will be required. >=20 > If all communication networks are finally migrated to IP, an=20 > IP Interconnect regime is required. >=20 > The problem here is that currently there are national=20 > interconnect regimes and the international regime on top=20 > (hierarchical) as default. >=20 > The new regime allows global direct interconnect, mixing up=20 > the current national and international regimes. In many=20 > countries national forums are popping up (e.g. in UK and=20 > Germany) talking about IP-based interconnect (with or without=20 > L3 peering). But they still need to recognize that this is=20 > only half of the picture. >=20 > Some of these discussions are going around in circles (like=20 > the discussions here? ;-). Maybe one task of SPEERMINT could=20 > also be to make scenarios and BCP, showing what works and=20 > what not and why not, saving these other bodies some time on=20 > useless discussions on not implementable or non-scalable models. >=20 > Richard >=20 > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Wednesday, April 05, 2006 5:12 PM > > To: Stastny Richard; speermint@ietf.org > > Subject: Background Reading on NGN Interconnect - transit vs peering > > > > Richard: > > Thanks for posting this. I recommend it to all. In=20 > particular we ought=20 > > to pay attention to the definition of peering versus transit offered > by > > the US FCC and cited in the Marcus paper: > > > > Peering is an agreement between ISPs to carry traffic=20 > for each=20 > > other and for their respective > > customers. Peering does not include the obligation to carry=20 > > traffic to third parties. Peering is usually a > > bilateral business and technical arrangement, where two=20 > > providers agree to accept traffic from one > > another, and from one another's customers (and thus=20 > from their=20 > > customers' customers). ... > > > > Transit is an agreement where an ISP agrees to carry=20 > traffic on=20 > > behalf of another ISP or end user. In > > most cases transit will include an obligation to=20 > carry traffic=20 > > to third parties. Transit is usually a > > bilateral business and technical arrangement, where=20 > one provider=20 > > (the transit provider) agrees to carry > > traffic to third parties on behalf of another=20 > provider or an end=20 > > user (the customer). In most cases, the > > transit provider carries traffic to and from its other=20 > > customers, and to and from every destination on > > the Internet, as part of the transit arrangement. In=20 > a transit=20 > > agreement, the ISP often also provides > > ancillary services, such as Service Level Agreements,=20 > > installation support, local telecom provisioning, > > and Network Operations Center (NOC) support. > > > > While we NEED not accept this definition I think it does=20 > reflect the=20 > > reality of layer 3 peering and it will not be helpful to use a=20 > > definition for layer 5 that is at odds with layer 3 since=20 > that's what=20 > > people are familiar with. > > If the will of the WG is to include transit in our charter=20 > that's fine > - > > but not an excuse for calling apples and oranges both apples. If, at > the > > end of the day, there are no important differences in how=20 > we treat the=20 > > two cases - which I doubt - then life is good. > > > > We also ought to be thinking about how what Speermint is working on=20 > > relates to what's going on in other bodies, e.g. the ITU.=20 > (yes, I said=20 > > it, we're not alone on the planet :-) Is what we want to do an > enabling > > piece of what NGN folks are looking toward or is it a fundamentally=20 > > different animal? From the discussion on the list and at=20 > the IETF I'm=20 > > not entirely sure. > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, March 31, 2006 3:59 PM > > To: speermint@ietf.org > > Subject: [Speermint] Background Reading on NGN Interconnect > > > > Folks, > > > > Weekend reading > > > > Since we obviosly are dealing more with NGN Interconnect in=20 > Speermint,=20 > > I recommend everybody on this this list to read the excellent > Background > > Paper > > from Scott Marcus - Interconnection in an IP-based NGN Environment > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323- > Fin-v2.1.p > > df > > > > to his presentation > > > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus- > 23-march-2 > > 006.ppt > > given at the ITU-T Workshop last week > > What Rules for Ip-eneabled NGNs? > > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml > > > > The agenda and some other excellent presentations can be downloaded > from > > here: > > http://www.itu.int/osg/spu/ngn/presentations.html > > > > In addition I would also like to point to a CEPT ECC Draft=20 > Report on=20 > > the Future on Numbering, tabled for the next ITU-T SG2=20 > Meeting as TD=20 > > 198-GEN. > > > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero > .dk/271322 > > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > > The document is in public consultation and not final yet. > > It contains also some statements regarding termination rates. > > > > The paper from Scott is on-topic regarding the current=20 > discussion here=20 > > and dealing with both the European and US situation > > > > Scott Marcus is currently living in Europe, but in his=20 > former life he=20 > > was Senior Advisor to the FCC and also CTO for GTE Interworking, so=20 > > his knowledge is not only theoretical. > > > > In the document also contains a definition on peering and=20 > transit from=20 > > the FCC is given: > > > > The two most prevalent forms of Internet interconnection are peering > and > > transit. For a definition of these > > terms, we turn to a publication of the Network Reliability and=20 > > Interoperability Council (NRIC), an industry advisory panel to the=20 > > U.S. FCC: > > > > Peering is an agreement between ISPs to carry traffic for each other > and > > for their respective > > customers. Peering does not include the obligation to carry=20 > traffic to=20 > > third parties. Peering is usually a bilateral business and=20 > technical=20 > > arrangement, where two providers > agree > > to accept traffic from one > > another, and from one another's customers (and thus from their=20 > > customers' customers). ... > > > > Transit is an agreement where an ISP agrees to carry=20 > traffic on behalf=20 > > of another ISP or end user. In most cases transit will include an=20 > > obligation to carry traffic to > third > > parties. Transit is usually a > > bilateral business and technical arrangement, where one=20 > provider (the=20 > > transit provider) agrees to carry traffic to third parties=20 > on behalf=20 > > of another provider or an end user (the customer). In most=20 > cases, the=20 > > transit provider carries traffic to and from its other=20 > customers, and > to > > and from every destination on > > the Internet, as part of the transit arrangement. In a transit=20 > > agreement, the ISP often also provides ancillary services, such as=20 > > Service Level Agreements, installation support, local telecom=20 > > provisioning, and Network Operations Center (NOC) support. > > > > Peering thus offers a provider access only to a single provider's=20 > > customers. Transit, by contrast, usually provides access at a=20 > > predictable price to the entire Internet. > > ... Historically, peering has often > > been done on a bill-and-keep basis, without cash payments. Peering > where > > there is no explicit > > exchange of money between parties, and where each party=20 > supports part > of > > the cost of the > > interconnect, ... is typically used where both parties perceive a=20 > > roughly equal exchange of value. > > Peering therefore is fundamentally a barter relationship > > > > Here the Executive Summary of the paper: > > > > This report considers the likely evolution of interconnection=20 > > arrangements in the context of IP-based Next Generation Networks=20 > > (NGNs). > > > > The NGN represents a synthesis of existing world of the=20 > "traditional" > > Public Switched Telephone Network > > (PSTN) with the world of the Internet. The economic and regulatory=20 > > arrangements for the two have historically been very=20 > different. What=20 > > should happen when these two worlds collide? > > > > Many of the networks created over the past ten years contain most of > the > > key elements of an NGN. Most, if > > not all, of the technology necessary for IP-based NGN=20 > interconnection=20 > > has been available for five to ten years. Advanced approaches to=20 > > interconnection have been slow to > deploy, > > even where the technology has > > been mature or within hailing distance of maturity. > > > > The NGN interconnection problem is best understood, not as a problem > of > > technology, but rather as a > > problem in economics. With that in mind, this report seeks=20 > to review=20 > > what is known about interconnection from an economic=20 > perspective, in=20 > > order to reach conclusions about the prospects for deployment going=20 > > forward and the corresponding implications for policymakers. > > > > A substantial body of economic theory has been developed=20 > over the past=20 > > decade as regards interconnection in the traditional PSTN.=20 > A smaller=20 > > body of solid economic research has emerged in regard to=20 > > interconnection of IP-based networks. At the level of=20 > economic theory,=20 > > the PSTN and the Internet are not worlds apart. > > Economics provides the necessary bridge between the two worlds,=20 > > illuminating both the similarities and the differences in these two=20 > > environments. > > > > This report begins by laying out, for the most part at a=20 > non-technical=20 > > level, the established theory of interconnection, for both the PSTN=20 > > and the Internet. Wholesale and retail arrangements are considered=20 > > separately. Most of the observed behavior of these economic networks > can > > be explained in terms of a > > constellation of known economic effects: market power, the=20 > termination=20 > > monopoly, demand elasticity, network exernalities,=20 > transaction costs,=20 > > service differentiation, > price > > discrimination, and the Coase theorem > > (which says that private parties can often negotiate=20 > arrangements more=20 > > efficiently than government regulators, provided that necessary=20 > > preconditions have been met). > > > > With this theory in hand, the report considers the implications for > the > > deployment of differentiated Quality of Service, and of universal=20 > > service. We also consider the implications > of > > IP-based technology - with the > > layering, and the changes in industry structure that it implies -=20 > > service providers become independent of the network, but neither is=20 > > well equipped to measure or to charge for the other's resource=20 > > consumption. > > The last section of the report represents a hypothetical=20 > scenario, a=20 > > "thought experiment", where the historic wired and mobile=20 > incumbent of=20 > > European country upgrades its networks > to > > an IP-based NGN. We consider > > the likely results in terms of regulation of the access network, and > of > > interconnection; likely domestic and > > international interconnection arrangements; and the=20 > implications for=20 > > ubiquitous support of QoS. Key findings > > include: > > * Provided that markets for Internet transit and for consumer > broadband > > Internet access are effectively > > competitive, a "Coasian" interconnection regime is likely=20 > to be more=20 > > efficient, and more consistent with consumer welfare, than=20 > a regulated=20 > > regime. > > * Conversely, where these markets are not effectively competitive,=20 > > mandates for interconnection at the IP level may prove to be=20 > > unavoidable, particularly once existing PSTN interconnection is=20 > > withdrawn. > > The migration to NGN potentially creates new sources of=20 > market power, > at > > the same time that it > > creates new possibilities for competition. > > * Policymakers might consequently be well advised to focus their=20 > > attention first on ensuring competitive markets, and only=20 > secondarily=20 > > on interconnection. > > > > Current Calling Party's Network Pays (CPNP) arrangements contain a=20 > > number of implicit subsidies. In the world of the NGN,=20 > where services=20 > > providers and networks operators may > be > > different entities, these > > subsidies need major re-thinking - call termination=20 > payments that were=20 > > intended to finance the terminating network would, by=20 > default, flow to=20 > > independent VoIP service provides > who > > have no network to support. In > > the absence of termination fees, independent VoIP providers=20 > would tend=20 > > to compete price levels for telephony service, independent of the=20 > > network, down to levels not greatly above cost, which would=20 > appear to=20 > > be a societally desirable outcome. > > > > The thought experiment does not flatly preclude the=20 > possibility that=20 > > governments might somehow erect a new system of subsidies=20 > to replace=20 > > the old, but it suggests that any subsidy system will be=20 > difficult to=20 > > sustain over time in the face of new forms of competition=20 > enabled by=20 > > the IP-based NGN - all provided, once again, that=20 > underlying markets=20 > > (especially for wholesale Internet transit and for retail Internet=20 > > broadband access) remain effectively competitive. A system=20 > of Coasian=20 > > private arrangements, in the absence of vertically integrated=20 > > competitive bottlenecks, seems likely to lead to > unsubsidized > > arrangements at wholesale and retail > > price levels not greatly in excess of cost. > > > > cheer > > Richard > > > > _______________________________________________ > > 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 Apr 06 18:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdMc-0008Mo-6P; Thu, 06 Apr 2006 18:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdMa-0008Mj-Vh for speermint@ietf.org; Thu, 06 Apr 2006 18:54:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRdMZ-00023h-MX for speermint@ietf.org; Thu, 06 Apr 2006 18:54:04 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2006 15:54:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,94,1144047600"; d="scan'208"; a="25367252:sNHT24513724" 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 k36Ms2Wc005463; Thu, 6 Apr 2006 18:54:03 -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.211); Thu, 6 Apr 2006 18:54:02 -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] Reachability Date: Thu, 6 Apr 2006 18:54:01 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30150A545@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAisd/AAF6UQ8A== From: "Michael Hammer \(mhammer\)" To: "Patrick Melampy" , "Reinaldo Penno" , "Stastny Richard" , "Lee, Yiu" , "Hadriel Kaplan" , X-OriginalArrivalTime: 06 Apr 2006 22:54:02.0655 (UTC) FILETIME=[FFCE52F0:01C659CC] 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 Be careful of saying that "media must follow signaling". Given mobility, that can lead to sub-optimal routes and possibly horrible QoS. Maybe the media is handed from the control of A to control of B to C, but that doesn't necessarily mean going through all the same boxes. Mike > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 > Sent: Thursday, April 06, 2006 7:52 AM > To: 'Reinaldo Penno'; 'Stastny Richard'; 'Lee, Yiu'; 'Hadriel=20 > Kaplan'; speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 > Reinaldo -- you wrote >=20 > >Are A and C paying B to carry _IP_ packets (which includes signaling=20 > >and media)? >=20 > I think that a communication with media packets is like a day=20 > without sunshine... I think the media packets are what the=20 > service is all about. > Guarantees, reliability, trust, signaling systems, bi-lateral=20 > agreements, service level agreements are all about delivery=20 > of media. Nobody would ever pay B if B doesn't carry the=20 > communication request. If B only provided a location service,=20 > then this business model is very close to what Nuestar is=20 > doing with their public ENUM. People do pay for this, but=20 > this is not what SPEERMINT is about. >=20 > >Can A send and receive packets from C? So, unless A and C want=20 > >something special done to their signaling traffic I wonder=20 > what B has=20 > >to do with it... Why would I pay B to be a proxy hop if I can send=20 > >packets directly? >=20 > This is exactly why managing the media flows is so important=20 > to these business models. The media must follow the signaling=20 > when a communication request goes from A to B to C for B to=20 > have any value to A and C. If A and C can interconnect with=20 > quality for free (A.K.A. the internet), why would A and C use=20 > B? Well -- it is likely because they are unaware of each=20 > other -- or B has some special attributes (such as QoS,=20 > routing or aggregation) that the internet doesn't have. >=20 > I also believe that A and C may be telephone companies where=20 > the telephone traffic might originate from PSTN phones=20 > alongside IP originated calls. > These operators have real expenses associated with receiving=20 > and terminating a communication request. A and C could not=20 > afford to connect to the internet and offer termination=20 > services to just anybody. They would rather NOT do this. This=20 > is the reason for the bi-lateral agreements. Since they can't=20 > have infinity agreements, there is room for aggregating=20 > carriers (B in this example). B aggregates signaling, media,=20 > and business agreements. >=20 > If we got rid of the PSTN completely, and all of the=20 > regulations in the world, then we can stop worrying about=20 > these minor economic issues. I think this is unlikely. >=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 Apr 07 00:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRi9X-00047a-Ic; Fri, 07 Apr 2006 00:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRi9V-00040M-UU for speermint@ietf.org; Fri, 07 Apr 2006 00:00:53 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRi9U-00030k-Jj for speermint@ietf.org; Fri, 07 Apr 2006 00:00:53 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A3F304B4; Fri, 07 Apr 2006 00:00:51 -0400 From: "Hadriel Kaplan" To: , Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 00:00:57 -0400 Message-ID: <08b401c659f7$e05c3010$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAAoErIA= In-Reply-To: <025601c659b4$ae66b5f0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Brian, Thanks for trying to bring clarity to this. I appear unable to do so. :( This may really not be a big deal at all. Or it is. I don't know. I said at the beginning of this thread (well not this exact thread) that I'm trying to describe a context which is acceptable to the IETF in general, so we may support as many peering relationships as possible. My goal is to have the output of this WG be as broadly applicable as possible, yet remain within the politicaly-acceptable confines of the IETF. In order to exit and enter a L3 VPN, to not "violate" the layers, you must join the disparate L3 networks at above L3. In other words terminate L3 on both "sides". Although any proxy can sit in two networks, clearly SIP includes lower-layer addressing. For that to work, then, one must change such addressing to represent the change in media termination. As many media servers do today (I think): they are media B2BUAs. (is that a safe term?) I am not suggesting this be a mandated action by any element whatsoever - just describing one way in which the application layer may "interact" with the lower layer when crossing L3 VPNs. I'm not sure that makes one iota of difference to this working group. If all we're defining is signaling and media between two L3/L5 SIP/media interfaces across the public internet (or common routing space, whatever) it shouldn't be a problem at all. If the WG decides to define some mechanism which starts at a UA before that peering point which has issues with that, such as S/MIME, then we would have a problem. I doubt anyone would suggest S/MIME, as it's not exactly the most popular mechanism around, but you get the idea. So I honestly don't know if this will make any difference at all. -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 00:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRiks-0006aJ-N5; Fri, 07 Apr 2006 00:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRikr-0006aE-3x for speermint@ietf.org; Fri, 07 Apr 2006 00:39:29 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRikq-0004B6-TO for speermint@ietf.org; Fri, 07 Apr 2006 00:39:29 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id AD00047C; Fri, 07 Apr 2006 00:39:28 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] Reachability Date: Fri, 7 Apr 2006 00:39:34 -0400 Message-ID: <08b601c659fd$4527ec00$6501a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAisd/AAF6UQ8AALsC3w In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30150A545@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Indeed, and there are mechanisms to handle that; but in such a case one wouldn't know whether it will lead to sub-optimal routes, nits, or better routes. I don't think he meant follow signaling hopy-by-hop, but rather provider-by-provider (if the middle providers wanted it to). -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, April 06, 2006 6:54 PM > To: Patrick Melampy; Reinaldo Penno; Stastny Richard; Lee, > Yiu; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] Reachability > > Be careful of saying that "media must follow signaling". > Given mobility, that can lead to sub-optimal routes and > possibly horrible QoS. > Maybe the media is handed from the control of A to control of > B to C, but that doesn't necessarily mean going through all > the same boxes. > > Mike > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 03:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlb2-0002FP-Ld; Fri, 07 Apr 2006 03:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlb0-0002E7-Dp for speermint@ietf.org; Fri, 07 Apr 2006 03:41:30 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRlav-0001z1-QO for speermint@ietf.org; Fri, 07 Apr 2006 03:41:30 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: transit vs peering Date: Fri, 7 Apr 2006 09:41:18 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4EC9@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: transit vs peering Thread-Index: AcZVBe2ExnqTs7UgTW2kTJiDtOSMxQDu1C1AACIPx+AACaRd8AAA0Eq2AABK6lAAFSWhAAATVrEA From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Pfautz, Penn L, NEO" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 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 > So, > rather than spin wheels defining all the contextual variations, best to > define the basic interaction first assuming just one context and split > out deltas later, if other contexts requires that. Agreed Richard > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 07, 2006 12:40 AM > To: Pfautz, Penn L, NEO; Stastny Richard; speermint@ietf.org > Subject: RE: [Speermint] RE: transit vs peering >=20 > The association of media to L3 struck me as odd as well. Last I checked > RTP was a L5 protocol up there with SIP. I think some of the questions > floating on the list relate to folks differing topology perspectives. I > think that the three questions that ground us are: >=20 > What is needed for peers to discover each other and exchange SIP > signaling? >=20 > What is needed for peers to exchange media packets? >=20 > What is the relationship between the signaling peering point and the > media peering point for a given call? >=20 > I also happen to agree with Brian Rosen's posts that despite the variety > of contextual aspects (like addressability) that make a given peering > public or private, the technical process might just be the same. So, > rather than spin wheels defining all the contextual variations, best to > define the basic interaction first assuming just one context and split > out deltas later, if other contexts requires that. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Thursday, April 06, 2006 8:25 AM > > To: Stastny Richard; speermint@ietf.org > > Subject: [Speermint] RE: transit vs peering > > > > I heartily agree with the need to keep layer 3 and layer 5 > > clear in our discussions. But I don't think they necessarily > > correspond to media versus signaling. Also, although I > > personally, think intercarrier compensation is a swamp that I > > 'd like to stay out of, in the US carriers do charge each > > other for signaling traffic under certain circumstances. > > > > Penn > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, April 06, 2006 8:21 AM > > To: Pfautz, Penn L, NEO; speermint@ietf.org > > Subject: Re: transit vs peering > > > > Penn, > > > > I think we should start from even one step further back: > > > > I always hear here that there is "traffic" exchanged between > > "Provider A" or Provider "B", which requires some kind of > > settlement This implies IMHO "bulk traffic" i.e. media, which > > in turn implies the media is also touching "entites" of the > > providers In the Internet model the bulk traffic is exchanged > > between the UA. > > > > In L5 peering the only traffic exchanged is signalling > > traffic and I do not think there is any volume to cause > > settlement for "traffic" > > > > There is always an intrinsic mix-up of L5 and L3 peering IMHO > > we should be very careful in our wording > > > > Within the scope of SPEERMINT we should never user the term > > "traffic" standalone, only in context with signalling (L5) > > traffic or media (L3) traffic. and we should also make clear > > where these "traffics" originate and terminate. > > > > Richard > > > > ________________________________ > > > > Von: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Gesendet: Do 06.04.2006 13:59 > > An: Stastny Richard; speermint@ietf.org > > Betreff: transit vs peering > > > > > > > > Richard: > > I think you are taking "bi-lateral" to mean something more > > restrictive than I intend. The aspect of concern to me is > > that traffic is being exchanged between the originating > > provider and the terminating provider. > > Whether federations etc are used to establish whatever > > relationship the parties require is a business issue. In > > either case this is different from paying a transit provider. > > Transit is just wholesale. I'm not necessarily against it but > > it's not peering. > > The global IP interconnect regime could still be bi-lateral. > > The scaling issue is not a technical one. What you want to > > avoid is negotiating interconnection agreements between all > > possible pairs of parties. > > > > Penn > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Thursday, April 06, 2006 3:29 AM > > To: Pfautz, Penn L, NEO; speermint@ietf.org > > Subject: RE: Background Reading on NGN Interconnect - transit > > vs peering > > > > > > The problem I have with the FCC definition is that is states > > that peering is always bi-lateral > > > > The major reason for setting up SPEERMINT was that everybody > > seems at least to agree that bi-lateral peering does not > > scale globally. > > > > And our real goal is to achieve global connectivity and reachability. > > > > Maybe the name of the WG is wrong in this context > > > > I still believe that the task of SPEERMINT is to show a way > > forward to overcome these bi-lateral peering. Away forward in > > this direction are federations, but finally we should lay the > > framework for a global IP Interconnect regime, at least protocol wise > > > > It is obvious that this cannot be done only by protocols in a > > vacuum, so I fully agree that co-operation with other > > standard bodies e.g. ITU-T and national authorities will be required. > > > > If all communication networks are finally migrated to IP, an > > IP Interconnect regime is required. > > > > The problem here is that currently there are national > > interconnect regimes and the international regime on top > > (hierarchical) as default. > > > > The new regime allows global direct interconnect, mixing up > > the current national and international regimes. In many > > countries national forums are popping up (e.g. in UK and > > Germany) talking about IP-based interconnect (with or without > > L3 peering). But they still need to recognize that this is > > only half of the picture. > > > > Some of these discussions are going around in circles (like > > the discussions here? ;-). Maybe one task of SPEERMINT could > > also be to make scenarios and BCP, showing what works and > > what not and why not, saving these other bodies some time on > > useless discussions on not implementable or non-scalable models. > > > > Richard > > > > > -----Original Message----- > > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > > Sent: Wednesday, April 05, 2006 5:12 PM > > > To: Stastny Richard; speermint@ietf.org > > > Subject: Background Reading on NGN Interconnect - transit vs peering > > > > > > Richard: > > > Thanks for posting this. I recommend it to all. In > > particular we ought > > > to pay attention to the definition of peering versus transit offered > > by > > > the US FCC and cited in the Marcus paper: > > > > > > Peering is an agreement between ISPs to carry traffic > > for each > > > other and for their respective > > > customers. Peering does not include the obligation to carry > > > traffic to third parties. Peering is usually a > > > bilateral business and technical arrangement, where two > > > providers agree to accept traffic from one > > > another, and from one another's customers (and thus > > from their > > > customers' customers). ... > > > > > > Transit is an agreement where an ISP agrees to carry > > traffic on > > > behalf of another ISP or end user. In > > > most cases transit will include an obligation to > > carry traffic > > > to third parties. Transit is usually a > > > bilateral business and technical arrangement, where > > one provider > > > (the transit provider) agrees to carry > > > traffic to third parties on behalf of another > > provider or an end > > > user (the customer). In most cases, the > > > transit provider carries traffic to and from its other > > > customers, and to and from every destination on > > > the Internet, as part of the transit arrangement. In > > a transit > > > agreement, the ISP often also provides > > > ancillary services, such as Service Level Agreements, > > > installation support, local telecom provisioning, > > > and Network Operations Center (NOC) support. > > > > > > While we NEED not accept this definition I think it does > > reflect the > > > reality of layer 3 peering and it will not be helpful to use a > > > definition for layer 5 that is at odds with layer 3 since > > that's what > > > people are familiar with. > > > If the will of the WG is to include transit in our charter > > that's fine > > - > > > but not an excuse for calling apples and oranges both apples. If, at > > the > > > end of the day, there are no important differences in how > > we treat the > > > two cases - which I doubt - then life is good. > > > > > > We also ought to be thinking about how what Speermint is working on > > > relates to what's going on in other bodies, e.g. the ITU. > > (yes, I said > > > it, we're not alone on the planet :-) Is what we want to do an > > enabling > > > piece of what NGN folks are looking toward or is it a fundamentally > > > different animal? From the discussion on the list and at > > the IETF I'm > > > not entirely sure. > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, March 31, 2006 3:59 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Background Reading on NGN Interconnect > > > > > > Folks, > > > > > > Weekend reading > > > > > > Since we obviosly are dealing more with NGN Interconnect in > > Speermint, > > > I recommend everybody on this this list to read the excellent > > Background > > > Paper > > > from Scott Marcus - Interconnection in an IP-based NGN Environment > > > > > http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323- > > Fin-v2.1.p > > > df > > > > > > to his presentation > > > > > http://www.itu.int/osg/spu/ngn/documents/presentations/marcus- > > 23-march-2 > > > 006.ppt > > > given at the ITU-T Workshop last week > > > What Rules for Ip-eneabled NGNs? > > > http://www.itu.int/osg/spu/ngn/event-march-2006.phtml > > > > > > The agenda and some other excellent presentations can be downloaded > > from > > > here: > > > http://www.itu.int/osg/spu/ngn/presentations.html > > > > > > In addition I would also like to point to a CEPT ECC Draft > > Report on > > > the Future on Numbering, tabled for the next ITU-T SG2 > > Meeting as TD > > > 198-GEN. > > > > > https://mail.oefeg.at/exchweb/bin/redir.asp?URL=3Dhttp://www.ero > > .dk/271322 > > > 2D-C8AF-4407-BE53-131EA2EED278?frames=3Dno%26 > > > The document is in public consultation and not final yet. > > > It contains also some statements regarding termination rates. > > > > > > The paper from Scott is on-topic regarding the current > > discussion here > > > and dealing with both the European and US situation > > > > > > Scott Marcus is currently living in Europe, but in his > > former life he > > > was Senior Advisor to the FCC and also CTO for GTE Interworking, so > > > his knowledge is not only theoretical. > > > > > > In the document also contains a definition on peering and > > transit from > > > the FCC is given: > > > > > > The two most prevalent forms of Internet interconnection are peering > > and > > > transit. For a definition of these > > > terms, we turn to a publication of the Network Reliability and > > > Interoperability Council (NRIC), an industry advisory panel to the > > > U.S. FCC: > > > > > > Peering is an agreement between ISPs to carry traffic for each other > > and > > > for their respective > > > customers. Peering does not include the obligation to carry > > traffic to > > > third parties. Peering is usually a bilateral business and > > technical > > > arrangement, where two providers > > agree > > > to accept traffic from one > > > another, and from one another's customers (and thus from their > > > customers' customers). ... > > > > > > Transit is an agreement where an ISP agrees to carry > > traffic on behalf > > > of another ISP or end user. In most cases transit will include an > > > obligation to carry traffic to > > third > > > parties. Transit is usually a > > > bilateral business and technical arrangement, where one > > provider (the > > > transit provider) agrees to carry traffic to third parties > > on behalf > > > of another provider or an end user (the customer). In most > > cases, the > > > transit provider carries traffic to and from its other > > customers, and > > to > > > and from every destination on > > > the Internet, as part of the transit arrangement. In a transit > > > agreement, the ISP often also provides ancillary services, such as > > > Service Level Agreements, installation support, local telecom > > > provisioning, and Network Operations Center (NOC) support. > > > > > > Peering thus offers a provider access only to a single provider's > > > customers. Transit, by contrast, usually provides access at a > > > predictable price to the entire Internet. > > > ... Historically, peering has often > > > been done on a bill-and-keep basis, without cash payments. Peering > > where > > > there is no explicit > > > exchange of money between parties, and where each party > > supports part > > of > > > the cost of the > > > interconnect, ... is typically used where both parties perceive a > > > roughly equal exchange of value. > > > Peering therefore is fundamentally a barter relationship > > > > > > Here the Executive Summary of the paper: > > > > > > This report considers the likely evolution of interconnection > > > arrangements in the context of IP-based Next Generation Networks > > > (NGNs). > > > > > > The NGN represents a synthesis of existing world of the > > "traditional" > > > Public Switched Telephone Network > > > (PSTN) with the world of the Internet. The economic and regulatory > > > arrangements for the two have historically been very > > different. What > > > should happen when these two worlds collide? > > > > > > Many of the networks created over the past ten years contain most of > > the > > > key elements of an NGN. Most, if > > > not all, of the technology necessary for IP-based NGN > > interconnection > > > has been available for five to ten years. Advanced approaches to > > > interconnection have been slow to > > deploy, > > > even where the technology has > > > been mature or within hailing distance of maturity. > > > > > > The NGN interconnection problem is best understood, not as a problem > > of > > > technology, but rather as a > > > problem in economics. With that in mind, this report seeks > > to review > > > what is known about interconnection from an economic > > perspective, in > > > order to reach conclusions about the prospects for deployment going > > > forward and the corresponding implications for policymakers. > > > > > > A substantial body of economic theory has been developed > > over the past > > > decade as regards interconnection in the traditional PSTN. > > A smaller > > > body of solid economic research has emerged in regard to > > > interconnection of IP-based networks. At the level of > > economic theory, > > > the PSTN and the Internet are not worlds apart. > > > Economics provides the necessary bridge between the two worlds, > > > illuminating both the similarities and the differences in these two > > > environments. > > > > > > This report begins by laying out, for the most part at a > > non-technical > > > level, the established theory of interconnection, for both the PSTN > > > and the Internet. Wholesale and retail arrangements are considered > > > separately. Most of the observed behavior of these economic networks > > can > > > be explained in terms of a > > > constellation of known economic effects: market power, the > > termination > > > monopoly, demand elasticity, network exernalities, > > transaction costs, > > > service differentiation, > > price > > > discrimination, and the Coase theorem > > > (which says that private parties can often negotiate > > arrangements more > > > efficiently than government regulators, provided that necessary > > > preconditions have been met). > > > > > > With this theory in hand, the report considers the implications for > > the > > > deployment of differentiated Quality of Service, and of universal > > > service. We also consider the implications > > of > > > IP-based technology - with the > > > layering, and the changes in industry structure that it implies - > > > service providers become independent of the network, but neither is > > > well equipped to measure or to charge for the other's resource > > > consumption. > > > The last section of the report represents a hypothetical > > scenario, a > > > "thought experiment", where the historic wired and mobile > > incumbent of > > > European country upgrades its networks > > to > > > an IP-based NGN. We consider > > > the likely results in terms of regulation of the access network, and > > of > > > interconnection; likely domestic and > > > international interconnection arrangements; and the > > implications for > > > ubiquitous support of QoS. Key findings > > > include: > > > * Provided that markets for Internet transit and for consumer > > broadband > > > Internet access are effectively > > > competitive, a "Coasian" interconnection regime is likely > > to be more > > > efficient, and more consistent with consumer welfare, than > > a regulated > > > regime. > > > * Conversely, where these markets are not effectively competitive, > > > mandates for interconnection at the IP level may prove to be > > > unavoidable, particularly once existing PSTN interconnection is > > > withdrawn. > > > The migration to NGN potentially creates new sources of > > market power, > > at > > > the same time that it > > > creates new possibilities for competition. > > > * Policymakers might consequently be well advised to focus their > > > attention first on ensuring competitive markets, and only > > secondarily > > > on interconnection. > > > > > > Current Calling Party's Network Pays (CPNP) arrangements contain a > > > number of implicit subsidies. In the world of the NGN, > > where services > > > providers and networks operators may > > be > > > different entities, these > > > subsidies need major re-thinking - call termination > > payments that were > > > intended to finance the terminating network would, by > > default, flow to > > > independent VoIP service provides > > who > > > have no network to support. In > > > the absence of termination fees, independent VoIP providers > > would tend > > > to compete price levels for telephony service, independent of the > > > network, down to levels not greatly above cost, which would > > appear to > > > be a societally desirable outcome. > > > > > > The thought experiment does not flatly preclude the > > possibility that > > > governments might somehow erect a new system of subsidies > > to replace > > > the old, but it suggests that any subsidy system will be > > difficult to > > > sustain over time in the face of new forms of competition > > enabled by > > > the IP-based NGN - all provided, once again, that > > underlying markets > > > (especially for wholesale Internet transit and for retail Internet > > > broadband access) remain effectively competitive. A system > > of Coasian > > > private arrangements, in the absence of vertically integrated > > > competitive bottlenecks, seems likely to lead to > > unsubsidized > > > arrangements at wholesale and retail > > > price levels not greatly in excess of cost. > > > > > > cheer > > > 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 > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 04:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRm0Q-0000ff-9e; Fri, 07 Apr 2006 04:07:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRlzp-0008C1-UL for speermint@ietf.org; Fri, 07 Apr 2006 04:07:09 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRlmK-00029Z-Bz for speermint@ietf.org; Fri, 07 Apr 2006 03:53:15 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 09:57:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4ECA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAAoErIAAD0gHEA== From: "Stastny Richard" To: "Hadriel Kaplan" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 >For that to work, then, one must change > such addressing to represent the change in media termination. As many > media > servers do today (I think): they are media B2BUAs. (is that a safe term?) > I > am not suggesting this be a mandated action by any element whatsoever - > just > describing one way in which the application layer may "interact" with the > lower layer when crossing L3 VPNs. This is exactly the reason why I wanted to avoid talking about L3 and media now. We should first get L5 sorted out. Media streaming Between different address spaces required B2BUAs with all their problems and we should sort out the straightforward cases first Richard > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 6:01 AM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading onNGNInterconnect- > transitvs peering >=20 > Hi Brian, > Thanks for trying to bring clarity to this. I appear unable to do so. :( > This may really not be a big deal at all. Or it is. I don't know. >=20 > I said at the beginning of this thread (well not this exact thread) that > I'm > trying to describe a context which is acceptable to the IETF in general, > so > we may support as many peering relationships as possible. My goal is to > have the output of this WG be as broadly applicable as possible, yet > remain > within the politicaly-acceptable confines of the IETF. >=20 > In order to exit and enter a L3 VPN, to not "violate" the layers, you must > join the disparate L3 networks at above L3. In other words terminate L3 > on > both "sides". Although any proxy can sit in two networks, clearly SIP > includes lower-layer addressing. For that to work, then, one must change > such addressing to represent the change in media termination. As many > media > servers do today (I think): they are media B2BUAs. (is that a safe term?) > I > am not suggesting this be a mandated action by any element whatsoever - > just > describing one way in which the application layer may "interact" with the > lower layer when crossing L3 VPNs. >=20 > I'm not sure that makes one iota of difference to this working group. If > all we're defining is signaling and media between two L3/L5 SIP/media > interfaces across the public internet (or common routing space, whatever) > it > shouldn't be a problem at all. If the WG decides to define some mechanism > which starts at a UA before that peering point which has issues with that, > such as S/MIME, then we would have a problem. I doubt anyone would > suggest > S/MIME, as it's not exactly the most popular mechanism around, but you get > the idea. So I honestly don't know if this will make any difference at > all. >=20 > -hadriel >=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 Apr 07 08:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRpdJ-0006Vx-Cs; Fri, 07 Apr 2006 08:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRpdH-0006Un-Ov for speermint@ietf.org; Fri, 07 Apr 2006 08:00:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRpdH-0001ZA-IG for speermint@ietf.org; Fri, 07 Apr 2006 08:00:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRpdA-0002nH-MN; Fri, 07 Apr 2006 07:00:01 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect-transitvs peering Date: Fri, 7 Apr 2006 08:00:01 -0400 Message-ID: <02f901c65a3a$ce690570$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 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE607@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAACJnEwAB3P8jA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 the SIP proxy is at L7. If that L7 entity tells a router how to route > a > flow (at L3 or worse, sub IP), then you have a layer violation. [[Reinaldo]] I believe this is where we part ways. I see what you mean, but I interpret it differently. I think routing of the media associated with a L7 SIP routing decision is also a L7 routing decision since it is all part of the same call.
Perhaps you would care to explain what protocol is doing this and how it works. I don't think we are defining new protocols here. I'm not aware of any L7 protocol already defined that could reasonably be used to route media with any more specificity than SIP now does (which ultimately is a direct path between UAS and UAC). You seem to be implying that there is an L7 protocol, not SIP, which some peering element would use to cause media to flow between the UAS and UAC via some set of ?what? L7 Intermediaries? Routers? Links? Sub-IP tunnels? What protocol would that be? Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 08:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqK5-0007wi-Ec; Fri, 07 Apr 2006 08:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqK4-0007wd-9x for speermint@ietf.org; Fri, 07 Apr 2006 08:44:20 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqK3-00032J-1s for speermint@ietf.org; Fri, 07 Apr 2006 08:44:20 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Fri, 7 Apr 2006 08:44:08 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040708440821766 ; Fri, 07 Apr 2006 08:44:08 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Apr 2006 08:44:08 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C18@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: br@brianrosen.net, Reinaldo Penno , Medhavi Bhatia , Otmar Lendl , speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transit vs peering Date: Fri, 7 Apr 2006 08:44:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Folks: Brian is right. Layer 7 is only signaling-message aware, and has no clue about the lower IP network layer routing schemes. In terms of media, it (layer 7) is only carrying the identifier of media addresses provided by UAC and UAS. In fact, media addresses remain in the message body, and a SIP proxy is not aware what is going in the message body. So, SIP proxy is only ware of signaling of messages between the proxies and UAC and UAS assuming that both UAS and UAC are also layer 7-aware entity. One can say that this is layer 7 server-server routing scheme. Best regards, Radhika _____ From: speermint-bounces@ietf.org on behalf of Brian Rosen Sent: Fri 4/7/2006 8:00 AM To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering > So the SIP proxy is at L7. If that L7 entity tells a router how to route > a > flow (at L3 or worse, sub IP), then you have a layer violation. [[Reinaldo]] I believe this is where we part ways. I see what you mean, but I interpret it differently. I think routing of the media associated with a L7 SIP routing decision is also a L7 routing decision since it is all part of the same call.
Perhaps you would care to explain what protocol is doing this and how it works. I don't think we are defining new protocols here. I'm not aware of any L7 protocol already defined that could reasonably be used to route media with any more specificity than SIP now does (which ultimately is a direct path between UAS and UAC). You seem to be implying that there is an L7 protocol, not SIP, which some peering element would use to cause media to flow between the UAS and UAC via some set of ?what? L7 Intermediaries? Routers? Links? Sub-IP tunnels? What protocol would that be? Brian _______________________________________________ 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 Apr 07 08:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqP0-0002bB-EH; Fri, 07 Apr 2006 08:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqOz-0002b6-FS for speermint@ietf.org; Fri, 07 Apr 2006 08:49:25 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRqOz-00038X-0A for speermint@ietf.org; Fri, 07 Apr 2006 08:49:25 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 14:53:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4ED5@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Thread-Index: AcZaQZE37k5Kemd+R2OXkIj976xz7gAAF5yg From: "Stastny Richard" To: "Roy, Radhika R." , , "Reinaldo Penno" , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) 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 Agree, in plain SIP But, You should have a look at 3GPP and TISPAN IMS specifications all the complexities added there is about making the upper layers aware what is going on in the lower layers Richard > -----Original Message----- > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] > Sent: Friday, April 07, 2006 2:44 PM > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering >=20 > Folks: >=20 > Brian is right. >=20 > Layer 7 is only signaling-message aware, and has no clue about the lower > IP > network layer routing schemes. In terms of media, it (layer 7) is only > carrying the identifier of media addresses provided by UAC and UAS. In > fact, > media addresses remain in the message body, and a SIP proxy is not aware > what is going in the message body. >=20 > So, SIP proxy is only ware of signaling of messages between the proxies > and > UAC and UAS assuming that both UAS and UAC are also layer 7-aware entity. > One can say that this is layer 7 server-server routing scheme. >=20 > Best regards, > Radhika >=20 >=20 >=20 > _____ >=20 > From: speermint-bounces@ietf.org on behalf of Brian Rosen > Sent: Fri 4/7/2006 8:00 AM > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering >=20 >=20 >=20 > > So the SIP proxy is at L7. If that L7 entity tells a router how to > route > > a > > flow (at L3 or worse, sub IP), then you have a layer violation. > [[Reinaldo]] >=20 > I believe this is where we part ways. I see what you mean, but I > interpret it differently. I think routing of the media associated with a > L7 SIP routing decision is also a L7 routing decision since it is all > part of the same call. >=20 >
Perhaps you would care to explain what protocol is doing this and how > it works. I don't think we are defining new protocols here. I'm not > aware > of any L7 protocol already defined that could reasonably be used to route > media with any more specificity than SIP now does (which ultimately is a > direct path between UAS and UAC). You seem to be implying that there is > an > L7 protocol, not SIP, which some peering element would use to cause media > to >=20 > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > Routers? Links? Sub-IP tunnels? What protocol would that be? >=20 > Brian >=20 >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 08:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqXL-0006Pr-SG; Fri, 07 Apr 2006 08:58:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqXK-0006Pm-N6 for speermint@ietf.org; Fri, 07 Apr 2006 08:58:02 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqXK-0003J0-CN for speermint@ietf.org; Fri, 07 Apr 2006 08:58:02 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 07 Apr 2006 05:58:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,96,1144047600"; d="scan'208"; a="538392361:sNHT25478988" 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] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 08:57:59 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE60D@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Thread-Index: AcZaQZE37k5Kemd+R2OXkIj976xz7gAAF5ygAAAaYFA= From: "Reinaldo Penno" To: "Stastny Richard" , "Roy, Radhika R." , , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 Richard. I was going to point that out but you already did. A lot of work was done in this area in 3GPP and TISPAN as Richard mentions. It might be irrelevant here or not. Time will decide. For those interested: TISPAN NGN functional architecture TISPAN gate control protocol TISPAN services and capabilities requirements Regards, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, April 07, 2006 5:53 AM > To: Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; > Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering >=20 > Agree, in plain SIP >=20 > But, >=20 > You should have a look at 3GPP and TISPAN IMS specifications >=20 > all the complexities added there is about > making the upper layers aware what is going on in > the lower layers >=20 > Richard >=20 > > -----Original Message----- > > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] > > Sent: Friday, April 07, 2006 2:44 PM > > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs peering > > > > Folks: > > > > Brian is right. > > > > Layer 7 is only signaling-message aware, and has no clue about the > lower > > IP > > network layer routing schemes. In terms of media, it (layer 7) is only > > carrying the identifier of media addresses provided by UAC and UAS. In > > fact, > > media addresses remain in the message body, and a SIP proxy is not > aware > > what is going in the message body. > > > > So, SIP proxy is only ware of signaling of messages between the > proxies > > and > > UAC and UAS assuming that both UAS and UAC are also layer 7-aware > entity. > > One can say that this is layer 7 server-server routing scheme. > > > > Best regards, > > Radhika > > > > > > > > _____ > > > > From: speermint-bounces@ietf.org on behalf of Brian Rosen > > Sent: Fri 4/7/2006 8:00 AM > > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs > > peering > > > > > > > > > So the SIP proxy is at L7. If that L7 entity tells a router how to > > route > > > a > > > flow (at L3 or worse, sub IP), then you have a layer violation. > > [[Reinaldo]] > > > > I believe this is where we part ways. I see what you mean, but I > > interpret it differently. I think routing of the media associated with > a > > L7 SIP routing decision is also a L7 routing decision since it is all > > part of the same call. > > > >
Perhaps you would care to explain what protocol is doing this and > how > > it works. I don't think we are defining new protocols here. I'm not > > aware > > of any L7 protocol already defined that could reasonably be used to > route > > media with any more specificity than SIP now does (which ultimately is > a > > direct path between UAS and UAC). You seem to be implying that there > is > > an > > L7 protocol, not SIP, which some peering element would use to cause > media > > to > > > > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > > Routers? Links? Sub-IP tunnels? What protocol would that be? > > > > Brian > > > > > > > > _______________________________________________ > > 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 Fri Apr 07 09:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqeS-0003On-FD; Fri, 07 Apr 2006 09:05:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqeR-0003Oi-8Z for speermint@ietf.org; Fri, 07 Apr 2006 09:05:23 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqeQ-0003Un-TW for speermint@ietf.org; Fri, 07 Apr 2006 09:05:23 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Fri, 7 Apr 2006 09:05:06 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040709050607590 ; Fri, 07 Apr 2006 09:05:06 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Apr 2006 09:05:06 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C19@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: Stastny Richard , "Roy, Radhika R." , br@brianrosen.net, Reinaldo Penno , Medhavi Bhatia , Otmar Lendl , speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transit vs peering Date: Fri, 7 Apr 2006 09:05:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Richard: I understand this. Let us not correct the mess what others are creating. If all the entities in the network need to be aware of all layers, we would not be here. We have to create separate standards and charter as well as requirements. In this case, we all can create solutions based on this basis. For example, a new work has emerged known as cross-layer/inter-layer communications especially in wireless where it is seen that, like wire-line network, it is sub-optimal to consider rigid 7 OSI layers in wireless. To optimize communications in wireless networks, many research works and implementations are coming out, and soon some standard works will be done in many standard organizations including IEEE and IETF. I would advise 3GPP folks, not to put cart before the horse. Let us create the standards following the established norms across whole world with step-by-step procedures without creating technical mess and confusions. Let them have the courage to face this, without being confined in the self-creating own narrow wall-prison. Unless this is clarified, we all will be fooled though breaking our fundamental working assumptions. Best regards, Radhika _____ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Fri 4/7/2006 8:53 AM To: Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Agree, in plain SIP But, You should have a look at 3GPP and TISPAN IMS specifications all the complexities added there is about making the upper layers aware what is going on in the lower layers Richard > -----Original Message----- > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com ] > Sent: Friday, April 07, 2006 2:44 PM > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering > > Folks: > > Brian is right. > > Layer 7 is only signaling-message aware, and has no clue about the lower > IP > network layer routing schemes. In terms of media, it (layer 7) is only > carrying the identifier of media addresses provided by UAC and UAS. In > fact, > media addresses remain in the message body, and a SIP proxy is not aware > what is going in the message body. > > So, SIP proxy is only ware of signaling of messages between the proxies > and > UAC and UAS assuming that both UAS and UAC are also layer 7-aware entity. > One can say that this is layer 7 server-server routing scheme. > > Best regards, > Radhika > > > > _____ > > From: speermint-bounces@ietf.org on behalf of Brian Rosen > Sent: Fri 4/7/2006 8:00 AM > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering > > > > > So the SIP proxy is at L7. If that L7 entity tells a router how to > route > > a > > flow (at L3 or worse, sub IP), then you have a layer violation. > [[Reinaldo]] > > I believe this is where we part ways. I see what you mean, but I > interpret it differently. I think routing of the media associated with a > L7 SIP routing decision is also a L7 routing decision since it is all > part of the same call. > >
Perhaps you would care to explain what protocol is doing this and how > it works. I don't think we are defining new protocols here. I'm not > aware > of any L7 protocol already defined that could reasonably be used to route > media with any more specificity than SIP now does (which ultimately is a > direct path between UAS and UAC). You seem to be implying that there is > an > L7 protocol, not SIP, which some peering element would use to cause media > to > > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > Routers? Links? Sub-IP tunnels? What protocol would that be? > > Brian > > > > _______________________________________________ > 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 Fri Apr 07 09:27:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqzU-0007RV-QN; Fri, 07 Apr 2006 09:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqzT-0007NL-7U for speermint@ietf.org; Fri, 07 Apr 2006 09:27:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqzS-0004T3-PK for speermint@ietf.org; Fri, 07 Apr 2006 09:27:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRqzF-0000NM-0u; Fri, 07 Apr 2006 08:26:53 -0500 From: "Brian Rosen" To: , "'Stastny Richard'" , "'Reinaldo Penno'" , "'Medhavi Bhatia'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 09:26:54 -0400 Message-ID: <030701c65a46$f1c04cc0$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 In-Reply-To: <62D92A9A02BCC845B202323D49A48426209C19@0591-ITS-EXMP02.us.saic.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZaQ+sV0rlBEtKqTr6r3dsywa2odAAAUH/Q X-PopBeforeSMTPSenders: br@brianrosen.net 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: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 this, but I don't think we need to start a religious war. One of the things I think we may be able to agree on is that the peering point can be assumed to either: a) Just not be involved with the media or b) Have essentially infinite bandwidth available AT THE PEERING POINT for the media Carriers can do all kinds of shenanigans to get the media to the peering point, but peering is limited by the "pipe" and not the "fabric" (however the actual L3 packet routing is handled) If I look around, I think this is the case for the kinds of arrangements we are contemplating. It may be that eventually the world coalesces on some ideas to mix L3 routing with L7 routing, and we could then handle more distributed peering fabrics where there may be limitations at the peering point. Could we agree to postpone such discussions for now? This still allows a quite wide space for media arrangements. Every carrier could bring in dumb pipes and just let a router at the peering point shovel the traffic around. One could have MPLS tunnels for peering partners that were address sensitive (all traffic from Pa to Pb goes in a specific tunnel). What it doesn't do is put some kind of bandwidth manager function at the peering point which chooses among multiple paths between Pa and Pb at the peering point. At least it doesn't try to standardize such a function. Is that satisfactory? I note that "gate control" has more to do with distributed pinhole firewall management than with bandwidth management. I don't think we are going to deal with such things, are we? I don't think peering entities have to bring standardized interfaces to their pinhole firewall for the peering system to tickle; they just get the SDP in the INVITE and use whatever they want to open the hole for that flow. -----Original Message----- From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com] Sent: Friday, April 07, 2006 9:05 AM To: Stastny Richard; Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Richard: I understand this. Let us not correct the mess what others are creating. If all the entities in the network need to be aware of all layers, we would not be here. We have to create separate standards and charter as well as requirements. In this case, we all can create solutions based on this basis. For example, a new work has emerged known as cross-layer/inter-layer communications especially in wireless where it is seen that, like wire-line network, it is sub-optimal to consider rigid 7 OSI layers in wireless. To optimize communications in wireless networks, many research works and implementations are coming out, and soon some standard works will be done in many standard organizations including IEEE and IETF. I would advise 3GPP folks, not to put cart before the horse. Let us create the standards following the established norms across whole world with step-by-step procedures without creating technical mess and confusions. Let them have the courage to face this, without being confined in the self-creating own narrow wall-prison. Unless this is clarified, we all will be fooled though breaking our fundamental working assumptions. Best regards, Radhika _____ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Fri 4/7/2006 8:53 AM To: Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Agree, in plain SIP But, You should have a look at 3GPP and TISPAN IMS specifications all the complexities added there is about making the upper layers aware what is going on in the lower layers Richard > -----Original Message----- > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com ] > Sent: Friday, April 07, 2006 2:44 PM > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering > > Folks: > > Brian is right. > > Layer 7 is only signaling-message aware, and has no clue about the lower > IP > network layer routing schemes. In terms of media, it (layer 7) is only > carrying the identifier of media addresses provided by UAC and UAS. In > fact, > media addresses remain in the message body, and a SIP proxy is not aware > what is going in the message body. > > So, SIP proxy is only ware of signaling of messages between the proxies > and > UAC and UAS assuming that both UAS and UAC are also layer 7-aware entity. > One can say that this is layer 7 server-server routing scheme. > > Best regards, > Radhika > > > > _____ > > From: speermint-bounces@ietf.org on behalf of Brian Rosen > Sent: Fri 4/7/2006 8:00 AM > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering > > > > > So the SIP proxy is at L7. If that L7 entity tells a router how to > route > > a > > flow (at L3 or worse, sub IP), then you have a layer violation. > [[Reinaldo]] > > I believe this is where we part ways. I see what you mean, but I > interpret it differently. I think routing of the media associated with a > L7 SIP routing decision is also a L7 routing decision since it is all > part of the same call. > >
Perhaps you would care to explain what protocol is doing this and how > it works. I don't think we are defining new protocols here. I'm not > aware > of any L7 protocol already defined that could reasonably be used to route > media with any more specificity than SIP now does (which ultimately is a > direct path between UAS and UAC). You seem to be implying that there is > an > L7 protocol, not SIP, which some peering element would use to cause media > to > > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > Routers? Links? Sub-IP tunnels? What protocol would that be? > > Brian > > > > _______________________________________________ > 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 Fri Apr 07 09:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr2M-0000R4-DD; Fri, 07 Apr 2006 09:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr2L-0000Qz-R3 for speermint@ietf.org; Fri, 07 Apr 2006 09:30:05 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRr2J-0004bQ-B1 for speermint@ietf.org; Fri, 07 Apr 2006 09:30:05 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Apr 2006 06:30:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,96,1144047600"; d="scan'208"; a="541641523:sNHT25029664" 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] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 09:30:00 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE611@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Thread-Index: AcZaRALzn0j5B5W8RwOm5nXKttiyCgAAP5rQ From: "Reinaldo Penno" To: , "Stastny Richard" , , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 > -----Original Message----- > From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com] > Sent: Friday, April 07, 2006 6:05 AM > To: Stastny Richard; Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; > Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering >=20 > Richard: >=20 > I understand this. >=20 > Let us not correct the mess what others are creating. [[Reinaldo]]=20 Let me get this straight. Are you saying the work of 3GPP/IMS and TISPAN is a mess? That's a pretty strong statement. >=20 > If all the entities in the network need to be aware of all layers, we > would > not be here. We have to create separate standards and charter as well as > requirements. In this case, we all can create solutions based on this > basis. >=20 >=20 > For example, a new work has emerged known as cross-layer/inter-layer > communications especially in wireless where it is seen that, like wire- > line > network, it is sub-optimal to consider rigid 7 OSI layers in wireless. To > optimize communications in wireless networks, many research works and > implementations are coming out, and soon some standard works will be done > in > many standard organizations including IEEE and IETF. >=20 > I would advise 3GPP folks, not to put cart before the horse. Let us create > the standards following the established norms across whole world with > step-by-step procedures without creating technical mess and confusions. > Let > them have the courage to face this, without being confined in the > self-creating own narrow wall-prison. >=20 [[Reinaldo]]=20 Huh?=20 > Unless this is clarified, we all will be fooled though breaking our > fundamental working assumptions. > Best regards, > Radhika >=20 > _____ >=20 > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Fri 4/7/2006 8:53 AM > To: Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; > Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering >=20 >=20 >=20 > Agree, in plain SIP >=20 > But, >=20 > You should have a look at 3GPP and TISPAN IMS specifications >=20 > all the complexities added there is about > making the upper layers aware what is going on in > the lower layers >=20 > Richard >=20 > > -----Original Message----- > > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com > ] > > Sent: Friday, April 07, 2006 2:44 PM > > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs peering > > > > Folks: > > > > Brian is right. > > > > Layer 7 is only signaling-message aware, and has no clue about the > lower > > IP > > network layer routing schemes. In terms of media, it (layer 7) is only > > carrying the identifier of media addresses provided by UAC and UAS. In > > fact, > > media addresses remain in the message body, and a SIP proxy is not > aware > > what is going in the message body. > > > > So, SIP proxy is only ware of signaling of messages between the > proxies > > and > > UAC and UAS assuming that both UAS and UAC are also layer 7-aware > entity. > > One can say that this is layer 7 server-server routing scheme. > > > > Best regards, > > Radhika > > > > > > > > _____ > > > > From: speermint-bounces@ietf.org on behalf of Brian Rosen > > Sent: Fri 4/7/2006 8:00 AM > > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs > > peering > > > > > > > > > So the SIP proxy is at L7. If that L7 entity tells a router how to > > route > > > a > > > flow (at L3 or worse, sub IP), then you have a layer violation. > > [[Reinaldo]] > > > > I believe this is where we part ways. I see what you mean, but I > > interpret it differently. I think routing of the media associated with > a > > L7 SIP routing decision is also a L7 routing decision since it is all > > part of the same call. > > > >
Perhaps you would care to explain what protocol is doing this and > how > > it works. I don't think we are defining new protocols here. I'm not > > aware > > of any L7 protocol already defined that could reasonably be used to > route > > media with any more specificity than SIP now does (which ultimately is > a > > direct path between UAS and UAC). You seem to be implying that there > is > > an > > L7 protocol, not SIP, which some peering element would use to cause > media > > to > > > > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > > Routers? Links? Sub-IP tunnels? What protocol would that be? > > > > Brian > > > > > > > > _______________________________________________ > > 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 Fri Apr 07 09:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr7R-0003Qs-3l; Fri, 07 Apr 2006 09:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRr7Q-0003Qn-56 for speermint@ietf.org; Fri, 07 Apr 2006 09:35:20 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRr7O-0004ti-UZ for speermint@ietf.org; Fri, 07 Apr 2006 09:35:20 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc13) with SMTP id <20060407133517m1300r1m2pe>; Fri, 7 Apr 2006 13:35:17 +0000 Message-ID: <040e01c65a47$c7491070$5a087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <030701c65a46$f1c04cc0$640fa8c0@cis.neustar.com> Subject: Re: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 08:32:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 this, but I don't think we need to start a religious war. Agree with Brian ... and if we ENDED one, that would be even better :-) Thanks, Spencer _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 09:40:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrCo-0005Zv-FR; Fri, 07 Apr 2006 09:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrCn-0005Zi-OS for speermint@ietf.org; Fri, 07 Apr 2006 09:40:53 -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 1FRrCm-000537-IX for speermint@ietf.org; Fri, 07 Apr 2006 09:40:53 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.18424483; Fri, 07 Apr 2006 09:40:16 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:40:20 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 09:40:19 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247DD5@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAAoErIAAD0gHEAAMM0hA From: "Livingood, Jason" To: "Stastny Richard" , "Hadriel Kaplan" , , X-OriginalArrivalTime: 07 Apr 2006 13:40:20.0627 (UTC) FILETIME=[D058E630:01C65A48] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > This is exactly the reason why I wanted to avoid talking=20 > about L3 and media now. We should first get L5 sorted out.=20 > Media streaming Between different address spaces required=20 > B2BUAs with all their problems and we should sort out the=20 > straightforward cases first Right approach - begin at the highest layer and once that is addressed, move on down the stack. Thus, start with getting the basics right and move on from there. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 09:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrHq-0005t5-66; Fri, 07 Apr 2006 09:46:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrHp-0005t0-BB for speermint@ietf.org; Fri, 07 Apr 2006 09:46:05 -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 1FRrHo-00057p-2j for speermint@ietf.org; Fri, 07 Apr 2006 09:46:05 -0400 Received: from ([10.20.62.12]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.18424641; Fri, 07 Apr 2006 09:45:21 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:44:43 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 09:44:41 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247DD6@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Thread-Index: AcZaRALzn0j5B5W8RwOm5nXKttiyCgAAP5rQAAEMbIA= From: "Livingood, Jason" To: "Reinaldo Penno" , , "Stastny Richard" , , "Medhavi Bhatia" , "Otmar Lendl" , X-OriginalArrivalTime: 07 Apr 2006 13:44:43.0226 (UTC) FILETIME=[6CDE53A0:01C65A49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 understand this. > >=20 > > Let us not correct the mess what others are creating. > [[Reinaldo]]=20 >=20 > Let me get this straight. Are you saying the work of 3GPP/IMS=20 > and TISPAN is a mess? That's a pretty strong statement. Let's not spin this aspect of the discussion out too far. No flame wars / religious wars please. :-) Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 10:36:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRs4v-0002ws-65; Fri, 07 Apr 2006 10:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRs4u-0002wn-Oj for speermint@ietf.org; Fri, 07 Apr 2006 10:36:48 -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 1FRs4t-0007J0-Hw for speermint@ietf.org; Fri, 07 Apr 2006 10:36:48 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 47F263EA4 for ; Fri, 7 Apr 2006 10:36:47 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 10:36: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 Date: Fri, 7 Apr 2006 10:36:45 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/w== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 07 Apr 2006 14:36:47.0156 (UTC) FILETIME=[B2E03740:01C65A50] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Speermint] 2 Basic Constructs for SIP Peering 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 have gnawed on the latest series of threads, and while wadding through the noise and rhetoric, it appears to me that there are 2 basic constructs for SIP peering. Subscribing to Brian's notion that we must try to keep this simple - at least at this stage - it seems to boil down to the following: (I acknowledge that there may be contextual variations) Option A) Session routing by 3rd party. =20 S /\ O--T In this model, O-Network queries S-Network (signaling) for routing options. S-Network redirects or proxies signaling request to T-network. There is an assumption that L3 connectivity exists between all three, though S-Network would not be transit for media, but possible for signaling. The media flows directly from O-Network to T-Network. Option B) Direct bi-lateral routing. O--T In this model, O-Network signals T-Network directly, and receives routing instructions. Media would follow the same relationship, maybe not the same path, but same bi-lateral relationship. Should there be more than one L3 peering point, any peering point may be used, but it all follows the same contextual relationship between O-Network and T-Network. I find it possible to apply either Option A or Option B to public, private, and even carrier (even carrier pigeon) environments. Maybe I am pointing out the obvious, but that's OK as I have been often accused of being master of the obvious. ;) Adam Uzelac _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 11:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsVz-0005o7-Fx; Fri, 07 Apr 2006 11:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsVy-0005o2-Ge for speermint@ietf.org; Fri, 07 Apr 2006 11:04:46 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRsVx-00087B-7L for speermint@ietf.org; Fri, 07 Apr 2006 11:04:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRsVq-0006gA-VF; Fri, 07 Apr 2006 10:04:39 -0500 From: "Brian Rosen" To: "'Uzelac, Adam'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Fri, 7 Apr 2006 11:04:40 -0400 Message-ID: <031901c65a54$9a6179f0$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAA6iFA X-PopBeforeSMTPSenders: br@brianrosen.net 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: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 people want to have option c O-S-T That is, the media goes through S as well as the signaling. I think that is agnostic to public/private/carrier I don't think it changes much. Brian -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Friday, April 07, 2006 10:37 AM To: speermint@ietf.org Subject: [Speermint] 2 Basic Constructs for SIP Peering I have gnawed on the latest series of threads, and while wadding through the noise and rhetoric, it appears to me that there are 2 basic constructs for SIP peering. Subscribing to Brian's notion that we must try to keep this simple - at least at this stage - it seems to boil down to the following: (I acknowledge that there may be contextual variations) Option A) Session routing by 3rd party. S /\ O--T In this model, O-Network queries S-Network (signaling) for routing options. S-Network redirects or proxies signaling request to T-network. There is an assumption that L3 connectivity exists between all three, though S-Network would not be transit for media, but possible for signaling. The media flows directly from O-Network to T-Network. Option B) Direct bi-lateral routing. O--T In this model, O-Network signals T-Network directly, and receives routing instructions. Media would follow the same relationship, maybe not the same path, but same bi-lateral relationship. Should there be more than one L3 peering point, any peering point may be used, but it all follows the same contextual relationship between O-Network and T-Network. I find it possible to apply either Option A or Option B to public, private, and even carrier (even carrier pigeon) environments. Maybe I am pointing out the obvious, but that's OK as I have been often accused of being master of the obvious. ;) Adam Uzelac _______________________________________________ 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 Apr 07 11:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsds-0001fv-3U; Fri, 07 Apr 2006 11:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRsdq-0001fq-EF for speermint@ietf.org; Fri, 07 Apr 2006 11:12:54 -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 1FRsdq-0008M4-66 for speermint@ietf.org; Fri, 07 Apr 2006 11:12:54 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 9C37D3D93; Fri, 7 Apr 2006 11:12:50 -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, 7 Apr 2006 11:12: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] 2 Basic Constructs for SIP Peering Date: Fri, 7 Apr 2006 11:12:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAA6iFAAAA5XpA= From: "Uzelac, Adam" To: , X-OriginalArrivalTime: 07 Apr 2006 15:12:49.0842 (UTC) FILETIME=[BBEFE920:01C65A55] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Brian, I agree. Though in most of the scenarios I know of, O-S-T looks like O-T via B2BUAs and Media Relay. Adam -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, April 07, 2006 11:05 AM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering I think people want to have option c O-S-T That is, the media goes through S as well as the signaling. I think that is agnostic to public/private/carrier I don't think it changes much. Brian -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Friday, April 07, 2006 10:37 AM To: speermint@ietf.org Subject: [Speermint] 2 Basic Constructs for SIP Peering I have gnawed on the latest series of threads, and while wadding through the noise and rhetoric, it appears to me that there are 2 basic constructs for SIP peering. Subscribing to Brian's notion that we must try to keep this simple - at least at this stage - it seems to boil down to the following: (I acknowledge that there may be contextual variations) Option A) Session routing by 3rd party. =20 S /\ O--T In this model, O-Network queries S-Network (signaling) for routing options. S-Network redirects or proxies signaling request to T-network. There is an assumption that L3 connectivity exists between all three, though S-Network would not be transit for media, but possible for signaling. The media flows directly from O-Network to T-Network. Option B) Direct bi-lateral routing. O--T In this model, O-Network signals T-Network directly, and receives routing instructions. Media would follow the same relationship, maybe not the same path, but same bi-lateral relationship. Should there be more than one L3 peering point, any peering point may be used, but it all follows the same contextual relationship between O-Network and T-Network. I find it possible to apply either Option A or Option B to public, private, and even carrier (even carrier pigeon) environments. Maybe I am pointing out the obvious, but that's OK as I have been often accused of being master of the obvious. ;) Adam Uzelac _______________________________________________ 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 Fri Apr 07 11:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtGJ-0007ja-Cw; Fri, 07 Apr 2006 11:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtGH-0007jV-Mk for speermint@ietf.org; Fri, 07 Apr 2006 11:52:37 -0400 Received: from test-iport-2.cisco.com ([171.71.176.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtGG-00017p-Dy for speermint@ietf.org; Fri, 07 Apr 2006 11:52:37 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 07 Apr 2006 08:52:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k37FqZw1022658; Fri, 7 Apr 2006 08:52:35 -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.211); Fri, 7 Apr 2006 11:52: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] Reachability Date: Fri, 7 Apr 2006 11:52:33 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30150A6EC@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Reachability Thread-Index: AcZVxOSydKFviB8aSGGgeVYRAZALIAAQFy1wAL+rSVAAENVkwAAA/adQAAisd/AAF6UQ8AALsC3wABf80LA= From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 07 Apr 2006 15:52:35.0041 (UTC) FILETIME=[49A06510:01C65A5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 clarifying, that sounds better to me. Mike =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Friday, April 07, 2006 12:40 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Reachability >=20 >=20 > Indeed, and there are mechanisms to handle that; but in such=20 > a case one wouldn't know whether it will lead to sub-optimal=20 > routes, nits, or better routes. I don't think he meant=20 > follow signaling hopy-by-hop, but rather provider-by-provider=20 > (if the middle providers wanted it to). > -hadriel > =20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, April 06, 2006 6:54 PM > > To: Patrick Melampy; Reinaldo Penno; Stastny Richard; Lee, Yiu;=20 > > Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] Reachability > >=20 > > Be careful of saying that "media must follow signaling". =20 > > Given mobility, that can lead to sub-optimal routes and possibly=20 > > horrible QoS. > > Maybe the media is handed from the control of A to control=20 > of B to C,=20 > > but that doesn't necessarily mean going through all the same boxes. > >=20 > > Mike > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 13:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRuPE-0001T9-0r; Fri, 07 Apr 2006 13:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRuPD-0001T4-12 for speermint@ietf.org; Fri, 07 Apr 2006 13:05:55 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRuPC-0004KS-Cl for speermint@ietf.org; Fri, 07 Apr 2006 13:05:54 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Apr 2006 10:05:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,98,1144047600"; d="scan'208"; a="541684869:sNHT27883764" 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] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 13:05:45 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE614@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Thread-Index: AcZaQ+sV0rlBEtKqTr6r3dsywa2odAAAUH/QAAcXBYA= From: "Reinaldo Penno" To: , , "Stastny Richard" , "Medhavi Bhatia" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c 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.... > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 6:27 AM > To: RADHIKA.R.ROY@saic.com; 'Stastny Richard'; Reinaldo Penno; 'Medhavi > Bhatia'; 'Otmar Lendl'; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs peering >=20 > I agree with this, but I don't think we need to start a religious war. >=20 > One of the things I think we may be able to agree on is that the peering > point can be assumed to either: >=20 > a) Just not be involved with the media >=20 > or >=20 > b) Have essentially infinite bandwidth available AT THE PEERING POINT for > the media >=20 > Carriers can do all kinds of shenanigans to get the media to the peering > point, but peering is limited by the "pipe" and not the "fabric" (however > the actual L3 packet routing is handled) >=20 > If I look around, I think this is the case for the kinds of arrangements > we > are contemplating. >=20 > It may be that eventually the world coalesces on some ideas to mix L3 > routing with L7 routing, and we could then handle more distributed peering > fabrics where there may be limitations at the peering point. Could we > agree > to postpone such discussions for now? [[Reinaldo]]=20 Fine, I wanted to create awareness because you do not want which would be the consumers of this standard/BCP to have to cram together IMS/TISPAN, which uses SIP and things such as gate control, with this standard (which also uses SIP). This would be problematic if:=20 1) They are in any way conflicting 2) Have huge functionalities gap (Well, some would argue that means more WG fun) I mean, we create BCP/standards for the community. We cannot just plainly ignore something that has been going on for years - that does not seem very responsible from our part. By that I mean there is a difference between not bothering about 3GPP, make sure we work together with their standards and getting in the way of 3GPP. That's my main concern. If we build something that does not work well with, or gets in the way of 3GPP that could be a problem for ISP/VSP/Carriers, etc. I hope it is very clear now. But I will postpone the discussions. >=20 > This still allows a quite wide space for media arrangements. Every > carrier > could bring in dumb pipes and just let a router at the peering point > shovel > the traffic around. One could have MPLS tunnels for peering partners that > were address sensitive (all traffic from Pa to Pb goes in a specific > tunnel). >=20 > What it doesn't do is put some kind of bandwidth manager function at the > peering point which chooses among multiple paths between Pa and Pb at the > peering point. At least it doesn't try to standardize such a function. > Is > that satisfactory? >=20 [[Reinaldo]]=20 Yes, I was referring more to the scheduling and prioritization of media and signaling flows (or QoS as you put it some emails ago) than bandwidth manager. It seems to me when there is peering, even though we could assume bandwidth is infinite as you mention, other QoS aspects come into play. If Layer 5 peering is dynamic such as some advocate, how domain A is going to let domain B know which flows are media and as such should receive better treatment. I have more similar questions. How to reconcile PHBs used in domain A and B? Or even diffserv markings? Are we going to do that through the peering policies? Alternatively could domain B trust domain A to remark media packets at the border with the dscp that make sense in domain B. Or will domain B do it? Or is each domain responsible for looking into the SDP information and marking/scheduling independently. This is certainly simpler (although the results are questionable), but seems to defeat somewhat the purpose of peering, which implies some cooperation. Not sure this relevant or not to this WG. > I note that "gate control" has more to do with distributed pinhole > firewall > management than with bandwidth management. I don't think we are going to > deal with such things, are we? I don't think peering entities have to > bring > standardized interfaces to their pinhole firewall for the peering system > to > tickle; they just get the SDP in the INVITE and use whatever they want to > open the hole for that flow. [[Reinaldo]]=20 No, we are not. I was relating more to the QoS treatment aspect of gate control as mentioned above. More specifically, QoS for media and signaling flows.=20 >=20 >=20 >=20 > -----Original Message----- > From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com] > Sent: Friday, April 07, 2006 9:05 AM > To: Stastny Richard; Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; > Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering >=20 > Richard: >=20 > I understand this. >=20 > Let us not correct the mess what others are creating. >=20 > If all the entities in the network need to be aware of all layers, we > would > not be here. We have to create separate standards and charter as well as > requirements. In this case, we all can create solutions based on this > basis. >=20 >=20 > For example, a new work has emerged known as cross-layer/inter-layer > communications especially in wireless where it is seen that, like wire- > line > network, it is sub-optimal to consider rigid 7 OSI layers in wireless. To > optimize communications in wireless networks, many research works and > implementations are coming out, and soon some standard works will be done > in > many standard organizations including IEEE and IETF. >=20 > I would advise 3GPP folks, not to put cart before the horse. Let us create > the standards following the established norms across whole world with > step-by-step procedures without creating technical mess and confusions. > Let > them have the courage to face this, without being confined in the > self-creating own narrow wall-prison. >=20 > Unless this is clarified, we all will be fooled though breaking our > fundamental working assumptions. >=20 > Best regards, > Radhika >=20 > _____ >=20 > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Fri 4/7/2006 8:53 AM > To: Roy, Radhika R.; br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; > Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > transitvs > peering >=20 >=20 >=20 > Agree, in plain SIP >=20 > But, >=20 > You should have a look at 3GPP and TISPAN IMS specifications >=20 > all the complexities added there is about > making the upper layers aware what is going on in > the lower layers >=20 > Richard >=20 > > -----Original Message----- > > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com > ] > > Sent: Friday, April 07, 2006 2:44 PM > > To: br@brianrosen.net; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; > > speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs peering > > > > Folks: > > > > Brian is right. > > > > Layer 7 is only signaling-message aware, and has no clue about the > lower > > IP > > network layer routing schemes. In terms of media, it (layer 7) is only > > carrying the identifier of media addresses provided by UAC and UAS. In > > fact, > > media addresses remain in the message body, and a SIP proxy is not > aware > > what is going in the message body. > > > > So, SIP proxy is only ware of signaling of messages between the > proxies > > and > > UAC and UAS assuming that both UAS and UAC are also layer 7-aware > entity. > > One can say that this is layer 7 server-server routing scheme. > > > > Best regards, > > Radhika > > > > > > > > _____ > > > > From: speermint-bounces@ietf.org on behalf of Brian Rosen > > Sent: Fri 4/7/2006 8:00 AM > > To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect- > > transitvs > > peering > > > > > > > > > So the SIP proxy is at L7. If that L7 entity tells a router how to > > route > > > a > > > flow (at L3 or worse, sub IP), then you have a layer violation. > > [[Reinaldo]] > > > > I believe this is where we part ways. I see what you mean, but I > > interpret it differently. I think routing of the media associated with > a > > L7 SIP routing decision is also a L7 routing decision since it is all > > part of the same call. > > > >
Perhaps you would care to explain what protocol is doing this and > how > > it works. I don't think we are defining new protocols here. I'm not > > aware > > of any L7 protocol already defined that could reasonably be used to > route > > media with any more specificity than SIP now does (which ultimately is > a > > direct path between UAS and UAC). You seem to be implying that there > is > > an > > L7 protocol, not SIP, which some peering element would use to cause > media > > to > > > > flow between the UAS and UAC via some set of ?what? L7 Intermediaries? > > Routers? Links? Sub-IP tunnels? What protocol would that be? > > > > Brian > > > > > > > > _______________________________________________ > > 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 Fri Apr 07 13:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRv0c-0000d6-OM; Fri, 07 Apr 2006 13:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRv0b-0000cd-Cr for speermint@ietf.org; Fri, 07 Apr 2006 13:44:33 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRuzf-0005tQ-Ca for speermint@ietf.org; Fri, 07 Apr 2006 13:43:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRuzY-0003bC-62 for speermint@ietf.org; Fri, 07 Apr 2006 12:43:28 -0500 From: "Brian Rosen" To: Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 13:43:31 -0400 Message-ID: <033b01c65a6a$cb00d360$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.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQA== X-PopBeforeSMTPSenders: br@brianrosen.net 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: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 changed the subject line, at least this part of the thread may be fruitful> >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any other >>kind of links down in the router. > >The process of getting signaled RTP data onto these tunnels, and not the >best efforts packets from the same IP address pairs, is essential and in >scope. .... >>This doesn't say you can't mark media packets in some way that sends them >>down some specific tunnels. >The process of doing this -- routing by packet markings -- and how this >will >be setup on a call-by-call basis from the same IP address pairs used for >best efforts should be in scope. Now we may be getting somewhere. This seems like it creates requirements I might be able to deal with. What I'm hearing is that you think, fundamentally, that signaling packets must be able to be marked differently from media packets. Seems hard to argue with that. But I believe you want a requirement that we cover PER FLOW marking. I think that might be something worth discussing. There are two ways we know how to do this. The right way (get the origin to mark them right in the first place) and the expeditious way (put an intermediary in the path and remark them). That intermediary could be an L5/L7 entity, or it could be down in router-land using normal flow identifier techniques. Are you looking for requirements like that? >>This doesn't say you can't create any kind of static routing mechanisms you >>like for any set of flows you can identify. >Once again....how to use these static routes (which is often why SBC's are >used--essentially creating the head of a static route) needs to be studied >by this group. Well, is this any different from the marking issue above? What do you want the BCP to say beyond marking of packets? What is the requirement? Marking of packets is a subject worthy of discussion I think. In the best of all worlds, we would agree on the proper marking of packets, all networks would mark in a uniform way, and routers would route in an optimal manner for the packets marked appropriately no matter how many domains the packets crossed. Dream on you say. I agree, but we should, probably, at least mention the ideal (which implies we actually specify what the marking should be). I'd expect to see signaling packets marked differently than media packets. There could reasonably be different marking for different kinds of media (text vs audio vs video, for example). Then we have to deal with the reality that marking within a domain may be consistent, but in peering, the O marking won't be the same as the T marking, and we need to remark at the peering edge. Then we could consider per-flow marking. I'm not so sure I want to go there, but I'm willing to listen. But is there more than that? What, exactly? Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 13:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvAM-0005rB-M7; Fri, 07 Apr 2006 13:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvAK-0005qw-IJ for speermint@ietf.org; Fri, 07 Apr 2006 13:54:36 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvAJ-0007Uy-9y for speermint@ietf.org; Fri, 07 Apr 2006 13:54:36 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Fri, 7 Apr 2006 13:54:15 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006040713541522595 ; Fri, 07 Apr 2006 13:54:15 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Apr 2006 13:54:15 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426209C1A@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: "Livingood, Jason" , Reinaldo Penno , RADHIKA.R.ROY@saic.com, Stastny Richard , br@brianrosen.net, Medhavi Bhatia , Otmar Lendl , speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading onNGNInterconnect-transitv s peering Date: Fri, 7 Apr 2006 13:54:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" 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 Inline [RRR] _____ From: jason_livingood@cable.comcast.com on behalf of Livingood, Jason Sent: Fri 4/7/2006 9:44 AM To: Reinaldo Penno; RADHIKA.R.ROY@saic.com; Stastny Richard; br@brianrosen.net; Medhavi Bhatia; Otmar Lendl; speermint@ietf.org Subject: RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering > > I understand this. > > > > Let us not correct the mess what others are creating. > [[Reinaldo]] > > Let me get this straight. Are you saying the work of 3GPP/IMS > and TISPAN is a mess? That's a pretty strong statement. Let's not spin this aspect of the discussion out too far. No flame wars / religious wars please. :-) [RRR] It is a non-technical statement. [RRR] The issue is this: To manage the media routing in IP network layer from the application layer (L7) by the SIP Proxy. If 3GPP wnats to solve this problem, let them put this requirement and charter for standardization. People throughout the world will particiapte to solve this problem: How to make a standard like this - IETF will also join to this if it makes sense. [RRR] Without making any clear statetement for standardization, if some ad hoc things are done here and there, they are violating the norms of the worldwide standardization. It is very dangerous and technically harmful for standardization for all people throughout the world. [RRR] When we are talking something in the IETF, we are deal with the world community of standardization open to all, not some close things that others do. Is this clear? Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 07 14:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRw7H-0002fB-8q; Fri, 07 Apr 2006 14:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRw7F-0002f1-SE for speermint@ietf.org; Fri, 07 Apr 2006 14:55:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRw7F-0001Kl-Iv for speermint@ietf.org; Fri, 07 Apr 2006 14:55:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2006 14:55:30 -0400 X-IronPort-AV: i="4.04,98,1144036800"; d="scan'208"; a="85981789:sNHT31824806" 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 k37ItQVk018050; Fri, 7 Apr 2006 14:55:29 -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.211); Fri, 7 Apr 2006 14:55:28 -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: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 14:55:25 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30150A7D4@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+A From: "Michael Hammer \(mhammer\)" To: , X-OriginalArrivalTime: 07 Apr 2006 18:55:28.0877 (UTC) FILETIME=[D68AE1D0:01C65A74] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Brian, Are you talking something like?: draft-ietf-tsvwg-diffserv-service-classes-02.txt=20 Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, April 07, 2006 1:44 PM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:=20 > Background Reading onNGNInterconnect-transitvs peering >=20 >=20 > I changed the subject line, at least this part of the thread may be > fruitful> >=20 >=20 > >>This doesn't say you can't have VPN tunnels, or MPLS=20 > tunnels, or any=20 > >>other kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not=20 > >the best efforts packets from the same IP address pairs, is=20 > essential=20 > >and in scope. >=20 > .... >=20 > >>This doesn't say you can't mark media packets in some way=20 > that sends=20 > >>them down some specific tunnels. >=20 > >The process of doing this -- routing by packet markings --=20 > and how this=20 > >will be setup on a call-by-call basis from the same IP address pairs=20 > >used for best efforts should be in scope. >=20 > Now we may be getting somewhere. This seems like it creates=20 > requirements I might be able to deal with. >=20 > What I'm hearing is that you think, fundamentally, that=20 > signaling packets must be able to be marked differently from=20 > media packets. Seems hard to argue with that. >=20 > But I believe you want a requirement that we cover PER FLOW=20 > marking. I think that might be something worth discussing. =20 >=20 > There are two ways we know how to do this. The right way=20 > (get the origin to mark them right in the first place) and=20 > the expeditious way (put an intermediary in the path and=20 > remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal=20 > flow identifier techniques. >=20 > Are you looking for requirements like that? >=20 >=20 >=20 >=20 >=20 > >>This doesn't say you can't create any kind of static routing=20 > >>mechanisms > you > >>like for any set of flows you can identify. >=20 > >Once again....how to use these static routes (which is often=20 > why SBC's=20 > >are used--essentially creating the head of a static route)=20 > needs to be=20 > >studied by this group. > Well, is this any different from the marking issue above? =20 > What do you want the BCP to say beyond marking of packets? =20 > What is the requirement? >=20 > Marking of packets is a subject worthy of discussion I think. >=20 > In the best of all worlds, we would agree on the proper=20 > marking of packets, all networks would mark in a uniform way,=20 > and routers would route in an optimal manner for the packets=20 > marked appropriately no matter how many domains the packets crossed. =20 >=20 > Dream on you say. =20 >=20 > I agree, but we should, probably, at least mention the ideal=20 > (which implies we actually specify what the marking should=20 > be). I'd expect to see signaling packets marked differently=20 > than media packets. There could reasonably be different=20 > marking for different kinds of media (text vs audio vs video,=20 > for example). >=20 > Then we have to deal with the reality that marking within a=20 > domain may be consistent, but in peering, the O marking won't=20 > be the same as the T marking, and we need to remark at the=20 > peering edge. >=20 > Then we could consider per-flow marking. I'm not so sure I=20 > want to go there, but I'm willing to listen. >=20 > But is there more than that? What, exactly? >=20 > Brian >=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 Fri Apr 07 14:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwBL-0008LU-GJ; Fri, 07 Apr 2006 14:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwBK-0008LP-1U for speermint@ietf.org; Fri, 07 Apr 2006 14:59:42 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRwBJ-0001dX-Ia for speermint@ietf.org; Fri, 07 Apr 2006 14:59:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Apr 2006 11:59:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,98,1144047600"; d="scan'208"; a="541708275:sNHT25918424" 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: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 14:59:39 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE61A@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAACZH6w From: "Reinaldo Penno" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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 I must have missed a message...you are quoting/replying to somebody saying many things in a message I did not see... > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 10:44 AM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading onNGNInterconnect-transitvs peering >=20 >=20 > I changed the subject line, at least this part of the thread may be > fruitful> >=20 >=20 > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any > other > >>kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not the > >best efforts packets from the same IP address pairs, is essential and in > >scope. >=20 [[Reinaldo]]=20 I seem to agree with this. Who said this? >=20 > >>This doesn't say you can't mark media packets in some way that sends > them > >>down some specific tunnels. >=20 > >The process of doing this -- routing by packet markings -- and how this > >will > >be setup on a call-by-call basis from the same IP address pairs used for > >best efforts should be in scope. >=20 > Now we may be getting somewhere. This seems like it creates requirements > I > might be able to deal with. >=20 > What I'm hearing is that you think, fundamentally, that signaling packets > must be able to be marked differently from media packets. Seems hard to > argue with that. >=20 > But I believe you want a requirement that we cover PER FLOW marking. I > think that might be something worth discussing. >=20 > There are two ways we know how to do this. The right way (get the origin > to > mark them right in the first place) and the expeditious way (put an > intermediary in the path and remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal flow > identifier techniques. >=20 > Are you looking for requirements like that? [[Reinaldo]]=20 Well, yes. Can domain A trust B to the point that it will trust B's users to mark packets correctly? And carry those marking into its network across the peering point? Seems like a stretch...It seems ISPs sometimes do not trust their own users and remark packets and the edge. The problem is not really mark the packets by an intermediary, but mark them in an away acceptable (and maps to the correct PHB) in the other domain.=20 As I mentioned before: If Layer 5 peering is dynamic such as some advocate, how domain A is going to let domain B know which flows are media and as such should receive better treatment. I have more similar questions. How to reconcile PHBs used in domain A and B? Or even diffserv markings? Are we going to do that through the peering policies? Alternatively could domain B trust domain A to remark media packets at the border with the dscp that make sense in domain B. Or will domain B do it? Or is each domain responsible for looking into the SDP information and marking/scheduling independently. This is certainly simpler (although the results are questionable), but seems to defeat somewhat the purpose of peering, which implies some cooperation. >=20 >=20 >=20 >=20 >=20 > >>This doesn't say you can't create any kind of static routing mechanisms > you > >>like for any set of flows you can identify. >=20 > >Once again....how to use these static routes (which is often why SBC's > are > >used--essentially creating the head of a static route) needs to be > studied > >by this group. > Well, is this any different from the marking issue above? What do you > want > the BCP to say beyond marking of packets? What is the requirement? >=20 > Marking of packets is a subject worthy of discussion I think. >=20 > In the best of all worlds, we would agree on the proper marking of > packets, > all networks would mark in a uniform way, and routers would route in an > optimal manner for the packets marked appropriately no matter how many > domains the packets crossed. >=20 > Dream on you say. >=20 > I agree, but we should, probably, at least mention the ideal (which > implies > we actually specify what the marking should be). I'd expect to see > signaling packets marked differently than media packets. There could > reasonably be different marking for different kinds of media (text vs > audio > vs video, for example). >=20 > Then we have to deal with the reality that marking within a domain may be > consistent, but in peering, the O marking won't be the same as the T > marking, and we need to remark at the peering edge. [[Reinaldo]]=20 Could not agree more. >=20 > Then we could consider per-flow marking. I'm not so sure I want to go > there, but I'm willing to listen. [[Reinaldo]]=20 Well, is there any other way? Are we assuming gazillions of call-pairs across a peering point will have the same markings?? Please elaborate. >=20 > But is there more than that? What, exactly? >=20 > Brian >=20 >=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 Apr 07 15:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwE9-0000TK-2e; Fri, 07 Apr 2006 15:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwE7-0000TF-LM for speermint@ietf.org; Fri, 07 Apr 2006 15:02:35 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRwE7-0001pc-99 for speermint@ietf.org; Fri, 07 Apr 2006 15:02:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRwDz-0002sm-GD; Fri, 07 Apr 2006 14:02:27 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 15:02:31 -0400 Message-ID: <035301c65a75$d42277e0$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 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30150A7D4@xmb-rtp-20b.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Uh-huh, at least for a generic "everyone should do this" kind of thing. I have no illusions that big complex carrier networks will adopt anything as straightforward as -service-classes, but many more focused carriers could, and profit there-by. So, I think our BCP should reference that work, but I believe it's not sufficient. We probably need some kind of policy driven re-marking thingy. What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" is maybe doable. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, April 07, 2006 2:55 PM To: br@brianrosen.net; speermint@ietf.org Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Brian, Are you talking something like?: draft-ietf-tsvwg-diffserv-service-classes-02.txt Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 1:44 PM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > Background Reading onNGNInterconnect-transitvs peering > > > I changed the subject line, at least this part of the thread may be > fruitful> > > > >>This doesn't say you can't have VPN tunnels, or MPLS > tunnels, or any > >>other kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not > >the best efforts packets from the same IP address pairs, is > essential > >and in scope. > > .... > > >>This doesn't say you can't mark media packets in some way > that sends > >>them down some specific tunnels. > > >The process of doing this -- routing by packet markings -- > and how this > >will be setup on a call-by-call basis from the same IP address pairs > >used for best efforts should be in scope. > > Now we may be getting somewhere. This seems like it creates > requirements I might be able to deal with. > > What I'm hearing is that you think, fundamentally, that > signaling packets must be able to be marked differently from > media packets. Seems hard to argue with that. > > But I believe you want a requirement that we cover PER FLOW > marking. I think that might be something worth discussing. > > There are two ways we know how to do this. The right way > (get the origin to mark them right in the first place) and > the expeditious way (put an intermediary in the path and > remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal > flow identifier techniques. > > Are you looking for requirements like that? > > > > > > >>This doesn't say you can't create any kind of static routing > >>mechanisms > you > >>like for any set of flows you can identify. > > >Once again....how to use these static routes (which is often > why SBC's > >are used--essentially creating the head of a static route) > needs to be > >studied by this group. > Well, is this any different from the marking issue above? > What do you want the BCP to say beyond marking of packets? > What is the requirement? > > Marking of packets is a subject worthy of discussion I think. > > In the best of all worlds, we would agree on the proper > marking of packets, all networks would mark in a uniform way, > and routers would route in an optimal manner for the packets > marked appropriately no matter how many domains the packets crossed. > > Dream on you say. > > I agree, but we should, probably, at least mention the ideal > (which implies we actually specify what the marking should > be). I'd expect to see signaling packets marked differently > than media packets. There could reasonably be different > marking for different kinds of media (text vs audio vs video, > for example). > > Then we have to deal with the reality that marking within a > domain may be consistent, but in peering, the O marking won't > be the same as the T marking, and we need to remark at the > peering edge. > > Then we could consider per-flow marking. I'm not so sure I > want to go there, but I'm willing to listen. > > But is there more than that? What, exactly? > > Brian > > > > _______________________________________________ > 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 Apr 07 15:17:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwSw-00034D-VF; Fri, 07 Apr 2006 15:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwSv-000346-Dp for speermint@ietf.org; Fri, 07 Apr 2006 15:17:53 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRwSu-0002j0-WC for speermint@ietf.org; Fri, 07 Apr 2006 15:17:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FRwSm-0004FB-Jd; Fri, 07 Apr 2006 14:17:45 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 15:17:48 -0400 Message-ID: <035a01c65a77$f6e8d560$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 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE61A@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAACZH6wAAB8QqA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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, from this I get Yes, you think marking is a good idea No, you don't think source marking is sufficient Yes, you think re-marking at the edge of peering is needed Is it sufficient, at least for now, if we say we can do per-T-domain remarking? That implies all media flows to a given T-domain are marked the same way. I can handle this. Is this sufficient? Do we need more than marking per T-domain? What I don't want to do, if we can help it, is to have to specify mechanisms where a peering domain has to use some kind of bookkeeping on flows to determine marking. If all we have is a per-T-domain mark, I can deal with that. I'm saying "per-T-domain" but of course the flows from T to O are marked with O's choice of mark. Is marking sufficient? Does that mean DiffServ is sufficient? Think a little about how this is done. If the peering point has infinite bandwidth, than you can mark on entry to peering, traverse the peering fabric, and get to the other side ready-marked. If it doesn't, you may have to mark on entry to the fabric using a peering-specified mark, let the fabric do DiffServ on a PHB it defines, then remark again on entry to the other domain. We have to say how this works, because it does affect the interface to the peering point (assuming that it is the source who is responsible for at least the initial re-marking). Brian -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Friday, April 07, 2006 3:00 PM To: br@brianrosen.net; speermint@ietf.org Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering I think I must have missed a message...you are quoting/replying to somebody saying many things in a message I did not see... > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 10:44 AM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading onNGNInterconnect-transitvs peering > > > I changed the subject line, at least this part of the thread may be > fruitful> > > > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any > other > >>kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not the > >best efforts packets from the same IP address pairs, is essential and in > >scope. > [[Reinaldo]] I seem to agree with this. Who said this? > > >>This doesn't say you can't mark media packets in some way that sends > them > >>down some specific tunnels. > > >The process of doing this -- routing by packet markings -- and how this > >will > >be setup on a call-by-call basis from the same IP address pairs used for > >best efforts should be in scope. > > Now we may be getting somewhere. This seems like it creates requirements > I > might be able to deal with. > > What I'm hearing is that you think, fundamentally, that signaling packets > must be able to be marked differently from media packets. Seems hard to > argue with that. > > But I believe you want a requirement that we cover PER FLOW marking. I > think that might be something worth discussing. > > There are two ways we know how to do this. The right way (get the origin > to > mark them right in the first place) and the expeditious way (put an > intermediary in the path and remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal flow > identifier techniques. > > Are you looking for requirements like that? [[Reinaldo]] Well, yes. Can domain A trust B to the point that it will trust B's users to mark packets correctly? And carry those marking into its network across the peering point? Seems like a stretch...It seems ISPs sometimes do not trust their own users and remark packets and the edge. The problem is not really mark the packets by an intermediary, but mark them in an away acceptable (and maps to the correct PHB) in the other domain. As I mentioned before: If Layer 5 peering is dynamic such as some advocate, how domain A is going to let domain B know which flows are media and as such should receive better treatment. I have more similar questions. How to reconcile PHBs used in domain A and B? Or even diffserv markings? Are we going to do that through the peering policies? Alternatively could domain B trust domain A to remark media packets at the border with the dscp that make sense in domain B. Or will domain B do it? Or is each domain responsible for looking into the SDP information and marking/scheduling independently. This is certainly simpler (although the results are questionable), but seems to defeat somewhat the purpose of peering, which implies some cooperation. > > > > > > >>This doesn't say you can't create any kind of static routing mechanisms > you > >>like for any set of flows you can identify. > > >Once again....how to use these static routes (which is often why SBC's > are > >used--essentially creating the head of a static route) needs to be > studied > >by this group. > Well, is this any different from the marking issue above? What do you > want > the BCP to say beyond marking of packets? What is the requirement? > > Marking of packets is a subject worthy of discussion I think. > > In the best of all worlds, we would agree on the proper marking of > packets, > all networks would mark in a uniform way, and routers would route in an > optimal manner for the packets marked appropriately no matter how many > domains the packets crossed. > > Dream on you say. > > I agree, but we should, probably, at least mention the ideal (which > implies > we actually specify what the marking should be). I'd expect to see > signaling packets marked differently than media packets. There could > reasonably be different marking for different kinds of media (text vs > audio > vs video, for example). > > Then we have to deal with the reality that marking within a domain may be > consistent, but in peering, the O marking won't be the same as the T > marking, and we need to remark at the peering edge. [[Reinaldo]] Could not agree more. > > Then we could consider per-flow marking. I'm not so sure I want to go > there, but I'm willing to listen. [[Reinaldo]] Well, is there any other way? Are we assuming gazillions of call-pairs across a peering point will have the same markings?? Please elaborate. > > But is there more than that? What, exactly? > > Brian > > > > _______________________________________________ > 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 Apr 07 21:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS2XG-0000qg-HZ; Fri, 07 Apr 2006 21:46:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS2XE-0000qY-Ap for speermint@ietf.org; Fri, 07 Apr 2006 21:46:44 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS2XD-0006fh-Sn for speermint@ietf.org; Fri, 07 Apr 2006 21:46:44 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A5FE03A0; Fri, 07 Apr 2006 21:46:38 -0400 From: "Hadriel Kaplan" To: , "'Reinaldo Penno'" , Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 21:46:44 -0400 Message-ID: <00a501c65aae$4a7e7a50$91c8000a@acmepacket.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: <035a01c65a77$f6e8d560$640fa8c0@cis.neustar.com> Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAACZH6wAAB8QqAADS+AgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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 Hey Brian, I think that would be one place to start for media. One thing is it's different for different media types (audio, video, image, etc.). But it doesn't have to be per call-flow; just the "policy rule" exchanged has to define the media-type+dscp and applied to all media flows going to T. -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 3:18 PM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > ReadingonNGNInterconnect-transitvs peering > > So, from this I get > Yes, you think marking is a good idea > No, you don't think source marking is sufficient > Yes, you think re-marking at the edge of peering is needed > > Is it sufficient, at least for now, if we say we can do per-T-domain > remarking? That implies all media flows to a given T-domain are marked > the > same way. I can handle this. > > Is this sufficient? Do we need more than marking per T-domain? > What I don't want to do, if we can help it, is to have to specify > mechanisms > where a peering domain has to use some kind of bookkeeping on flows to > determine marking. If all we have is a per-T-domain mark, I can deal with > that. > > I'm saying "per-T-domain" but of course the flows from T to O are marked > with O's choice of mark. > > Is marking sufficient? Does that mean DiffServ is sufficient? > > Think a little about how this is done. If the peering point has infinite > bandwidth, than you can mark on entry to peering, traverse the peering > fabric, and get to the other side ready-marked. If it doesn't, you may > have > to mark on entry to the fabric using a peering-specified mark, let the > fabric do DiffServ on a PHB it defines, then remark again on entry to the > other domain. We have to say how this works, because it does affect the > interface to the peering point (assuming that it is the source who is > responsible for at least the initial re-marking). > > Brian > > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Friday, April 07, 2006 3:00 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading > onNGNInterconnect-transitvs peering > > I think I must have missed a message...you are quoting/replying to > somebody saying many things in a message I did not see... > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 10:44 AM > > To: speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > > > I changed the subject line, at least this part of the thread may be > > fruitful> > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any > > other > > >>kind of links down in the router. > > > > > >The process of getting signaled RTP data onto these tunnels, and not > the > > >best efforts packets from the same IP address pairs, is essential and > in > > >scope. > > > [[Reinaldo]] > > I seem to agree with this. Who said this? > > > > > >>This doesn't say you can't mark media packets in some way that sends > > them > > >>down some specific tunnels. > > > > >The process of doing this -- routing by packet markings -- and how > this > > >will > > >be setup on a call-by-call basis from the same IP address pairs used > for > > >best efforts should be in scope. > > > > Now we may be getting somewhere. This seems like it creates > requirements > > I > > might be able to deal with. > > > > What I'm hearing is that you think, fundamentally, that signaling > packets > > must be able to be marked differently from media packets. Seems hard > to > > argue with that. > > > > But I believe you want a requirement that we cover PER FLOW marking. > I > > think that might be something worth discussing. > > > > There are two ways we know how to do this. The right way (get the > origin > > to > > mark them right in the first place) and the expeditious way (put an > > intermediary in the path and remark them). That intermediary could be > an > > L5/L7 entity, or it could be down in router-land using normal flow > > identifier techniques. > > > > Are you looking for requirements like that? > [[Reinaldo]] > > Well, yes. Can domain A trust B to the point that it will trust B's > users to mark packets correctly? And carry those marking into its > network across the peering point? Seems like a stretch...It seems ISPs > sometimes do not trust their own users and remark packets and the edge. > > The problem is not really mark the packets by an intermediary, but mark > them in an away acceptable (and maps to the correct PHB) in the other > domain. > > As I mentioned before: > > If Layer 5 peering is dynamic such as some advocate, how domain A is > going to let domain B know which flows are media and as such should > receive better treatment. > > I have more similar questions. How to reconcile PHBs used in domain A > and B? Or even diffserv markings? Are we going to do that through the > peering policies? > > Alternatively could domain B trust domain A to remark media packets at > the border with the dscp that make sense in domain B. Or will domain B > do it? > > Or is each domain responsible for looking into the SDP information and > marking/scheduling independently. This is certainly simpler (although > the results are questionable), but seems to defeat somewhat the purpose > of peering, which implies some cooperation. > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > mechanisms > > you > > >>like for any set of flows you can identify. > > > > >Once again....how to use these static routes (which is often why > SBC's > > are > > >used--essentially creating the head of a static route) needs to be > > studied > > >by this group. > > Well, is this any different from the marking issue above? What do you > > want > > the BCP to say beyond marking of packets? What is the requirement? > > > > Marking of packets is a subject worthy of discussion I think. > > > > In the best of all worlds, we would agree on the proper marking of > > packets, > > all networks would mark in a uniform way, and routers would route in > an > > optimal manner for the packets marked appropriately no matter how many > > domains the packets crossed. > > > > Dream on you say. > > > > I agree, but we should, probably, at least mention the ideal (which > > implies > > we actually specify what the marking should be). I'd expect to see > > signaling packets marked differently than media packets. There could > > reasonably be different marking for different kinds of media (text vs > > audio > > vs video, for example). > > > > Then we have to deal with the reality that marking within a domain may > be > > consistent, but in peering, the O marking won't be the same as the T > > marking, and we need to remark at the peering edge. > [[Reinaldo]] > > Could not agree more. > > > > > Then we could consider per-flow marking. I'm not so sure I want to go > > there, but I'm willing to listen. > [[Reinaldo]] > > Well, is there any other way? Are we assuming gazillions of call-pairs > across a peering point will have the same markings?? > > Please elaborate. > > > > > > But is there more than that? What, exactly? > > > > Brian > > > > > > > > _______________________________________________ > > 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 Fri Apr 07 21:59:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS2j7-0005Fr-Pn; Fri, 07 Apr 2006 21:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS2j6-0005Du-Nd for speermint@ietf.org; Fri, 07 Apr 2006 21:59:00 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS2j6-00071g-EG for speermint@ietf.org; Fri, 07 Apr 2006 21:59:00 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A8E304A8; Fri, 07 Apr 2006 21:58:59 -0400 From: "Hadriel Kaplan" To: "'Uzelac, Adam'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Fri, 7 Apr 2006 21:59:05 -0400 Message-ID: <00a601c65ab0$048b2690$91c8000a@acmepacket.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: Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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, If S is doing a redirect/proxy, isn't it just the location lookup mechanism for O--T? (a trusted+shared location-lookup) So there's really just: L / O---T. Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:37 AM > To: speermint@ietf.org > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > I have gnawed on the latest series of threads, and while wadding through > the noise and rhetoric, it appears to me that there are 2 basic > constructs for SIP peering. Subscribing to Brian's notion that we must > try to keep this simple - at least at this stage - it seems to boil down > to the following: (I acknowledge that there may be contextual > variations) > > Option A) Session routing by 3rd party. > > S > /\ > O--T > > In this model, O-Network queries S-Network (signaling) for routing > options. S-Network redirects or proxies signaling request to T-network. > There is an assumption that L3 connectivity exists between all three, > though S-Network would not be transit for media, but possible for > signaling. The media flows directly from O-Network to T-Network. > > Option B) Direct bi-lateral routing. > > O--T > > In this model, O-Network signals T-Network directly, and receives > routing instructions. Media would follow the same relationship, maybe > not the same path, but same bi-lateral relationship. Should there be > more than one L3 peering point, any peering point may be used, but it > all follows the same contextual relationship between O-Network and > T-Network. > > I find it possible to apply either Option A or Option B to public, > private, and even carrier (even carrier pigeon) environments. Maybe I > am pointing out the obvious, but that's OK as I have been often accused > of being master of the obvious. ;) > > Adam Uzelac > > _______________________________________________ > 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 Apr 07 22:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS32C-0002uK-3X; Fri, 07 Apr 2006 22:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS32A-0002uF-6h for speermint@ietf.org; Fri, 07 Apr 2006 22:18:42 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS329-0007cB-KE for speermint@ietf.org; Fri, 07 Apr 2006 22:18:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 07 Apr 2006 19:18:40 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,101,1144047600"; d="scan'208"; a="538520887:sNHT26180820" 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: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 22:18:38 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE61E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Media Packet Marking, was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAACZH6wAAB8QqAADqEjYA== From: "Reinaldo Penno" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 12:18 PM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading onNGNInterconnect-transitvs peering >=20 > So, from this I get > Yes, you think marking is a good idea > No, you don't think source marking is sufficient > Yes, you think re-marking at the edge of peering is needed >=20 > Is it sufficient, at least for now, if we say we can do per-T-domain > remarking? That implies all media flows to a given T-domain are marked > the > same way. I can handle this. >=20 > Is this sufficient? Do we need more than marking per T-domain? > What I don't want to do, if we can help it, is to have to specify > mechanisms > where a peering domain has to use some kind of bookkeeping on flows to > determine marking. If all we have is a per-T-domain mark, I can deal with > that. >=20 > I'm saying "per-T-domain" but of course the flows from T to O are marked > with O's choice of mark. [[Reinaldo]]=20 Hello Brian, I could agree with you, the issue is if the (VoIP)service providers/carriers will think it is enough. What we are basically saying is that _all_ media flows to/from a certain domain will be marked with the _same_ dscp. So, if the service provider expects some differentiation based on the fact that a customer is a medium vs. large enterprise vs. home user, he will not be able to do that. Since providers today use sometimes between 4 and 8 service classes (and sometimes special ones per VPN), I wonder if our proposal will fly. Maybe the carriers/ISPs on the list could chime in the discussion. Now, if somebody says that the edge proxy or router has the ability to remark everything than the whole discussion is moot. But we are assuming media identification is done only by the endpoints because of the bookkeeping issue you mentioned. So, what options do we have? It seems: 1) _one_ dscp for all media flows (read all source-destination pairs) between domain A and B. Seems limited. 2) The "edge system" in the other domain can reclassify everything (with SIP over TLS and other things I think that would be difficult).=20 3) Per flow diffserv marking. Lots of bookkeeping 4) Something in between. Maybe per destination IP address (network, range, whatever). 5) =20 >=20 > Is marking sufficient? Does that mean DiffServ is sufficient? >=20 > Think a little about how this is done. If the peering point has infinite > bandwidth, than you can mark on entry to peering, traverse the peering > fabric, and get to the other side ready-marked. If it doesn't, you may > have > to mark on entry to the fabric using a peering-specified mark, let the > fabric do DiffServ on a PHB it defines, then remark again on entry to the > other domain. We have to say how this works, because it does affect the > interface to the peering point (assuming that it is the source who is > responsible for at least the initial re-marking). [[Reinaldo]]=20 Agree, I'm only concerned about the granularity offered.=20 >=20 > Brian >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Friday, April 07, 2006 3:00 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading > onNGNInterconnect-transitvs peering >=20 > I think I must have missed a message...you are quoting/replying to > somebody saying many things in a message I did not see... >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 10:44 AM > > To: speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > > > I changed the subject line, at least this part of the thread may be > > fruitful> > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or any > > other > > >>kind of links down in the router. > > > > > >The process of getting signaled RTP data onto these tunnels, and not > the > > >best efforts packets from the same IP address pairs, is essential and > in > > >scope. > > > [[Reinaldo]] >=20 > I seem to agree with this. Who said this? >=20 > > > > >>This doesn't say you can't mark media packets in some way that sends > > them > > >>down some specific tunnels. > > > > >The process of doing this -- routing by packet markings -- and how > this > > >will > > >be setup on a call-by-call basis from the same IP address pairs used > for > > >best efforts should be in scope. > > > > Now we may be getting somewhere. This seems like it creates > requirements > > I > > might be able to deal with. > > > > What I'm hearing is that you think, fundamentally, that signaling > packets > > must be able to be marked differently from media packets. Seems hard > to > > argue with that. > > > > But I believe you want a requirement that we cover PER FLOW marking. > I > > think that might be something worth discussing. > > > > There are two ways we know how to do this. The right way (get the > origin > > to > > mark them right in the first place) and the expeditious way (put an > > intermediary in the path and remark them). That intermediary could be > an > > L5/L7 entity, or it could be down in router-land using normal flow > > identifier techniques. > > > > Are you looking for requirements like that? > [[Reinaldo]] >=20 > Well, yes. Can domain A trust B to the point that it will trust B's > users to mark packets correctly? And carry those marking into its > network across the peering point? Seems like a stretch...It seems ISPs > sometimes do not trust their own users and remark packets and the edge. >=20 > The problem is not really mark the packets by an intermediary, but mark > them in an away acceptable (and maps to the correct PHB) in the other > domain. >=20 > As I mentioned before: >=20 > If Layer 5 peering is dynamic such as some advocate, how domain A is > going to let domain B know which flows are media and as such should > receive better treatment. >=20 > I have more similar questions. How to reconcile PHBs used in domain A > and B? Or even diffserv markings? Are we going to do that through the > peering policies? >=20 > Alternatively could domain B trust domain A to remark media packets at > the border with the dscp that make sense in domain B. Or will domain B > do it? >=20 > Or is each domain responsible for looking into the SDP information and > marking/scheduling independently. This is certainly simpler (although > the results are questionable), but seems to defeat somewhat the purpose > of peering, which implies some cooperation. >=20 > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > mechanisms > > you > > >>like for any set of flows you can identify. > > > > >Once again....how to use these static routes (which is often why > SBC's > > are > > >used--essentially creating the head of a static route) needs to be > > studied > > >by this group. > > Well, is this any different from the marking issue above? What do you > > want > > the BCP to say beyond marking of packets? What is the requirement? > > > > Marking of packets is a subject worthy of discussion I think. > > > > In the best of all worlds, we would agree on the proper marking of > > packets, > > all networks would mark in a uniform way, and routers would route in > an > > optimal manner for the packets marked appropriately no matter how many > > domains the packets crossed. > > > > Dream on you say. > > > > I agree, but we should, probably, at least mention the ideal (which > > implies > > we actually specify what the marking should be). I'd expect to see > > signaling packets marked differently than media packets. There could > > reasonably be different marking for different kinds of media (text vs > > audio > > vs video, for example). > > > > Then we have to deal with the reality that marking within a domain may > be > > consistent, but in peering, the O marking won't be the same as the T > > marking, and we need to remark at the peering edge. > [[Reinaldo]] >=20 > Could not agree more. >=20 > > > > Then we could consider per-flow marking. I'm not so sure I want to go > > there, but I'm willing to listen. > [[Reinaldo]] >=20 > Well, is there any other way? Are we assuming gazillions of call-pairs > across a peering point will have the same markings?? >=20 > Please elaborate. >=20 >=20 > > > > But is there more than that? What, exactly? > > > > Brian > > > > > > > > _______________________________________________ > > 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 Apr 07 22:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3Jt-0005DW-Hf; Fri, 07 Apr 2006 22:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3Js-0005DR-1A for speermint@ietf.org; Fri, 07 Apr 2006 22:37: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 1FS3Jr-00086O-PC for speermint@ietf.org; Fri, 07 Apr 2006 22:37:00 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 452315110; Fri, 7 Apr 2006 22:35:21 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 22:35:21 -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] 2 Basic Constructs for SIP Peering Date: Fri, 7 Apr 2006 22:35:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHA= From: "Uzelac, Adam" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 08 Apr 2006 02:35:21.0184 (UTC) FILETIME=[14D6CE00:01C65AB5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 can't agree in a proxied(non-redirect) call flow. Also, there may be a requirement to determine which T-Network to term the call to should there be more than one. There could be a subsequent T-Network proxy involved. So the call would be signaled from O-Network to S-Network, and then maybe S-Network to T-Network to determine ultimate T-Network end point. =20 Adam Uzelac -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Friday, April 07, 2006 9:59 PM To: Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Hi Adam, If S is doing a redirect/proxy, isn't it just the location lookup mechanism for O--T? (a trusted+shared location-lookup) So there's really just: L / O---T. Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:37 AM > To: speermint@ietf.org > Subject: [Speermint] 2 Basic Constructs for SIP Peering >=20 > I have gnawed on the latest series of threads, and while wadding=20 > through the noise and rhetoric, it appears to me that there are 2=20 > basic constructs for SIP peering. Subscribing to Brian's notion that=20 > we must try to keep this simple - at least at this stage - it seems to > boil down to the following: (I acknowledge that there may be=20 > contextual > variations) >=20 > Option A) Session routing by 3rd party. >=20 > S > /\ > O--T >=20 > In this model, O-Network queries S-Network (signaling) for routing=20 > options. S-Network redirects or proxies signaling request to T-network. > There is an assumption that L3 connectivity exists between all three,=20 > though S-Network would not be transit for media, but possible for=20 > signaling. The media flows directly from O-Network to T-Network. >=20 > Option B) Direct bi-lateral routing. >=20 > O--T >=20 > In this model, O-Network signals T-Network directly, and receives=20 > routing instructions. Media would follow the same relationship, maybe > not the same path, but same bi-lateral relationship. Should there be=20 > more than one L3 peering point, any peering point may be used, but it=20 > all follows the same contextual relationship between O-Network and=20 > T-Network. >=20 > I find it possible to apply either Option A or Option B to public,=20 > private, and even carrier (even carrier pigeon) environments. Maybe I > am pointing out the obvious, but that's OK as I have been often=20 > accused of being master of the obvious. ;) >=20 > Adam Uzelac >=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 Fri Apr 07 22:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3N7-00085Q-Qb; Fri, 07 Apr 2006 22:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3N6-00085L-Q3 for speermint@ietf.org; Fri, 07 Apr 2006 22:40:20 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS3N6-0008HX-9J for speermint@ietf.org; Fri, 07 Apr 2006 22:40:20 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A293041C; Fri, 07 Apr 2006 22:40:19 -0400 From: "Hadriel Kaplan" To: "'Reinaldo Penno'" , , Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Date: Fri, 7 Apr 2006 22:40:25 -0400 Message-ID: <00ac01c65ab5$ca5f6e30$91c8000a@acmepacket.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: <9BD5D7887235424FA97DFC223CAE3C2802DFE61E@proton.jnpr.net> Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAACZH6wAAB8QqAADqEjYAABKr6g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e 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 if different service classes are used for enterprise vs. consumer, then you're inferring the T-partner also has an agreement to service such classes, else it wouldn't want O-partner to differentiate such to it. So if you do have such an agreement, wouldn't it just be done with two logical T-partners? At least that's what I was thinking when he said it, but I haven't thought it through. -hadriel > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Friday, April 07, 2006 10:19 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > ReadingonNGNInterconnect-transitvs peering > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 12:18 PM > > To: Reinaldo Penno; speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > So, from this I get > > Yes, you think marking is a good idea > > No, you don't think source marking is sufficient > > Yes, you think re-marking at the edge of peering is needed > > > > Is it sufficient, at least for now, if we say we can do per-T-domain > > remarking? That implies all media flows to a given T-domain are > marked > > the > > same way. I can handle this. > > > > Is this sufficient? Do we need more than marking per T-domain? > > What I don't want to do, if we can help it, is to have to specify > > mechanisms > > where a peering domain has to use some kind of bookkeeping on flows to > > determine marking. If all we have is a per-T-domain mark, I can deal > with > > that. > > > > I'm saying "per-T-domain" but of course the flows from T to O are > marked > > with O's choice of mark. > [[Reinaldo]] > > Hello Brian, > > I could agree with you, the issue is if the (VoIP)service > providers/carriers will think it is enough. What we are basically saying > is that _all_ media flows to/from a certain domain will be marked with > the _same_ dscp. > > So, if the service provider expects some differentiation based on the > fact that a customer is a medium vs. large enterprise vs. home user, he > will not be able to do that. Since providers today use sometimes between > 4 and 8 service classes (and sometimes special ones per VPN), I wonder > if our proposal will fly. Maybe the carriers/ISPs on the list could > chime in the discussion. > > Now, if somebody says that the edge proxy or router has the ability to > remark everything than the whole discussion is moot. But we are assuming > media identification is done only by the endpoints because of the > bookkeeping issue you mentioned. > > So, what options do we have? It seems: > > 1) _one_ dscp for all media flows (read all source-destination pairs) > between domain A and B. Seems limited. > > 2) The "edge system" in the other domain can reclassify everything (with > SIP over TLS and other things I think that would be difficult). > > 3) Per flow diffserv marking. Lots of bookkeeping > > 4) Something in between. Maybe per destination IP address (network, > range, whatever). > > 5) > > > > > Is marking sufficient? Does that mean DiffServ is sufficient? > > > > Think a little about how this is done. If the peering point has > infinite > > bandwidth, than you can mark on entry to peering, traverse the peering > > fabric, and get to the other side ready-marked. If it doesn't, you > may > > have > > to mark on entry to the fabric using a peering-specified mark, let the > > fabric do DiffServ on a PHB it defines, then remark again on entry to > the > > other domain. We have to say how this works, because it does affect > the > > interface to the peering point (assuming that it is the source who is > > responsible for at least the initial re-marking). > [[Reinaldo]] > > Agree, I'm only concerned about the granularity offered. > > > > > Brian > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Friday, April 07, 2006 3:00 PM > > To: br@brianrosen.net; speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading > > onNGNInterconnect-transitvs peering > > > > I think I must have missed a message...you are quoting/replying to > > somebody saying many things in a message I did not see... > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 10:44 AM > > > To: speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > > Reading onNGNInterconnect-transitvs peering > > > > > > > > > I changed the subject line, at least this part of the thread may be > > > fruitful> > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS tunnels, or > any > > > other > > > >>kind of links down in the router. > > > > > > > >The process of getting signaled RTP data onto these tunnels, and > not > > the > > > >best efforts packets from the same IP address pairs, is essential > and > > in > > > >scope. > > > > > [[Reinaldo]] > > > > I seem to agree with this. Who said this? > > > > > > > > >>This doesn't say you can't mark media packets in some way that > sends > > > them > > > >>down some specific tunnels. > > > > > > >The process of doing this -- routing by packet markings -- and how > > this > > > >will > > > >be setup on a call-by-call basis from the same IP address pairs > used > > for > > > >best efforts should be in scope. > > > > > > Now we may be getting somewhere. This seems like it creates > > requirements > > > I > > > might be able to deal with. > > > > > > What I'm hearing is that you think, fundamentally, that signaling > > packets > > > must be able to be marked differently from media packets. Seems > hard > > to > > > argue with that. > > > > > > But I believe you want a requirement that we cover PER FLOW marking. > > I > > > think that might be something worth discussing. > > > > > > There are two ways we know how to do this. The right way (get the > > origin > > > to > > > mark them right in the first place) and the expeditious way (put an > > > intermediary in the path and remark them). That intermediary could > be > > an > > > L5/L7 entity, or it could be down in router-land using normal flow > > > identifier techniques. > > > > > > Are you looking for requirements like that? > > [[Reinaldo]] > > > > Well, yes. Can domain A trust B to the point that it will trust B's > > users to mark packets correctly? And carry those marking into its > > network across the peering point? Seems like a stretch...It seems ISPs > > sometimes do not trust their own users and remark packets and the > edge. > > > > The problem is not really mark the packets by an intermediary, but > mark > > them in an away acceptable (and maps to the correct PHB) in the other > > domain. > > > > As I mentioned before: > > > > If Layer 5 peering is dynamic such as some advocate, how domain A is > > going to let domain B know which flows are media and as such should > > receive better treatment. > > > > I have more similar questions. How to reconcile PHBs used in domain A > > and B? Or even diffserv markings? Are we going to do that through the > > peering policies? > > > > Alternatively could domain B trust domain A to remark media packets at > > the border with the dscp that make sense in domain B. Or will domain B > > do it? > > > > Or is each domain responsible for looking into the SDP information and > > marking/scheduling independently. This is certainly simpler (although > > the results are questionable), but seems to defeat somewhat the > purpose > > of peering, which implies some cooperation. > > > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > mechanisms > > > you > > > >>like for any set of flows you can identify. > > > > > > >Once again....how to use these static routes (which is often why > > SBC's > > > are > > > >used--essentially creating the head of a static route) needs to be > > > studied > > > >by this group. > > > Well, is this any different from the marking issue above? What do > you > > > want > > > the BCP to say beyond marking of packets? What is the requirement? > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > In the best of all worlds, we would agree on the proper marking of > > > packets, > > > all networks would mark in a uniform way, and routers would route in > > an > > > optimal manner for the packets marked appropriately no matter how > many > > > domains the packets crossed. > > > > > > Dream on you say. > > > > > > I agree, but we should, probably, at least mention the ideal (which > > > implies > > > we actually specify what the marking should be). I'd expect to see > > > signaling packets marked differently than media packets. There > could > > > reasonably be different marking for different kinds of media (text > vs > > > audio > > > vs video, for example). > > > > > > Then we have to deal with the reality that marking within a domain > may > > be > > > consistent, but in peering, the O marking won't be the same as the T > > > marking, and we need to remark at the peering edge. > > [[Reinaldo]] > > > > Could not agree more. > > > > > > > > Then we could consider per-flow marking. I'm not so sure I want to > go > > > there, but I'm willing to listen. > > [[Reinaldo]] > > > > Well, is there any other way? Are we assuming gazillions of call-pairs > > across a peering point will have the same markings?? > > > > Please elaborate. > > > > > > > > > > But is there more than that? What, exactly? > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > 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 Fri Apr 07 23:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3pi-0000aI-0u; Fri, 07 Apr 2006 23:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS3ph-0000aA-F0 for speermint@ietf.org; Fri, 07 Apr 2006 23:09:53 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS3pf-0000qf-3t for speermint@ietf.org; Fri, 07 Apr 2006 23:09:53 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A97E0388; Fri, 07 Apr 2006 23:09:50 -0400 From: "Hadriel Kaplan" To: "'Uzelac, Adam'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Fri, 7 Apr 2006 23:09:55 -0400 Message-ID: <00ae01c65ab9$e9e29cb0$91c8000a@acmepacket.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: Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I can't agree in a proxied(non-redirect) call flow. Also, there may be > a requirement to determine which T-Network to term the call to should > there be more than one. There could be a subsequent T-Network proxy > involved. So the call would be signaled from O-Network to S-Network, > and then maybe S-Network to T-Network to determine ultimate T-Network > end point. > > Adam Uzelac > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Hi Adam, > > If S is doing a redirect/proxy, isn't it just the location lookup > mechanism for O--T? (a trusted+shared location-lookup) > > So there's really just: > L > / > O---T. > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding > > through the noise and rhetoric, it appears to me that there are 2 > > basic constructs for SIP peering. Subscribing to Brian's notion that > > we must try to keep this simple - at least at this stage - it seems to > > > boil down to the following: (I acknowledge that there may be > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all three, > > though S-Network would not be transit for media, but possible for > > signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives > > routing instructions. Media would follow the same relationship, maybe > > > not the same path, but same bi-lateral relationship. Should there be > > more than one L3 peering point, any peering point may be used, but it > > all follows the same contextual relationship between O-Network and > > T-Network. > > > > I find it possible to apply either Option A or Option B to public, > > private, and even carrier (even carrier pigeon) environments. Maybe I > > > am pointing out the obvious, but that's OK as I have been often > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 Sat Apr 08 05:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS9rt-0006u7-Qh; Sat, 08 Apr 2006 05:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS9rs-0006gn-DK for speermint@ietf.org; Sat, 08 Apr 2006 05:36:32 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FS9rr-0005Pi-P3 for speermint@ietf.org; Sat, 08 Apr 2006 05:36:32 -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] 2 Basic Constructs for SIP Peering Date: Sat, 8 Apr 2006 11:40:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4979@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAAN1gzg From: "Stastny Richard" To: "Hadriel Kaplan" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f 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 > So there's really just: > L > / > O---T. The location function is one of the basic functions SPEERMINT needs to = work on =20 Of course the simplest case is defined in RFC 3263, but there are more=20 complex cases - e.g. a redirect/proxy server, eventaually also involving an ENUM lookup, this is basically what VPF or XConnect are providing. (the second is policy, i.e. if you are able to access the given proxy) =20 Another task may be to translate personal URIs or enterprise AoRs = hosted by a SP to the ingress proxy of the SP e.g. Sip:bill@microsoft.co.uk -> = sip:bill@ms.bt.com =20 The main task of a "location function" is to provide the out-bound proxy of the O-domain (one of) the ingress proxy(s) of the T-domain =20 > I can't agree in a proxied(non-redirect) call flow. Also, there may = be > a requirement to determine which T-Network to term the call to should > there be more than one. =20 =20 With terminating networks it is like Highlander there can only be one =20 > There could be a subsequent T-Network proxy > involved. So the call would be signaled from O-Network to S-Network, > and then maybe S-Network to T-Network to determine ultimate T-Network > end point. =20 >From the point of the O-domain there is only one T-domain ingress point If there are a bunch of T-domains hidden behind does not matter for the = O-domain or to be precise: it MUST NOT. =20 The reason for topology hiding proxies is topology hiding =20 If for example the mobile networks decide to open up the IPX GSMA network to be reached by selected partners from the Internet, they will put ingress proxies at the border of their network, and all what a O-domain on the internet will see for a AoR hosted by the mobile networks will be the ingress proxies of IPX. =20 The routing to the real t-domain (teh specific mobile network will then be done via the ingress proxy The O-domain is not concerend Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Sa 08.04.2006 05:09 An: 'Uzelac, Adam'; speermint@ietf.org Betreff: RE: [Speermint] 2 Basic Constructs for SIP Peering Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I can't agree in a proxied(non-redirect) call flow. Also, there may = be > a requirement to determine which T-Network to term the call to should > there be more than one. There could be a subsequent T-Network proxy > involved. So the call would be signaled from O-Network to S-Network, > and then maybe S-Network to T-Network to determine ultimate T-Network > end point. > > Adam Uzelac > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Hi Adam, > > If S is doing a redirect/proxy, isn't it just the location lookup > mechanism for O--T? (a trusted+shared location-lookup) > > So there's really just: > L > / > O---T. > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding > > through the noise and rhetoric, it appears to me that there are 2 > > basic constructs for SIP peering. Subscribing to Brian's notion = that > > we must try to keep this simple - at least at this stage - it seems = to > > > boil down to the following: (I acknowledge that there may be > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all = three, > > though S-Network would not be transit for media, but possible for > > signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives > > routing instructions. Media would follow the same relationship, = maybe > > > not the same path, but same bi-lateral relationship. Should there = be > > more than one L3 peering point, any peering point may be used, but = it > > all follows the same contextual relationship between O-Network and > > T-Network. > > > > I find it possible to apply either Option A or Option B to public, > > private, and even carrier (even carrier pigeon) environments. Maybe = I > > > am pointing out the obvious, but that's OK as I have been often > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 Sat Apr 08 10:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSEnj-00081C-SU; Sat, 08 Apr 2006 10:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSEni-000812-Lp for speermint@ietf.org; Sat, 08 Apr 2006 10:52:34 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSEni-0006mM-6S for speermint@ietf.org; Sat, 08 Apr 2006 10:52:34 -0400 Received: from PMelampy [68.189.242.21] by acmepacket.com with ESMTP (SMTPD-9.02) id AE31016C; Sat, 08 Apr 2006 10:52:33 -0400 From: "Patrick Melampy" To: Subject: RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Date: Sat, 8 Apr 2006 10:52:33 -0400 Message-ID: <00c001c65b1c$11c828a0$9dc8000a@acmepacket.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.2180 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6w X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 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, This new kind of policy driven marking thing must work across network borders -- and across trust boundaries. What we really need to solve the routing problem is a second forwarding equivalence class -- one for best efforts, and one for voice. These must be advertised through BGP4 edges to effect a second routing plane. Only then can you solve the routing problem. If this was all completed, and we could make packets route differently based on service (different next-hop networks), we have solved a first problem. However it is unclear that we have made the internet better. Now when you "ping" an address, you get a different response if the ToS is best efforts verses Voice. You also would have to revise ICMP handling to deal with "unreachable address messages" to take into account the ToS. There may be many other protocol issues that occur when these bits are not set properly. I can think of one simple one. I want to establish a TCP/TLS SIPS session to a proxy. This proxy is ONLY reachable in the ToS Voice forwarding plane. However, when I use the Berkely Sockets to create the socket ... the syn/syn syn/ack ack three way handshake doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until the socket is opened). Thus we would have to alter the ways Berkely sockets work to ensure that the 3way TCP handshake routes properly. These complications may be worth the salvation of honor and avoidance of doing something evil like a simple NAT like SBC's do. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, April 07, 2006 3:03 PM To: 'Michael Hammer (mhammer)'; speermint@ietf.org Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Uh-huh, at least for a generic "everyone should do this" kind of thing. I have no illusions that big complex carrier networks will adopt anything as straightforward as -service-classes, but many more focused carriers could, and profit there-by. So, I think our BCP should reference that work, but I believe it's not sufficient. We probably need some kind of policy driven re-marking thingy. What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" is maybe doable. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, April 07, 2006 2:55 PM To: br@brianrosen.net; speermint@ietf.org Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Brian, Are you talking something like?: draft-ietf-tsvwg-diffserv-service-classes-02.txt Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 1:44 PM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > Background Reading onNGNInterconnect-transitvs peering > > > I changed the subject line, at least this part of the thread may be > fruitful> > > > >>This doesn't say you can't have VPN tunnels, or MPLS > tunnels, or any > >>other kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not > >the best efforts packets from the same IP address pairs, is > essential > >and in scope. > > .... > > >>This doesn't say you can't mark media packets in some way > that sends > >>them down some specific tunnels. > > >The process of doing this -- routing by packet markings -- > and how this > >will be setup on a call-by-call basis from the same IP address pairs > >used for best efforts should be in scope. > > Now we may be getting somewhere. This seems like it creates > requirements I might be able to deal with. > > What I'm hearing is that you think, fundamentally, that > signaling packets must be able to be marked differently from > media packets. Seems hard to argue with that. > > But I believe you want a requirement that we cover PER FLOW > marking. I think that might be something worth discussing. > > There are two ways we know how to do this. The right way > (get the origin to mark them right in the first place) and > the expeditious way (put an intermediary in the path and > remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal > flow identifier techniques. > > Are you looking for requirements like that? > > > > > > >>This doesn't say you can't create any kind of static routing > >>mechanisms > you > >>like for any set of flows you can identify. > > >Once again....how to use these static routes (which is often > why SBC's > >are used--essentially creating the head of a static route) > needs to be > >studied by this group. > Well, is this any different from the marking issue above? > What do you want the BCP to say beyond marking of packets? > What is the requirement? > > Marking of packets is a subject worthy of discussion I think. > > In the best of all worlds, we would agree on the proper > marking of packets, all networks would mark in a uniform way, > and routers would route in an optimal manner for the packets > marked appropriately no matter how many domains the packets crossed. > > Dream on you say. > > I agree, but we should, probably, at least mention the ideal > (which implies we actually specify what the marking should > be). I'd expect to see signaling packets marked differently > than media packets. There could reasonably be different > marking for different kinds of media (text vs audio vs video, > for example). > > Then we have to deal with the reality that marking within a > domain may be consistent, but in peering, the O marking won't > be the same as the T marking, and we need to remark at the > peering edge. > > Then we could consider per-flow marking. I'm not so sure I > want to go there, but I'm willing to listen. > > But is there more than that? What, exactly? > > Brian > > > > _______________________________________________ > 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 Sat Apr 08 14:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSHlD-0002PO-QR; Sat, 08 Apr 2006 14:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSHlC-0002PI-Rj for speermint@ietf.org; Sat, 08 Apr 2006 14:02:10 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSHlB-0004eu-EN for speermint@ietf.org; Sat, 08 Apr 2006 14:02:10 -0400 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k38I2PF4001043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Apr 2006 11:02:34 -0700 Message-ID: <4437FA8D.5080509@shockey.us> Date: Sat, 08 Apr 2006 14:01:49 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Speermint] [Fwd: [SIPForum-techwg] IP PBX / SP Interoperability Proposed Final Draft - Working Group Last Call] FYI 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 FYI .. Just a note that the SIP forum is now essentially finished with its IP-PBX to SP interface specification which should have some relevance to the seemingly endless discussion going on here. -------- Original Message -------- Subject: [SIPForum-techwg] IP PBX / SP Interoperability Proposed Final Draft - Working Group Last Call Date: Mon, 27 Mar 2006 12:53:36 -0500 From: Richard Shockey To: Chris Sibley CC: SIP Forum Tech WG References: <68D2858458D1684999D254CB49C99CFB049CC995@exch-corp01.corp.cbeyond.net> After discussion with the authors and the chairs we have decided to begin a working group last call on the final draft listed below beginning today Monday March for 3 weeks. The intent of the last call is to solicit comments before submitting the draft to the SIP Forum Board of Directors as a Proposed Specification. This document has been under extensive discussion thought 2005. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work group last call will extend from today until at April 17 though we can modify that if new issues come up. > The proposed final draft of the IP PBX / SP Interoperability > specification is now available online for your review at the following URL: > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Interop-sibley-final.pdf > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 10 15:45:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2KH-0004qw-L8; Mon, 10 Apr 2006 15:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2KG-0004qm-O3 for speermint@ietf.org; Mon, 10 Apr 2006 15:45:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2KG-0008OJ-9q for speermint@ietf.org; Mon, 10 Apr 2006 15:45:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FT2K8-0008KZ-FK; Mon, 10 Apr 2006 14:45:20 -0500 From: "Brian Rosen" To: "'Patrick Melampy'" , Subject: RE: [Speermint] RE: BackgroundReadingonNGNInterconnect-transitvs peering Date: Mon, 10 Apr 2006 15:45:23 -0400 Message-ID: <056f01c65cd7$50d3a710$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 In-Reply-To: <00c001c65b1c$11c828a0$9dc8000a@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAA= 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: 16c9da4896bf5539ae3547c6c25f06a0 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 personally think this is way over the top for a BCP. If such things were deployed now, even experimentally, and we had some good reports on complexity, stability and usefulness, then maybe we could document that as "Best Current Practice". In the absence of anything like it, to my knowledge, in the wild, I'd say let's not go there. I'm pretty certain that an objective evaluation of this scheme would result in a "more bandwidth is cheaper" conclusion, but since my speculation isn't any more valid that yours I think we just fagetabodit. Can we just stick with per T-domain marking and DiffServ? Brian -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com] Sent: Saturday, April 08, 2006 10:53 AM To: speermint@ietf.org Subject: RE: [Speermint] RE: BackgroundReadingonNGNInterconnect-transitvs peering Brian, This new kind of policy driven marking thing must work across network borders -- and across trust boundaries. What we really need to solve the routing problem is a second forwarding equivalence class -- one for best efforts, and one for voice. These must be advertised through BGP4 edges to effect a second routing plane. Only then can you solve the routing problem. If this was all completed, and we could make packets route differently based on service (different next-hop networks), we have solved a first problem. However it is unclear that we have made the internet better. Now when you "ping" an address, you get a different response if the ToS is best efforts verses Voice. You also would have to revise ICMP handling to deal with "unreachable address messages" to take into account the ToS. There may be many other protocol issues that occur when these bits are not set properly. I can think of one simple one. I want to establish a TCP/TLS SIPS session to a proxy. This proxy is ONLY reachable in the ToS Voice forwarding plane. However, when I use the Berkely Sockets to create the socket ... the syn/syn syn/ack ack three way handshake doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until the socket is opened). Thus we would have to alter the ways Berkely sockets work to ensure that the 3way TCP handshake routes properly. These complications may be worth the salvation of honor and avoidance of doing something evil like a simple NAT like SBC's do. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, April 07, 2006 3:03 PM To: 'Michael Hammer (mhammer)'; speermint@ietf.org Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background ReadingonNGNInterconnect-transitvs peering Uh-huh, at least for a generic "everyone should do this" kind of thing. I have no illusions that big complex carrier networks will adopt anything as straightforward as -service-classes, but many more focused carriers could, and profit there-by. So, I think our BCP should reference that work, but I believe it's not sufficient. We probably need some kind of policy driven re-marking thingy. What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" is maybe doable. Brian -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, April 07, 2006 2:55 PM To: br@brianrosen.net; speermint@ietf.org Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background Reading onNGNInterconnect-transitvs peering Brian, Are you talking something like?: draft-ietf-tsvwg-diffserv-service-classes-02.txt Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 1:44 PM > To: speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > Background Reading onNGNInterconnect-transitvs peering > > > I changed the subject line, at least this part of the thread may be > fruitful> > > > >>This doesn't say you can't have VPN tunnels, or MPLS > tunnels, or any > >>other kind of links down in the router. > > > >The process of getting signaled RTP data onto these tunnels, and not > >the best efforts packets from the same IP address pairs, is > essential > >and in scope. > > .... > > >>This doesn't say you can't mark media packets in some way > that sends > >>them down some specific tunnels. > > >The process of doing this -- routing by packet markings -- > and how this > >will be setup on a call-by-call basis from the same IP address pairs > >used for best efforts should be in scope. > > Now we may be getting somewhere. This seems like it creates > requirements I might be able to deal with. > > What I'm hearing is that you think, fundamentally, that > signaling packets must be able to be marked differently from > media packets. Seems hard to argue with that. > > But I believe you want a requirement that we cover PER FLOW > marking. I think that might be something worth discussing. > > There are two ways we know how to do this. The right way > (get the origin to mark them right in the first place) and > the expeditious way (put an intermediary in the path and > remark them). That intermediary could be an > L5/L7 entity, or it could be down in router-land using normal > flow identifier techniques. > > Are you looking for requirements like that? > > > > > > >>This doesn't say you can't create any kind of static routing > >>mechanisms > you > >>like for any set of flows you can identify. > > >Once again....how to use these static routes (which is often > why SBC's > >are used--essentially creating the head of a static route) > needs to be > >studied by this group. > Well, is this any different from the marking issue above? > What do you want the BCP to say beyond marking of packets? > What is the requirement? > > Marking of packets is a subject worthy of discussion I think. > > In the best of all worlds, we would agree on the proper > marking of packets, all networks would mark in a uniform way, > and routers would route in an optimal manner for the packets > marked appropriately no matter how many domains the packets crossed. > > Dream on you say. > > I agree, but we should, probably, at least mention the ideal > (which implies we actually specify what the marking should > be). I'd expect to see signaling packets marked differently > than media packets. There could reasonably be different > marking for different kinds of media (text vs audio vs video, > for example). > > Then we have to deal with the reality that marking within a > domain may be consistent, but in peering, the O marking won't > be the same as the T marking, and we need to remark at the > peering edge. > > Then we could consider per-flow marking. I'm not so sure I > want to go there, but I'm willing to listen. > > But is there more than that? What, exactly? > > Brian > > > > _______________________________________________ > 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 Apr 10 16:19:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2qq-0004me-3V; Mon, 10 Apr 2006 16:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2qo-0004mZ-OY for speermint@ietf.org; Mon, 10 Apr 2006 16:19:06 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2qo-0002af-5f for speermint@ietf.org; Mon, 10 Apr 2006 16:19:06 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 10 Apr 2006 13:19:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,108,1144047600"; d="scan'208"; a="539023260:sNHT26386088" 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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Mon, 10 Apr 2006 16:19:03 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE628@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAAUcVMA== From: "Reinaldo Penno" To: , "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 10, 2006 12:45 PM > To: 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > I personally think this is way over the top for a BCP. >=20 > If such things were deployed now, even experimentally, and we had some > good > reports on complexity, stability and usefulness, then maybe we could > document that as "Best Current Practice". In the absence of anything like > it, to my knowledge, in the wild, I'd say let's not go there. >=20 > I'm pretty certain that an objective evaluation of this scheme would > result > in a "more bandwidth is cheaper" conclusion, but since my speculation > isn't > any more valid that yours I think we just fagetabodit. >=20 > Can we just stick with per T-domain marking and DiffServ? [[Reinaldo]]=20 I think this will not meet the needs to of (V)ISPs. We are talking about _multimedia_ peering, so we should at least have something similar to: ------------------------------------------------------------------ | Service | DSCP | DSCP | Application | | Class name | name | value | Examples | = |=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| | Telephony | EF | 101110 | IP Telephony bearer | |---------------+---------+-------------+--------------------------| | Signaling | CS5 | 101000 | IP Telephony signaling | |---------------+---------+-------------+--------------------------| | Multimedia |AF41,AF42|100010,100100| H.323/V2 video | | Conferencing | AF43 | 100110 | conferencing (adaptive) | |---------------+---------+-------------+--------------------------| | Real-time | CS4 | 100000 | Video conferencing and | | Interactive | | | Interactive gaming | |---------------+---------+-------------+--------------------------| | Multimedia |AF31,AF32|011010,011100| Streaming video and | | Streaming | AF33 | 011110 | audio on demand | |---------------+---------+-------------+--------------------------| |Broadcast Video| CS3 | 011000 |Broadcast TV & live events| |---------------+---------+-------------+--------------------------| Of course that does not preclude somebody from marking on a per flow basis. Regards, Reinaldo >=20 > Brian >=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Saturday, April 08, 2006 10:53 AM > To: speermint@ietf.org > Subject: RE: [Speermint] RE: BackgroundReadingonNGNInterconnect-transitvs > peering >=20 >=20 > Brian, >=20 > This new kind of policy driven marking thing must work across network > borders -- and across trust boundaries. What we really need to solve the > routing problem is a second forwarding equivalence class -- one for best > efforts, and one for voice. These must be advertised through BGP4 edges to > effect a second routing plane. Only then can you solve the routing > problem. >=20 > If this was all completed, and we could make packets route differently > based > on service (different next-hop networks), we have solved a first problem. > However it is unclear that we have made the internet better. Now when you > "ping" an address, you get a different response if the ToS is best efforts > verses Voice. You also would have to revise ICMP handling to deal with > "unreachable address messages" to take into account the ToS. There may be > many other protocol issues that occur when these bits are not set > properly. >=20 > I can think of one simple one. >=20 > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is ONLY > reachable in the ToS Voice forwarding plane. However, when I use the > Berkely > Sockets to create the socket ... the syn/syn syn/ack ack three way > handshake > doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until the > socket is opened). Thus we would have to alter the ways Berkely sockets > work > to ensure that the 3way TCP handshake routes properly. >=20 > These complications may be worth the salvation of honor and avoidance of > doing something evil like a simple NAT like SBC's do. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 3:03 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > ReadingonNGNInterconnect-transitvs peering >=20 > Uh-huh, at least for a generic "everyone should do this" kind of thing. >=20 > I have no illusions that big complex carrier networks will adopt anything > as > straightforward as -service-classes, but many more focused carriers could, > and profit there-by. >=20 > So, I think our BCP should reference that work, but I believe it's not > sufficient. We probably need some kind of policy driven re-marking > thingy. >=20 > What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" > is > maybe doable. >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 07, 2006 2:55 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading > onNGNInterconnect-transitvs peering >=20 > Brian, >=20 > Are you talking something like?: > draft-ietf-tsvwg-diffserv-service-classes-02.txt >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 1:44 PM > > To: speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > Background Reading onNGNInterconnect-transitvs peering > > > > > > I changed the subject line, at least this part of the thread may be > > fruitful> > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > tunnels, or any > > >>other kind of links down in the router. > > > > > >The process of getting signaled RTP data onto these tunnels, and not > > >the best efforts packets from the same IP address pairs, is > > essential > > >and in scope. > > > > .... > > > > >>This doesn't say you can't mark media packets in some way > > that sends > > >>them down some specific tunnels. > > > > >The process of doing this -- routing by packet markings -- > > and how this > > >will be setup on a call-by-call basis from the same IP address pairs > > >used for best efforts should be in scope. > > > > Now we may be getting somewhere. This seems like it creates > > requirements I might be able to deal with. > > > > What I'm hearing is that you think, fundamentally, that > > signaling packets must be able to be marked differently from > > media packets. Seems hard to argue with that. > > > > But I believe you want a requirement that we cover PER FLOW > > marking. I think that might be something worth discussing. > > > > There are two ways we know how to do this. The right way > > (get the origin to mark them right in the first place) and > > the expeditious way (put an intermediary in the path and > > remark them). That intermediary could be an > > L5/L7 entity, or it could be down in router-land using normal > > flow identifier techniques. > > > > Are you looking for requirements like that? > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > >>mechanisms > > you > > >>like for any set of flows you can identify. > > > > >Once again....how to use these static routes (which is often > > why SBC's > > >are used--essentially creating the head of a static route) > > needs to be > > >studied by this group. > > Well, is this any different from the marking issue above? > > What do you want the BCP to say beyond marking of packets? > > What is the requirement? > > > > Marking of packets is a subject worthy of discussion I think. > > > > In the best of all worlds, we would agree on the proper > > marking of packets, all networks would mark in a uniform way, > > and routers would route in an optimal manner for the packets > > marked appropriately no matter how many domains the packets crossed. > > > > Dream on you say. > > > > I agree, but we should, probably, at least mention the ideal > > (which implies we actually specify what the marking should > > be). I'd expect to see signaling packets marked differently > > than media packets. There could reasonably be different > > marking for different kinds of media (text vs audio vs video, > > for example). > > > > Then we have to deal with the reality that marking within a > > domain may be consistent, but in peering, the O marking won't > > be the same as the T marking, and we need to remark at the > > peering edge. > > > > Then we could consider per-flow marking. I'm not so sure I > > want to go there, but I'm willing to listen. > > > > But is there more than that? What, exactly? > > > > Brian > > > > > > > > _______________________________________________ > > 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 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 10 18:01:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT4Rw-00056i-O1; Mon, 10 Apr 2006 18:01:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT4Rv-00056d-Qb for speermint@ietf.org; Mon, 10 Apr 2006 18:01:31 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT4Ru-0006OE-Eq for speermint@ietf.org; Mon, 10 Apr 2006 18:01:31 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 10 Apr 2006 15:01:30 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,109,1144047600"; d="scan'208"; a="542350063:sNHT24153028" 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] [Fwd: [SIPForum-techwg] IP PBX / SP InteroperabilityProposed Final Draft - Working Group Last Call] FYI Date: Mon, 10 Apr 2006 18:01:28 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE62D@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [Fwd: [SIPForum-techwg] IP PBX / SP InteroperabilityProposed Final Draft - Working Group Last Call] FYI Thread-Index: AcZbNp9+hrf7vOoOR0aipSuafSgKKABs5ZvA From: "Reinaldo Penno" To: "Richard Shockey" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 a very interesting document. Many ideas we are discussing are discussed there. > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Saturday, April 08, 2006 11:02 AM > To: speermint@ietf.org > Subject: [Speermint] [Fwd: [SIPForum-techwg] IP PBX / SP > InteroperabilityProposed Final Draft - Working Group Last Call] FYI >=20 >=20 > FYI .. Just a note that the SIP forum is now essentially finished with its > IP-PBX to SP interface specification which should have some relevance to > the > seemingly endless discussion going on here. >=20 >=20 > -------- Original Message -------- > Subject: [SIPForum-techwg] IP PBX / SP Interoperability Proposed Final > Draft - > Working Group Last Call > Date: Mon, 27 Mar 2006 12:53:36 -0500 > From: Richard Shockey > To: Chris Sibley > CC: SIP Forum Tech WG > References: <68D2858458D1684999D254CB49C99CFB049CC995@exch- > corp01.corp.cbeyond.net> >=20 >=20 > After discussion with the authors and the chairs we have decided to begin > a > working group last call on the final draft listed below beginning today > Monday > March for 3 weeks. >=20 > The intent of the last call is to solicit comments before submitting the > draft to the SIP Forum Board of Directors as a Proposed Specification. >=20 > This document has been under extensive discussion thought 2005. >=20 > The purpose of a working group Last Call is in the style of "speak now > or forever hold your peace" in case there are fundamental objections > which have not gotten previous or adequate discussion, or minor errors > which need correction. >=20 > Work group last call will extend from today until at April 17 though we > can > modify that if new issues come up. >=20 >=20 >=20 >=20 > > The proposed final draft of the IP PBX / SP Interoperability > > specification is now available online for your review at the following > URL: > > > > > > > > http://data.memberclicks.com/bbattach/130808/sf-draft-twg- > IP_PBX_SP_Interop-sibley-final.pdf > > >=20 > -- >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ > techwg mailing list > Send mail to: techwg@sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg >=20 >=20 > -- >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=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 Tue Apr 11 12:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLNL-0004x7-UE; Tue, 11 Apr 2006 12:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLNK-0004wP-22 for speermint@ietf.org; Tue, 11 Apr 2006 12:05:54 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLNJ-0007li-Jf for speermint@ietf.org; Tue, 11 Apr 2006 12:05:54 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k3BG1Gu18154; Tue, 11 Apr 2006 12:01:16 -0400 (EDT) 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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Tue, 11 Apr 2006 12:05:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagA== From: "James McEachern" To: , "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f 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 Comments inline. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 10, 2006 3:45 PM > To: 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > I personally think this is way over the top for a BCP. >=20 > If such things were deployed now, even experimentally, and we had some > good > reports on complexity, stability and usefulness, then maybe we could > document that as "Best Current Practice". In the absence of anything = like > it, to my knowledge, in the wild, I'd say let's not go there. >=20 > I'm pretty certain that an objective evaluation of this scheme would > result > in a "more bandwidth is cheaper" conclusion, but since my speculation > isn't > any more valid that yours I think we just fagetabodit. >=20 > Can we just stick with per T-domain marking and DiffServ? [JMcE] If we have per T-domain marking and DiffServ, then presumably we = must have a policy that specifies the translation for each O-T pair. If = we agree on this, then does it really matter if that "per O-T = translation policy" has a single entry, an entry per media type, or = multiple options per media type? If fact, once we allow for such = translation, do we even need to specify how many options are possible? =20 >=20 > Brian >=20 > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Saturday, April 08, 2006 10:53 AM > To: speermint@ietf.org > Subject: RE: [Speermint] RE: = BackgroundReadingonNGNInterconnect-transitvs > peering >=20 >=20 > Brian, >=20 > This new kind of policy driven marking thing must work across network > borders -- and across trust boundaries. What we really need to solve = the > routing problem is a second forwarding equivalence class -- one for = best > efforts, and one for voice. These must be advertised through BGP4 = edges to > effect a second routing plane. Only then can you solve the routing = problem. >=20 > If this was all completed, and we could make packets route differently > based > on service (different next-hop networks), we have solved a first = problem. > However it is unclear that we have made the internet better. Now when = you > "ping" an address, you get a different response if the ToS is best = efforts > verses Voice. You also would have to revise ICMP handling to deal with > "unreachable address messages" to take into account the ToS. There may = be > many other protocol issues that occur when these bits are not set = properly. >=20 > I can think of one simple one. >=20 > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is = ONLY > reachable in the ToS Voice forwarding plane. However, when I use the > Berkely > Sockets to create the socket ... the syn/syn syn/ack ack three way > handshake > doesn't have the ToS bits set yet (since I can't do a SOCKOPTS until = the > socket is opened). Thus we would have to alter the ways Berkely = sockets > work > to ensure that the 3way TCP handshake routes properly. >=20 > These complications may be worth the salvation of honor and avoidance = of > doing something evil like a simple NAT like SBC's do. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 3:03 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > ReadingonNGNInterconnect-transitvs peering >=20 > Uh-huh, at least for a generic "everyone should do this" kind of = thing. >=20 > I have no illusions that big complex carrier networks will adopt = anything > as > straightforward as -service-classes, but many more focused carriers = could, > and profit there-by. >=20 > So, I think our BCP should reference that work, but I believe it's not > sufficient. We probably need some kind of policy driven re-marking = thingy. >=20 > What I'm not so sure about is PER FLOW decision making. PER = "T-NETWORK" > is > maybe doable. >=20 > Brian >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 07, 2006 2:55 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading > onNGNInterconnect-transitvs peering >=20 > Brian, >=20 > Are you talking something like?: > draft-ietf-tsvwg-diffserv-service-classes-02.txt >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 1:44 PM > > To: speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > Background Reading onNGNInterconnect-transitvs peering > > > > > > I changed the subject line, at least this part of the thread may be > > fruitful> > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > tunnels, or any > > >>other kind of links down in the router. > > > > > >The process of getting signaled RTP data onto these tunnels, and = not > > >the best efforts packets from the same IP address pairs, is > > essential > > >and in scope. > > > > .... > > > > >>This doesn't say you can't mark media packets in some way > > that sends > > >>them down some specific tunnels. > > > > >The process of doing this -- routing by packet markings -- > > and how this > > >will be setup on a call-by-call basis from the same IP address = pairs > > >used for best efforts should be in scope. > > > > Now we may be getting somewhere. This seems like it creates > > requirements I might be able to deal with. > > > > What I'm hearing is that you think, fundamentally, that > > signaling packets must be able to be marked differently from > > media packets. Seems hard to argue with that. > > > > But I believe you want a requirement that we cover PER FLOW > > marking. I think that might be something worth discussing. > > > > There are two ways we know how to do this. The right way > > (get the origin to mark them right in the first place) and > > the expeditious way (put an intermediary in the path and > > remark them). That intermediary could be an > > L5/L7 entity, or it could be down in router-land using normal > > flow identifier techniques. > > > > Are you looking for requirements like that? > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > >>mechanisms > > you > > >>like for any set of flows you can identify. > > > > >Once again....how to use these static routes (which is often > > why SBC's > > >are used--essentially creating the head of a static route) > > needs to be > > >studied by this group. > > Well, is this any different from the marking issue above? > > What do you want the BCP to say beyond marking of packets? > > What is the requirement? > > > > Marking of packets is a subject worthy of discussion I think. > > > > In the best of all worlds, we would agree on the proper > > marking of packets, all networks would mark in a uniform way, > > and routers would route in an optimal manner for the packets > > marked appropriately no matter how many domains the packets crossed. > > > > Dream on you say. > > > > I agree, but we should, probably, at least mention the ideal > > (which implies we actually specify what the marking should > > be). I'd expect to see signaling packets marked differently > > than media packets. There could reasonably be different > > marking for different kinds of media (text vs audio vs video, > > for example). > > > > Then we have to deal with the reality that marking within a > > domain may be consistent, but in peering, the O marking won't > > be the same as the T marking, and we need to remark at the > > peering edge. > > > > Then we could consider per-flow marking. I'm not so sure I > > want to go there, but I'm willing to listen. > > > > But is there more than that? What, exactly? > > > > Brian > > > > > > > > _______________________________________________ > > 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 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 11 15:43:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOlr-0002Yz-9i; Tue, 11 Apr 2006 15:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOlo-0002Yu-VY for speermint@ietf.org; Tue, 11 Apr 2006 15:43:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOlo-00077L-EL for speermint@ietf.org; Tue, 11 Apr 2006 15:43:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTOle-0001Et-6c; Tue, 11 Apr 2006 14:43:15 -0500 From: "Brian Rosen" To: , "'James McEachern'" , "'Patrick Melampy'" , Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Tue, 11 Apr 2006 15:43:18 -0400 Message-ID: <016501c65da0$30612060$4fe6a8c0@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: <003301c65d82$851c16a0$bf4632a6@mcilink.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: fe105289edd72640d9f392da880eefa2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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, well we aren't doing a good job of separating our terms, and transit networks are indeed a fact of life. So, yes, I think it's the peering destination network, which would be "next-hop" at the peering point who would have a marking policy. We could define this away by saying it was that network who was responsible for marking its packets any way in wants on entry, rather than the peering "network"'s responsibility. I don't think we need an O-T pair; I think we need a T (or as Tim says, next hop) policy. Every flow to that next hop gets marked the way that network wants it. Source doesn't matter. IN THE PEERING FABRIC, I think it probably doesn't matter; I think you can probably do admission control into the fabric that makes diffserv within the fabric unnecessary. If you did want it, then you have to remark on entrance to the fabric with the fabric's code points, and then remark again with the next hop network's desired codepoints. Brian -----Original Message----- From: Tim Dwight [mailto:timothy.dwight@verizon.com] Sent: Tuesday, April 11, 2006 12:11 PM To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy'; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Wouldn't the marking need to be per the requirements of the adjacent network rather than the network in which the session terminates? We are talking about L3 markings and there may be multiple L3 networks between O and T. Tim -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Tuesday, April 11, 2006 11:06 AM To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Comments inline. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 10, 2006 3:45 PM > To: 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint] > RE:BackgroundReadingonNGNInterconnect-transitvs > peering > > I personally think this is way over the top for a BCP. > > If such things were deployed now, even experimentally, and we had some > good reports on complexity, stability and usefulness, then maybe we > could document that as "Best Current Practice". In the absence of > anything like it, to my knowledge, in the wild, I'd say let's not go > there. > > I'm pretty certain that an objective evaluation of this scheme would > result in a "more bandwidth is cheaper" conclusion, but since my > speculation isn't any more valid that yours I think we just > fagetabodit. > > Can we just stick with per T-domain marking and DiffServ? [JMcE] If we have per T-domain marking and DiffServ, then presumably we must have a policy that specifies the translation for each O-T pair. If we agree on this, then does it really matter if that "per O-T translation policy" has a single entry, an entry per media type, or multiple options per media type? If fact, once we allow for such translation, do we even need to specify how many options are possible? > > Brian > > -----Original Message----- > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > Sent: Saturday, April 08, 2006 10:53 AM > To: speermint@ietf.org > Subject: RE: [Speermint] RE: > BackgroundReadingonNGNInterconnect-transitvs > peering > > > Brian, > > This new kind of policy driven marking thing must work across network > borders -- and across trust boundaries. What we really need to solve > the routing problem is a second forwarding equivalence class -- one > for best efforts, and one for voice. These must be advertised through > BGP4 edges to effect a second routing plane. Only then can you solve the routing problem. > > If this was all completed, and we could make packets route differently > based on service (different next-hop networks), we have solved a first > problem. > However it is unclear that we have made the internet better. Now when > you "ping" an address, you get a different response if the ToS is best > efforts verses Voice. You also would have to revise ICMP handling to > deal with "unreachable address messages" to take into account the ToS. > There may be many other protocol issues that occur when these bits are not set properly. > > I can think of one simple one. > > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is > ONLY reachable in the ToS Voice forwarding plane. However, when I use > the Berkely Sockets to create the socket ... the syn/syn syn/ack ack > three way handshake doesn't have the ToS bits set yet (since I can't > do a SOCKOPTS until the socket is opened). Thus we would have to alter > the ways Berkely sockets work to ensure that the 3way TCP handshake > routes properly. > > These complications may be worth the salvation of honor and avoidance > of doing something evil like a simple NAT like SBC's do. > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 07, 2006 3:03 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > ReadingonNGNInterconnect-transitvs peering > > Uh-huh, at least for a generic "everyone should do this" kind of thing. > > I have no illusions that big complex carrier networks will adopt > anything as straightforward as -service-classes, but many more focused > carriers could, and profit there-by. > > So, I think our BCP should reference that work, but I believe it's not > sufficient. We probably need some kind of policy driven re-marking thingy. > > What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" > is > maybe doable. > > Brian > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 07, 2006 2:55 PM > To: br@brianrosen.net; speermint@ietf.org > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > Reading onNGNInterconnect-transitvs peering > > Brian, > > Are you talking something like?: > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 1:44 PM > > To: speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > Background Reading onNGNInterconnect-transitvs peering > > > > > > I changed the subject line, at least this part of the thread may be > > fruitful> > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > tunnels, or any > > >>other kind of links down in the router. > > > > > >The process of getting signaled RTP data onto these tunnels, and > > >not the best efforts packets from the same IP address pairs, is > > essential > > >and in scope. > > > > .... > > > > >>This doesn't say you can't mark media packets in some way > > that sends > > >>them down some specific tunnels. > > > > >The process of doing this -- routing by packet markings -- > > and how this > > >will be setup on a call-by-call basis from the same IP address > > >pairs used for best efforts should be in scope. > > > > Now we may be getting somewhere. This seems like it creates > > requirements I might be able to deal with. > > > > What I'm hearing is that you think, fundamentally, that signaling > > packets must be able to be marked differently from media packets. > > Seems hard to argue with that. > > > > But I believe you want a requirement that we cover PER FLOW marking. > > I think that might be something worth discussing. > > > > There are two ways we know how to do this. The right way (get the > > origin to mark them right in the first place) and the expeditious > > way (put an intermediary in the path and remark them). That > > intermediary could be an > > L5/L7 entity, or it could be down in router-land using normal flow > > identifier techniques. > > > > Are you looking for requirements like that? > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > >>mechanisms > > you > > >>like for any set of flows you can identify. > > > > >Once again....how to use these static routes (which is often > > why SBC's > > >are used--essentially creating the head of a static route) > > needs to be > > >studied by this group. > > Well, is this any different from the marking issue above? > > What do you want the BCP to say beyond marking of packets? > > What is the requirement? > > > > Marking of packets is a subject worthy of discussion I think. > > > > In the best of all worlds, we would agree on the proper marking of > > packets, all networks would mark in a uniform way, and routers would > > route in an optimal manner for the packets marked appropriately no > > matter how many domains the packets crossed. > > > > Dream on you say. > > > > I agree, but we should, probably, at least mention the ideal (which > > implies we actually specify what the marking should be). I'd expect > > to see signaling packets marked differently than media packets. > > There could reasonably be different marking for different kinds of > > media (text vs audio vs video, for example). > > > > Then we have to deal with the reality that marking within a domain > > may be consistent, but in peering, the O marking won't be the same > > as the T marking, and we need to remark at the peering edge. > > > > Then we could consider per-flow marking. I'm not so sure I want to > > go there, but I'm willing to listen. > > > > But is there more than that? What, exactly? > > > > Brian > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 11 17:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQlp-00081j-LL; Tue, 11 Apr 2006 17:51:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQlo-00081Z-Q6 for speermint@ietf.org; Tue, 11 Apr 2006 17:51:32 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQlo-0005FE-94 for speermint@ietf.org; Tue, 11 Apr 2006 17:51:32 -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 k3BLpS418305; Tue, 11 Apr 2006 17:51:28 -0400 (EDT) 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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Tue, 11 Apr 2006 17:51:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYA== From: "James McEachern" To: , , "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae 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 Brian, Perhaps it is just an issue of terminology, but if an "originating" = network knows how to map from its internal marking to something = appropriate for each "peering destination network", and every other = originating network has a similar mapping for each of its peering = destination networks, then in aggregate we have a mapping for every O-T = (or O-D) pair. Jim > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 11, 2006 3:43 PM > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH]; = 'Patrick > Melampy'; speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Yes, well we aren't doing a good job of separating our terms, and = transit > networks are indeed a fact of life. >=20 > So, yes, I think it's the peering destination network, which would be > "next-hop" at the peering point who would have a marking policy. >=20 > We could define this away by saying it was that network who was > responsible > for marking its packets any way in wants on entry, rather than the = peering > "network"'s responsibility. >=20 > I don't think we need an O-T pair; I think we need a T (or as Tim = says, > next > hop) policy. Every flow to that next hop gets marked the way that = network > wants it. Source doesn't matter. >=20 > IN THE PEERING FABRIC, I think it probably doesn't matter; I think you = can > probably do admission control into the fabric that makes diffserv = within > the > fabric unnecessary. If you did want it, then you have to remark on > entrance > to the fabric with the fabric's code points, and then remark again = with > the > next hop network's desired codepoints. >=20 > Brian >=20 > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Tuesday, April 11, 2006 12:11 PM > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy'; > speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Wouldn't the marking need to be per the requirements of the adjacent > network > rather than the network in which the session terminates? We are = talking > about L3 markings and there may be multiple L3 networks between O and = T. >=20 > Tim >=20 >=20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Tuesday, April 11, 2006 11:06 AM > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Comments inline. >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, April 10, 2006 3:45 PM > > To: 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > I personally think this is way over the top for a BCP. > > > > If such things were deployed now, even experimentally, and we had = some > > good reports on complexity, stability and usefulness, then maybe we > > could document that as "Best Current Practice". In the absence of > > anything like it, to my knowledge, in the wild, I'd say let's not go > > there. > > > > I'm pretty certain that an objective evaluation of this scheme would > > result in a "more bandwidth is cheaper" conclusion, but since my > > speculation isn't any more valid that yours I think we just > > fagetabodit. > > > > Can we just stick with per T-domain marking and DiffServ? >=20 > [JMcE] If we have per T-domain marking and DiffServ, then presumably = we > must > have a policy that specifies the translation for each O-T pair. If we > agree > on this, then does it really matter if that "per O-T translation = policy" > has > a single entry, an entry per media type, or multiple options per media > type? > If fact, once we allow for such translation, do we even need to = specify > how > many options are possible? >=20 > > > > Brian > > > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Saturday, April 08, 2006 10:53 AM > > To: speermint@ietf.org > > Subject: RE: [Speermint] RE: > > BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > > > Brian, > > > > This new kind of policy driven marking thing must work across = network > > borders -- and across trust boundaries. What we really need to solve > > the routing problem is a second forwarding equivalence class -- one > > for best efforts, and one for voice. These must be advertised = through > > BGP4 edges to effect a second routing plane. Only then can you solve = the > routing problem. > > > > If this was all completed, and we could make packets route = differently > > based on service (different next-hop networks), we have solved a = first > > problem. > > However it is unclear that we have made the internet better. Now = when > > you "ping" an address, you get a different response if the ToS is = best > > efforts verses Voice. You also would have to revise ICMP handling to > > deal with "unreachable address messages" to take into account the = ToS. > > There may be many other protocol issues that occur when these bits = are > not > set properly. > > > > I can think of one simple one. > > > > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is > > ONLY reachable in the ToS Voice forwarding plane. However, when I = use > > the Berkely Sockets to create the socket ... the syn/syn syn/ack ack > > three way handshake doesn't have the ToS bits set yet (since I can't > > do a SOCKOPTS until the socket is opened). Thus we would have to = alter > > the ways Berkely sockets work to ensure that the 3way TCP handshake > > routes properly. > > > > These complications may be worth the salvation of honor and = avoidance > > of doing something evil like a simple NAT like SBC's do. > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 3:03 PM > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: = Background > > ReadingonNGNInterconnect-transitvs peering > > > > Uh-huh, at least for a generic "everyone should do this" kind of = thing. > > > > I have no illusions that big complex carrier networks will adopt > > anything as straightforward as -service-classes, but many more = focused > > carriers could, and profit there-by. > > > > So, I think our BCP should reference that work, but I believe it's = not > > sufficient. We probably need some kind of policy driven re-marking > thingy. > > > > What I'm not so sure about is PER FLOW decision making. PER = "T-NETWORK" > > is > > maybe doable. > > > > Brian > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, April 07, 2006 2:55 PM > > To: br@brianrosen.net; speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > Brian, > > > > Are you talking something like?: > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 1:44 PM > > > To: speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > I changed the subject line, at least this part of the thread may = be > > > fruitful> > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > tunnels, or any > > > >>other kind of links down in the router. > > > > > > > >The process of getting signaled RTP data onto these tunnels, and > > > >not the best efforts packets from the same IP address pairs, is > > > essential > > > >and in scope. > > > > > > .... > > > > > > >>This doesn't say you can't mark media packets in some way > > > that sends > > > >>them down some specific tunnels. > > > > > > >The process of doing this -- routing by packet markings -- > > > and how this > > > >will be setup on a call-by-call basis from the same IP address > > > >pairs used for best efforts should be in scope. > > > > > > Now we may be getting somewhere. This seems like it creates > > > requirements I might be able to deal with. > > > > > > What I'm hearing is that you think, fundamentally, that signaling > > > packets must be able to be marked differently from media packets. > > > Seems hard to argue with that. > > > > > > But I believe you want a requirement that we cover PER FLOW = marking. > > > I think that might be something worth discussing. > > > > > > There are two ways we know how to do this. The right way (get the > > > origin to mark them right in the first place) and the expeditious > > > way (put an intermediary in the path and remark them). That > > > intermediary could be an > > > L5/L7 entity, or it could be down in router-land using normal flow > > > identifier techniques. > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > > >>mechanisms > > > you > > > >>like for any set of flows you can identify. > > > > > > >Once again....how to use these static routes (which is often > > > why SBC's > > > >are used--essentially creating the head of a static route) > > > needs to be > > > >studied by this group. > > > Well, is this any different from the marking issue above? > > > What do you want the BCP to say beyond marking of packets? > > > What is the requirement? > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > In the best of all worlds, we would agree on the proper marking of > > > packets, all networks would mark in a uniform way, and routers = would > > > route in an optimal manner for the packets marked appropriately no > > > matter how many domains the packets crossed. > > > > > > Dream on you say. > > > > > > I agree, but we should, probably, at least mention the ideal = (which > > > implies we actually specify what the marking should be). I'd = expect > > > to see signaling packets marked differently than media packets. > > > There could reasonably be different marking for different kinds of > > > media (text vs audio vs video, for example). > > > > > > Then we have to deal with the reality that marking within a domain > > > may be consistent, but in peering, the O marking won't be the same > > > as the T marking, and we need to remark at the peering edge. > > > > > > Then we could consider per-flow marking. I'm not so sure I want = to > > > go there, but I'm willing to listen. > > > > > > But is there more than that? What, exactly? > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > 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 >=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 Tue Apr 11 18:07:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTR1K-0005z5-02; Tue, 11 Apr 2006 18:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTR1J-0005yz-75 for speermint@ietf.org; Tue, 11 Apr 2006 18:07:33 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTR1H-000688-S9 for speermint@ietf.org; Tue, 11 Apr 2006 18:07:33 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k3BM6b6r017303; Tue, 11 Apr 2006 22:06:52 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id D6A59124808; Tue, 11 Apr 2006 22:06:26 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 8371D12481C; Tue, 11 Apr 2006 22:06:26 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Apr 2006 16:06:26 -0600 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] 2 Basic Constructs for SIP Peering Date: Tue, 11 Apr 2006 16:06:25 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAC/RafQ From: "Malas, Daryl" To: "Hadriel Kaplan" , "Uzelac, Adam" , X-OriginalArrivalTime: 11 Apr 2006 22:06:26.0230 (UTC) FILETIME=[2D4F3560:01C65DB4] X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 just want to make sure I understand your statement below... If a redirect proxy is used, the call flow will look more like this: L (or S) // O---T Not this: S /\ O--T FYI...when I think of redirect proxy, I think of a proxy that issues a 3XX message to O in response to an INVITE. Are you speaking of it more generically? --Daryl M. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Friday, April 07, 2006 9:10 PM To: 'Uzelac, Adam'; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering >=20 > I can't agree in a proxied(non-redirect) call flow. Also, there may be > a requirement to determine which T-Network to term the call to should > there be more than one. There could be a subsequent T-Network proxy > involved. So the call would be signaled from O-Network to S-Network, > and then maybe S-Network to T-Network to determine ultimate T-Network > end point. >=20 > Adam Uzelac >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering >=20 > Hi Adam, >=20 > If S is doing a redirect/proxy, isn't it just the location lookup > mechanism for O--T? (a trusted+shared location-lookup) >=20 > So there's really just: > L > / > O---T. >=20 > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding > > through the noise and rhetoric, it appears to me that there are 2 > > basic constructs for SIP peering. Subscribing to Brian's notion that > > we must try to keep this simple - at least at this stage - it seems to >=20 > > boil down to the following: (I acknowledge that there may be > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all three, > > though S-Network would not be transit for media, but possible for > > signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives > > routing instructions. Media would follow the same relationship, maybe >=20 > > not the same path, but same bi-lateral relationship. Should there be > > more than one L3 peering point, any peering point may be used, but it > > all follows the same contextual relationship between O-Network and > > T-Network. > > > > I find it possible to apply either Option A or Option B to public, > > private, and even carrier (even carrier pigeon) environments. Maybe I >=20 > > am pointing out the obvious, but that's OK as I have been often > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 _______________________________________________ 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 Apr 12 09:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfi4-0005dU-0q; Wed, 12 Apr 2006 09:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfi2-0005dP-Tp for speermint@ietf.org; Wed, 12 Apr 2006 09:48:38 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfi2-0006F7-9t for speermint@ietf.org; Wed, 12 Apr 2006 09:48:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FTfht-0006e3-6l; Wed, 12 Apr 2006 08:48:29 -0500 From: "Brian Rosen" To: "'James McEachern'" , , "'Patrick Melampy'" , Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Wed, 12 Apr 2006 09:48:30 -0400 Message-ID: <031101c65e37$ca876180$4fe6a8c0@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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQ X-PopBeforeSMTPSenders: br@brianrosen.net 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: f0ea5880a0890be2408609376fa519aa Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Need a picture: O ---- P ---- T ^ You mark at the exit of the peering fabric with the T marking (where T here is either the terminating network or the transit network as Tim suggests). You could mark on entrance, but then, as you suggest, you would have O-T pairs. O ---- P ---- T ^ Of course, as I pointed out, there are two sides to the exit (and entrance). If the peering system does the marking, it's in scope. O ---- P ---- T ^ If the T network does its own marking on its entrance: O ---- P ---- T ^ then its out of scope. If it's done on entrance, than it's in scope. O ---- P ---- T ^ Or O ---- P ---- T ^ If it's done on entrance with T's marking, then the peering fabric can't use markings (can't implement DiffServ). As I said, this may not be a problem. If it's done on entrance with P's marking, and again on exit with T's: O ---- P ---- T ^ P ^ T then you can use diffserv in the fabric Brian -----Original Message----- From: James McEachern [mailto:jmce@nortel.com] Sent: Tuesday, April 11, 2006 5:51 PM To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Brian, Perhaps it is just an issue of terminology, but if an "originating" network knows how to map from its internal marking to something appropriate for each "peering destination network", and every other originating network has a similar mapping for each of its peering destination networks, then in aggregate we have a mapping for every O-T (or O-D) pair. Jim > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 11, 2006 3:43 PM > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH]; 'Patrick > Melampy'; speermint@ietf.org > Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs > peering > > Yes, well we aren't doing a good job of separating our terms, and transit > networks are indeed a fact of life. > > So, yes, I think it's the peering destination network, which would be > "next-hop" at the peering point who would have a marking policy. > > We could define this away by saying it was that network who was > responsible > for marking its packets any way in wants on entry, rather than the peering > "network"'s responsibility. > > I don't think we need an O-T pair; I think we need a T (or as Tim says, > next > hop) policy. Every flow to that next hop gets marked the way that network > wants it. Source doesn't matter. > > IN THE PEERING FABRIC, I think it probably doesn't matter; I think you can > probably do admission control into the fabric that makes diffserv within > the > fabric unnecessary. If you did want it, then you have to remark on > entrance > to the fabric with the fabric's code points, and then remark again with > the > next hop network's desired codepoints. > > Brian > > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Tuesday, April 11, 2006 12:11 PM > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy'; > speermint@ietf.org > Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs > peering > > Wouldn't the marking need to be per the requirements of the adjacent > network > rather than the network in which the session terminates? We are talking > about L3 markings and there may be multiple L3 networks between O and T. > > Tim > > > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Tuesday, April 11, 2006 11:06 AM > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs > peering > > Comments inline. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, April 10, 2006 3:45 PM > > To: 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > I personally think this is way over the top for a BCP. > > > > If such things were deployed now, even experimentally, and we had some > > good reports on complexity, stability and usefulness, then maybe we > > could document that as "Best Current Practice". In the absence of > > anything like it, to my knowledge, in the wild, I'd say let's not go > > there. > > > > I'm pretty certain that an objective evaluation of this scheme would > > result in a "more bandwidth is cheaper" conclusion, but since my > > speculation isn't any more valid that yours I think we just > > fagetabodit. > > > > Can we just stick with per T-domain marking and DiffServ? > > [JMcE] If we have per T-domain marking and DiffServ, then presumably we > must > have a policy that specifies the translation for each O-T pair. If we > agree > on this, then does it really matter if that "per O-T translation policy" > has > a single entry, an entry per media type, or multiple options per media > type? > If fact, once we allow for such translation, do we even need to specify > how > many options are possible? > > > > > Brian > > > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Saturday, April 08, 2006 10:53 AM > > To: speermint@ietf.org > > Subject: RE: [Speermint] RE: > > BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > > > Brian, > > > > This new kind of policy driven marking thing must work across network > > borders -- and across trust boundaries. What we really need to solve > > the routing problem is a second forwarding equivalence class -- one > > for best efforts, and one for voice. These must be advertised through > > BGP4 edges to effect a second routing plane. Only then can you solve the > routing problem. > > > > If this was all completed, and we could make packets route differently > > based on service (different next-hop networks), we have solved a first > > problem. > > However it is unclear that we have made the internet better. Now when > > you "ping" an address, you get a different response if the ToS is best > > efforts verses Voice. You also would have to revise ICMP handling to > > deal with "unreachable address messages" to take into account the ToS. > > There may be many other protocol issues that occur when these bits are > not > set properly. > > > > I can think of one simple one. > > > > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is > > ONLY reachable in the ToS Voice forwarding plane. However, when I use > > the Berkely Sockets to create the socket ... the syn/syn syn/ack ack > > three way handshake doesn't have the ToS bits set yet (since I can't > > do a SOCKOPTS until the socket is opened). Thus we would have to alter > > the ways Berkely sockets work to ensure that the 3way TCP handshake > > routes properly. > > > > These complications may be worth the salvation of honor and avoidance > > of doing something evil like a simple NAT like SBC's do. > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 3:03 PM > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: Background > > ReadingonNGNInterconnect-transitvs peering > > > > Uh-huh, at least for a generic "everyone should do this" kind of thing. > > > > I have no illusions that big complex carrier networks will adopt > > anything as straightforward as -service-classes, but many more focused > > carriers could, and profit there-by. > > > > So, I think our BCP should reference that work, but I believe it's not > > sufficient. We probably need some kind of policy driven re-marking > thingy. > > > > What I'm not so sure about is PER FLOW decision making. PER "T-NETWORK" > > is > > maybe doable. > > > > Brian > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, April 07, 2006 2:55 PM > > To: br@brianrosen.net; speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > Brian, > > > > Are you talking something like?: > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 1:44 PM > > > To: speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > I changed the subject line, at least this part of the thread may be > > > fruitful> > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > tunnels, or any > > > >>other kind of links down in the router. > > > > > > > >The process of getting signaled RTP data onto these tunnels, and > > > >not the best efforts packets from the same IP address pairs, is > > > essential > > > >and in scope. > > > > > > .... > > > > > > >>This doesn't say you can't mark media packets in some way > > > that sends > > > >>them down some specific tunnels. > > > > > > >The process of doing this -- routing by packet markings -- > > > and how this > > > >will be setup on a call-by-call basis from the same IP address > > > >pairs used for best efforts should be in scope. > > > > > > Now we may be getting somewhere. This seems like it creates > > > requirements I might be able to deal with. > > > > > > What I'm hearing is that you think, fundamentally, that signaling > > > packets must be able to be marked differently from media packets. > > > Seems hard to argue with that. > > > > > > But I believe you want a requirement that we cover PER FLOW marking. > > > I think that might be something worth discussing. > > > > > > There are two ways we know how to do this. The right way (get the > > > origin to mark them right in the first place) and the expeditious > > > way (put an intermediary in the path and remark them). That > > > intermediary could be an > > > L5/L7 entity, or it could be down in router-land using normal flow > > > identifier techniques. > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > > >>mechanisms > > > you > > > >>like for any set of flows you can identify. > > > > > > >Once again....how to use these static routes (which is often > > > why SBC's > > > >are used--essentially creating the head of a static route) > > > needs to be > > > >studied by this group. > > > Well, is this any different from the marking issue above? > > > What do you want the BCP to say beyond marking of packets? > > > What is the requirement? > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > In the best of all worlds, we would agree on the proper marking of > > > packets, all networks would mark in a uniform way, and routers would > > > route in an optimal manner for the packets marked appropriately no > > > matter how many domains the packets crossed. > > > > > > Dream on you say. > > > > > > I agree, but we should, probably, at least mention the ideal (which > > > implies we actually specify what the marking should be). I'd expect > > > to see signaling packets marked differently than media packets. > > > There could reasonably be different marking for different kinds of > > > media (text vs audio vs video, for example). > > > > > > Then we have to deal with the reality that marking within a domain > > > may be consistent, but in peering, the O marking won't be the same > > > as the T marking, and we need to remark at the peering edge. > > > > > > Then we could consider per-flow marking. I'm not so sure I want to > > > go there, but I'm willing to listen. > > > > > > But is there more than that? What, exactly? > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 12 10:05:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfxt-0003W5-KH; Wed, 12 Apr 2006 10:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfxs-0003Vf-WD for speermint@ietf.org; Wed, 12 Apr 2006 10:05:01 -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 1FTfxs-0006ku-JQ for speermint@ietf.org; Wed, 12 Apr 2006 10:05: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 44E4E36FE; Wed, 12 Apr 2006 10:05:00 -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, 12 Apr 2006 10:04:59 -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] 2 Basic Constructs for SIP Peering Date: Wed, 12 Apr 2006 10:04:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAAN1gzgALbU39A= From: "Uzelac, Adam" To: "Stastny Richard" , "Hadriel Kaplan" , X-OriginalArrivalTime: 12 Apr 2006 14:04:59.0412 (UTC) FILETIME=[15D65540:01C65E3A] X-Spam-Score: 0.1 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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] Comments inline... -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Saturday, April 08, 2006 5:41 AM To: Hadriel Kaplan; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > So there's really just: > L > / > O---T. The location function is one of the basic functions SPEERMINT needs to work on [adam] I agree. =20 Of course the simplest case is defined in RFC 3263, but there are more complex cases - e.g. a redirect/proxy server, eventaually also involving an ENUM lookup, this is basically what VPF or XConnect are providing. (the second is policy, i.e. if you are able to access the given proxy) [adam] It's in the redirect/proxy scenario that I am thinking that there could (maybe should) be communications between the S-Network and the T-Network to determine if S-Network should direct the session to the T-Network. With this said, I am thinking back to a triangle model of: [adam] S /\ O--T =20 Another task may be to translate personal URIs or enterprise AoRs hosted by a SP to the ingress proxy of the SP e.g. Sip:bill@microsoft.co.uk -> sip:bill@ms.bt.com [adam] I don't know if this task would be a requirement or not. Might be up to the implementor to determine, but to me this doesn't have anything to do with routing of the session. =20 The main task of a "location function" is to provide the out-bound proxy of the O-domain (one of) the ingress proxy(s) of the T-domain =20 > I can't agree in a proxied(non-redirect) call flow. Also, there may=20 > be a requirement to determine which T-Network to term the call to=20 > should there be more than one. =20 With terminating networks it is like Highlander there can only be one [adam] Great movie! I am thinking that all O-Networks will not be interconnected possible to all T-Networks. Therefore some (I hesitate stating) transit network options may need to be considered. Transit here meaning not the _ultimate_ T-Network where the called party resides, but granted, it is the T-Network from the O and S-Network's POV for that call. The S-Network may be aware of multiple routes to the ultimate T-Network via some transits, one path may have different characteristics than another. If the consensus here is that transits will not be considered, than B2BUAs would be required to hide the topology as you state below. =20 > There could be a subsequent T-Network proxy involved. So the call=20 > would be signaled from O-Network to S-Network, and then maybe=20 > S-Network to T-Network to determine ultimate T-Network end point. =20 >From the point of the O-domain there is only one T-domain ingress point If there are a bunch of T-domains hidden behind does not matter for the O-domain or to be precise: it MUST NOT. [adam] Should I read this MUST NOT as stating that a T-Network, if not the ultimate T-Network where calling party resides, must use B2BUAs? =20 The reason for topology hiding proxies is topology hiding =20 If for example the mobile networks decide to open up the IPX GSMA network to be reached by selected partners from the Internet, they will put ingress proxies at the border of their network, and all what a O-domain on the internet will see for a AoR hosted by the mobile networks will be the ingress proxies of IPX. =20 The routing to the real t-domain (teh specific mobile network will then be done via the ingress proxy The O-domain is not concerend [adam] The O-Network (domain) may not be concerned, but does the S-Network need to be? Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Sa 08.04.2006 05:09 An: 'Uzelac, Adam'; speermint@ietf.org Betreff: RE: [Speermint] 2 Basic Constructs for SIP Peering Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I can't agree in a proxied(non-redirect) call flow. Also, there may=20 > be a requirement to determine which T-Network to term the call to=20 > should there be more than one. There could be a subsequent T-Network=20 > proxy involved. So the call would be signaled from O-Network to=20 > S-Network, and then maybe S-Network to T-Network to determine ultimate > T-Network end point. > > Adam Uzelac > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Hi Adam, > > If S is doing a redirect/proxy, isn't it just the location lookup=20 > mechanism for O--T? (a trusted+shared location-lookup) > > So there's really just: > L > / > O---T. > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding=20 > > through the noise and rhetoric, it appears to me that there are 2=20 > > basic constructs for SIP peering. Subscribing to Brian's notion=20 > > that we must try to keep this simple - at least at this stage - it=20 > > seems to > > > boil down to the following: (I acknowledge that there may be=20 > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing=20 > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all=20 > > three, though S-Network would not be transit for media, but possible > > for signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives=20 > > routing instructions. Media would follow the same relationship,=20 > > maybe > > > not the same path, but same bi-lateral relationship. Should there=20 > > be more than one L3 peering point, any peering point may be used,=20 > > but it all follows the same contextual relationship between=20 > > O-Network and T-Network. > > > > I find it possible to apply either Option A or Option B to public,=20 > > private, and even carrier (even carrier pigeon) environments. Maybe > > I > > > am pointing out the obvious, but that's OK as I have been often=20 > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 Apr 12 11:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh4O-0004CD-Ql; Wed, 12 Apr 2006 11:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTh4O-0004C3-6b for speermint@ietf.org; Wed, 12 Apr 2006 11:15:48 -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 1FTgQB-0007oT-Cf for speermint@ietf.org; Wed, 12 Apr 2006 10:34:15 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTgDS-0003Hl-MO for speermint@ietf.org; Wed, 12 Apr 2006 10:21:08 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 49CC537F1; Wed, 12 Apr 2006 10:20:02 -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, 12 Apr 2006 10:20: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] 2 Basic Constructs for SIP Peering Date: Wed, 12 Apr 2006 10:20:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAC/RafQACGjUtA= From: "Uzelac, Adam" To: "Malas, Daryl" , "Hadriel Kaplan" , X-OriginalArrivalTime: 12 Apr 2006 14:20:01.0430 (UTC) FILETIME=[2F7B5B60:01C65E3C] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 thinking more generically. When considering 300 Multiple Choices, O-Network proxy would query S/L-Network proxy, and S/L-Network Proxy _may_ need to communicate with any number of potential T-Networks that may be able to eligible to term the session to the ultimate T-Network where called UA resides. With that said, we are speaking that both constructs are valid. Redirect blind, and Redirect with some forwarding resolution activity. Adam -----Original Message----- From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 Sent: Tuesday, April 11, 2006 6:06 PM To: Hadriel Kaplan; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering I just want to make sure I understand your statement below... If a redirect proxy is used, the call flow will look more like this: L (or S) // O---T Not this: S / \ O---T FYI...when I think of redirect proxy, I think of a proxy that issues a 3XX message to O in response to an INVITE. Are you speaking of it more generically? --Daryl M. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 07, 2006 9:10 PM To: 'Uzelac, Adam'; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering >=20 > I can't agree in a proxied(non-redirect) call flow. Also, there may be > a requirement to determine which T-Network to term the call to should=20 > there be more than one. There could be a subsequent T-Network proxy=20 > involved. So the call would be signaled from O-Network to S-Network,=20 > and then maybe S-Network to T-Network to determine ultimate T-Network=20 > end point. >=20 > Adam Uzelac >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering >=20 > Hi Adam, >=20 > If S is doing a redirect/proxy, isn't it just the location lookup=20 > mechanism for O--T? (a trusted+shared location-lookup) >=20 > So there's really just: > L > / > O---T. >=20 > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding=20 > > through the noise and rhetoric, it appears to me that there are 2=20 > > basic constructs for SIP peering. Subscribing to Brian's notion that > > we must try to keep this simple - at least at this stage - it seems to >=20 > > boil down to the following: (I acknowledge that there may be=20 > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing=20 > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all three, > > though S-Network would not be transit for media, but possible for=20 > > signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives=20 > > routing instructions. Media would follow the same relationship, maybe >=20 > > not the same path, but same bi-lateral relationship. Should there be > > more than one L3 peering point, any peering point may be used, but it > > all follows the same contextual relationship between O-Network and=20 > > T-Network. > > > > I find it possible to apply either Option A or Option B to public,=20 > > private, and even carrier (even carrier pigeon) environments. Maybe I >=20 > > am pointing out the obvious, but that's OK as I have been often=20 > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 _______________________________________________ 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 Apr 12 11:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThB4-0004Uv-67; Wed, 12 Apr 2006 11:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThB2-0004Uq-T3 for speermint@ietf.org; Wed, 12 Apr 2006 11:22:40 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FThB2-0001my-9l for speermint@ietf.org; Wed, 12 Apr 2006 11:22:40 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k3CFI0K26519; Wed, 12 Apr 2006 11:18:00 -0400 (EDT) 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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Wed, 12 Apr 2006 11:22:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtA= From: "James McEachern" To: , , "Patrick Melampy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f 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 Brian, We may need a picture, but I'm afraid these didn't help - I'm more = confused than I was when I started. I think I must be missing = something, so I'll state my assumptions here, and perhaps someone can = point out where I have gone astray. My assumptions: 1. The O network is using DiffServ markings within its network. 2. The T network is using DiffServ markings within its network, but they = are not the same markings as in the O network. =20 3. The peering point is carrying more than one media type, and the media = types do not all have the same DiffServ markings.=20 4. Therefore, it is not possible for the T network to determine a priori = the appropriate DiffServ markings (and apply them to all the traffic) = simply on the basis of the peering point. The T network must look at = the media-specific markings for each media type, and translate those to = the corresponding media-specific marking that it uses for that media = type in its network. Since each network (potentially) uses a different = marking scheme, this results in mappings for each O-T pair. This should = apply no matter where the marking is applied. What am I missing? Jim -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 12, 2006 9:49 AM To: McEachern, James [CAR:5N00:EXCH]; timothy.dwight@verizon.com; = 'Patrick Melampy'; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs = peering Jim Need a picture: O ---- P ---- T ^ You mark at the exit of the peering fabric with the T marking (where T = here is either the terminating network or the transit network as Tim = suggests). You could mark on entrance, but then, as you suggest, you would have O-T pairs. O ---- P ---- T ^ Of course, as I pointed out, there are two sides to the exit (and = entrance). If the peering system does the marking, it's in scope.=20 O ---- P ---- T ^=20 If the T network does its own marking on its entrance: O ---- P ---- T ^ then its out of scope. If it's done on entrance, than it's in scope. O ---- P ---- T ^ Or O ---- P ---- T ^ If it's done on entrance with T's marking, then the peering fabric can't = use markings (can't implement DiffServ). As I said, this may not be a = problem. If it's done on entrance with P's marking, and again on exit with T's: O ---- P ---- T ^ P ^ T then you can use diffserv in the fabric Brian -----Original Message----- From: James McEachern [mailto:jmce@nortel.com]=20 Sent: Tuesday, April 11, 2006 5:51 PM To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Brian, Perhaps it is just an issue of terminology, but if an "originating" = network knows how to map from its internal marking to something appropriate for = each "peering destination network", and every other originating network has a similar mapping for each of its peering destination networks, then in aggregate we have a mapping for every O-T (or O-D) pair. Jim > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 11, 2006 3:43 PM > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH]; = 'Patrick > Melampy'; speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Yes, well we aren't doing a good job of separating our terms, and = transit > networks are indeed a fact of life. >=20 > So, yes, I think it's the peering destination network, which would be > "next-hop" at the peering point who would have a marking policy. >=20 > We could define this away by saying it was that network who was > responsible > for marking its packets any way in wants on entry, rather than the = peering > "network"'s responsibility. >=20 > I don't think we need an O-T pair; I think we need a T (or as Tim = says, > next > hop) policy. Every flow to that next hop gets marked the way that = network > wants it. Source doesn't matter. >=20 > IN THE PEERING FABRIC, I think it probably doesn't matter; I think you = can > probably do admission control into the fabric that makes diffserv = within > the > fabric unnecessary. If you did want it, then you have to remark on > entrance > to the fabric with the fabric's code points, and then remark again = with > the > next hop network's desired codepoints. >=20 > Brian >=20 > -----Original Message----- > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > Sent: Tuesday, April 11, 2006 12:11 PM > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy'; > speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Wouldn't the marking need to be per the requirements of the adjacent > network > rather than the network in which the session terminates? We are = talking > about L3 markings and there may be multiple L3 networks between O and = T. >=20 > Tim >=20 >=20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Tuesday, April 11, 2006 11:06 AM > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > Subject: RE: [Speermint] = RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Comments inline. >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, April 10, 2006 3:45 PM > > To: 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > I personally think this is way over the top for a BCP. > > > > If such things were deployed now, even experimentally, and we had = some > > good reports on complexity, stability and usefulness, then maybe we > > could document that as "Best Current Practice". In the absence of > > anything like it, to my knowledge, in the wild, I'd say let's not go > > there. > > > > I'm pretty certain that an objective evaluation of this scheme would > > result in a "more bandwidth is cheaper" conclusion, but since my > > speculation isn't any more valid that yours I think we just > > fagetabodit. > > > > Can we just stick with per T-domain marking and DiffServ? >=20 > [JMcE] If we have per T-domain marking and DiffServ, then presumably = we > must > have a policy that specifies the translation for each O-T pair. If we > agree > on this, then does it really matter if that "per O-T translation = policy" > has > a single entry, an entry per media type, or multiple options per media > type? > If fact, once we allow for such translation, do we even need to = specify > how > many options are possible? >=20 > > > > Brian > > > > -----Original Message----- > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > Sent: Saturday, April 08, 2006 10:53 AM > > To: speermint@ietf.org > > Subject: RE: [Speermint] RE: > > BackgroundReadingonNGNInterconnect-transitvs > > peering > > > > > > Brian, > > > > This new kind of policy driven marking thing must work across = network > > borders -- and across trust boundaries. What we really need to solve > > the routing problem is a second forwarding equivalence class -- one > > for best efforts, and one for voice. These must be advertised = through > > BGP4 edges to effect a second routing plane. Only then can you solve = the > routing problem. > > > > If this was all completed, and we could make packets route = differently > > based on service (different next-hop networks), we have solved a = first > > problem. > > However it is unclear that we have made the internet better. Now = when > > you "ping" an address, you get a different response if the ToS is = best > > efforts verses Voice. You also would have to revise ICMP handling to > > deal with "unreachable address messages" to take into account the = ToS. > > There may be many other protocol issues that occur when these bits = are > not > set properly. > > > > I can think of one simple one. > > > > I want to establish a TCP/TLS SIPS session to a proxy. This proxy is > > ONLY reachable in the ToS Voice forwarding plane. However, when I = use > > the Berkely Sockets to create the socket ... the syn/syn syn/ack ack > > three way handshake doesn't have the ToS bits set yet (since I can't > > do a SOCKOPTS until the socket is opened). Thus we would have to = alter > > the ways Berkely sockets work to ensure that the 3way TCP handshake > > routes properly. > > > > These complications may be worth the salvation of honor and = avoidance > > of doing something evil like a simple NAT like SBC's do. > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 07, 2006 3:03 PM > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE: = Background > > ReadingonNGNInterconnect-transitvs peering > > > > Uh-huh, at least for a generic "everyone should do this" kind of = thing. > > > > I have no illusions that big complex carrier networks will adopt > > anything as straightforward as -service-classes, but many more = focused > > carriers could, and profit there-by. > > > > So, I think our BCP should reference that work, but I believe it's = not > > sufficient. We probably need some kind of policy driven re-marking > thingy. > > > > What I'm not so sure about is PER FLOW decision making. PER = "T-NETWORK" > > is > > maybe doable. > > > > Brian > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, April 07, 2006 2:55 PM > > To: br@brianrosen.net; speermint@ietf.org > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: Background > > Reading onNGNInterconnect-transitvs peering > > > > Brian, > > > > Are you talking something like?: > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > Mike > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 1:44 PM > > > To: speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > I changed the subject line, at least this part of the thread may = be > > > fruitful> > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > tunnels, or any > > > >>other kind of links down in the router. > > > > > > > >The process of getting signaled RTP data onto these tunnels, and > > > >not the best efforts packets from the same IP address pairs, is > > > essential > > > >and in scope. > > > > > > .... > > > > > > >>This doesn't say you can't mark media packets in some way > > > that sends > > > >>them down some specific tunnels. > > > > > > >The process of doing this -- routing by packet markings -- > > > and how this > > > >will be setup on a call-by-call basis from the same IP address > > > >pairs used for best efforts should be in scope. > > > > > > Now we may be getting somewhere. This seems like it creates > > > requirements I might be able to deal with. > > > > > > What I'm hearing is that you think, fundamentally, that signaling > > > packets must be able to be marked differently from media packets. > > > Seems hard to argue with that. > > > > > > But I believe you want a requirement that we cover PER FLOW = marking. > > > I think that might be something worth discussing. > > > > > > There are two ways we know how to do this. The right way (get the > > > origin to mark them right in the first place) and the expeditious > > > way (put an intermediary in the path and remark them). That > > > intermediary could be an > > > L5/L7 entity, or it could be down in router-land using normal flow > > > identifier techniques. > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing > > > >>mechanisms > > > you > > > >>like for any set of flows you can identify. > > > > > > >Once again....how to use these static routes (which is often > > > why SBC's > > > >are used--essentially creating the head of a static route) > > > needs to be > > > >studied by this group. > > > Well, is this any different from the marking issue above? > > > What do you want the BCP to say beyond marking of packets? > > > What is the requirement? > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > In the best of all worlds, we would agree on the proper marking of > > > packets, all networks would mark in a uniform way, and routers = would > > > route in an optimal manner for the packets marked appropriately no > > > matter how many domains the packets crossed. > > > > > > Dream on you say. > > > > > > I agree, but we should, probably, at least mention the ideal = (which > > > implies we actually specify what the marking should be). I'd = expect > > > to see signaling packets marked differently than media packets. > > > There could reasonably be different marking for different kinds of > > > media (text vs audio vs video, for example). > > > > > > Then we have to deal with the reality that marking within a domain > > > may be consistent, but in peering, the O marking won't be the same > > > as the T marking, and we need to remark at the peering edge. > > > > > > Then we could consider per-flow marking. I'm not so sure I want = to > > > go there, but I'm willing to listen. > > > > > > But is there more than that? What, exactly? > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > 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 >=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 Apr 12 11:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThZh-0002PK-D3; Wed, 12 Apr 2006 11:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FThZg-0002PC-2X for speermint@ietf.org; Wed, 12 Apr 2006 11:48:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FThZe-0002Uy-6w for speermint@ietf.org; Wed, 12 Apr 2006 11:48:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2006 11:47:55 -0400 X-IronPort-AV: i="4.04,115,1144036800"; d="scan'208"; a="86290228:sNHT29422415666" 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 k3CFltTL019834; Wed, 12 Apr 2006 11:47:55 -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.211); Wed, 12 Apr 2006 11:47:55 -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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Wed, 12 Apr 2006 11:47:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301570078@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUA== From: "Michael Hammer \(mhammer\)" To: "James McEachern" , , , "Patrick Melampy" , X-OriginalArrivalTime: 12 Apr 2006 15:47:55.0129 (UTC) FILETIME=[76D9F690:01C65E48] X-Spam-Score: 0.0 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d 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 James, Let us say that network A uses markings A1, A2, A3 for voice, video, and data internally. Let us say that network B uses markings B1, B2, B3 ... ... Assume we want to allow each network operator to assign them independently. This leads to many, many permutations. Now, let us say that for handoff at a peering point,=20 we standardize markings P1, P2, and P3 ... We now have: A1 -> P1 -> B1 A2 -> P2 -> B2 A3 -> P3 -> B3 The mapping is always to/from the internal to the standard. Each operator only needs to know how to map from their Ax assignments to the standard Px assignments. That was my understanding of the problem and solution. But, perhaps there is more to it. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Wednesday, April 12, 2006 11:23 AM > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick=20 > Melampy; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > Brian, > We may need a picture, but I'm afraid these didn't help - I'm=20 > more confused than I was when I started. I think I must be=20 > missing something, so I'll state my assumptions here, and=20 > perhaps someone can point out where I have gone astray. >=20 > My assumptions: > 1. The O network is using DiffServ markings within its network. > 2. The T network is using DiffServ markings within its=20 > network, but they are not the same markings as in the O network. =20 > 3. The peering point is carrying more than one media type,=20 > and the media types do not all have the same DiffServ markings.=20 > 4. Therefore, it is not possible for the T network to=20 > determine a priori the appropriate DiffServ markings (and=20 > apply them to all the traffic) simply on the basis of the=20 > peering point. The T network must look at the media-specific=20 > markings for each media type, and translate those to the=20 > corresponding media-specific marking that it uses for that=20 > media type in its network. Since each network (potentially)=20 > uses a different marking scheme, this results in mappings for=20 > each O-T pair. This should apply no matter where the marking=20 > is applied. >=20 > What am I missing? >=20 > Jim >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 12, 2006 9:49 AM > To: McEachern, James [CAR:5N00:EXCH];=20 > timothy.dwight@verizon.com; 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > Jim >=20 > Need a picture: >=20 >=20 > O ---- P ---- T > ^ >=20 > You mark at the exit of the peering fabric with the T marking=20 > (where T here is either the terminating network or the=20 > transit network as Tim suggests). >=20 > You could mark on entrance, but then, as you suggest, you=20 > would have O-T pairs. > O ---- P ---- T > ^ >=20 > Of course, as I pointed out, there are two sides to the exit=20 > (and entrance). > If the peering system does the marking, it's in scope.=20 > O ---- P ---- T > ^ > If the T network does its own marking on its entrance: > O ---- P ---- T > ^ > then its out of scope. >=20 > If it's done on entrance, than it's in scope. > O ---- P ---- T > ^ > Or > O ---- P ---- T > ^ >=20 > If it's done on entrance with T's marking, then the peering=20 > fabric can't use markings (can't implement DiffServ). As I=20 > said, this may not be a problem. > If it's done on entrance with P's marking, and again on exit with T's: > O ---- P ---- T > ^ > P > ^ > T >=20 > then you can use diffserv in the fabric >=20 > Brian >=20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Tuesday, April 11, 2006 5:51 PM > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick=20 > Melampy; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Brian, > Perhaps it is just an issue of terminology, but if an=20 > "originating" network knows how to map from its internal=20 > marking to something appropriate for each "peering=20 > destination network", and every other originating network has=20 > a similar mapping for each of its peering destination=20 > networks, then in aggregate we have a mapping for every O-T=20 > (or O-D) pair. >=20 > Jim >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, April 11, 2006 3:43 PM > > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH];=20 > > 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Yes, well we aren't doing a good job of separating our terms, and=20 > > transit networks are indeed a fact of life. > >=20 > > So, yes, I think it's the peering destination network,=20 > which would be=20 > > "next-hop" at the peering point who would have a marking policy. > >=20 > > We could define this away by saying it was that network who was=20 > > responsible for marking its packets any way in wants on=20 > entry, rather=20 > > than the peering "network"'s responsibility. > >=20 > > I don't think we need an O-T pair; I think we need a T (or as Tim=20 > > says, next > > hop) policy. Every flow to that next hop gets marked the way that=20 > > network wants it. Source doesn't matter. > >=20 > > IN THE PEERING FABRIC, I think it probably doesn't matter;=20 > I think you=20 > > can probably do admission control into the fabric that=20 > makes diffserv=20 > > within the fabric unnecessary. If you did want it, then=20 > you have to=20 > > remark on entrance to the fabric with the fabric's code points, and=20 > > then remark again with the next hop network's desired codepoints. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Tuesday, April 11, 2006 12:11 PM > > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy';=20 > > speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Wouldn't the marking need to be per the requirements of the=20 > adjacent=20 > > network rather than the network in which the session=20 > terminates? We=20 > > are talking about L3 markings and there may be multiple L3 networks=20 > > between O and T. > >=20 > > Tim > >=20 > >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Tuesday, April 11, 2006 11:06 AM > > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Comments inline. > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, April 10, 2006 3:45 PM > > > To: 'Patrick Melampy'; speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > I personally think this is way over the top for a BCP. > > > > > > If such things were deployed now, even experimentally, and we had=20 > > > some good reports on complexity, stability and usefulness, then=20 > > > maybe we could document that as "Best Current Practice". In the=20 > > > absence of anything like it, to my knowledge, in the=20 > wild, I'd say=20 > > > let's not go there. > > > > > > I'm pretty certain that an objective evaluation of this=20 > scheme would=20 > > > result in a "more bandwidth is cheaper" conclusion, but since my=20 > > > speculation isn't any more valid that yours I think we just=20 > > > fagetabodit. > > > > > > Can we just stick with per T-domain marking and DiffServ? > >=20 > > [JMcE] If we have per T-domain marking and DiffServ, then=20 > presumably=20 > > we must have a policy that specifies the translation for each O-T=20 > > pair. If we agree on this, then does it really matter if that "per=20 > > O-T translation policy" > > has > > a single entry, an entry per media type, or multiple=20 > options per media=20 > > type? > > If fact, once we allow for such translation, do we even need to=20 > > specify how many options are possible? > >=20 > > > > > > Brian > > > > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Saturday, April 08, 2006 10:53 AM > > > To: speermint@ietf.org > > > Subject: RE: [Speermint] RE: > > > BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > > > > Brian, > > > > > > This new kind of policy driven marking thing must work across=20 > > > network borders -- and across trust boundaries. What we=20 > really need=20 > > > to solve the routing problem is a second forwarding equivalence=20 > > > class -- one for best efforts, and one for voice. These must be=20 > > > advertised through > > > BGP4 edges to effect a second routing plane. Only then=20 > can you solve=20 > > > the > > routing problem. > > > > > > If this was all completed, and we could make packets route=20 > > > differently based on service (different next-hop=20 > networks), we have=20 > > > solved a first problem. > > > However it is unclear that we have made the internet better. Now=20 > > > when you "ping" an address, you get a different response=20 > if the ToS=20 > > > is best efforts verses Voice. You also would have to revise ICMP=20 > > > handling to deal with "unreachable address messages" to=20 > take into account the ToS. > > > There may be many other protocol issues that occur when=20 > these bits=20 > > > are > > not > > set properly. > > > > > > I can think of one simple one. > > > > > > I want to establish a TCP/TLS SIPS session to a proxy.=20 > This proxy is=20 > > > ONLY reachable in the ToS Voice forwarding plane. However, when I=20 > > > use the Berkely Sockets to create the socket ... the=20 > syn/syn syn/ack=20 > > > ack three way handshake doesn't have the ToS bits set yet=20 > (since I=20 > > > can't do a SOCKOPTS until the socket is opened). Thus we=20 > would have=20 > > > to alter the ways Berkely sockets work to ensure that the=20 > 3way TCP=20 > > > handshake routes properly. > > > > > > These complications may be worth the salvation of honor and=20 > > > avoidance of doing something evil like a simple NAT like SBC's do. > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 3:03 PM > > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE:=20 > > > Background ReadingonNGNInterconnect-transitvs peering > > > > > > Uh-huh, at least for a generic "everyone should do this"=20 > kind of thing. > > > > > > I have no illusions that big complex carrier networks will adopt=20 > > > anything as straightforward as -service-classes, but many more=20 > > > focused carriers could, and profit there-by. > > > > > > So, I think our BCP should reference that work, but I=20 > believe it's=20 > > > not sufficient. We probably need some kind of policy driven=20 > > > re-marking > > thingy. > > > > > > What I'm not so sure about is PER FLOW decision making. =20 > PER "T-NETWORK" > > > is > > > maybe doable. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Friday, April 07, 2006 2:55 PM > > > To: br@brianrosen.net; speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:=20 > Background=20 > > > Reading onNGNInterconnect-transitvs peering > > > > > > Brian, > > > > > > Are you talking something like?: > > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, April 07, 2006 1:44 PM > > > > To: speermint@ietf.org > > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > > > > I changed the subject line, at least this part of the=20 > thread may=20 > > > > be > > > > fruitful> > > > > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > > tunnels, or any > > > > >>other kind of links down in the router. > > > > > > > > > >The process of getting signaled RTP data onto these=20 > tunnels, and=20 > > > > >not the best efforts packets from the same IP address pairs, is > > > > essential > > > > >and in scope. > > > > > > > > .... > > > > > > > > >>This doesn't say you can't mark media packets in some way > > > > that sends > > > > >>them down some specific tunnels. > > > > > > > > >The process of doing this -- routing by packet markings -- > > > > and how this > > > > >will be setup on a call-by-call basis from the same IP address=20 > > > > >pairs used for best efforts should be in scope. > > > > > > > > Now we may be getting somewhere. This seems like it creates=20 > > > > requirements I might be able to deal with. > > > > > > > > What I'm hearing is that you think, fundamentally, that=20 > signaling=20 > > > > packets must be able to be marked differently from=20 > media packets. > > > > Seems hard to argue with that. > > > > > > > > But I believe you want a requirement that we cover PER=20 > FLOW marking. > > > > I think that might be something worth discussing. > > > > > > > > There are two ways we know how to do this. The right=20 > way (get the=20 > > > > origin to mark them right in the first place) and the=20 > expeditious=20 > > > > way (put an intermediary in the path and remark them). That=20 > > > > intermediary could be an > > > > L5/L7 entity, or it could be down in router-land using=20 > normal flow=20 > > > > identifier techniques. > > > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing=20 > > > > >>mechanisms > > > > you > > > > >>like for any set of flows you can identify. > > > > > > > > >Once again....how to use these static routes (which is often > > > > why SBC's > > > > >are used--essentially creating the head of a static route) > > > > needs to be > > > > >studied by this group. > > > > Well, is this any different from the marking issue above? > > > > What do you want the BCP to say beyond marking of packets? > > > > What is the requirement? > > > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > > > In the best of all worlds, we would agree on the proper=20 > marking of=20 > > > > packets, all networks would mark in a uniform way, and routers=20 > > > > would route in an optimal manner for the packets marked=20 > > > > appropriately no matter how many domains the packets crossed. > > > > > > > > Dream on you say. > > > > > > > > I agree, but we should, probably, at least mention the ideal=20 > > > > (which implies we actually specify what the marking=20 > should be). =20 > > > > I'd expect to see signaling packets marked differently=20 > than media packets. > > > > There could reasonably be different marking for=20 > different kinds of=20 > > > > media (text vs audio vs video, for example). > > > > > > > > Then we have to deal with the reality that marking=20 > within a domain=20 > > > > may be consistent, but in peering, the O marking won't=20 > be the same=20 > > > > as the T marking, and we need to remark at the peering edge. > > > > > > > > Then we could consider per-flow marking. I'm not so=20 > sure I want=20 > > > > to go there, but I'm willing to listen. > > > > > > > > But is there more than that? What, exactly? > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=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 Apr 12 13:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjPX-00071C-01; Wed, 12 Apr 2006 13:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjPV-000717-Gj for speermint@ietf.org; Wed, 12 Apr 2006 13:45:45 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTjPU-0006eV-P6 for speermint@ietf.org; Wed, 12 Apr 2006 13:45:45 -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 k3CHjcV07060; Wed, 12 Apr 2006 13:45:39 -0400 (EDT) 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] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Wed, 12 Apr 2006 13:45:36 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXA= From: "James McEachern" To: , "Michael Hammer \(mhammer\)" , , "Patrick Melampy" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8bebc843ecf489bb7d907f63ccb001af 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 - I think I finally understand. My question now, is whether this is in scope for the initial SPEERMINT = deliverables, or part of the second wave? (Reading the charter again, = my initial suspicion is second wave, but I'm just asking...) Jim=20 -----Original Message----- From: Tim Dwight [mailto:timothy.dwight@verizon.com]=20 Sent: Wednesday, April 12, 2006 12:19 PM To: 'Michael Hammer (mhammer)'; McEachern, James [CAR:5N00:EXCH]; = br@brianrosen.net; 'Patrick Melampy'; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs = peering I think this is becoming more realistic, let's extend on it a little. =20 Suppose there is as Mike suggests, a standard that says voice, video and data map to DSCPs P1, P2 and P3 at inter-network interfaces. Suppose further you have networks A, B and C which pass traffic at L3 serially, = as follows: A | <---L3---> | B | <---L3---> | C Within network A these services are mapped to DSCPs A1, A2 and A3. = Within network B they are mapped to DSCPs to B1, B2 and B3. Within network C = they are mapped to DSCPs C1, C2 and C3. I believe the expectation at inter-network boundaries is that the sending network maps the traffic = per the "standard". Which means that each operator can reliably interpret = the arriving traffic, mapping it to its internal mappings if desired, then mapping it back to the "standard" before handing it to the next = operator. There is of course the potential to lose granularity in this mapping process. For example network B might map P1 and P2 both to EF. At the interface to C there's no easy way for it to reverse this. Which can = lead to a sort of "QoS inflation", assuming that in this example network B = would map EF to P1. There are commercial implications to its doing so, which = are WAY outside the scope of this WG but that would in practice mitigate = such practice (i.e., the simplest thing to do is to maintain the granularity implied by the standard markings). =20 tim -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Wednesday, April 12, 2006 10:48 AM To: James McEachern; br@brianrosen.net; timothy.dwight@verizon.com; = Patrick Melampy; speermint@ietf.org Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering James, Let us say that network A uses markings A1, A2, A3 for voice, video, and data internally. Let us say that network B uses markings B1, B2, B3 ... ... Assume we want to allow each network operator to assign them = independently. This leads to many, many permutations. Now, let us say that for handoff at a peering point, we standardize = markings P1, P2, and P3 ... We now have: A1 -> P1 -> B1 A2 -> P2 -> B2 A3 -> P3 -> B3 The mapping is always to/from the internal to the standard. Each = operator only needs to know how to map from their Ax assignments to the standard = Px assignments. That was my understanding of the problem and solution. = But, perhaps there is more to it. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Wednesday, April 12, 2006 11:23 AM > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy;=20 > speermint@ietf.org > Subject: RE: [Speermint] > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > Brian, > We may need a picture, but I'm afraid these didn't help - I'm more=20 > confused than I was when I started. I think I must be missing=20 > something, so I'll state my assumptions here, and perhaps someone can=20 > point out where I have gone astray. >=20 > My assumptions: > 1. The O network is using DiffServ markings within its network. > 2. The T network is using DiffServ markings within its network, but=20 > they are not the same markings as in the O network. > 3. The peering point is carrying more than one media type, and the=20 > media types do not all have the same DiffServ markings. > 4. Therefore, it is not possible for the T network to determine a=20 > priori the appropriate DiffServ markings (and apply them to all the=20 > traffic) simply on the basis of the peering point. The T network must = > look at the media-specific markings for each media type, and translate = > those to the corresponding media-specific marking that it uses for=20 > that media type in its network. Since each network (potentially) uses = > a different marking scheme, this results in mappings for each O-T=20 > pair. This should apply no matter where the marking is applied. >=20 > What am I missing? >=20 > Jim >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 12, 2006 9:49 AM > To: McEachern, James [CAR:5N00:EXCH]; timothy.dwight@verizon.com;=20 > 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint] > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > Jim >=20 > Need a picture: >=20 >=20 > O ---- P ---- T > ^ >=20 > You mark at the exit of the peering fabric with the T marking (where T = > here is either the terminating network or the transit network as Tim=20 > suggests). >=20 > You could mark on entrance, but then, as you suggest, you would have=20 > O-T pairs. > O ---- P ---- T > ^ >=20 > Of course, as I pointed out, there are two sides to the exit (and=20 > entrance). > If the peering system does the marking, it's in scope.=20 > O ---- P ---- T > ^ > If the T network does its own marking on its entrance: > O ---- P ---- T > ^ > then its out of scope. >=20 > If it's done on entrance, than it's in scope. > O ---- P ---- T > ^ > Or > O ---- P ---- T > ^ >=20 > If it's done on entrance with T's marking, then the peering fabric=20 > can't use markings (can't implement DiffServ). As I said, this may=20 > not be a problem. > If it's done on entrance with P's marking, and again on exit with T's: > O ---- P ---- T > ^ > P > ^ > T >=20 > then you can use diffserv in the fabric >=20 > Brian >=20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Tuesday, April 11, 2006 5:51 PM > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy;=20 > speermint@ietf.org > Subject: RE: [Speermint] > RE:BackgroundReadingonNGNInterconnect-transitvs > peering >=20 > Brian, > Perhaps it is just an issue of terminology, but if an "originating"=20 > network knows how to map from its internal marking to something=20 > appropriate for each "peering destination network", and every other=20 > originating network has a similar mapping for each of its peering=20 > destination networks, then in aggregate we have a mapping for every=20 > O-T (or O-D) pair. >=20 > Jim >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, April 11, 2006 3:43 PM > > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH];=20 > > 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Yes, well we aren't doing a good job of separating our terms, and=20 > > transit networks are indeed a fact of life. > >=20 > > So, yes, I think it's the peering destination network, > which would be > > "next-hop" at the peering point who would have a marking policy. > >=20 > > We could define this away by saying it was that network who was=20 > > responsible for marking its packets any way in wants on > entry, rather > > than the peering "network"'s responsibility. > >=20 > > I don't think we need an O-T pair; I think we need a T (or as Tim=20 > > says, next > > hop) policy. Every flow to that next hop gets marked the way that=20 > > network wants it. Source doesn't matter. > >=20 > > IN THE PEERING FABRIC, I think it probably doesn't matter; > I think you > > can probably do admission control into the fabric that > makes diffserv > > within the fabric unnecessary. If you did want it, then > you have to > > remark on entrance to the fabric with the fabric's code points, and=20 > > then remark again with the next hop network's desired codepoints. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Tuesday, April 11, 2006 12:11 PM > > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy';=20 > > speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Wouldn't the marking need to be per the requirements of the > adjacent > > network rather than the network in which the session > terminates? We > > are talking about L3 markings and there may be multiple L3 networks=20 > > between O and T. > >=20 > > Tim > >=20 > >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Tuesday, April 11, 2006 11:06 AM > > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Comments inline. > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, April 10, 2006 3:45 PM > > > To: 'Patrick Melampy'; speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > I personally think this is way over the top for a BCP. > > > > > > If such things were deployed now, even experimentally, and we had=20 > > > some good reports on complexity, stability and usefulness, then=20 > > > maybe we could document that as "Best Current Practice". In the=20 > > > absence of anything like it, to my knowledge, in the > wild, I'd say > > > let's not go there. > > > > > > I'm pretty certain that an objective evaluation of this > scheme would > > > result in a "more bandwidth is cheaper" conclusion, but since my=20 > > > speculation isn't any more valid that yours I think we just=20 > > > fagetabodit. > > > > > > Can we just stick with per T-domain marking and DiffServ? > >=20 > > [JMcE] If we have per T-domain marking and DiffServ, then > presumably > > we must have a policy that specifies the translation for each O-T=20 > > pair. If we agree on this, then does it really matter if that "per=20 > > O-T translation policy" > > has > > a single entry, an entry per media type, or multiple > options per media > > type? > > If fact, once we allow for such translation, do we even need to=20 > > specify how many options are possible? > >=20 > > > > > > Brian > > > > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Saturday, April 08, 2006 10:53 AM > > > To: speermint@ietf.org > > > Subject: RE: [Speermint] RE: > > > BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > > > > Brian, > > > > > > This new kind of policy driven marking thing must work across=20 > > > network borders -- and across trust boundaries. What we > really need > > > to solve the routing problem is a second forwarding equivalence=20 > > > class -- one for best efforts, and one for voice. These must be=20 > > > advertised through > > > BGP4 edges to effect a second routing plane. Only then > can you solve > > > the > > routing problem. > > > > > > If this was all completed, and we could make packets route=20 > > > differently based on service (different next-hop > networks), we have > > > solved a first problem. > > > However it is unclear that we have made the internet better. Now=20 > > > when you "ping" an address, you get a different response > if the ToS > > > is best efforts verses Voice. You also would have to revise ICMP=20 > > > handling to deal with "unreachable address messages" to > take into account the ToS. > > > There may be many other protocol issues that occur when > these bits > > > are > > not > > set properly. > > > > > > I can think of one simple one. > > > > > > I want to establish a TCP/TLS SIPS session to a proxy.=20 > This proxy is > > > ONLY reachable in the ToS Voice forwarding plane. However, when I=20 > > > use the Berkely Sockets to create the socket ... the > syn/syn syn/ack > > > ack three way handshake doesn't have the ToS bits set yet > (since I > > > can't do a SOCKOPTS until the socket is opened). Thus we > would have > > > to alter the ways Berkely sockets work to ensure that the > 3way TCP > > > handshake routes properly. > > > > > > These complications may be worth the salvation of honor and=20 > > > avoidance of doing something evil like a simple NAT like SBC's do. > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 3:03 PM > > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE:=20 > > > Background ReadingonNGNInterconnect-transitvs peering > > > > > > Uh-huh, at least for a generic "everyone should do this"=20 > kind of thing. > > > > > > I have no illusions that big complex carrier networks will adopt=20 > > > anything as straightforward as -service-classes, but many more=20 > > > focused carriers could, and profit there-by. > > > > > > So, I think our BCP should reference that work, but I > believe it's > > > not sufficient. We probably need some kind of policy driven=20 > > > re-marking > > thingy. > > > > > > What I'm not so sure about is PER FLOW decision making. =20 > PER "T-NETWORK" > > > is > > > maybe doable. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Friday, April 07, 2006 2:55 PM > > > To: br@brianrosen.net; speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:=20 > Background > > > Reading onNGNInterconnect-transitvs peering > > > > > > Brian, > > > > > > Are you talking something like?: > > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, April 07, 2006 1:44 PM > > > > To: speermint@ietf.org > > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > > > > I changed the subject line, at least this part of the > thread may > > > > be > > > > fruitful> > > > > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > > tunnels, or any > > > > >>other kind of links down in the router. > > > > > > > > > >The process of getting signaled RTP data onto these > tunnels, and > > > > >not the best efforts packets from the same IP address pairs, is > > > > essential > > > > >and in scope. > > > > > > > > .... > > > > > > > > >>This doesn't say you can't mark media packets in some way > > > > that sends > > > > >>them down some specific tunnels. > > > > > > > > >The process of doing this -- routing by packet markings -- > > > > and how this > > > > >will be setup on a call-by-call basis from the same IP address=20 > > > > >pairs used for best efforts should be in scope. > > > > > > > > Now we may be getting somewhere. This seems like it creates=20 > > > > requirements I might be able to deal with. > > > > > > > > What I'm hearing is that you think, fundamentally, that > signaling > > > > packets must be able to be marked differently from > media packets. > > > > Seems hard to argue with that. > > > > > > > > But I believe you want a requirement that we cover PER > FLOW marking. > > > > I think that might be something worth discussing. > > > > > > > > There are two ways we know how to do this. The right > way (get the > > > > origin to mark them right in the first place) and the > expeditious > > > > way (put an intermediary in the path and remark them). That=20 > > > > intermediary could be an > > > > L5/L7 entity, or it could be down in router-land using > normal flow > > > > identifier techniques. > > > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing=20 > > > > >>mechanisms > > > > you > > > > >>like for any set of flows you can identify. > > > > > > > > >Once again....how to use these static routes (which is often > > > > why SBC's > > > > >are used--essentially creating the head of a static route) > > > > needs to be > > > > >studied by this group. > > > > Well, is this any different from the marking issue above? > > > > What do you want the BCP to say beyond marking of packets? > > > > What is the requirement? > > > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > > > In the best of all worlds, we would agree on the proper > marking of > > > > packets, all networks would mark in a uniform way, and routers=20 > > > > would route in an optimal manner for the packets marked=20 > > > > appropriately no matter how many domains the packets crossed. > > > > > > > > Dream on you say. > > > > > > > > I agree, but we should, probably, at least mention the ideal=20 > > > > (which implies we actually specify what the marking > should be). =20 > > > > I'd expect to see signaling packets marked differently > than media packets. > > > > There could reasonably be different marking for > different kinds of > > > > media (text vs audio vs video, for example). > > > > > > > > Then we have to deal with the reality that marking > within a domain > > > > may be consistent, but in peering, the O marking won't > be the same > > > > as the T marking, and we need to remark at the peering edge. > > > > > > > > Then we could consider per-flow marking. I'm not so > sure I want > > > > to go there, but I'm willing to listen. > > > > > > > > But is there more than that? What, exactly? > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 12 15:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTklj-0006bf-Bh; Wed, 12 Apr 2006 15:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTklh-0006bQ-Q1 for speermint@ietf.org; Wed, 12 Apr 2006 15:12:45 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTklh-0001Db-0J for speermint@ietf.org; Wed, 12 Apr 2006 15:12:45 -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] 2 Basic Constructs for SIP Peering Date: Wed, 12 Apr 2006 21:13:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4986@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] 2 Basic Constructs for SIP Peering Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAAN1gzgALbU39AAJvougg== From: "Stastny Richard" To: "Uzelac, Adam" , "Hadriel Kaplan" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f 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 >From the point of the O-domain there is only one T-domain ingress point If there are a bunch of T-domains hidden behind does not matter for the O-domain or to be precise: it MUST NOT. [adam] Should I read this MUST NOT as stating that a T-Network, if not the ultimate T-Network where calling party resides, must use B2BUAs? If it is breaking the end-to-end flow on L3 between the UAs IMHO Yes Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Mi 12.04.2006 16:04 An: Stastny Richard; Hadriel Kaplan; speermint@ietf.org Betreff: RE: [Speermint] 2 Basic Constructs for SIP Peering [adam] Comments inline... -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Saturday, April 08, 2006 5:41 AM To: Hadriel Kaplan; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > So there's really just: > L > / > O---T. The location function is one of the basic functions SPEERMINT needs to work on [adam] I agree. Of course the simplest case is defined in RFC 3263, but there are more complex cases - e.g. a redirect/proxy server, eventaually also involving an ENUM lookup, this is basically what VPF or XConnect are providing. (the second is policy, i.e. if you are able to access the given proxy) [adam] It's in the redirect/proxy scenario that I am thinking that there could (maybe should) be communications between the S-Network and the T-Network to determine if S-Network should direct the session to the T-Network. With this said, I am thinking back to a triangle model of: [adam] S /\ O--T Another task may be to translate personal URIs or enterprise AoRs hosted by a SP to the ingress proxy of the SP e.g. Sip:bill@microsoft.co.uk -> sip:bill@ms.bt.com [adam] I don't know if this task would be a requirement or not. Might be up to the implementor to determine, but to me this doesn't have anything to do with routing of the session. The main task of a "location function" is to provide the out-bound proxy of the O-domain (one of) the ingress proxy(s) of the T-domain > I can't agree in a proxied(non-redirect) call flow. Also, there may > be a requirement to determine which T-Network to term the call to > should there be more than one. With terminating networks it is like Highlander there can only be one [adam] Great movie! I am thinking that all O-Networks will not be interconnected possible to all T-Networks. Therefore some (I hesitate stating) transit network options may need to be considered. Transit here meaning not the _ultimate_ T-Network where the called party resides, but granted, it is the T-Network from the O and S-Network's POV for that call. The S-Network may be aware of multiple routes to the ultimate T-Network via some transits, one path may have different characteristics than another. If the consensus here is that transits will not be considered, than B2BUAs would be required to hide the topology as you state below. > There could be a subsequent T-Network proxy involved. So the call > would be signaled from O-Network to S-Network, and then maybe > S-Network to T-Network to determine ultimate T-Network end point. >From the point of the O-domain there is only one T-domain ingress point If there are a bunch of T-domains hidden behind does not matter for the O-domain or to be precise: it MUST NOT. [adam] Should I read this MUST NOT as stating that a T-Network, if not the ultimate T-Network where calling party resides, must use B2BUAs? The reason for topology hiding proxies is topology hiding If for example the mobile networks decide to open up the IPX GSMA network to be reached by selected partners from the Internet, they will put ingress proxies at the border of their network, and all what a O-domain on the internet will see for a AoR hosted by the mobile networks will be the ingress proxies of IPX. The routing to the real t-domain (teh specific mobile network will then be done via the ingress proxy The O-domain is not concerend [adam] The O-Network (domain) may not be concerned, but does the S-Network need to be? Richard ________________________________ Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Gesendet: Sa 08.04.2006 05:09 An: 'Uzelac, Adam'; speermint@ietf.org Betreff: RE: [Speermint] 2 Basic Constructs for SIP Peering Ahh, yes I see - I thought you were talking about redirect. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Friday, April 07, 2006 10:35 PM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I can't agree in a proxied(non-redirect) call flow. Also, there may > be a requirement to determine which T-Network to term the call to > should there be more than one. There could be a subsequent T-Network > proxy involved. So the call would be signaled from O-Network to > S-Network, and then maybe S-Network to T-Network to determine ultimate > T-Network end point. > > Adam Uzelac > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:59 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Hi Adam, > > If S is doing a redirect/proxy, isn't it just the location lookup > mechanism for O--T? (a trusted+shared location-lookup) > > So there's really just: > L > / > O---T. > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:37 AM > > To: speermint@ietf.org > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > I have gnawed on the latest series of threads, and while wadding > > through the noise and rhetoric, it appears to me that there are 2 > > basic constructs for SIP peering. Subscribing to Brian's notion > > that we must try to keep this simple - at least at this stage - it > > seems to > > > boil down to the following: (I acknowledge that there may be > > contextual > > variations) > > > > Option A) Session routing by 3rd party. > > > > S > > /\ > > O--T > > > > In this model, O-Network queries S-Network (signaling) for routing > > options. S-Network redirects or proxies signaling request to > T-network. > > There is an assumption that L3 connectivity exists between all > > three, though S-Network would not be transit for media, but possible > > for signaling. The media flows directly from O-Network to T-Network. > > > > Option B) Direct bi-lateral routing. > > > > O--T > > > > In this model, O-Network signals T-Network directly, and receives > > routing instructions. Media would follow the same relationship, > > maybe > > > not the same path, but same bi-lateral relationship. Should there > > be more than one L3 peering point, any peering point may be used, > > but it all follows the same contextual relationship between > > O-Network and T-Network. > > > > I find it possible to apply either Option A or Option B to public, > > private, and even carrier (even carrier pigeon) environments. Maybe > > I > > > am pointing out the obvious, but that's OK as I have been often > > accused of being master of the obvious. ;) > > > > Adam Uzelac > > > > _______________________________________________ > > 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 Apr 12 16:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlvo-0003ev-2R; Wed, 12 Apr 2006 16:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlvl-0003ZB-T8 for speermint@ietf.org; Wed, 12 Apr 2006 16:27:13 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlvl-0006nm-6K for speermint@ietf.org; Wed, 12 Apr 2006 16:27:13 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 12 Apr 2006 13:27:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,115,1144047600"; d="scan'208"; a="539518952:sNHT24978766" 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 Date: Wed, 12 Apr 2006 16:27:11 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE64E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8A== From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Speermint] SPEERMINT Routing Architecture Message Flows 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, We wrote a draft to help frame our discussions.=20 Thanks, Reinaldo A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Routing Architecture Message Flows =20 Author(s) : R. Penno, et al. Filename : draft-penno-message-flows-00.txt Pages : 19 Date : 2006-4-12 =09 This draft describes the message flows associated with the SPEERMINT=20 routing architecture. We show message flows in several peering=20 scenarios. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of 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 username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-penno-message-flows-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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 13:02:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Cl-0000iZ-Or; Thu, 13 Apr 2006 13:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Ck-0000iU-4I for speermint@ietf.org; Thu, 13 Apr 2006 13:02:02 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Ci-0003L3-Qc for speermint@ietf.org; Thu, 13 Apr 2006 13:02:02 -0400 Received: (qmail 14950 invoked by uid 510); 13 Apr 2006 13:41:35 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.176):. Processed in 0.941446 secs); 13 Apr 2006 17:41:35 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.176):. Processed in 0.941446 secs Process 14945) Received: from c-24-1-142-176.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.176) by 192.246.69.184 with SMTP; Thu, 13 Apr 2006 17:41:34 +0000 From: "Henry Sinnreich" To: "'Reinaldo Penno'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 11:55:18 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE64E@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGA X-Antivirus-MYDOMAIN-Message-ID: <114495009483514945@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com 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 Message-Id: The call flows shown are pretty much as would be expected from the trapezoid model in RFC 3261 using well defined SIP proxy behavior (lengthy section in RFC 3261). Why use B2BUA that have no defined behavior at all? Is it possible to standardize undefined behavior? Thanks, Henry -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Wednesday, April 12, 2006 3:27 PM To: speermint@ietf.org Subject: [Speermint] SPEERMINT Routing Architecture Message Flows Hello, We wrote a draft to help frame our discussions. Thanks, Reinaldo A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPEERMINT Routing Architecture Message Flows Author(s) : R. Penno, et al. Filename : draft-penno-message-flows-00.txt Pages : 19 Date : 2006-4-12 This draft describes the message flows associated with the SPEERMINT routing architecture. We show message flows in several peering scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 14:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU67X-00071o-IY; Thu, 13 Apr 2006 14:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU67W-00071j-Bd for speermint@ietf.org; Thu, 13 Apr 2006 14:00:42 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU67W-0005QQ-1t for speermint@ietf.org; Thu, 13 Apr 2006 14:00:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 11:00:41 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539720602:sNHT24170316" 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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 14:00:38 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE65C@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAIAiXA= From: "Reinaldo Penno" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Hello henry, > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Thursday, April 13, 2006 9:55 AM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > The call flows shown are pretty much as would be expected from the > trapezoid > model in RFC 3261 using well defined SIP proxy behavior (lengthy section > in > RFC 3261). [[Reinaldo]]=20 You are right. At some point in the list there was this big discussion on what we would need "besides" the current established RFCs, and if anything, what. The purpose of those sections is to show some call flows in peering scenarios and based on those ask the questions: 1) Do we need anything else? If we need, what would it be? 2) Is it SIP specific or more related to DNS? >=20 > Why use B2BUA that have no defined behavior at all? [[Reinaldo]]=20 On one hand I agree that B2BUA have no defined behavior (actually you and me discussed this in the past in the sip-implementors mailing list). On the other hand I do not want to take the "IPV6 will take over the world and NAT is evil and will disappear" similar stance. I'm taking the moderate approach here. I believe there are some specific functions that a B2BUA could do in peering scenarios. Can it be done some other way through clever network rollouts, NAT traversal, IPv6 etc? Sure it can, and I mention that...But real networks do not work like that.=20 >=20 > Is it possible to standardize undefined behavior? [[Reinaldo]]=20 That would be a difficult proposition, yes. Instead of mentioning SBC/B2BUA all over, I tried to concentrate on media relay, which is a function we might need, vis a vis: 1) How to get media to the peering point. 2) Private addresses when a NAT traversal cannot be used 3) Some media functions such as translation, quality measurement, etc=20 I will rework some of the portions to make more specific on the functions and needs to B2BUA. Maybe a couple of scenarios that combine private address and media relay (when media would not normally make to the peering point through layer 3 routing). Thanks, Reinaldo >=20 > Thanks, Henry >=20 >=20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 3:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > Hello, >=20 > We wrote a draft to help frame our discussions. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : SPEERMINT Routing Architecture Message Flows > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 >=20 > This draft describes the message flows associated with the SPEERMINT > routing architecture. We show message flows in several peering > scenarios. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 14:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6FX-0004et-3o; Thu, 13 Apr 2006 14:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6FV-0004ej-OE for speermint@ietf.org; Thu, 13 Apr 2006 14:08:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6FV-0005d1-FY for speermint@ietf.org; Thu, 13 Apr 2006 14:08:57 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2006 11:08:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="25848736:sNHT23652116" 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 k3DI8uvF000765; Thu, 13 Apr 2006 14:08:56 -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.211); Thu, 13 Apr 2006 14:08:55 -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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 14:08:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301570445@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfA= From: "Michael Hammer \(mhammer\)" To: , "Reinaldo Penno" , X-OriginalArrivalTime: 13 Apr 2006 18:08:55.0857 (UTC) FILETIME=[54405A10:01C65F25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 To the authors of draft-penno-message-flows-00.txt, One part of this that didn't seem quite right to me was the use of mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain B. (e.g., Do you intend to do some type of Contact routing?) Could I ask by way of suggestion why you don't use mutual Subscribe/Notify? That would require the same authentication and authorization to the requesting domain and would likely be much richer in terms of XML documents that could be supplied to the other domain in a Notify. An event package per federation type could be defined, for example. What do you think? Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Thursday, April 13, 2006 12:55 PM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > The call flows shown are pretty much as would be expected=20 > from the trapezoid model in RFC 3261 using well defined SIP=20 > proxy behavior (lengthy section in RFC 3261). >=20 > Why use B2BUA that have no defined behavior at all? >=20 > Is it possible to standardize undefined behavior? >=20 > Thanks, Henry >=20 > =20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 3:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > Hello, >=20 > We wrote a draft to help frame our discussions.=20 >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : SPEERMINT Routing Architecture Message Flows =20 > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 > =09 > This draft describes the message flows associated with the=20 > SPEERMINT routing architecture. We show message flows in=20 > several peering scenarios. =20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt >=20 >=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 Apr 13 14:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6Ym-00055p-B2; Thu, 13 Apr 2006 14:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6Yk-00055d-DJ for speermint@ietf.org; Thu, 13 Apr 2006 14:28:50 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6Yj-0006XI-OO for speermint@ietf.org; Thu, 13 Apr 2006 14:28:50 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Thu, 13 Apr 2006 14:26:27 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247E97@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAA3+UMQ From: "Livingood, Jason" To: "Michael Hammer \(mhammer\)" , "James McEachern" , , , "Patrick Melampy" , X-OriginalArrivalTime: 13 Apr 2006 18:28:17.0219 (UTC) FILETIME=[087A2130:01C65F28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d53b06eede2bb6b618e318c7466f38f 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 this is what I was just asking in my last post Mike, sounds like we're thinking the same thing on this question. =20 Jason =20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Wednesday, April 12, 2006 11:48 AM > To: James McEachern; br@brianrosen.net;=20 > timothy.dwight@verizon.com; Patrick Melampy; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > James, >=20 > Let us say that network A uses markings A1, A2, A3 for voice,=20 > video, and data internally. > Let us say that network B uses markings B1, B2, B3 ... > ... >=20 > Assume we want to allow each network operator to assign them=20 > independently. > This leads to many, many permutations. >=20 > Now, let us say that for handoff at a peering point, we=20 > standardize markings P1, P2, and P3 ... >=20 > We now have: > A1 -> P1 -> B1 > A2 -> P2 -> B2 > A3 -> P3 -> B3 >=20 > The mapping is always to/from the internal to the standard. =20 > Each operator only needs to know how to map from their Ax=20 > assignments to the standard Px assignments. That was my=20 > understanding of the problem and solution. But, perhaps=20 > there is more to it. >=20 > Mike >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Wednesday, April 12, 2006 11:23 AM > > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs peering > >=20 > > Brian, > > We may need a picture, but I'm afraid these didn't help - I'm more=20 > > confused than I was when I started. I think I must be missing=20 > > something, so I'll state my assumptions here, and perhaps=20 > someone can=20 > > point out where I have gone astray. > >=20 > > My assumptions: > > 1. The O network is using DiffServ markings within its network. > > 2. The T network is using DiffServ markings within its network, but=20 > > they are not the same markings as in the O network. > > 3. The peering point is carrying more than one media type, and the=20 > > media types do not all have the same DiffServ markings. > > 4. Therefore, it is not possible for the T network to determine a=20 > > priori the appropriate DiffServ markings (and apply them to all the=20 > > traffic) simply on the basis of the peering point. The T=20 > network must=20 > > look at the media-specific markings for each media type,=20 > and translate=20 > > those to the corresponding media-specific marking that it uses for=20 > > that media type in its network. Since each network=20 > (potentially) uses=20 > > a different marking scheme, this results in mappings for each O-T=20 > > pair. This should apply no matter where the marking is applied. > >=20 > > What am I missing? > >=20 > > Jim > >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 12, 2006 9:49 AM > > To: McEachern, James [CAR:5N00:EXCH]; timothy.dwight@verizon.com;=20 > > 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs peering > >=20 > > Jim > >=20 > > Need a picture: > >=20 > >=20 > > O ---- P ---- T > > ^ > >=20 > > You mark at the exit of the peering fabric with the T=20 > marking (where T=20 > > here is either the terminating network or the transit=20 > network as Tim=20 > > suggests). > >=20 > > You could mark on entrance, but then, as you suggest, you=20 > would have=20 > > O-T pairs. > > O ---- P ---- T > > ^ > >=20 > > Of course, as I pointed out, there are two sides to the exit (and=20 > > entrance). > > If the peering system does the marking, it's in scope.=20 > > O ---- P ---- T > > ^ > > If the T network does its own marking on its entrance: > > O ---- P ---- T > > ^ > > then its out of scope. > >=20 > > If it's done on entrance, than it's in scope. > > O ---- P ---- T > > ^ > > Or > > O ---- P ---- T > > ^ > >=20 > > If it's done on entrance with T's marking, then the peering fabric=20 > > can't use markings (can't implement DiffServ). As I said, this may=20 > > not be a problem. > > If it's done on entrance with P's marking, and again on=20 > exit with T's: > > O ---- P ---- T > > ^ > > P > > ^ > > T > >=20 > > then you can use diffserv in the fabric > >=20 > > Brian > >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Tuesday, April 11, 2006 5:51 PM > > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick Melampy;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Brian, > > Perhaps it is just an issue of terminology, but if an "originating"=20 > > network knows how to map from its internal marking to something=20 > > appropriate for each "peering destination network", and every other=20 > > originating network has a similar mapping for each of its peering=20 > > destination networks, then in aggregate we have a mapping for every=20 > > O-T (or O-D) pair. > >=20 > > Jim > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, April 11, 2006 3:43 PM > > > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH];=20 > > > 'Patrick Melampy'; speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > >=20 > > > Yes, well we aren't doing a good job of separating our terms, and=20 > > > transit networks are indeed a fact of life. > > >=20 > > > So, yes, I think it's the peering destination network, > > which would be > > > "next-hop" at the peering point who would have a marking policy. > > >=20 > > > We could define this away by saying it was that network who was=20 > > > responsible for marking its packets any way in wants on > > entry, rather > > > than the peering "network"'s responsibility. > > >=20 > > > I don't think we need an O-T pair; I think we need a T (or as Tim=20 > > > says, next > > > hop) policy. Every flow to that next hop gets marked the=20 > way that=20 > > > network wants it. Source doesn't matter. > > >=20 > > > IN THE PEERING FABRIC, I think it probably doesn't matter; > > I think you > > > can probably do admission control into the fabric that > > makes diffserv > > > within the fabric unnecessary. If you did want it, then > > you have to > > > remark on entrance to the fabric with the fabric's code=20 > points, and=20 > > > then remark again with the next hop network's desired codepoints. > > >=20 > > > Brian > > >=20 > > > -----Original Message----- > > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > Sent: Tuesday, April 11, 2006 12:11 PM > > > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy';=20 > > > speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > >=20 > > > Wouldn't the marking need to be per the requirements of the > > adjacent > > > network rather than the network in which the session > > terminates? We > > > are talking about L3 markings and there may be multiple=20 > L3 networks=20 > > > between O and T. > > >=20 > > > Tim > > >=20 > > >=20 > > > -----Original Message----- > > > From: James McEachern [mailto:jmce@nortel.com] > > > Sent: Tuesday, April 11, 2006 11:06 AM > > > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > >=20 > > > Comments inline. > > >=20 > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Monday, April 10, 2006 3:45 PM > > > > To: 'Patrick Melampy'; speermint@ietf.org > > > > Subject: RE: [Speermint] > > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > > peering > > > > > > > > I personally think this is way over the top for a BCP. > > > > > > > > If such things were deployed now, even experimentally,=20 > and we had=20 > > > > some good reports on complexity, stability and usefulness, then=20 > > > > maybe we could document that as "Best Current=20 > Practice". In the=20 > > > > absence of anything like it, to my knowledge, in the > > wild, I'd say > > > > let's not go there. > > > > > > > > I'm pretty certain that an objective evaluation of this > > scheme would > > > > result in a "more bandwidth is cheaper" conclusion, but=20 > since my=20 > > > > speculation isn't any more valid that yours I think we just=20 > > > > fagetabodit. > > > > > > > > Can we just stick with per T-domain marking and DiffServ? > > >=20 > > > [JMcE] If we have per T-domain marking and DiffServ, then > > presumably > > > we must have a policy that specifies the translation for each O-T=20 > > > pair. If we agree on this, then does it really matter if=20 > that "per=20 > > > O-T translation policy" > > > has > > > a single entry, an entry per media type, or multiple > > options per media > > > type? > > > If fact, once we allow for such translation, do we even need to=20 > > > specify how many options are possible? > > >=20 > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > > Sent: Saturday, April 08, 2006 10:53 AM > > > > To: speermint@ietf.org > > > > Subject: RE: [Speermint] RE: > > > > BackgroundReadingonNGNInterconnect-transitvs > > > > peering > > > > > > > > > > > > Brian, > > > > > > > > This new kind of policy driven marking thing must work across=20 > > > > network borders -- and across trust boundaries. What we > > really need > > > > to solve the routing problem is a second forwarding equivalence=20 > > > > class -- one for best efforts, and one for voice. These must be=20 > > > > advertised through > > > > BGP4 edges to effect a second routing plane. Only then > > can you solve > > > > the > > > routing problem. > > > > > > > > If this was all completed, and we could make packets route=20 > > > > differently based on service (different next-hop > > networks), we have > > > > solved a first problem. > > > > However it is unclear that we have made the internet=20 > better. Now=20 > > > > when you "ping" an address, you get a different response > > if the ToS > > > > is best efforts verses Voice. You also would have to=20 > revise ICMP=20 > > > > handling to deal with "unreachable address messages" to > > take into account the ToS. > > > > There may be many other protocol issues that occur when > > these bits > > > > are > > > not > > > set properly. > > > > > > > > I can think of one simple one. > > > > > > > > I want to establish a TCP/TLS SIPS session to a proxy.=20 > > This proxy is > > > > ONLY reachable in the ToS Voice forwarding plane.=20 > However, when I=20 > > > > use the Berkely Sockets to create the socket ... the > > syn/syn syn/ack > > > > ack three way handshake doesn't have the ToS bits set yet > > (since I > > > > can't do a SOCKOPTS until the socket is opened). Thus we > > would have > > > > to alter the ways Berkely sockets work to ensure that the > > 3way TCP > > > > handshake routes properly. > > > > > > > > These complications may be worth the salvation of honor and=20 > > > > avoidance of doing something evil like a simple NAT=20 > like SBC's do. > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, April 07, 2006 3:03 PM > > > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE:=20 > > > > Background ReadingonNGNInterconnect-transitvs peering > > > > > > > > Uh-huh, at least for a generic "everyone should do this"=20 > > kind of thing. > > > > > > > > I have no illusions that big complex carrier networks=20 > will adopt=20 > > > > anything as straightforward as -service-classes, but many more=20 > > > > focused carriers could, and profit there-by. > > > > > > > > So, I think our BCP should reference that work, but I > > believe it's > > > > not sufficient. We probably need some kind of policy driven=20 > > > > re-marking > > > thingy. > > > > > > > > What I'm not so sure about is PER FLOW decision making. =20 > > PER "T-NETWORK" > > > > is > > > > maybe doable. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > Sent: Friday, April 07, 2006 2:55 PM > > > > To: br@brianrosen.net; speermint@ietf.org > > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:=20 > > Background > > > > Reading onNGNInterconnect-transitvs peering > > > > > > > > Brian, > > > > > > > > Are you talking something like?: > > > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Friday, April 07, 2006 1:44 PM > > > > > To: speermint@ietf.org > > > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > > > > > > > I changed the subject line, at least this part of the > > thread may > > > > > be > > > > > fruitful> > > > > > > > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > > > tunnels, or any > > > > > >>other kind of links down in the router. > > > > > > > > > > > >The process of getting signaled RTP data onto these > > tunnels, and > > > > > >not the best efforts packets from the same IP=20 > address pairs, is > > > > > essential > > > > > >and in scope. > > > > > > > > > > .... > > > > > > > > > > >>This doesn't say you can't mark media packets in some way > > > > > that sends > > > > > >>them down some specific tunnels. > > > > > > > > > > >The process of doing this -- routing by packet markings -- > > > > > and how this > > > > > >will be setup on a call-by-call basis from the same=20 > IP address=20 > > > > > >pairs used for best efforts should be in scope. > > > > > > > > > > Now we may be getting somewhere. This seems like it creates=20 > > > > > requirements I might be able to deal with. > > > > > > > > > > What I'm hearing is that you think, fundamentally, that > > signaling > > > > > packets must be able to be marked differently from > > media packets. > > > > > Seems hard to argue with that. > > > > > > > > > > But I believe you want a requirement that we cover PER > > FLOW marking. > > > > > I think that might be something worth discussing. > > > > > > > > > > There are two ways we know how to do this. The right > > way (get the > > > > > origin to mark them right in the first place) and the > > expeditious > > > > > way (put an intermediary in the path and remark them). That=20 > > > > > intermediary could be an > > > > > L5/L7 entity, or it could be down in router-land using > > normal flow > > > > > identifier techniques. > > > > > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of=20 > static routing=20 > > > > > >>mechanisms > > > > > you > > > > > >>like for any set of flows you can identify. > > > > > > > > > > >Once again....how to use these static routes (which is often > > > > > why SBC's > > > > > >are used--essentially creating the head of a static route) > > > > > needs to be > > > > > >studied by this group. > > > > > Well, is this any different from the marking issue above? > > > > > What do you want the BCP to say beyond marking of packets? > > > > > What is the requirement? > > > > > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > > > > > In the best of all worlds, we would agree on the proper > > marking of > > > > > packets, all networks would mark in a uniform way,=20 > and routers=20 > > > > > would route in an optimal manner for the packets marked=20 > > > > > appropriately no matter how many domains the packets crossed. > > > > > > > > > > Dream on you say. > > > > > > > > > > I agree, but we should, probably, at least mention the ideal=20 > > > > > (which implies we actually specify what the marking > > should be). =20 > > > > > I'd expect to see signaling packets marked differently > > than media packets. > > > > > There could reasonably be different marking for > > different kinds of > > > > > media (text vs audio vs video, for example). > > > > > > > > > > Then we have to deal with the reality that marking > > within a domain > > > > > may be consistent, but in peering, the O marking won't > > be the same > > > > > as the T marking, and we need to remark at the peering edge. > > > > > > > > > > Then we could consider per-flow marking. I'm not so > > sure I want > > > > > to go there, but I'm willing to listen. > > > > > > > > > > But is there more than that? What, exactly? > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > >=20 > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 > >=20 > >=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 Thu Apr 13 14:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6ZB-00059d-P5; Thu, 13 Apr 2006 14:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6ZA-00059Y-8m for speermint@ietf.org; Thu, 13 Apr 2006 14:29:16 -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 1FU6Z9-0006ZJ-1d for speermint@ietf.org; Thu, 13 Apr 2006 14:29:16 -0400 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.18604536; Thu, 13 Apr 2006 14:28:59 -0400 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 14:28:58 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Thu, 13 Apr 2006 14:28:57 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247EA4@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAlBkFoA== From: "Livingood, Jason" To: , "Patrick Melampy" , X-OriginalArrivalTime: 13 Apr 2006 18:28:58.0745 (UTC) FILETIME=[213A7E90:01C65F28] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, April 10, 2006 3:45 PM > To: 'Patrick Melampy'; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > I personally think this is way over the top for a BCP. >=20 > If such things were deployed now, even experimentally, and we=20 > had some good reports on complexity, stability and=20 > usefulness, then maybe we could document that as "Best=20 > Current Practice". In the absence of anything like it, to my=20 > knowledge, in the wild, I'd say let's not go there. I know some of the North American MSOs have had a trial going for awhile and have gone through a few iterations. Perhaps some of them will consider submitting an I-D for the WG to understand the iterations they've evolved through and share some knowledge in a structured manner. Some of those learnings could be helpful to our work and discussions here. I'd encourage any other active trials to consider doing the same, for what its worth. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 14:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6ZQ-0005Dr-04; Thu, 13 Apr 2006 14:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6ZO-0005Dl-85 for speermint@ietf.org; Thu, 13 Apr 2006 14:29:30 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6ZN-0006a6-Ln for speermint@ietf.org; Thu, 13 Apr 2006 14:29:30 -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" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Date: Thu, 13 Apr 2006 14:28:57 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247EA5@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] RE:BackgroundReadingonNGNInterconnect-transitvs peering Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYABdeM2Q From: "Livingood, Jason" To: "James McEachern" , , , "Patrick Melampy" , X-OriginalArrivalTime: 13 Apr 2006 18:28:58.0854 (UTC) FILETIME=[214B2060:01C65F28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b 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 So are you saying that there should be some commonly agreed DSCP marking values where domains peer, and each domain is then responsible for translating those values to whatever is used (if different) inside their own network? Jason=20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Tuesday, April 11, 2006 5:51 PM > To: br@brianrosen.net; timothy.dwight@verizon.com; Patrick=20 > Melampy; speermint@ietf.org > Subject: RE: [Speermint]=20 > RE:BackgroundReadingonNGNInterconnect-transitvs peering >=20 > Brian, > Perhaps it is just an issue of terminology, but if an=20 > "originating" network knows how to map from its internal=20 > marking to something appropriate for each "peering=20 > destination network", and every other originating network has=20 > a similar mapping for each of its peering destination=20 > networks, then in aggregate we have a mapping for every O-T=20 > (or O-D) pair. >=20 > Jim >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, April 11, 2006 3:43 PM > > To: timothy.dwight@verizon.com; McEachern, James [CAR:5N00:EXCH];=20 > > 'Patrick Melampy'; speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Yes, well we aren't doing a good job of separating our terms, and=20 > > transit networks are indeed a fact of life. > >=20 > > So, yes, I think it's the peering destination network,=20 > which would be=20 > > "next-hop" at the peering point who would have a marking policy. > >=20 > > We could define this away by saying it was that network who was=20 > > responsible for marking its packets any way in wants on=20 > entry, rather=20 > > than the peering "network"'s responsibility. > >=20 > > I don't think we need an O-T pair; I think we need a T (or as Tim=20 > > says, next > > hop) policy. Every flow to that next hop gets marked the way that=20 > > network wants it. Source doesn't matter. > >=20 > > IN THE PEERING FABRIC, I think it probably doesn't matter;=20 > I think you=20 > > can probably do admission control into the fabric that=20 > makes diffserv=20 > > within the fabric unnecessary. If you did want it, then=20 > you have to=20 > > remark on entrance to the fabric with the fabric's code points, and=20 > > then remark again with the next hop network's desired codepoints. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Tim Dwight [mailto:timothy.dwight@verizon.com] > > Sent: Tuesday, April 11, 2006 12:11 PM > > To: 'James McEachern'; br@brianrosen.net; 'Patrick Melampy';=20 > > speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Wouldn't the marking need to be per the requirements of the=20 > adjacent=20 > > network rather than the network in which the session=20 > terminates? We=20 > > are talking about L3 markings and there may be multiple L3 networks=20 > > between O and T. > >=20 > > Tim > >=20 > >=20 > > -----Original Message----- > > From: James McEachern [mailto:jmce@nortel.com] > > Sent: Tuesday, April 11, 2006 11:06 AM > > To: br@brianrosen.net; Patrick Melampy; speermint@ietf.org > > Subject: RE: [Speermint]=20 > > RE:BackgroundReadingonNGNInterconnect-transitvs > > peering > >=20 > > Comments inline. > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, April 10, 2006 3:45 PM > > > To: 'Patrick Melampy'; speermint@ietf.org > > > Subject: RE: [Speermint] > > > RE:BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > I personally think this is way over the top for a BCP. > > > > > > If such things were deployed now, even experimentally, and we had=20 > > > some good reports on complexity, stability and usefulness, then=20 > > > maybe we could document that as "Best Current Practice". In the=20 > > > absence of anything like it, to my knowledge, in the=20 > wild, I'd say=20 > > > let's not go there. > > > > > > I'm pretty certain that an objective evaluation of this=20 > scheme would=20 > > > result in a "more bandwidth is cheaper" conclusion, but since my=20 > > > speculation isn't any more valid that yours I think we just=20 > > > fagetabodit. > > > > > > Can we just stick with per T-domain marking and DiffServ? > >=20 > > [JMcE] If we have per T-domain marking and DiffServ, then=20 > presumably=20 > > we must have a policy that specifies the translation for each O-T=20 > > pair. If we agree on this, then does it really matter if that "per=20 > > O-T translation policy" > > has > > a single entry, an entry per media type, or multiple=20 > options per media=20 > > type? > > If fact, once we allow for such translation, do we even need to=20 > > specify how many options are possible? > >=20 > > > > > > Brian > > > > > > -----Original Message----- > > > From: Patrick Melampy [mailto:PMelampy@acmepacket.com] > > > Sent: Saturday, April 08, 2006 10:53 AM > > > To: speermint@ietf.org > > > Subject: RE: [Speermint] RE: > > > BackgroundReadingonNGNInterconnect-transitvs > > > peering > > > > > > > > > Brian, > > > > > > This new kind of policy driven marking thing must work across=20 > > > network borders -- and across trust boundaries. What we=20 > really need=20 > > > to solve the routing problem is a second forwarding equivalence=20 > > > class -- one for best efforts, and one for voice. These must be=20 > > > advertised through > > > BGP4 edges to effect a second routing plane. Only then=20 > can you solve=20 > > > the > > routing problem. > > > > > > If this was all completed, and we could make packets route=20 > > > differently based on service (different next-hop=20 > networks), we have=20 > > > solved a first problem. > > > However it is unclear that we have made the internet better. Now=20 > > > when you "ping" an address, you get a different response=20 > if the ToS=20 > > > is best efforts verses Voice. You also would have to revise ICMP=20 > > > handling to deal with "unreachable address messages" to=20 > take into account the ToS. > > > There may be many other protocol issues that occur when=20 > these bits=20 > > > are > > not > > set properly. > > > > > > I can think of one simple one. > > > > > > I want to establish a TCP/TLS SIPS session to a proxy.=20 > This proxy is=20 > > > ONLY reachable in the ToS Voice forwarding plane. However, when I=20 > > > use the Berkely Sockets to create the socket ... the=20 > syn/syn syn/ack=20 > > > ack three way handshake doesn't have the ToS bits set yet=20 > (since I=20 > > > can't do a SOCKOPTS until the socket is opened). Thus we=20 > would have=20 > > > to alter the ways Berkely sockets work to ensure that the=20 > 3way TCP=20 > > > handshake routes properly. > > > > > > These complications may be worth the salvation of honor and=20 > > > avoidance of doing something evil like a simple NAT like SBC's do. > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 07, 2006 3:03 PM > > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > Subject: RE: Media Packet Marking, was RE: [Speermint] RE:=20 > > > Background ReadingonNGNInterconnect-transitvs peering > > > > > > Uh-huh, at least for a generic "everyone should do this"=20 > kind of thing. > > > > > > I have no illusions that big complex carrier networks will adopt=20 > > > anything as straightforward as -service-classes, but many more=20 > > > focused carriers could, and profit there-by. > > > > > > So, I think our BCP should reference that work, but I=20 > believe it's=20 > > > not sufficient. We probably need some kind of policy driven=20 > > > re-marking > > thingy. > > > > > > What I'm not so sure about is PER FLOW decision making. =20 > PER "T-NETWORK" > > > is > > > maybe doable. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Friday, April 07, 2006 2:55 PM > > > To: br@brianrosen.net; speermint@ietf.org > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE:=20 > Background=20 > > > Reading onNGNInterconnect-transitvs peering > > > > > > Brian, > > > > > > Are you talking something like?: > > > draft-ietf-tsvwg-diffserv-service-classes-02.txt > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, April 07, 2006 1:44 PM > > > > To: speermint@ietf.org > > > > Subject: RE: Media Packet Marking,was RE: [Speermint] RE: > > > > Background Reading onNGNInterconnect-transitvs peering > > > > > > > > > > > > I changed the subject line, at least this part of the=20 > thread may=20 > > > > be > > > > fruitful> > > > > > > > > > > > > >>This doesn't say you can't have VPN tunnels, or MPLS > > > > tunnels, or any > > > > >>other kind of links down in the router. > > > > > > > > > >The process of getting signaled RTP data onto these=20 > tunnels, and=20 > > > > >not the best efforts packets from the same IP address pairs, is > > > > essential > > > > >and in scope. > > > > > > > > .... > > > > > > > > >>This doesn't say you can't mark media packets in some way > > > > that sends > > > > >>them down some specific tunnels. > > > > > > > > >The process of doing this -- routing by packet markings -- > > > > and how this > > > > >will be setup on a call-by-call basis from the same IP address=20 > > > > >pairs used for best efforts should be in scope. > > > > > > > > Now we may be getting somewhere. This seems like it creates=20 > > > > requirements I might be able to deal with. > > > > > > > > What I'm hearing is that you think, fundamentally, that=20 > signaling=20 > > > > packets must be able to be marked differently from=20 > media packets. > > > > Seems hard to argue with that. > > > > > > > > But I believe you want a requirement that we cover PER=20 > FLOW marking. > > > > I think that might be something worth discussing. > > > > > > > > There are two ways we know how to do this. The right=20 > way (get the=20 > > > > origin to mark them right in the first place) and the=20 > expeditious=20 > > > > way (put an intermediary in the path and remark them). That=20 > > > > intermediary could be an > > > > L5/L7 entity, or it could be down in router-land using=20 > normal flow=20 > > > > identifier techniques. > > > > > > > > Are you looking for requirements like that? > > > > > > > > > > > > > > > > > > > > > > > > >>This doesn't say you can't create any kind of static routing=20 > > > > >>mechanisms > > > > you > > > > >>like for any set of flows you can identify. > > > > > > > > >Once again....how to use these static routes (which is often > > > > why SBC's > > > > >are used--essentially creating the head of a static route) > > > > needs to be > > > > >studied by this group. > > > > Well, is this any different from the marking issue above? > > > > What do you want the BCP to say beyond marking of packets? > > > > What is the requirement? > > > > > > > > Marking of packets is a subject worthy of discussion I think. > > > > > > > > In the best of all worlds, we would agree on the proper=20 > marking of=20 > > > > packets, all networks would mark in a uniform way, and routers=20 > > > > would route in an optimal manner for the packets marked=20 > > > > appropriately no matter how many domains the packets crossed. > > > > > > > > Dream on you say. > > > > > > > > I agree, but we should, probably, at least mention the ideal=20 > > > > (which implies we actually specify what the marking=20 > should be). =20 > > > > I'd expect to see signaling packets marked differently=20 > than media packets. > > > > There could reasonably be different marking for=20 > different kinds of=20 > > > > media (text vs audio vs video, for example). > > > > > > > > Then we have to deal with the reality that marking=20 > within a domain=20 > > > > may be consistent, but in peering, the O marking won't=20 > be the same=20 > > > > as the T marking, and we need to remark at the peering edge. > > > > > > > > Then we could consider per-flow marking. I'm not so=20 > sure I want=20 > > > > to go there, but I'm willing to listen. > > > > > > > > But is there more than that? What, exactly? > > > > > > > > Brian > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > >=20 > >=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 Thu Apr 13 14:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6mq-0003VD-Jq; Thu, 13 Apr 2006 14:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU6mp-0003Qf-JC for speermint@ietf.org; Thu, 13 Apr 2006 14:43:23 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU6mp-00072V-9G for speermint@ietf.org; Thu, 13 Apr 2006 14:43:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 11:43:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539729906:sNHT23554944" 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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 14:43:20 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE662@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAAXvb0A== From: "Reinaldo Penno" To: "Michael Hammer \(mhammer\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 a good idea Mike.=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, April 13, 2006 11:09 AM > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > To the authors of draft-penno-message-flows-00.txt, >=20 > One part of this that didn't seem quite right to me was the use of > mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain > B. (e.g., Do you intend to do some type of Contact routing?) >=20 > Could I ask by way of suggestion why you don't use mutual > Subscribe/Notify? That would require the same authentication and > authorization to the requesting domain and would likely be much richer > in terms of XML documents that could be supplied to the other domain in > a Notify. An event package per federation type could be defined, for > example. >=20 > What do you think? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Thursday, April 13, 2006 12:55 PM > > To: 'Reinaldo Penno'; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > The call flows shown are pretty much as would be expected > > from the trapezoid model in RFC 3261 using well defined SIP > > proxy behavior (lengthy section in RFC 3261). > > > > Why use B2BUA that have no defined behavior at all? > > > > Is it possible to standardize undefined behavior? > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, April 12, 2006 3:27 PM > > To: speermint@ietf.org > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > Hello, > > > > We wrote a draft to help frame our discussions. > > > > Thanks, > > > > Reinaldo > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : SPEERMINT Routing Architecture Message Flows > > Author(s) : R. Penno, et al. > > Filename : draft-penno-message-flows-00.txt > > Pages : 19 > > Date : 2006-4-12 > > > > This draft describes the message flows associated with the > > SPEERMINT routing architecture. We show message flows in > > several peering scenarios. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > _______________________________________________ > > 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 Apr 13 18:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9uJ-0001zV-Sv; Thu, 13 Apr 2006 18:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9uH-0001zM-Q6 for speermint@ietf.org; Thu, 13 Apr 2006 18:03:17 -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 1FU9uH-0005JR-CU for speermint@ietf.org; Thu, 13 Apr 2006 18:03:17 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k3DM3DaK018984; Thu, 13 Apr 2006 22:03:13 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id EADC0124855; Thu, 13 Apr 2006 22:03:12 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 8910C12484B; Thu, 13 Apr 2006 22:03:12 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Apr 2006 16:03:10 -0600 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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 16:03:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAACC3SgA== From: "Malas, Daryl" To: "Michael Hammer (mhammer)" , , "Reinaldo Penno" , X-OriginalArrivalTime: 13 Apr 2006 22:03:10.0836 (UTC) FILETIME=[0DABF340:01C65F46] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Comments in-line... Daryl M. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Thursday, April 13, 2006 12:09 PM To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 To the authors of draft-penno-message-flows-00.txt, One part of this that didn't seem quite right to me was the use of mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain B. (e.g., Do you intend to do some type of Contact routing?) [Daryl] Contact routing wasn't my primary reason for doing this, but I did think of that as an option. You could specify NPA-NXX or similar you are providing routes to as a peering entity. Also, this would allow a method for dynamically updating supported peering routes if you were not using a common routing location server. I certainly do not think exchanging telephony routes is an efficient or even realistic method for some peering architectures, but if I wanted to peer with another operator and only provide routing for a certain block of numbers...it may be an acceptable method. Obviously, I may want to do a LNP query to make sure the TN hasn't been ported away from my peer before I route to them, but it could work for 10k blocks, etc.. Could I ask by way of suggestion why you don't use mutual Subscribe/Notify? That would require the same authentication and authorization to the requesting domain and would likely be much richer in terms of XML documents that could be supplied to the other domain in a Notify. An event package per federation type could be defined, for example. [Daryl] I think this is an interesting idea, and I am still chewing on it. I am trying to evaluate the positives and negatives for accomplishing it with either method or a combination of both based on architecture. Thanks for the input. What do you think? Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com]=20 > Sent: Thursday, April 13, 2006 12:55 PM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > The call flows shown are pretty much as would be expected=20 > from the trapezoid model in RFC 3261 using well defined SIP=20 > proxy behavior (lengthy section in RFC 3261). >=20 > Why use B2BUA that have no defined behavior at all? >=20 > Is it possible to standardize undefined behavior? >=20 > Thanks, Henry >=20 > =20 >=20 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 3:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > Hello, >=20 > We wrote a draft to help frame our discussions.=20 >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : SPEERMINT Routing Architecture Message Flows =20 > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 > =09 > This draft describes the message flows associated with the=20 > SPEERMINT routing architecture. We show message flows in=20 > several peering scenarios. =20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt >=20 >=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 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 18:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUAYf-0000pZ-QM; Thu, 13 Apr 2006 18:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUAYe-0000pR-QX for speermint@ietf.org; Thu, 13 Apr 2006 18:45:00 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUAYc-00071V-FZ for speermint@ietf.org; Thu, 13 Apr 2006 18:44:58 -0400 Received: (qmail 28972 invoked by uid 510); 13 Apr 2006 19:31:19 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.114.230):. Processed in 1.352391 secs); 13 Apr 2006 23:31:19 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.114.230):. Processed in 1.352391 secs Process 28962) Received: from unknown (HELO 1AB764895C324D3) (henry@pulver.com@67.187.114.230) by 192.246.69.184 with SMTP; Thu, 13 Apr 2006 23:31:17 +0000 From: "Henry Sinnreich" To: "'Reinaldo Penno'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 17:44:50 -0500 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <9BD5D7887235424FA97DFC223CAE3C2802DFE65C@proton.jnpr.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAIAiXAACfNUAA== X-Antivirus-MYDOMAIN-Message-ID: <114497107783528962@mail.pulver.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com 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 Message-Id: Reinaldo, >I believe there are some specific functions that a B2BUA could do in >peering scenarios. You are right. Specific functions like media relay are OK. I would also suggest to put this in the framework of BEHAVE, STUN, TURN, ICE, Outbound, etc. This will give designers a set of clear option what solution to choose, when is media a relay required, etc. Such guidelines would be very useful. Thanks, Henry -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net] Sent: Thursday, April 13, 2006 1:01 PM To: henry@pulver.com; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Hello henry, > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Thursday, April 13, 2006 9:55 AM > To: Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > The call flows shown are pretty much as would be expected from the > trapezoid > model in RFC 3261 using well defined SIP proxy behavior (lengthy section > in > RFC 3261). [[Reinaldo]] You are right. At some point in the list there was this big discussion on what we would need "besides" the current established RFCs, and if anything, what. The purpose of those sections is to show some call flows in peering scenarios and based on those ask the questions: 1) Do we need anything else? If we need, what would it be? 2) Is it SIP specific or more related to DNS? > > Why use B2BUA that have no defined behavior at all? [[Reinaldo]] On one hand I agree that B2BUA have no defined behavior (actually you and me discussed this in the past in the sip-implementors mailing list). On the other hand I do not want to take the "IPV6 will take over the world and NAT is evil and will disappear" similar stance. I'm taking the moderate approach here. I believe there are some specific functions that a B2BUA could do in peering scenarios. Can it be done some other way through clever network rollouts, NAT traversal, IPv6 etc? Sure it can, and I mention that...But real networks do not work like that. > > Is it possible to standardize undefined behavior? [[Reinaldo]] That would be a difficult proposition, yes. Instead of mentioning SBC/B2BUA all over, I tried to concentrate on media relay, which is a function we might need, vis a vis: 1) How to get media to the peering point. 2) Private addresses when a NAT traversal cannot be used 3) Some media functions such as translation, quality measurement, etc I will rework some of the portions to make more specific on the functions and needs to B2BUA. Maybe a couple of scenarios that combine private address and media relay (when media would not normally make to the peering point through layer 3 routing). Thanks, Reinaldo > > Thanks, Henry > > > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 3:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > Hello, > > We wrote a draft to help frame our discussions. > > Thanks, > > Reinaldo > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SPEERMINT Routing Architecture Message Flows > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 > > This draft describes the message flows associated with the SPEERMINT > routing architecture. We show message flows in several peering > scenarios. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 21:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCqS-0003a3-Uh; Thu, 13 Apr 2006 21:11:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCq5-00039g-Lj for speermint@ietf.org; Thu, 13 Apr 2006 21:11:09 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUCk3-0003O1-Jb for speermint@ietf.org; Thu, 13 Apr 2006 21:04:55 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A531041C; Thu, 13 Apr 2006 21:04:49 -0400 From: "Hadriel Kaplan" To: "'Malas, Daryl'" , "'Uzelac, Adam'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Thu, 13 Apr 2006 21:05:00 -0400 Message-ID: <037e01c65f5f$747a9400$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAC/RafQAGqczyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d 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, Are you referring to my comment? I was saying a redirect-proxy S is logically similar to O using a lookup function to a lookup database L. The line wasn't meant as a uni-directional path, but as a logical bi-directional one. For a redirect, yes I assumed a 3xx to an invite. It's effectively a location lookup function, although obviously the L node makes the lookup "decision" so to speak, and can do so based on its local policies, rather than having O implement a lookup function based on returned policies. But then one could also implement a DNS box to return different responses based on its internal policies as well (though it would be much more cumbersome for it to do so without other information that's in the Invite). I agree with Adam that if it's not a redirect-node in the middle, then it's the O-S-L triangle. (or it could be a straight line for signaling if S is a stateful proxy, or b2bua) The advantages of S being stateful is it can perform policies based on full session knowledge (e.g., session load capacity of T), among other things. -hadriel > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 11, 2006 6:06 PM > To: Hadriel Kaplan; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I just want to make sure I understand your statement below... > > If a redirect proxy is used, the call flow will look more like this: > > L (or S) > // > O---T > > Not this: > > > S > /\ > O--T > > FYI...when I think of redirect proxy, I think of a proxy that issues a > 3XX message to O in response to an INVITE. Are you speaking of it more > generically? > > --Daryl M. > > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:10 PM > To: 'Uzelac, Adam'; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Ahh, yes I see - I thought you were talking about redirect. > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:35 PM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > > > I can't agree in a proxied(non-redirect) call flow. Also, there may > be > > a requirement to determine which T-Network to term the call to should > > there be more than one. There could be a subsequent T-Network proxy > > involved. So the call would be signaled from O-Network to S-Network, > > and then maybe S-Network to T-Network to determine ultimate T-Network > > end point. > > > > Adam Uzelac > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Friday, April 07, 2006 9:59 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > > > Hi Adam, > > > > If S is doing a redirect/proxy, isn't it just the location lookup > > mechanism for O--T? (a trusted+shared location-lookup) > > > > So there's really just: > > L > > / > > O---T. > > > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > > Sent: Friday, April 07, 2006 10:37 AM > > > To: speermint@ietf.org > > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > > > I have gnawed on the latest series of threads, and while wadding > > > through the noise and rhetoric, it appears to me that there are 2 > > > basic constructs for SIP peering. Subscribing to Brian's notion > that > > > we must try to keep this simple - at least at this stage - it seems > to > > > > > boil down to the following: (I acknowledge that there may be > > > contextual > > > variations) > > > > > > Option A) Session routing by 3rd party. > > > > > > S > > > /\ > > > O--T > > > > > > In this model, O-Network queries S-Network (signaling) for routing > > > options. S-Network redirects or proxies signaling request to > > T-network. > > > There is an assumption that L3 connectivity exists between all > three, > > > though S-Network would not be transit for media, but possible for > > > signaling. The media flows directly from O-Network to T-Network. > > > > > > Option B) Direct bi-lateral routing. > > > > > > O--T > > > > > > In this model, O-Network signals T-Network directly, and receives > > > routing instructions. Media would follow the same relationship, > maybe > > > > > not the same path, but same bi-lateral relationship. Should there > be > > > more than one L3 peering point, any peering point may be used, but > it > > > all follows the same contextual relationship between O-Network and > > > T-Network. > > > > > > I find it possible to apply either Option A or Option B to public, > > > private, and even carrier (even carrier pigeon) environments. Maybe > I > > > > > am pointing out the obvious, but that's OK as I have been often > > > accused of being master of the obvious. ;) > > > > > > Adam Uzelac > > > > > > _______________________________________________ > > > 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 Apr 13 21:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCvM-0005Tc-LR; Thu, 13 Apr 2006 21:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCvL-0005SV-RJ for speermint@ietf.org; Thu, 13 Apr 2006 21:16:35 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUCvJ-0003lo-Hk for speermint@ietf.org; Thu, 13 Apr 2006 21:16:33 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A7EF06E8; Thu, 13 Apr 2006 21:16:31 -0400 From: "Hadriel Kaplan" To: "'Uzelac, Adam'" , "'Stastny Richard'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Thu, 13 Apr 2006 21:16:42 -0400 Message-ID: <037f01c65f61$170ef340$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAAN1gzgALbU39AAZZqHYA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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, comments inline... > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Saturday, April 08, 2006 5:41 AM > > Another task may be to translate personal URIs or enterprise AoRs > hosted by a SP to the ingress proxy of the SP e.g. > Sip:bill@microsoft.co.uk -> sip:bill@ms.bt.com > > [adam] I don't know if this task would be a requirement or not. Might > be up to the implementor to determine, but to me this doesn't have > anything to do with routing of the session. I think what Richard meant, or at least I think is a problem, is if bi-lateral peering agreements are needed, then it's very difficult to imagine every provider having one with every other one. I would assume a tiered/chained model would occur, whereby some enterprises or small providers would only be reachable through a set of providers they have relationships with. If that's true, then there would probably be a chain of such providers that would need to be transited to reach the final destination. So if a provider wants to send a session to the final one, it has to figure out how to reach it, and it can't just be one DNS lookup, or even a lookup that results in "use this federation to reach me". It could be a lookup of the final target's domain that results in a "use federation X", and then a lookup of X that results in "use Y" and so on until a federation directly reachable by O is found. Someone had a draft on this into spearmint I think. It's not very optimal on a call-by-call basis, but the only other alternative is to use TRIP I think. (which had that model down pat, since it included accumulated costs as well) Even handing the call off to an S domain to figure out will only work if S has such knowledge itself. And that's essentially the same problem faced by O if it doesn't use an S. -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 13 21:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCyl-0007xg-6n; Thu, 13 Apr 2006 21:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUCyj-0007xb-R6 for speermint@ietf.org; Thu, 13 Apr 2006 21:20:05 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUCyj-0003vN-F9 for speermint@ietf.org; Thu, 13 Apr 2006 21:20:05 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A8C3055C; Thu, 13 Apr 2006 21:20:03 -0400 From: "Hadriel Kaplan" To: "'Uzelac, Adam'" , "'Malas, Daryl'" , Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering Date: Thu, 13 Apr 2006 21:20:14 -0400 Message-ID: <038001c65f61$9556d4c0$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZaULId4h1QjJbXQAGpqQ7foOqK/wAROLzwAAetQHAAAJG9kAC/RafQACGjUtAAScIdgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 Agreed, but if S doesn't have that direct knowledge of how to reach T, or if O has multiple S's, then they're either hunting which takes too long, or forking which could create big virtual broadcasts across a web of middle-providers. -hadriel > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, April 12, 2006 10:20 AM > To: Malas, Daryl; Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I am thinking more generically. When considering 300 Multiple Choices, > O-Network proxy would query S/L-Network proxy, and S/L-Network Proxy > _may_ need to communicate with any number of potential T-Networks that > may be able to eligible to term the session to the ultimate T-Network > where called UA resides. With that said, we are speaking that both > constructs are valid. Redirect blind, and Redirect with some forwarding > resolution activity. > > Adam > > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Tuesday, April 11, 2006 6:06 PM > To: Hadriel Kaplan; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > I just want to make sure I understand your statement below... > > If a redirect proxy is used, the call flow will look more like this: > > L (or S) > // > O---T > > Not this: > > > S > / \ > O---T > > FYI...when I think of redirect proxy, I think of a proxy that issues a > 3XX message to O in response to an INVITE. Are you speaking of it more > generically? > > --Daryl M. > > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 07, 2006 9:10 PM > To: 'Uzelac, Adam'; speermint@ietf.org > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > Ahh, yes I see - I thought you were talking about redirect. > -hadriel > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Friday, April 07, 2006 10:35 PM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > > > I can't agree in a proxied(non-redirect) call flow. Also, there may > be > > a requirement to determine which T-Network to term the call to should > > there be more than one. There could be a subsequent T-Network proxy > > involved. So the call would be signaled from O-Network to S-Network, > > and then maybe S-Network to T-Network to determine ultimate T-Network > > end point. > > > > Adam Uzelac > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Friday, April 07, 2006 9:59 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] 2 Basic Constructs for SIP Peering > > > > Hi Adam, > > > > If S is doing a redirect/proxy, isn't it just the location lookup > > mechanism for O--T? (a trusted+shared location-lookup) > > > > So there's really just: > > L > > / > > O---T. > > > > Whereby L is "lookup" - could be DNS, SIP, SQL, LRQ... :) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > > Sent: Friday, April 07, 2006 10:37 AM > > > To: speermint@ietf.org > > > Subject: [Speermint] 2 Basic Constructs for SIP Peering > > > > > > I have gnawed on the latest series of threads, and while wadding > > > through the noise and rhetoric, it appears to me that there are 2 > > > basic constructs for SIP peering. Subscribing to Brian's notion > that > > > we must try to keep this simple - at least at this stage - it seems > to > > > > > boil down to the following: (I acknowledge that there may be > > > contextual > > > variations) > > > > > > Option A) Session routing by 3rd party. > > > > > > S > > > /\ > > > O--T > > > > > > In this model, O-Network queries S-Network (signaling) for routing > > > options. S-Network redirects or proxies signaling request to > > T-network. > > > There is an assumption that L3 connectivity exists between all > three, > > > though S-Network would not be transit for media, but possible for > > > signaling. The media flows directly from O-Network to T-Network. > > > > > > Option B) Direct bi-lateral routing. > > > > > > O--T > > > > > > In this model, O-Network signals T-Network directly, and receives > > > routing instructions. Media would follow the same relationship, > maybe > > > > > not the same path, but same bi-lateral relationship. Should there > be > > > more than one L3 peering point, any peering point may be used, but > it > > > all follows the same contextual relationship between O-Network and > > > T-Network. > > > > > > I find it possible to apply either Option A or Option B to public, > > > private, and even carrier (even carrier pigeon) environments. Maybe > I > > > > > am pointing out the obvious, but that's OK as I have been often > > > accused of being master of the obvious. ;) > > > > > > Adam Uzelac > > > > > > _______________________________________________ > > > 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 Apr 13 22:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUE6D-0006HG-2x; Thu, 13 Apr 2006 22:31:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUE6B-0006HB-L1 for speermint@ietf.org; Thu, 13 Apr 2006 22:31:51 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUE69-0006lC-9y for speermint@ietf.org; Thu, 13 Apr 2006 22:31:49 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A99306D0; Thu, 13 Apr 2006 22:31:47 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 22:31:58 -0400 Message-ID: <038101c65f6b$9aa6a630$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301570445@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 was confused by the registration as well but it must be for different reasons because doing subscribe/notify doesn't solve my confusion. :) It has benefits for other things, and was what I was assuming would be used for some policy exchanges ultimately, but not the piece I was confused with this draft. In the draft it says it's used for mutual proxy authentication. For a typical register challenge method to do that, they have to have shared/known passwords and usernames. (are we assuming that?) If a "key" is exchanged in the register to be used as the password, as shown in the draft I think, it does nothing; a man-in-the-middle has a view of those keys and can use them, and there's no authentication scheme for one proxy to believe the key of the other anyway. (unless "key" means a nonce?) Regardless, why not just use mutually-authenticated TLS? The details of how to believe the certs of each side though are still being discussed in the sip mailing list I think. (I haven't been following it) -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, April 13, 2006 2:09 PM > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > To the authors of draft-penno-message-flows-00.txt, > > One part of this that didn't seem quite right to me was the use of > mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain > B. (e.g., Do you intend to do some type of Contact routing?) > > Could I ask by way of suggestion why you don't use mutual > Subscribe/Notify? That would require the same authentication and > authorization to the requesting domain and would likely be much richer > in terms of XML documents that could be supplied to the other domain in > a Notify. An event package per federation type could be defined, for > example. > > What do you think? > > Mike > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Thursday, April 13, 2006 12:55 PM > > To: 'Reinaldo Penno'; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > The call flows shown are pretty much as would be expected > > from the trapezoid model in RFC 3261 using well defined SIP > > proxy behavior (lengthy section in RFC 3261). > > > > Why use B2BUA that have no defined behavior at all? > > > > Is it possible to standardize undefined behavior? > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, April 12, 2006 3:27 PM > > To: speermint@ietf.org > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > Hello, > > > > We wrote a draft to help frame our discussions. > > > > Thanks, > > > > Reinaldo > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : SPEERMINT Routing Architecture Message Flows > > Author(s) : R. Penno, et al. > > Filename : draft-penno-message-flows-00.txt > > Pages : 19 > > Date : 2006-4-12 > > > > This draft describes the message flows associated with the > > SPEERMINT routing architecture. We show message flows in > > several peering scenarios. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > _______________________________________________ > > 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 Apr 13 22:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUELn-0007ni-1e; Thu, 13 Apr 2006 22:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUELl-0007ld-FO for speermint@ietf.org; Thu, 13 Apr 2006 22:47:57 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUELi-0006yq-TR for speermint@ietf.org; Thu, 13 Apr 2006 22:47:57 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 19:44:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,119,1144047600"; d="scan'208"; a="539827788:sNHT25782820" 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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 22:44:50 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE66E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+A From: "Reinaldo Penno" To: "Hadriel Kaplan" , "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 believe it would be similar to what is described in the document sent by Shockey to the list. Pasted below 10.1.2 Option 2: Digest Access Authentication The second method of authenticating an Enterprise utilizes the digest authentication scheme as described in section 22.4 of RFC 3261 [8]. In this model the Service Provider assigns the Enterprise Network a username and password (referred to as a "Network Account" hereafter) that is valid within the Service Provider's domain (realm). It is important to note that if the digest authentication scheme is employed, it does not eliminate the requirement to utilize TLS between the Service Provider and Enterprise Network SIP Proxy Servers. When this model is employed, the following rules must be observed: 1. When processing an INVITE request from an unauthenticated PBX, the SIP Application Server MUST challenge the message, only accepting authentication credentials that are valid within its realm. 2. When processing a REGISTER request from an unauthenticated PBX, the SIP Application Server MUST challenge the message, only accepting authentication credentials that are valid within its realm. 3. When challenged by the SIP Application Server, the PBX MUST respond with authentication credentials that are valid within the Service Provider's realm (i.e. the network account username and password supplied by the Service Provider). 4. In order to avoid unnecessary challenges, the PBX SHOULD include its authentication credentials using the current nonce in each request sent to the SIP Application Server. Finally, as with any peering "endeavour" I believe there will always be the casethat they have physical/co-location security so TLS is not needed. Regards, reinaldo > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Thursday, April 13, 2006 7:32 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > I was confused by the registration as well but it must be for different > reasons because doing subscribe/notify doesn't solve my confusion. :) It > has benefits for other things, and was what I was assuming would be used > for > some policy exchanges ultimately, but not the piece I was confused with > this > draft. >=20 > In the draft it says it's used for mutual proxy authentication. For a > typical register challenge method to do that, they have to have > shared/known > passwords and usernames. (are we assuming that?) If a "key" is exchanged > in > the register to be used as the password, as shown in the draft I think, it > does nothing; a man-in-the-middle has a view of those keys and can use > them, > and there's no authentication scheme for one proxy to believe the key of > the > other anyway. (unless "key" means a nonce?) >=20 > Regardless, why not just use mutually-authenticated TLS? The details of > how > to believe the certs of each side though are still being discussed in the > sip mailing list I think. (I haven't been following it) >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, April 13, 2006 2:09 PM > > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > To the authors of draft-penno-message-flows-00.txt, > > > > One part of this that didn't seem quite right to me was the use of > > mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain > > B. (e.g., Do you intend to do some type of Contact routing?) > > > > Could I ask by way of suggestion why you don't use mutual > > Subscribe/Notify? That would require the same authentication and > > authorization to the requesting domain and would likely be much richer > > in terms of XML documents that could be supplied to the other domain in > > a Notify. An event package per federation type could be defined, for > > example. > > > > What do you think? > > > > Mike > > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Thursday, April 13, 2006 12:55 PM > > > To: 'Reinaldo Penno'; speermint@ietf.org > > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > > > The call flows shown are pretty much as would be expected > > > from the trapezoid model in RFC 3261 using well defined SIP > > > proxy behavior (lengthy section in RFC 3261). > > > > > > Why use B2BUA that have no defined behavior at all? > > > > > > Is it possible to standardize undefined behavior? > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Wednesday, April 12, 2006 3:27 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > > > Hello, > > > > > > We wrote a draft to help frame our discussions. > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : SPEERMINT Routing Architecture Message Flows > > > Author(s) : R. Penno, et al. > > > Filename : draft-penno-message-flows-00.txt > > > Pages : 19 > > > Date : 2006-4-12 > > > > > > This draft describes the message flows associated with the > > > SPEERMINT routing architecture. We show message flows in > > > several peering scenarios. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > > > > > > _______________________________________________ > > > 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 >=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 Apr 13 22:52:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUEPn-0001WR-5g; Thu, 13 Apr 2006 22:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUEPm-0001WM-8J for speermint@ietf.org; Thu, 13 Apr 2006 22:52:06 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUEPm-00072l-0V for speermint@ietf.org; Thu, 13 Apr 2006 22:52:06 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 22:52:04 -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] SPEERMINT Routing Architecture Message Flows Date: Thu, 13 Apr 2006 22:52:06 -0400 Message-ID: <8812D8156467224C9E9739E513037EF15EF5CC@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows thread-index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AA/o2rA From: "Medhavi Bhatia" To: "Reinaldo Penno" , X-OriginalArrivalTime: 14 Apr 2006 02:52:04.0979 (UTC) FILETIME=[69A04430:01C65F6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 like the requirements aspect in the draft (sections 5, 6) My suggestion is to separate requirements into a separate draft so that they can be dealt w/ separately. The message flows lie somewhere in the middle of reality and fiction and the fictitious ones should probably wait :) -Medhavi. > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 4:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > Hello, >=20 > We wrote a draft to help frame our discussions. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : SPEERMINT Routing Architecture Message Flows > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 >=20 > This draft describes the message flows associated with the SPEERMINT > routing architecture. We show message flows in several peering > scenarios. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at 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. >=20 >=20 > 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-penno-message-flows-00.txt". >=20 > 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 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 4/11/2006 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 00:21:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUFne-0007Vp-RQ; Fri, 14 Apr 2006 00:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUFnd-0007Ve-J7 for speermint@ietf.org; Fri, 14 Apr 2006 00:20:49 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUFnc-00013q-1k for speermint@ietf.org; Fri, 14 Apr 2006 00:20:49 -0400 Received: from HKaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.02) id A31D072C; Fri, 14 Apr 2006 00:20:45 -0400 From: "Hadriel Kaplan" To: "'Reinaldo Penno'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 00:20:55 -0400 Message-ID: <038601c65f7a$d375cf40$0a01a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+AAAKNq6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE66E@proton.jnpr.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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 Ahh, so the "key" in the draft is a nonce then? The sip-connect model assumed the enterprise would be given the password/username by the provider servicing it. That would be possible for the static peer-to-peer connection, but you could just as easily challenge the first invite in that case, and not "register" anything. For the dynamic connect model it would be impractical to have configured pass/user info per potential peer wouldn't it? (I don't know, just assuming) Wouldn't it be cleaner to just have it check the SAN of the cert matches a rule for previous/next-peer domain authorization? If they have physical/co-location "security" then why bother with proxy-proxy authentication for that case? I would think you'd only need it for insecure peering links, where spoofing, mitm, and such can occur. -hadriel > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, April 13, 2006 10:45 PM > To: Hadriel Kaplan; Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > I believe it would be similar to what is described in the document sent > by Shockey to the list. Pasted below > > 10.1.2 Option 2: Digest Access Authentication > The second method of authenticating an Enterprise utilizes the digest > authentication scheme as described in section 22.4 > of RFC 3261 [8]. In this model the Service Provider assigns the > Enterprise Network a username and password (referred to > as a "Network Account" hereafter) that is valid within the Service > Provider's domain (realm). It is important to note that if > the digest authentication scheme is employed, it does not eliminate the > requirement to utilize TLS between the Service > Provider and Enterprise Network SIP Proxy Servers. > When this model is employed, the following rules must be observed: > 1. When processing an INVITE request from an unauthenticated PBX, the > SIP Application Server MUST challenge > the message, only accepting authentication credentials that are valid > within its realm. > 2. When processing a REGISTER request from an unauthenticated PBX, the > SIP Application Server MUST > challenge the message, only accepting authentication credentials that > are valid within its realm. > 3. When challenged by the SIP Application Server, the PBX MUST respond > with authentication credentials that are > valid within the Service Provider's realm (i.e. the network account > username and password supplied by the > Service Provider). > 4. In order to avoid unnecessary challenges, the PBX SHOULD include its > authentication credentials using the > current nonce in each request sent to the SIP Application Server. > > > Finally, as with any peering "endeavour" I believe there will always be > the casethat they have physical/co-location security so TLS is not > needed. > > > Regards, > > reinaldo > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Thursday, April 13, 2006 7:32 PM > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > I was confused by the registration as well but it must be for > different > > reasons because doing subscribe/notify doesn't solve my confusion. :) > It > > has benefits for other things, and was what I was assuming would be > used > > for > > some policy exchanges ultimately, but not the piece I was confused > with > > this > > draft. > > > > In the draft it says it's used for mutual proxy authentication. For a > > typical register challenge method to do that, they have to have > > shared/known > > passwords and usernames. (are we assuming that?) If a "key" is > exchanged > > in > > the register to be used as the password, as shown in the draft I > think, it > > does nothing; a man-in-the-middle has a view of those keys and can use > > them, > > and there's no authentication scheme for one proxy to believe the key > of > > the > > other anyway. (unless "key" means a nonce?) > > > > Regardless, why not just use mutually-authenticated TLS? The details > of > > how > > to believe the certs of each side though are still being discussed in > the > > sip mailing list I think. (I haven't been following it) > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Thursday, April 13, 2006 2:09 PM > > > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message > Flows > > > > > > To the authors of draft-penno-message-flows-00.txt, > > > > > > One part of this that didn't seem quite right to me was the use of > > > mutual Registrations between Proxy 1 or domain A and Proxy 2 of > domain > > > B. (e.g., Do you intend to do some type of Contact routing?) > > > > > > Could I ask by way of suggestion why you don't use mutual > > > Subscribe/Notify? That would require the same authentication and > > > authorization to the requesting domain and would likely be much > richer > > > in terms of XML documents that could be supplied to the other domain > in > > > a Notify. An event package per federation type could be defined, > for > > > example. > > > > > > What do you think? > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > > Sent: Thursday, April 13, 2006 12:55 PM > > > > To: 'Reinaldo Penno'; speermint@ietf.org > > > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message > Flows > > > > > > > > The call flows shown are pretty much as would be expected > > > > from the trapezoid model in RFC 3261 using well defined SIP > > > > proxy behavior (lengthy section in RFC 3261). > > > > > > > > Why use B2BUA that have no defined behavior at all? > > > > > > > > Is it possible to standardize undefined behavior? > > > > > > > > Thanks, Henry > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > > Sent: Wednesday, April 12, 2006 3:27 PM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > > > > > Hello, > > > > > > > > We wrote a draft to help frame our discussions. > > > > > > > > Thanks, > > > > > > > > Reinaldo > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > > > > > > > > > Title : SPEERMINT Routing Architecture Message Flows > > > > Author(s) : R. Penno, et al. > > > > Filename : draft-penno-message-flows-00.txt > > > > Pages : 19 > > > > Date : 2006-4-12 > > > > > > > > This draft describes the message flows associated with the > > > > SPEERMINT routing architecture. We show message flows in > > > > several peering scenarios. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Fri Apr 14 02:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIFF-0000fC-UW; Fri, 14 Apr 2006 02:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIFF-0000f6-6k for speermint@ietf.org; Fri, 14 Apr 2006 02:57:29 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUIFA-0006CP-Uy for speermint@ietf.org; Fri, 14 Apr 2006 02:57:29 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 23:57:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,119,1144047600"; d="scan'208"; a="539868485:sNHT21092284" 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 Date: Fri, 14 Apr 2006 02:57:22 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE670@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPEERMINT routing flows v. 01 Thread-Index: AcZfkK3TwC0sJRhySvyHfftEXFNQHw== From: "Reinaldo Penno" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Speermint] SPEERMINT routing flows v. 01 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 updated this draft before the recent suggestions on the list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-penno-message-flows-01.txt The next version (02) will include: * Discussion on SUBCRIBE/NOTIFY as a way to authenticate and provide policies (as opposed to DNS) * Scenario with Media Relay and private addresses. * More detailed discussion on the mutual authentication with REGISTER * More in-depth QoS discussion (in respect to call routing) and accounting. * Some discussion on transit networks. Thanks for all comments/suggestions. Keep them coming. Reinaldo _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 04:25:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJbz-0005or-FZ; Fri, 14 Apr 2006 04:25:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJbx-0005ol-Pm for speermint@ietf.org; Fri, 14 Apr 2006 04:25:02 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUJbx-0000eD-69 for speermint@ietf.org; Fri, 14 Apr 2006 04:25:01 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 10:27:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C498A@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAACC3SgAAWFR4+ From: "Stastny Richard" To: "Malas, Daryl" , "Michael Hammer \(mhammer\)" , , "Reinaldo Penno" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Daryl] Contact routing wasn't my primary reason for doing this, but I did think of that as an option. You could specify NPA-NXX or similar you are providing routes to as a peering entity. Also, this would allow a method for dynamically updating supported peering routes if you were not using a common routing location server. I certainly do not think exchanging telephony routes is an efficient or even realistic method for some peering architectures, but if I wanted to peer with another operator and only provide routing for a certain block of numbers...it may be an acceptable method. Obviously, I may want to do a LNP query to make sure the TN hasn't been ported away from my peer before I route to them, but it could work for 10k blocks, etc.. [Richard]=20 IMHO the whole issue is completely out of scope in speermint =20 Richard ________________________________ Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] Gesendet: Fr 14.04.2006 00:03 An: Michael Hammer (mhammer); henry@pulver.com; Reinaldo Penno; = speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 Comments in-line... Daryl M. -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Thursday, April 13, 2006 12:09 PM To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows To the authors of draft-penno-message-flows-00.txt, One part of this that didn't seem quite right to me was the use of mutual Registrations between Proxy 1 or domain A and Proxy 2 of domain B. (e.g., Do you intend to do some type of Contact routing?) [Daryl] Contact routing wasn't my primary reason for doing this, but I did think of that as an option. You could specify NPA-NXX or similar you are providing routes to as a peering entity. Also, this would allow a method for dynamically updating supported peering routes if you were not using a common routing location server. I certainly do not think exchanging telephony routes is an efficient or even realistic method for some peering architectures, but if I wanted to peer with another operator and only provide routing for a certain block of numbers...it may be an acceptable method. Obviously, I may want to do a LNP query to make sure the TN hasn't been ported away from my peer before I route to them, but it could work for 10k blocks, etc.. Could I ask by way of suggestion why you don't use mutual Subscribe/Notify? That would require the same authentication and authorization to the requesting domain and would likely be much richer in terms of XML documents that could be supplied to the other domain in a Notify. An event package per federation type could be defined, for example. [Daryl] I think this is an interesting idea, and I am still chewing on it. I am trying to evaluate the positives and negatives for accomplishing it with either method or a combination of both based on architecture. Thanks for the input. What do you think? Mike > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Thursday, April 13, 2006 12:55 PM > To: 'Reinaldo Penno'; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > The call flows shown are pretty much as would be expected > from the trapezoid model in RFC 3261 using well defined SIP > proxy behavior (lengthy section in RFC 3261). > > Why use B2BUA that have no defined behavior at all? > > Is it possible to standardize undefined behavior? > > Thanks, Henry > >=20 > > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, April 12, 2006 3:27 PM > To: speermint@ietf.org > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > Hello, > > We wrote a draft to help frame our discussions. > > Thanks, > > Reinaldo > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : SPEERMINT Routing Architecture Message Flows=20 > Author(s) : R. Penno, et al. > Filename : draft-penno-message-flows-00.txt > Pages : 19 > Date : 2006-4-12 > =20 > This draft describes the message flows associated with the > SPEERMINT routing architecture. We show message flows in > several peering scenarios.=20 > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > _______________________________________________ > 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 Fri Apr 14 05:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKE0-0003I5-Qu; Fri, 14 Apr 2006 05:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUKDz-0003I0-KB for speermint@ietf.org; Fri, 14 Apr 2006 05:04: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 1FUKDw-0001tr-B8 for speermint@ietf.org; Fri, 14 Apr 2006 05:04:17 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 7066E1A529; Fri, 14 Apr 2006 11:04:14 +0200 (CEST) Date: Fri, 14 Apr 2006 11:04:14 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Message-ID: <20060414090414.GA1811@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: de4f315c9369b71d7dd5909b42224370 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/04/14 00:04, "Malas, Daryl" wrote: > > Contact routing wasn't my primary reason for doing this, but I > did think of that as an option. You could specify NPA-NXX or similar > you are providing routes to as a peering entity. Also, this would allow > a method for dynamically updating supported peering routes if you were > not using a common routing location server. I certainly do not think > exchanging telephony routes is an efficient or even realistic method for > some peering architectures, but if I wanted to peer with another > operator and only provide routing for a certain block of numbers...it > may be an acceptable method. Speermint deals with SIP URIs and not telephone numbers. /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 Apr 14 07:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUMoQ-00073B-3f; Fri, 14 Apr 2006 07:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUMoO-000736-Ag for speermint@ietf.org; Fri, 14 Apr 2006 07:50:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUMoN-0006uG-P6 for speermint@ietf.org; Fri, 14 Apr 2006 07:50:04 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Apr 2006 04:50:04 -0700 X-IronPort-AV: i="4.04,120,1144047600"; d="scan'208"; a="1795011907:sNHT33810956" 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 k3EBo2Yi010348; Fri, 14 Apr 2006 04:50:02 -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.211); Fri, 14 Apr 2006 07:50: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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 07:50:01 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3015705AF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbw From: "Michael Hammer \(mhammer\)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 14 Apr 2006 11:50:01.0882 (UTC) FILETIME=[9028CFA0:01C65FB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 want this exchange to be between peers. Registration is more subordinate to superior. You don't normally see SIP Proxies registering to their client phones. Also, I think the registration is more specific, whereas the Subscribe is more general and extensible. In both cases, there is an authentication and authorization, so the key mangement issues will be there in both cases. I don't see that as a discriminating factor. In passing some type of session key to the requestor, I saw a more general need to pass parameter values regarding the interconnection scheme. Suggesting XML bodies to do that was simply making the mechanism more general. While we are still in the stages of trying to figure out what information needs to be exchanged between peers, generality seems useful. Mike > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Thursday, April 13, 2006 10:32 PM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > I was confused by the registration as well but it must be for=20 > different reasons because doing subscribe/notify doesn't=20 > solve my confusion. :) It has benefits for other things,=20 > and was what I was assuming would be used for some policy=20 > exchanges ultimately, but not the piece I was confused with=20 > this draft. >=20 > In the draft it says it's used for mutual proxy=20 > authentication. For a typical register challenge method to=20 > do that, they have to have shared/known passwords and=20 > usernames. (are we assuming that?) If a "key" is exchanged=20 > in the register to be used as the password, as shown in the=20 > draft I think, it does nothing; a man-in-the-middle has a=20 > view of those keys and can use them, and there's no=20 > authentication scheme for one proxy to believe the key of the=20 > other anyway. (unless "key" means a nonce?)=20 >=20 > Regardless, why not just use mutually-authenticated TLS? The=20 > details of how to believe the certs of each side though are=20 > still being discussed in the sip mailing list I think. (I=20 > haven't been following it)=20 >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, April 13, 2006 2:09 PM > > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture=20 > Message Flows > >=20 > > To the authors of draft-penno-message-flows-00.txt, > >=20 > > One part of this that didn't seem quite right to me was the use of=20 > > mutual Registrations between Proxy 1 or domain A and Proxy=20 > 2 of domain=20 > > B. (e.g., Do you intend to do some type of Contact routing?) > >=20 > > Could I ask by way of suggestion why you don't use mutual=20 > > Subscribe/Notify? That would require the same authentication and=20 > > authorization to the requesting domain and would likely be=20 > much richer=20 > > in terms of XML documents that could be supplied to the=20 > other domain=20 > > in a Notify. An event package per federation type could be=20 > defined,=20 > > for example. > >=20 > > What do you think? > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Thursday, April 13, 2006 12:55 PM > > > To: 'Reinaldo Penno'; speermint@ietf.org > > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message=20 > > > Flows > > > > > > The call flows shown are pretty much as would be expected=20 > from the=20 > > > trapezoid model in RFC 3261 using well defined SIP proxy behavior=20 > > > (lengthy section in RFC 3261). > > > > > > Why use B2BUA that have no defined behavior at all? > > > > > > Is it possible to standardize undefined behavior? > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Wednesday, April 12, 2006 3:27 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > > > Hello, > > > > > > We wrote a draft to help frame our discussions. > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > > > > > > > Title : SPEERMINT Routing Architecture Message Flows > > > Author(s) : R. Penno, et al. > > > Filename : draft-penno-message-flows-00.txt > > > Pages : 19 > > > Date : 2006-4-12 > > > > > > This draft describes the message flows associated with=20 > the SPEERMINT=20 > > > routing architecture. We show message flows in several peering=20 > > > scenarios. > > > > > > > > > A URL for this Internet-Draft is: > > >=20 > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Apr 14 08:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUN3O-00052b-3K; Fri, 14 Apr 2006 08:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUN3M-00052W-Ue for speermint@ietf.org; Fri, 14 Apr 2006 08:05:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUN3L-0007Pw-Bi for speermint@ietf.org; Fri, 14 Apr 2006 08:05:32 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Apr 2006 08:05:31 -0400 X-IronPort-AV: i="4.04,120,1144036800"; d="scan'208"; a="86444456:sNHT647689892" 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 k3EC5TvF004965; Fri, 14 Apr 2006 08:05: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.211); Fri, 14 Apr 2006 08:05:29 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 08:05:28 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3015705BA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAACC3SgAAWFR4+AAeOXDA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Malas, Daryl" , , "Reinaldo Penno" , X-OriginalArrivalTime: 14 Apr 2006 12:05:29.0461 (UTC) FILETIME=[B90A2250:01C65FBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 agree. This should not be about reaching some PSTN number. And presumably, you are contacting this peering point because a previous DNS or equivalent dip has indicated that a particular domain can be reached through this peering point. Mike =20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Friday, April 14, 2006 4:27 AM > To: Malas, Daryl; Michael Hammer (mhammer); henry@pulver.com;=20 > Reinaldo Penno; speermint@ietf.org > Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > Daryl] Contact routing wasn't my primary reason for doing=20 > this, but I did think of that as an option. You could=20 > specify NPA-NXX or similar you are providing routes to as a=20 > peering entity. Also, this would allow a method for=20 > dynamically updating supported peering routes if you were not=20 > using a common routing location server. I certainly do not=20 > think exchanging telephony routes is an efficient or even=20 > realistic method for some peering architectures, but if I=20 > wanted to peer with another operator and only provide routing=20 > for a certain block of numbers...it may be an acceptable=20 > method. Obviously, I may want to do a LNP query to make sure=20 > the TN hasn't been ported away from my peer before I route to=20 > them, but it could work for 10k blocks, etc.. >=20 > [Richard] > IMHO the whole issue is completely out of scope in speermint > =20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Gesendet: Fr 14.04.2006 00:03 > An: Michael Hammer (mhammer); henry@pulver.com; Reinaldo=20 > Penno; speermint@ietf.org > Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 >=20 >=20 > Comments in-line... >=20 > Daryl M. >=20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, April 13, 2006 12:09 PM > To: henry@pulver.com; Reinaldo Penno; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > To the authors of draft-penno-message-flows-00.txt, >=20 > One part of this that didn't seem quite right to me was the=20 > use of mutual Registrations between Proxy 1 or domain A and=20 > Proxy 2 of domain B. (e.g., Do you intend to do some type of=20 > Contact routing?) >=20 >=20 > [Daryl] Contact routing wasn't my primary reason for doing=20 > this, but I did think of that as an option. You could=20 > specify NPA-NXX or similar you are providing routes to as a=20 > peering entity. Also, this would allow a method for=20 > dynamically updating supported peering routes if you were not=20 > using a common routing location server. I certainly do not=20 > think exchanging telephony routes is an efficient or even=20 > realistic method for some peering architectures, but if I=20 > wanted to peer with another operator and only provide routing=20 > for a certain block of numbers...it may be an acceptable=20 > method. Obviously, I may want to do a LNP query to make sure=20 > the TN hasn't been ported away from my peer before I route to=20 > them, but it could work for 10k blocks, etc.. >=20 > Could I ask by way of suggestion why you don't use mutual=20 > Subscribe/Notify? That would require the same authentication=20 > and authorization to the requesting domain and would likely=20 > be much richer in terms of XML documents that could be=20 > supplied to the other domain in a Notify. An event package=20 > per federation type could be defined, for example. >=20 >=20 > [Daryl] I think this is an interesting idea, and I am still=20 > chewing on it. I am trying to evaluate the positives and=20 > negatives for accomplishing it with either method or a=20 > combination of both based on architecture. Thanks for the input. >=20 > What do you think? >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Thursday, April 13, 2006 12:55 PM > > To: 'Reinaldo Penno'; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture=20 > Message Flows > > > > The call flows shown are pretty much as would be expected from the=20 > > trapezoid model in RFC 3261 using well defined SIP proxy behavior=20 > > (lengthy section in RFC 3261). > > > > Why use B2BUA that have no defined behavior at all? > > > > Is it possible to standardize undefined behavior? > > > > Thanks, Henry > > > >=20 > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Wednesday, April 12, 2006 3:27 PM > > To: speermint@ietf.org > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > Hello, > > > > We wrote a draft to help frame our discussions. > > > > Thanks, > > > > Reinaldo > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > > > Title : SPEERMINT Routing Architecture=20 > Message Flows=20 > > Author(s) : R. Penno, et al. > > Filename : draft-penno-message-flows-00.txt > > Pages : 19 > > Date : 2006-4-12 > > =20 > > This draft describes the message flows associated with the=20 > SPEERMINT=20 > > routing architecture. We show message flows in several peering=20 > > scenarios. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt > > > > > > > > > > _______________________________________________ > > 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 Fri Apr 14 09:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOSE-0004qm-UG; Fri, 14 Apr 2006 09:35:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUOSD-0004qh-RV for speermint@ietf.org; Fri, 14 Apr 2006 09:35:17 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUOSC-0001lY-Fn for speermint@ietf.org; Fri, 14 Apr 2006 09:35:17 -0400 Received: from [10.31.32.196] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k3EDVPYK027789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Apr 2006 06:31:26 -0700 Message-ID: <443FA40A.7000505@shockey.us> Date: Fri, 14 Apr 2006 09:30:50 -0400 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows References: <072C5B76F7CEAB488172C6F64B30B5E3015705BA@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3015705BA@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Malas, Daryl" , 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 Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous DNS > or equivalent dip has indicated that a particular domain can be reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function. Now that said in those countries with full database number portability such as the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The resolution to point of interconnection must be at the full E.164 number. > > Mike > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 10:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPW6-0003Fl-7o; Fri, 14 Apr 2006 10:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPW4-0003Fg-Kc for speermint@ietf.org; Fri, 14 Apr 2006 10:43:20 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPW3-00044y-BC for speermint@ietf.org; Fri, 14 Apr 2006 10:43:20 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.02) id A5060474; Fri, 14 Apr 2006 10:43:18 -0400 From: "Patrick Melampy" To: "'Richard Shockey'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 10:43:18 -0400 Message-ID: <023101c65fd1$c52f1ac0$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZfyEkIE+5Pw3SVR5isX4+YhPAEcwACKfCQ In-Reply-To: <443FA40A.7000505@shockey.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "'Malas, Daryl'" , '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 When enum fails -- should that be out of scope? -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Friday, April 14, 2006 9:31 AM To: Michael Hammer (mhammer) Cc: Malas, Daryl; Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous DNS > or equivalent dip has indicated that a particular domain can be reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function. Now that said in those countries with full database number portability such as the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The resolution to point of interconnection must be at the full E.164 number. > > Mike > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Apr 14 11:12:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPxv-0002tb-VH; Fri, 14 Apr 2006 11:12:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPxv-0002tW-FX for speermint@ietf.org; Fri, 14 Apr 2006 11:12:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUPxu-0004gz-0f for speermint@ietf.org; Fri, 14 Apr 2006 11:12:07 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 17:14:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C498B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZfyEkIE+5Pw3SVR5isX4+YhPAEcwACKfCQAAFMM+M= From: "Stastny Richard" To: "Patrick Melampy" , "Richard Shockey" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Malas, Daryl" , 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 >When enum fails -- should that be out of scope? Could you please be more specific what you mean with enum fails? Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Fr 14.04.2006 16:43 An: 'Richard Shockey'; 'Michael Hammer (mhammer)' Cc: 'Malas, Daryl'; Stastny Richard; speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows When enum fails -- should that be out of scope? -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Friday, April 14, 2006 9:31 AM To: Michael Hammer (mhammer) Cc: Malas, Daryl; Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous = DNS > or equivalent dip has indicated that a particular domain can be = reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function. Now that said in those countries with full database number portability = such as the US you cannot effectively delegate on 10,000 or 1,000 number blocks. = The resolution to point of interconnection must be at the full E.164 number. > > Mike >=20 > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Apr 14 12:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURYt-0008HQ-LO; Fri, 14 Apr 2006 12:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURYs-0008HI-7K for speermint@ietf.org; Fri, 14 Apr 2006 12:54:22 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURYr-0008Fp-TL for speermint@ietf.org; Fri, 14 Apr 2006 12:54:22 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.02) id A3AD07F4; Fri, 14 Apr 2006 12:54:05 -0400 From: "Patrick Melampy" To: "'Stastny Richard'" , "'Richard Shockey'" , "'Michael Hammer \(mhammer\)'" Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 12:54:06 -0400 Message-ID: <026801c65fe4$0a949650$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZfyEkIE+5Pw3SVR5isX4+YhPAEcwACKfCQAAFMM+MAA3RHAA== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C498B@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "'Malas, Daryl'" , 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 When I query a specific address, and it is not resolvable. So the DNS server responds with NO ENTRY FOUND. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, April 14, 2006 11:15 AM To: Patrick Melampy; Richard Shockey; Michael Hammer (mhammer) Cc: Malas, Daryl; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows >When enum fails -- should that be out of scope? Could you please be more specific what you mean with enum fails? Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Fr 14.04.2006 16:43 An: 'Richard Shockey'; 'Michael Hammer (mhammer)' Cc: 'Malas, Daryl'; Stastny Richard; speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows When enum fails -- should that be out of scope? -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Friday, April 14, 2006 9:31 AM To: Michael Hammer (mhammer) Cc: Malas, Daryl; Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous DNS > or equivalent dip has indicated that a particular domain can be reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function. Now that said in those countries with full database number portability such as the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The resolution to point of interconnection must be at the full E.164 number. > > Mike > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Apr 14 12:58:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURcn-0000Bt-Fo; Fri, 14 Apr 2006 12:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURcm-0000Bo-Px for speermint@ietf.org; Fri, 14 Apr 2006 12:58:24 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FURcm-0008LI-6x for speermint@ietf.org; Fri, 14 Apr 2006 12:58:24 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-4.tower-124.messagelabs.com!1145033902!9000475!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5314 invoked from network); 14 Apr 2006 16:58:22 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-4.tower-124.messagelabs.com with SMTP; 14 Apr 2006 16:58:22 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F750040504F; Fri, 14 Apr 2006 12:58: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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 12:58:20 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C96E384@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <026801c65fe4$0a949650$6701a8c0@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZfyEkIE+5Pw3SVR5isX4+YhPAEcwACKfCQAAFMM+MAA3RHAAAAF/ww From: "Pfautz, Penn L, NEO" To: "Patrick Melampy" , "Stastny Richard" , "Richard Shockey" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.5 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "Malas, Daryl" , 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 can imagine alternate ways of resolving an E.164 number to a SIP A0R, I think they are all out of scope for Speermint.=20 -----Original Message----- From: Patrick Melampy [mailto:PMelampy@acmepacket.com]=20 Sent: Friday, April 14, 2006 12:54 PM To: 'Stastny Richard'; 'Richard Shockey'; 'Michael Hammer (mhammer)' Cc: 'Malas, Daryl'; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows When I query a specific address, and it is not resolvable. So the DNS server responds with NO ENTRY FOUND. -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Friday, April 14, 2006 11:15 AM To: Patrick Melampy; Richard Shockey; Michael Hammer (mhammer) Cc: Malas, Daryl; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows >When enum fails -- should that be out of scope? Could you please be more specific what you mean with enum fails? Richard ________________________________ Von: Patrick Melampy [mailto:PMelampy@acmepacket.com] Gesendet: Fr 14.04.2006 16:43 An: 'Richard Shockey'; 'Michael Hammer (mhammer)' Cc: 'Malas, Daryl'; Stastny Richard; speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows When enum fails -- should that be out of scope? -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us] Sent: Friday, April 14, 2006 9:31 AM To: Michael Hammer (mhammer) Cc: Malas, Daryl; Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous DNS > or equivalent dip has indicated that a particular domain can be reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function. Now that said in those countries with full database number portability such as the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The resolution to point of interconnection must be at the full E.164 number. > > Mike >=20 > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 Fri Apr 14 13:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURhk-0000QY-53; Fri, 14 Apr 2006 13:03:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURhj-0000QS-AC for speermint@ietf.org; Fri, 14 Apr 2006 13:03:31 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURhi-00005f-UA for speermint@ietf.org; Fri, 14 Apr 2006 13:03:31 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3EH3Udt004103; Fri, 14 Apr 2006 10:03:30 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k3EH3UEO004102; Fri, 14 Apr 2006 10:03:30 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Apr 2006 10:03:30 -0700 From: David Meyer To: Richard Shockey Subject: Re: [Speermint] Notation? Message-ID: <20060414170330.GA1551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D463C4EC6@oefeg-s04.oefeg.loc> <4435362F.2060206@shockey.us> Mime-Version: 1.0 In-Reply-To: <4435362F.2060206@shockey.us> 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============1907532822==" Errors-To: speermint-bounces@ietf.org --===============1907532822== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 06, 2006 at 11:39:27AM -0400, Richard Shockey wrote: > Stastny Richard wrote: > >Hi Medhavi, > >inline > > > >>-----Original Message----- > >>From: Medhavi Bhatia [mailto:mbhatia@nextone.com] > >>Sent: Thursday, April 06, 2006 5:01 PM > >>To: Pfautz, Penn L, NEO; Otmar Lendl; speermint@ietf.org > >>Subject: RE: [Speermint] Notation? > >> > >>IXP =3D L5 SP which sits for the duration of the complete call between > >>Core-O and Core-T (from my draft). It may do just signaling or both > >>signaling and media. > > > >As far as I know there exist more types of IXP today, some offer > >proxy services (which is L5 signaling in your model, some offer > >also L3 media transit, and some offer just redirect services > >(covered below - i.e. a location service), and some offer=20 > >both proxy and redirect >=20 >=20 > Use of the term IXP in this context is incorrect and misleading. You need= =20 > to come up with something specific to the SPEERMINT context. >=20 > IXP means some thing in Internet Terminoogy. Agreed, use of IXP in this context is going to confuse things (further). > Now peering arrangements can be organized at an IXP such as LINX / Equini= x=20 > if two service providers choose to match their L3 and L5 traffic at those= =20 > points and share access to common signaling databases such as ENUM or SIP= =20 > Redirect. But by no means required. > >>This is different from a Federation or DNS Registry which may be > >>involved only for lookups. So there is some form of SIP profile > >>terminated to the IXP (we can deal with media later on). > > > >Not necessarily, see below > >>Location of IXPs seems to be a problem today: How does Core-O locate > >the IXP required to get to Core-T if it exists. It is almost like the SIP > >>next hop required to get to the administrative domain of choice. >=20 > No not necessarily each domain should have internal knowledge of its=20 > bilateral agreements and make decisions based at call origination as to= =20 > what is the optimal point of transit interconnection. Agree with the latter. Dave --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEP9XiORgD1qCZ2KcRAjFUAJwJ7doJ7lY0tjF4n8U1nBdsD/r+fwCeNO2l is+eph3WWiSo2u3nX/LtaoY= =5JhY -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- --===============1907532822== 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 --===============1907532822==-- From speermint-bounces@ietf.org Fri Apr 14 13:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURjz-00013B-T8; Fri, 14 Apr 2006 13:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURjy-000136-Ln for speermint@ietf.org; Fri, 14 Apr 2006 13:05:50 -0400 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURjy-0000BJ-DF for speermint@ietf.org; Fri, 14 Apr 2006 13:05:50 -0400 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k3EH506r010425; Fri, 14 Apr 2006 17:05:10 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id EFB9E124847; Fri, 14 Apr 2006 17:04:49 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id 8816612484B; Fri, 14 Apr 2006 17:04:49 +0000 (GMT) Received: from idc1exc0006.corp.global.level3.com ([10.1.9.17]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 11:04:49 -0600 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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 11:04:48 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZfx9mbI1e558tVS7a1nyNEKfv8awAHFS7A From: "Malas, Daryl" To: "Richard Shockey" , "Michael Hammer (mhammer)" X-OriginalArrivalTime: 14 Apr 2006 17:04:49.0334 (UTC) FILETIME=[89F54560:01C65FE5] X-Spam-Score: 0.6 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 I don't really have a strong argument against this, so perhaps it was a bad example in the beginning....and not specifically intended or specified in the draft. =20 One wild thought, which may have multiple solutions already available... I was thinking in line with a TN located in the user part of the SIP URI. An ENUM server could respond with this type of information in the SIP URI, such as, sip:3035551212@companyA.com...companyA.com may be acting as an IXC in order to reach user 3035551212, when in fact the user actually exists at 3035551212@companyB.com; however, I (companyC.com) am not directly peered to companyB.com. CompanyA.com may be peered with CompanyB.com, and provides a least cost route instead of terminating over the PSTN.=20 Perhaps it is a funky, edge example...but I can foresee this occurring. --Daryl M. -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Friday, April 14, 2006 7:31 AM To: Michael Hammer (mhammer) Cc: Stastny Richard; Malas, Daryl; henry@pulver.com; Reinaldo Penno; speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Michael Hammer (mhammer) wrote: > I agree. This should not be about reaching some PSTN number. And > presumably, you are contacting this peering point because a previous DNS > or equivalent dip has indicated that a particular domain can be reached > through this peering point. Correct... the translation of the PSTN number to some URI is the ENUM function.=20 Now that said in those countries with full database number portability such as=20 the US you cannot effectively delegate on 10,000 or 1,000 number blocks. The=20 resolution to point of interconnection must be at the full E.164 number. >=20 > Mike > =20 >=20 --=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 13:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURks-00029c-J0; Fri, 14 Apr 2006 13:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURkr-00023U-9G for speermint@ietf.org; Fri, 14 Apr 2006 13:06:45 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURkp-0000CN-Te for speermint@ietf.org; Fri, 14 Apr 2006 13:06:45 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3EH6hBL004146; Fri, 14 Apr 2006 10:06:43 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k3EH6hdn004145; Fri, 14 Apr 2006 10:06:43 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Apr 2006 10:06:43 -0700 From: David Meyer To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering Message-ID: <20060414170643.GB1551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> <44353325.5080802@shockey.us> <20060406154408.GE12968@nic.at> Mime-Version: 1.0 In-Reply-To: <20060406154408.GE12968@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: 538aad3a3c4f01d8b6a6477ca4248793 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="===============0882115438==" Errors-To: speermint-bounces@ietf.org --===============0882115438== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 06, 2006 at 05:44:08PM +0200, Otmar Lendl wrote: > On 2006/04/06 17:04, Richard Shockey wrote: > > Stastny Richard wrote: > > >The problem I have with the FCC definition is that > > >is states that peering is always bi-lateral > > > > > >The major reason for setting up SPEERMINT was that > > >everybody seems at least to agree that bi-lateral > > >peering does not scale globally. > >=20 > > All peering arrangements among IP backbones are bi-lateral and the Inte= rnet=20 > > seems to have scaled reasonably well. >=20 > The reason for that is "transit". It is thus not necessary that > any Autonomous Systems peers with all other AS. We might also want to stay away from the term transit, since it doesn't really exist (at least in the L3 internet).=20 > I think we should define the difference between "Peering" and > "Interconnection" (which in my mind also allows for transit). >=20 > Bi-lateral peering alone will definitly not solve the world-wide > reachability problem. Other than the (obvious) scaling problems, why not? OTOH, if I don't have a route to you, I don't have a route to you. How do I get your routes? I peer with you.=20 Dave --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEP9ajORgD1qCZ2KcRAlSxAJoDi35V3erHUGlGHlvUFmQuCColrgCfVvEv GwD0Kb3pwgiCcEflPkpZP2U= =QjSc -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- --===============0882115438== 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 --===============0882115438==-- From speermint-bounces@ietf.org Fri Apr 14 13:11:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURpg-00086w-H3; Fri, 14 Apr 2006 13:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURpf-00082X-FK for speermint@ietf.org; Fri, 14 Apr 2006 13:11:43 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURpd-0000Gy-6a for speermint@ietf.org; Fri, 14 Apr 2006 13:11:43 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FURpU-0006Mj-Em; Fri, 14 Apr 2006 12:11:33 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Hadriel Kaplan'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:11:34 -0400 Message-ID: <068301c65fe6$7de5b240$4fe6a8c0@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: <9BD5D7887235424FA97DFC223CAE3C2802DFE66E@proton.jnpr.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+AAB2myWA= X-PopBeforeSMTPSenders: br@brianrosen.net 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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, as with any peering "endeavour" I believe there will always be >the casethat they have physical/co-location security so TLS is not >needed. I wonder about that. Seems to me there are a few cases of interest: 1. Peering is conducted in a closed environment, where you have no L3 connectivity unless you are allowed L5/L7 connectivity 2. Peering is conducted in an open environment where you have open L3, and need restricted L5/L7 3. Peering is conducted in a closed L3 environment, but needs authorization for L5/L7 In case 1, you don't need any form of authentication. If you can connect, you are allowed to peer. In case 2, TLS is appropriate In case 3, you want some form of authorization, but don't need privacy or integrity protection. What you need is authorization. TLS mutual authentication would be very appropriate. You don't have to engage encryption or MAC processing, just the authentication part. I think the registration mechanisms discussed are a misuse of SIP. Registration in 3261 is described as UAC to Registrar, not proxy to proxy. There are also problems with using the Proxy-Authenticate process defined in section 22.4. Section 22 of 3261 discusses User to User and User to proxy authentication. Proxy to proxy is noticeably not discussed in 3261. RFC3603 gives some private extensions for proxy to proxy within PacketCable DCS, but these are not generalizable to SPEERMINT. Thus, I suggest we consider using TLS mutual authentication when peers need to authenticate with one another. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 13:18:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURvc-0003ME-59; Fri, 14 Apr 2006 13:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURva-0003Hm-Jw for speermint@ietf.org; Fri, 14 Apr 2006 13:17:50 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURvZ-0000Qh-8I for speermint@ietf.org; Fri, 14 Apr 2006 13:17:50 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3EHHmwd004247; Fri, 14 Apr 2006 10:17:48 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k3EHHmtl004246; Fri, 14 Apr 2006 10:17:48 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Apr 2006 10:17:48 -0700 From: David Meyer To: Stastny Richard Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Message-ID: <20060414171748.GC1551@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D462C498A@oefeg-s04.oefeg.loc> Mime-Version: 1.0 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C498A@oefeg-s04.oefeg.loc> 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: 8b30eb7682a596edff707698f4a80f7d Cc: "Malas, Daryl" , 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="===============1882337580==" Errors-To: speermint-bounces@ietf.org --===============1882337580== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 14, 2006 at 10:27:10AM +0200, Stastny Richard wrote: > Daryl] Contact routing wasn't my primary reason for doing this, but I > did think of that as an option. You could specify NPA-NXX or similar > you are providing routes to as a peering entity. Also, this would allow > a method for dynamically updating supported peering routes if you were > not using a common routing location server. I certainly do not think > exchanging telephony routes is an efficient or even realistic method for > some peering architectures, but if I wanted to peer with another > operator and only provide routing for a certain block of numbers...it > may be an acceptable method. Obviously, I may want to do a LNP query to > make sure the TN hasn't been ported away from my peer before I route to > them, but it could work for 10k blocks, etc.. >=20 > [Richard]=20 > IMHO the whole issue is completely out of scope in speermint That much I can agree with. Dave --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEP9k8ORgD1qCZ2KcRAl00AJ0Y0OD4zgSQLu9nMXpPd77mcxK0QwCfXqB5 XtLTi9Syrj+zfXQOZiODtbw= =G8sZ -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- --===============1882337580== 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 --===============1882337580==-- From speermint-bounces@ietf.org Fri Apr 14 13:20:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURxk-0004eN-0i; Fri, 14 Apr 2006 13:20:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FURxj-0004eI-4f for speermint@ietf.org; Fri, 14 Apr 2006 13:20:03 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FURxi-0000VD-Th for speermint@ietf.org; Fri, 14 Apr 2006 13:20:03 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.02) id A9B903DC; Fri, 14 Apr 2006 13:19:53 -0400 From: "Patrick Melampy" To: "'David Meyer'" , "'Otmar Lendl'" , Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Date: Fri, 14 Apr 2006 13:19:53 -0400 Message-ID: <027b01c65fe7$a50cee50$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZf5dCwPCyBpDohSxGQGBHN8hd2YQAAKu4g In-Reply-To: <20060414170643.GB1551@1-4-5.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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, Assume the following 4 bi-lateral agreements A---B B---C B---D B---E What your saying, is that B's bilateral agreements with C, D, and E do not have any value to the bilateral relationship B has with A. I would argue that this is not true. Since your accepting of the notion that bilateral agreements make sense, its clear that many bilateral agreements will exist. The aggregation of bi-lateral agreements defines logically a "transit" carrier. If "B" were the public internet, then A would have to have a contract and business terms with C, D, and E. This would include many complex business issues which are definitely out of scope. I think that the very presence of bilateral agreements for VOIP implies that carriers like B will exist. -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net] Sent: Friday, April 14, 2006 1:07 PM To: Otmar Lendl; speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering On Thu, Apr 06, 2006 at 05:44:08PM +0200, Otmar Lendl wrote: > On 2006/04/06 17:04, Richard Shockey wrote: > > Stastny Richard wrote: > > >The problem I have with the FCC definition is that > > >is states that peering is always bi-lateral > > > > > >The major reason for setting up SPEERMINT was that > > >everybody seems at least to agree that bi-lateral > > >peering does not scale globally. > > > > All peering arrangements among IP backbones are bi-lateral and the Internet > > seems to have scaled reasonably well. > > The reason for that is "transit". It is thus not necessary that > any Autonomous Systems peers with all other AS. We might also want to stay away from the term transit, since it doesn't really exist (at least in the L3 internet). > I think we should define the difference between "Peering" and > "Interconnection" (which in my mind also allows for transit). > > Bi-lateral peering alone will definitly not solve the world-wide > reachability problem. Other than the (obvious) scaling problems, why not? OTOH, if I don't have a route to you, I don't have a route to you. How do I get your routes? I peer with you. Dave _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 13:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS1t-0007Zc-9x; Fri, 14 Apr 2006 13:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS1s-0007ZU-Ca for speermint@ietf.org; Fri, 14 Apr 2006 13:24: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 1FUS1p-0000cq-S6 for speermint@ietf.org; Fri, 14 Apr 2006 13:24:20 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 94E631A529; Fri, 14 Apr 2006 19:24:16 +0200 (CEST) Date: Fri, 14 Apr 2006 19:24:16 +0200 From: Otmar Lendl To: David Meyer Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering Message-ID: <20060414172416.GD28504@nic.at> Mail-Followup-To: Otmar Lendl , David Meyer , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> <44353325.5080802@shockey.us> <20060406154408.GE12968@nic.at> <20060414170643.GB1551@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060414170643.GB1551@1-4-5.net> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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/04/14 19:04, David Meyer wrote: > On Thu, Apr 06, 2006 at 05:44:08PM +0200, Otmar Lendl wrote: > > On 2006/04/06 17:04, Richard Shockey wrote: > > > Stastny Richard wrote: > > > >The problem I have with the FCC definition is that > > > >is states that peering is always bi-lateral > > > > > > > >The major reason for setting up SPEERMINT was that > > > >everybody seems at least to agree that bi-lateral > > > >peering does not scale globally. > > > > > > All peering arrangements among IP backbones are bi-lateral and the Internet > > > seems to have scaled reasonably well. > > > > The reason for that is "transit". It is thus not necessary that > > any Autonomous Systems peers with all other AS. > > We might also want to stay away from the term transit, > since it doesn't really exist (at least in the L3 > internet). Hm? Back in the days when I was working for a big ISPs we used to call the product "I'll connect your small network to the world" "IP transit". That's synonymous to "IP upstream". (see. e.g. http://en.wikipedia.org/wiki/IP_Transit_%28Internet%29 ) That contrasts to IP peering where both sides just give each other access to the own network (+customers) but not upstream. On the protocol level, both are BGP links. It's just the configuration of the route filters which make the difference. (plus of course the commercial side) > > I think we should define the difference between "Peering" and > > "Interconnection" (which in my mind also allows for transit). > > > > Bi-lateral peering alone will definitly not solve the world-wide > > reachability problem. > > Other than the (obvious) scaling problems, why not? OTOH, > if I don't have a route to you, I don't have a route to > you. How do I get your routes? I peer with you. *If* you can solve the scaling, then yes, you're correct. It will depend on how the VoIP business evolves. I may well be that all corporate PBX will act as their own independent VoIP operators who want to peer with each other directly. (Just as the corporate mailservers connect to each other without the help of a carrier's mailserver.) >From the point of view of a corporate PBX: using a VoIP service provider to connect to some other corporate PBX is to use them as a transit network. As I see the problem, you will have thousands (if not millions) peering partners to get universal connectivity without resorting to transit networks. That's only manageable by automatic ad-hoc peering. /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 Apr 14 13:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS4l-00083a-34; Fri, 14 Apr 2006 13:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS4j-00083U-K0 for speermint@ietf.org; Fri, 14 Apr 2006 13:27:17 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUS4j-0000lm-Cz for speermint@ietf.org; Fri, 14 Apr 2006 13:27:17 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.02) id AB740654; Fri, 14 Apr 2006 13:27:16 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:27:25 -0400 Message-ID: <006a01c65fe8$b2636e70$91c8000a@acmepacket.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: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbwAAS/2TA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3015705AF@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Michael, comments inline... > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 14, 2006 7:50 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > I think we want this exchange to be between peers. Registration is more > subordinate to superior. You don't normally see SIP Proxies registering > to their client phones. Nor do they generate such register requests anyway. They'd have to have a UA component to do it, and act as a registrar on the other side, and registration is not the semantics you want anyway. > In both cases, there is an authentication and authorization, so the key > mangement issues will be there in both cases. I don't see that as a > discriminating factor. Indeed, that's why I said the sub/notify did not resolve my confusion. In either method the auth problems are not solved, assuming you meant the Subscribe would be challenged as the auth mechanism. If you just meant the xml contents would be used to provide some auth mechanism, then that's different. > In passing some type of session key to the requestor, I saw a more > general need to pass parameter values regarding the interconnection > scheme. Suggesting XML bodies to do that was simply making the > mechanism more general. While we are still in the stages of trying to > figure out what information needs to be exchanged between peers, > generality seems useful. Agreed, as I said I assumed sub/notify would be proposed for policy exchanges at some point in this WG. It was the proposed proxy-proxy authentication idea in the draft that confuses me. -hadriel _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 13:32:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS9e-0001bE-Oc; Fri, 14 Apr 2006 13:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUS9d-0001b4-HV for speermint@ietf.org; Fri, 14 Apr 2006 13:32:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUS9d-0000zi-1b for speermint@ietf.org; Fri, 14 Apr 2006 13:32:21 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 19:31:26 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C498D@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+AAB2myWAAAWSoKw== From: "Stastny Richard" To: , "Reinaldo Penno" , "Hadriel Kaplan" , "Michael Hammer \(mhammer\)" , 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 Maybe I am finally getting confused now, because I am already one week = on vacation, =20 I do not understand scenario 1: how can I have L5/L7 connectivity without having L3 connectivity? Telepathy? =20 I know some IMS and TISPAN guys are discussing this, but ... =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 14.04.2006 19:11 An: 'Reinaldo Penno'; 'Hadriel Kaplan'; 'Michael Hammer (mhammer)'; = speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >Finally, as with any peering "endeavour" I believe there will always be >the casethat they have physical/co-location security so TLS is not >needed. I wonder about that. Seems to me there are a few cases of interest: 1. Peering is conducted in a closed environment, where you have no L3 connectivity unless you are allowed L5/L7 connectivity 2. Peering is conducted in an open environment where you have open L3, = and need restricted L5/L7 3. Peering is conducted in a closed L3 environment, but needs = authorization for L5/L7 In case 1, you don't need any form of authentication. If you can = connect, you are allowed to peer. In case 2, TLS is appropriate In case 3, you want some form of authorization, but don't need privacy = or integrity protection. What you need is authorization. TLS mutual authentication would be very appropriate. You don't have to engage encryption or MAC processing, just the authentication part.=20 I think the registration mechanisms discussed are a misuse of SIP. Registration in 3261 is described as UAC to Registrar, not proxy to = proxy. There are also problems with using the Proxy-Authenticate process = defined in section 22.4. Section 22 of 3261 discusses User to User and User to = proxy authentication. Proxy to proxy is noticeably not discussed in 3261. RFC3603 gives some private extensions for proxy to proxy within = PacketCable DCS, but these are not generalizable to SPEERMINT. Thus, I suggest we consider using TLS mutual authentication when peers = need to authenticate with one another. _______________________________________________ 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 Apr 14 13:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSBY-0003VV-AN; Fri, 14 Apr 2006 13:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSBW-0003MU-Fi for speermint@ietf.org; Fri, 14 Apr 2006 13:34:18 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUSBW-00012b-2N for speermint@ietf.org; Fri, 14 Apr 2006 13:34:18 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-124.messagelabs.com!1145035984!8996508!14 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12573 invoked from network); 14 Apr 2006 17:34:16 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-11.tower-124.messagelabs.com with SMTP; 14 Apr 2006 17:34:16 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 441D8F75004065CD for speermint@ietf.org; Fri, 14 Apr 2006 13:34: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 Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:34:15 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0C96E408@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <006a01c65fe8$b2636e70$91c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbwAAS/2TAAB2Lu0A== From: "Pfautz, Penn L, NEO" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Hmm... Maybe my mind is already on the weekend but how does all this authorization and authentication fit in with the scaling concerns people keep expressing? Are we driving back to a bilateral process?=20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Friday, April 14, 2006 1:27 PM To: 'Michael Hammer (mhammer)'; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 Hi Michael, comments inline... > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 14, 2006 7:50 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > I think we want this exchange to be between peers. Registration is more > subordinate to superior. You don't normally see SIP Proxies registering > to their client phones. Nor do they generate such register requests anyway. They'd have to have a UA component to do it, and act as a registrar on the other side, and registration is not the semantics you want anyway. =20 > In both cases, there is an authentication and authorization, so the key > mangement issues will be there in both cases. I don't see that as a > discriminating factor. Indeed, that's why I said the sub/notify did not resolve my confusion. In either method the auth problems are not solved, assuming you meant the Subscribe would be challenged as the auth mechanism. If you just meant the xml contents would be used to provide some auth mechanism, then that's different. > In passing some type of session key to the requestor, I saw a more > general need to pass parameter values regarding the interconnection > scheme. Suggesting XML bodies to do that was simply making the > mechanism more general. While we are still in the stages of trying to > figure out what information needs to be exchanged between peers, > generality seems useful. Agreed, as I said I assumed sub/notify would be proposed for policy exchanges at some point in this WG. It was the proposed proxy-proxy authentication idea in the draft that confuses me. -hadriel _______________________________________________ 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 Apr 14 13:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSGY-0001rx-2R; Fri, 14 Apr 2006 13:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSGW-0001rH-Fp for speermint@ietf.org; Fri, 14 Apr 2006 13:39:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSGW-0001Ez-6H for speermint@ietf.org; Fri, 14 Apr 2006 13:39:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FUSGO-0008KX-Lx; Fri, 14 Apr 2006 12:39:21 -0500 From: "Brian Rosen" To: "'Pfautz, Penn L, NEO'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:39:21 -0400 Message-ID: <069701c65fea$60326820$4fe6a8c0@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: <34DA635B184A644DA4588E260EC0A25A0C96E408@ACCLUST02EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbwAAS/2TAAB2Lu0AAASu9A X-PopBeforeSMTPSenders: br@brianrosen.net 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: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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 Case 1 -----Original Message----- From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] Sent: Friday, April 14, 2006 1:34 PM To: speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Hmm... Maybe my mind is already on the weekend but how does all this authorization and authentication fit in with the scaling concerns people keep expressing? Are we driving back to a bilateral process? -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, April 14, 2006 1:27 PM To: 'Michael Hammer (mhammer)'; speermint@ietf.org Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Hi Michael, comments inline... > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 14, 2006 7:50 AM > To: Hadriel Kaplan; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > I think we want this exchange to be between peers. Registration is more > subordinate to superior. You don't normally see SIP Proxies registering > to their client phones. Nor do they generate such register requests anyway. They'd have to have a UA component to do it, and act as a registrar on the other side, and registration is not the semantics you want anyway. > In both cases, there is an authentication and authorization, so the key > mangement issues will be there in both cases. I don't see that as a > discriminating factor. Indeed, that's why I said the sub/notify did not resolve my confusion. In either method the auth problems are not solved, assuming you meant the Subscribe would be challenged as the auth mechanism. If you just meant the xml contents would be used to provide some auth mechanism, then that's different. > In passing some type of session key to the requestor, I saw a more > general need to pass parameter values regarding the interconnection > scheme. Suggesting XML bodies to do that was simply making the > mechanism more general. While we are still in the stages of trying to > figure out what information needs to be exchanged between peers, > generality seems useful. Agreed, as I said I assumed sub/notify would be proposed for policy exchanges at some point in this WG. It was the proposed proxy-proxy authentication idea in the draft that confuses me. -hadriel _______________________________________________ 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 Fri Apr 14 13:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSIF-00038R-G6; Fri, 14 Apr 2006 13:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSIE-00038M-Bo for speermint@ietf.org; Fri, 14 Apr 2006 13:41:14 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSIC-0001IE-V3 for speermint@ietf.org; Fri, 14 Apr 2006 13:41:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FUSI3-0008WT-1V; Fri, 14 Apr 2006 12:41:04 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Reinaldo Penno'" , "'Hadriel Kaplan'" , "'Michael Hammer \(mhammer\)'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:41:05 -0400 Message-ID: <069801c65fea$9d433050$4fe6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0699_01C65FC9.16319050" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <32755D354E6B65498C3BD9FD496C7D462C498D@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+AAB2myWAAAWSoKwAAR7MQ X-MS-TNEF-Correlator: 00000000EACB561B9FD48D4AAE99D1789099C5DE0700ED0887AEB595F74DB74934F4C37C08DC0000010D1FF6000062B89492B130A740A48CEE3227174D9D0002CD1160040000 X-PopBeforeSMTPSenders: br@brianrosen.net 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: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net 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_000_0699_01C65FC9.16319050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is the "Club Room" environment. I run a peering service. I only let you into my peering fabric under controlled conditions (private network connection, IPsec or other VPN connections). If you are in, you are in, no further authorization needed. Brian _____ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Friday, April 14, 2006 1:31 PM To: br@brianrosen.net; Reinaldo Penno; Hadriel Kaplan; Michael Hammer (mhammer); speermint@ietf.org Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows Maybe I am finally getting confused now, because I am already one week on vacation, I do not understand scenario 1: how can I have L5/L7 connectivity without having L3 connectivity? Telepathy? I know some IMS and TISPAN guys are discussing this, but ... Richard _____ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 14.04.2006 19:11 An: 'Reinaldo Penno'; 'Hadriel Kaplan'; 'Michael Hammer (mhammer)'; speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >Finally, as with any peering "endeavour" I believe there will always be >the casethat they have physical/co-location security so TLS is not >needed. I wonder about that. Seems to me there are a few cases of interest: 1. Peering is conducted in a closed environment, where you have no L3 connectivity unless you are allowed L5/L7 connectivity 2. Peering is conducted in an open environment where you have open L3, and need restricted L5/L7 3. Peering is conducted in a closed L3 environment, but needs authorization for L5/L7 In case 1, you don't need any form of authentication. If you can connect, you are allowed to peer. In case 2, TLS is appropriate In case 3, you want some form of authorization, but don't need privacy or integrity protection. What you need is authorization. TLS mutual authentication would be very appropriate. You don't have to engage encryption or MAC processing, just the authentication part. I think the registration mechanisms discussed are a misuse of SIP. Registration in 3261 is described as UAC to Registrar, not proxy to proxy. There are also problems with using the Proxy-Authenticate process defined in section 22.4. Section 22 of 3261 discusses User to User and User to proxy authentication. Proxy to proxy is noticeably not discussed in 3261. RFC3603 gives some private extensions for proxy to proxy within PacketCable DCS, but these are not generalizable to SPEERMINT. Thus, I suggest we consider using TLS mutual authentication when peers need to authenticate with one another. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------=_NextPart_000_0699_01C65FC9.16319050 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgkRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgCMHQAAJwAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA LgAAAAAAHgBwAAEAAAA7AAAAW1NwZWVybWludF0gU1BFRVJNSU5UIFJvdXRpbmcgQXJjaGl0ZWN0 dXJlIE1lc3NhZ2UgRmxvd3MgIAAAAgFxAAEAAADAAAAAAcZZkYOcA08HWr6HQfGDr9/mSqMb9wAC f1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zE QAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAA AR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAACoz+AAB2myWAAAWSoKwAAR7MQCwAB DgAAAAACAQoOAQAAAC4AAAAAAAAA6stWG5/UjUqumdF4kJnF3gEA7QiHrrWV9023STT0w3wI3AAA AQ0f9wAAAAADABQOAQAAAB4AKA4BAAAALwAAADAwMDAwMDA0AWJyQGJyaWFucm9zZW4ubmV0AW1h aWwuYnJpYW5yb3Nlbi5uZXQAAB4AKQ4BAAAALwAAADAwMDAwMDA0AWJyQGJyaWFucm9zZW4ubmV0 AW1haWwuYnJpYW5yb3Nlbi5uZXQAAAMA3j+fTgAAAwACWQAAFgADAAlZAgAAAAMAA4AIIAYAAAAA AMAAAAAAAABGAAAAABCFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAAaA CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAsAEIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAA AAAAAwARgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAA AABghQAAAAjW6CkAAAADAHyACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAgYAIIAYAAAAA AMAAAAAAAABGAAAAAIKFAAAAAAAACwAfDgEAAAACAfgPAQAAABAAAAB4QR1Cah7+QLImLlYtXpRQ AgH6DwEAAAAQAAAA6stWG5/UjUqumdF4kJnF3gMA/g8FAAAAAgEJEAEAAABiGAAAXhgAAA5eAABM WkZ1hj7PMQMACgByY3BnMTI1gjIDQ2h0bWwxAzD/AQMB9wqAAqQD5AcTAoAQA/8AUARWCFUHshE1 DlEDAQIAhGNoCsBzZXQyBgDbBsMRNTMERhPHMBI/AgCuNAPFFdkQ6jUXvyAHbcURNTYDxlRhaANx AoC3EUMI7wn3Ox4PDjA1Hy96ZQ4gOCB/HwERQQxgY2cAUAsJAWQzNhZgC6U0ciAQAipcDrIBkA4Q OWQgPA6yIHgO0ACAOkh2PSIIcG46BPBoYmUAwHMtbQ3gA2Bzam8BgC0FoG0nEA7QIl0mtW8nPyhJ KHBmDeBleytlKSZ3Kb8qzyywBbBk8Skmc3QxLN8t7zBAAMA7ACAmAXMpJS/wDrB0cBA6Ly93M7Au dzMCLgWwZy9UUi9SCEVDLQ6yNDAiPj8RQyWnFFAKozVfNm9nM+MlQCZgZWFkNU0O8Te/azo/JeQ2 DvA8B4ABkCBkbmEHgD1HCfAEkGFedAWxBaACMAnwdC/wTUkoJiBXLxEgMQ7wKC8rkCXwBJAJgCAH gGRpuHVtKTU+O583QzQ9ARAhLS1bBpAgIW0pKGBdPgqjPC/AeWyCZUSUdlxcOioDMEh7YmUT8HZp BbA6kQhwbCgjAQFhdSXwoCNWTUwpIcB9CqPub0XPRt9H5XdIb0l/R+XkLnMT8HBlS09MX0TCNi9F CUPAWwnwQOBmXU9D4EFPQl8mETc3JlB0HGl0RTFCrwfwRTogvFtTTdAEkCgQAjBdBgAAUEVFUk1J TlTlB/F1VFBuZxDRE+BUYK0FkHQIcE3gTQeQcyYQNU3gRh2gdwQgUd04NY9QMVRfUo9DGm86UzIy sRywZ1R5TdE9gnMKsH8rsAhxL/8xDzIZCqM9dCImUASQKGBuTj2RIi//Wz9cT0NvRH8KwS/BSwJO D8tPFQiQbwhgaSkDME/v/1D/ZA9lHz0BRQRt/22UZkKVYkQvSzBGAiEgRAEQTwuAWvBpEAYxKi9i RED9AhItTyArsAqkAZFN8XNlcSgQbHk6HLVz+AqwbmEoUGUtMToUUD/xNvIgJUAzIFqgJUAlQBRQ djRH1nGCU0UScg9iYnA0Lk0oYE4FsADAbCzYIGxpespA4HZ6yHP65TIxZwuAOjALgHXZffROLQbg AkAowS4wgDAx7wUwddlzYwCQeivADiCAICuAf3T2IgdtIkfWYTpZe4Bua3tgXvFuesJI315xTsCF cXP6HYM6CjJ12f0+oHgokAWDPiBygU6gbCC/hnOIIYTmaQAAkD6gZIWv+4WAccBsWVEJgIbfh++I /32KDXB9OyhgKAB/VD4wcHItB0B0Ok8wPjB+ny39BRBnDrB+XpI4f7STD38Y/0UwAYB+XYFPgl+D b4R7i6P+RQDAAxB5E1qAkW5FA5LAvV5xOoZhYzEHQJSgZQtQfnma73UUEORz+I30PYB2+6FxR/RA CrBZEQZgWGBygccjY3Q2mjM4LjULgD/h34Agfn9+MadzP+AuDjCpE/+pCEfWfGKlf03xpSJd0KtF /0fWbHFtr2XiJkFrJWyvrg/3sL8l42YSLzkfN2+0jyWYyjUWYDwG4GR5e3AAcMBnPUVOLVUF8IVi /j0KMkWguMez8CWzACEDMPG4EjEwM3eguiYWYCVrrySxtm+8vyXjOXdgPHxh9z5gC2AEED2rNroJ AAC7b9e9z8JvJWs2OOFwv9V61+fAz8HfDhA0OCZQAhJoIO2aQT0UUB2DPaRSmdBfEd49BxPG6wvi AzBjE1ADMfclQMevJdQ4OOGLomghRSF8PSeZ6AqjuwCao6I/O+2j+CfG781zVFggBCDUQYZ0X/DN vyYjODIB0LMCgLooJzkVQM03QwpA/3RwCAADcNTv1fKtMNZbF6D/zT+zFMRVuifNGQnwaQADYBZu B4ACMC7U3yZuYhte8NZLYQFA2sdJIHK/kECFMHZwVkFXshQgcmkA/yuw3p/fr+C+AiB1QHtwFDDc IHkIYNRgAjBvQLC38OviFk8gYgUQY9tf3G/a5f+QQz5jA2CM0ECRPnFA4HJ09ChwBRB2PiBekRQw LwGeaz5iPfCrU3tgSVAUIB5jSEBIMdShBcBWUE7P6F/pb9rl7bhzKeMP5B//4L1moOayCsBN4AuA e2D2Gn92oJnQCHDvE5dRHNAFEHrvj+PtIQmACYAub5044V3A/nCz/g5AawH6v79Q+/KLote6CboX yC41v3EvAhL97//+87omcTL+mAqBujcKsQN4/cINN/vy+t7ETwcPxR/GL//TH8hPyV/Kb8t/zI/N n86v/8+/0M/R3wtfwf76b/N/9I//GC/7z/zfAL8cfwAPAR8CL/8DPwRPBV8HvwjPKP8Jnwqv/xef DM8N3w7vD/8RDxIfEy+vFD8VTxZfLU9CMUFuGH//GY8dfx6PH58zfyG/Py8j3/8k7yX/Jw8oHyp/ SB8rTyxf/y1vLn8vjzCfMa8yvzPPNN//Ne82/zgPTG8YbzuPGo8bn/8crzzvPf9B30AfQS9CP0NP /0RfRW9Gf0jfSJ9qH79HWA9/Z49rP27vvt9LPeHge4Bn/G494uBOwO8xVGWPQ3NT9jpztFf8ce6w bchKK20f/24vTl3XII1CUBOcX1C+UkH8ZjVSX1NvVH6ahFf/fp//8EiDP/CrZB9hHGf78Ndlio1x D2idwU8Ed2lk1KDje9C7ADAlInNMkcGpgNHrAHg9LcC8ZqugdoBBdnBqXHVsZJHhfrwgX5BSkBG6 sKmAZWVD/2cfcA+ST7U/TmJgRZTfYwb1sUwwWlEvbNxhT5Pvmt/fSe9K/0wPmk9/lWKfe6wxz6BP ef9PE1ATVGH4cHMQ/1C/UhFi4KLvf2+AflXUe0RnVkmltFYkd2V1APDwOi+3wI/ggc+ntEbeIG06 /18/YE+nf2JvsK+xv7ADoer/tB+j7070e0ilv6bPtx+o75up/qtPYa1/u8QgU5ygVb2Abk/wUugw aGbwZHeEj/Cvu7VbcxBWsOcQOgXCJS7BpUBvZWZl1Gcu7PBdt00xsuHoEP+h+ZDTkX+Dj6Dvof/J z7y/91SmrM/Aj1PeYa8vsD+2r5+1L9R/8WCu4IwwYXnuUL5B7LFzMKRQ7lBRoDCy4HAxOjMxyk/D r9UlUP5Nx0/IX8lv2h/Lj8yf3v/vzr/Pz9Df4vhUXuDVn9PvX+L/1g/pv1lf5IF02aBQM/gQcsBu TlaQ9zB3Ot+9gHvQ+PB84d2wQN2wOlHVrvBz0pAu3rB0Xb/pAbvum5ZAO9+f2v/qVVLlwA9PwOZA 96DuwG5ubztQIEhhZPiQZXMwS9RhcHJgbvbgTcIy91HN9wBtfBB7cChtwlD4onYp9uBcAGVz8Fag TsBA6/dAZSAuV4Bn3J/dr96///Ov4N/h7/0v5A/lH+Yv0engdWJqZWPSv+j/6g+v6x8IH8Fx9gA6 xRBT+bYBxyBTUEVFUk1JHE5U/c/0j/WWb3V01fYgZ9igcsJAaXPgBlDUdXLvUE18IHNaEO9Q+kZX cHd8MAlPB58Ir7Jv/xOvFL9aP14vZM9l32bvZ///aQ/+vx/PmG8Wj5qPIU8lH/+dv57Pn9+3b3qZ e498n32v/ypfAp9U7YF/Ke8YL1rfW+//XP8Zj18fEy8jvxVPFl9kb/8bbxx/PL8enyZfRH9xH3Ih xYwwPYwwT1dB9gD3oPR5VHShOTagPdAzD0KP/0Y/S19sD0mPSp9M/1CvJ29vKH9PDyqfpJtjBGD6 kD3yYnJgY2ssZBCA8HBUzPm69GNmLFCPMP6RVa8wX9cxbzJxvq86WSM7WBMEQFdYgjL/W2RN2HBi 71BJXXNAbSxg9iK/kCARoHQjEDNYEG5mdfDAZCB59sB3LA1/Do9bVWJgY/5hZCFihHTgESD3EMIA pLDP71H5wFiwpLAgdrmAxwD+aaSwZKw7DzwfPS8+P2wv/zT/OO8af0CfQa9Cv0PPUh//dz8h7yL/ dQ94v3yPTZ9Or/97z34vgd9S71P/gD9WHyuP/yyfLa8uv1u/XM8x72DPjG//No83n29vcH85X2of ay+Tz/9tT5jPP79zb3R/dY92n4Of/6G/ec+bb5+Poz+nD38fkB//pk+or6xfhG+Ff6q/h59XX/9Y b1l/Wo+RL42vXb9ez1/fP7CPtyJikPZh9sCI0HVu/mTu0a2gvnCI4ImA9jDYQD/2cNmg+s/73/zv ZO99aF8R8K9wuJFikPgwdu9QTPA1L0w3Y9LB4AZQR+D7EMBjQHcQwMQQECDEohBC9ky2YMVqP7/P wN/B78L//n1I4LjwrgDGUMgNl/+ln/+aH5svz1+Uz5Xfci+dj56f/5+voL+tv9pvo++k/9g/2+// 37+pP6pP3v/hX+UPro+vn//jb7G/iH+Jj4qfi6+3X7hv/47fvG/vn5IPkx/Sn9Ovlk//zU/OX/b/ 0H/7/5yv1p/Xr//Yv9nP5s8E79z//p8CvwZv/wo/4k/zTwl/C98Pj+ef6K//De/qz7L6tH+1iraf 8D/xT746uiXyY7qf8x+9dmtkcWfsEO2gYnFNU2gAvuFU4ElTUEFO9I/1n/aq+Gd1ee0wAhBosEfQ vxD/Z4C5gGOxxlAkUGSvZb9mx/3GgS4oEPpf+28Y7/2PKb//Ks/4P/lP/+8A/wIPAx8EL/8RLzXf B18snw6/N187Lwyv/x4POm88z0B/Ef8TDz7fFS//6+/s/+4P7x8ZvxrP8k9Ev/9LDyHP9o8uDy8f +b8ovzlP/0W/K+//DzD/Mg8zHzQvQS//QO9gXzhvWg9gz2HfZa89v/9Ov2Y/Zf9q/0MPRB9pX0Y/ /xZvF38Yj0s/TE8bvxzPbt+RdGNSaWPEsHJkVY//Vp90H1i/fE99X1NvVH9bH/9cL10/Xk9fX2xf iG9ij38v/2nvie+Nv4q/i8+M348/kw//Z895L5JPlK+YX20fbi+Wv/9wT0cPSB9JL0o/dN91701v /5yfgD+BT1A/UU+nb1Tfez//kS+rv35vWi+Df4SPhZ+Gr3+ZD5ofuD+VqZt+ICDKIGd0bj2/IXS+ kKRmvOB4m6UQvFM6vLSmPHFjomn/mnumX7Xfnq53lJ/PoN+h7/+i/6QPdral78HPJa3MPyZbv7Jf r1y2OyaHs8q6D2i9AXFxtHdpZCTwxNCQgDDMJSK8TLlQYkkgQL2gaD0tMXK8Mb9xv3BqIFx1bGRi x0B+IJZf2VLZEVy98G5ls4P/tV+5D9tP3F7G4J7BroXd3/+xRo+/kM/an9z/4++aT5tfJ7wwyVWc QHJnJLAtYnhvdHTFoMpfy2/IO2IfcrvZAesfwv9xyFRhaP/FoXK/xwGxIO2/yGylg8lfz3cld+rw hPX0d2W8cCagXjrpYNjg6j/yhFafADr/rX+uj/JPsK/7X/xv+rPsuv/+z+6+9DTv3/Dv8f/zD8kv T/Vv9nn4PwZ0IEJycW4nzY8mX3n2b3O8wCBbP5xAeGDpkPncqHMIMDE6ZlC88Jvwbk54QB/Qdx46 CDDE0J8AxeFickCrEtAMcXIPQi7aAHSr/9f64RFLgbBdAgwx/ZES0P8E2dnT2n/Mj+u/7M8Yrwdv 96S2948LP0fFILzA1xAfkJ//f/r/HI//7yOvIEalsS406fAnkHOgMP2QMTn9dxAxFi8XPxhPGV8a bxt/3yrvHZ8erx+/LuhB+c8i708j/yUPNY8MISdSMbBuEZxQZG8gEXBubm9EJzs5QEhhZHJwZY5s K48NvzZFS2Fwm5BabjpCTXpyOtAgOoBts8UQ5NAobXqQPsIpOkHdqkBlvPB4UJ8QQDrAquD6Lpwg ZyiPKZ8qrzsvLM+/Ld9DXy//MQ8yH0dYQhPA8HJlZmYz7zT/Ng83H6NOXwwwUkU6D4BTP+YAXSBT UEVFUk04SU5UQ/88Dw7HdXRV2fBnM7ByeoBpvOBjpHR1TGAgTcUgc+Ww4RIARmxvd8UwT39Nz/9O 3/0fWd9a76h/rG+zD7Qf/7Uvtj+3T0TvZf/hb1y/44//Z39rT5V/Sw9qj2zvcJ/myf9uj2+f7x/E j8WfBYfHP0hP3wg/CURKz3nvqcRnCZBU6No+fehGOYIKQCxTr1S/H34Vm6DVEdVQvEBueSBnP+JW cn6PcXXpcKppIvN96CGSYXZWQGMhhY+Gn7EL1kkgYjrQOsB2EgAf1VC88BIBCjC8Mndhef93gIuA QP9CD0Mfgc9FP3+P/4/GjAHncJugE8A+UJ8gjAHnhMA+UIvRcGiM8D4wnFDwL2NvLVgQlGBWYJ8A P58wVxBXQFbwhMCb8CBU8ExTIGl3gDogE9yOH7+PL5A/kU+SX4Ba2gBl1xD8ZC6YT5lfmm+bf2fd oH/voY+in6Oii2B3w6DXEHEA/9bQVkGL8ZTAn4+k76X/pw9fo8+qb6t/rI9xAVM/8G37d4DpkCAR 8YwEYxCzEXbQ93exlGJ3gG+vkEAxjCF7oJ9MrK6fr6+wv61zMS454e+FBJfhliCIIHVXIJ9AtFGf s2HngA9BuqC8wHZpE1C2bndgw7AsEhCME3lWQOOVNDogIEwztP+2D7cffbgvfboh2gBXIG5glzJ1 /m5JgFegvKOzM4FQWCC6keBMNS9MN7oSwhe9n/++r7+/wM+tv8ZPx1/Ib3Jg7+nguW+6d3uAbz/g e4C7id+8Ts/DvXC8MHtwZMmfyq/ry7/Mz32fIiC0ogxgunP/xCPSj9Of1K/Vv8mP2S/aP3vbT3Jg M83/um+9Ybt8Yneo8Z8id4BhVlAKkAxget+Wg9x/3Y/en9+vfQmwcQD/19/mP+dP6F/cH+sP7B/t L/+nxnuAlGIncLwwvLI5wD3Q9+QkhJPpwW20IuSivAGV0WeWkqlsiXJuYntQnclc+CdhMIq68HC8 spXg8wH/wfSBjO9/8I/xn+5Twy6ycf8/4qlv+2/8f/2P7o8BLwI/uwNP8skyvDCXpT2QcBNQ/woQ DHC0gASPBZ8Grwe/BH//C68Mvw3P8tjSIbyyjNB2Qn938IxA9Nrk5+Pk8+kKQXZ/dvCVIEDADv8Q DxEfEi99/bRiZ5cjChFXAvYP9x/4L/5XlLK8stbTCcLkuh1vHn/r+FyXom1WUHU5oBffGO/bGf8b D331XKhBdUqgi3H6IIvQcpUgCfkiTyNf+FzeWfO3lUOycdAQZ1fBJe/XJv8oDykffdAQYyvQfPDj lqLp0U1BQxyydwBXoPOFIbwwanV7oJQTKj0Oof+pXS2fLq4xPzJPM180bw7vvz0fPi8/P6gSlKCF IGuUE/1XUGeX4ExQloR3YFbQe3D3l+CyQW5Qc5cAV6D0YrNDHVKwczdw0aFCMFNJUN8AL0FvQn9D j3JgUkWKusHwMzI2MZfSiDBHEApQd40g9HF3gFU2cbJxTSZy97wwmBEcsniVIP+yUOJIz/9J30rv S/9AT1K/U89U33EB2lSy6GyXcQoRYsLQskEvhFM3cIUilCJQUOItQe/1aJVxNrROkWZYIbqiVh+3 Vy9YP1lPfZbhlpMyzeD+NDkvOj/4XLIQY5a0Ik4j/0b2T1Gz8HEAsnFpA9JRaPf/UNNfL2A/YU9i XyotZD9lT//4XFzTUSeX1ddwiEBbgJUg/1CSRvhN9VG/a+9s/24PTQHgRkMzNjDjEEWQi9BPT1AU gxczXdFleAqAbn+VwKhgT1DpwlDchEO6wVD1F3BrlJBDdJExL3dPeF/jeW9V8ERDU+PkjAHzQf+z MlCSMRDEsEXQgUDlEFuBAbJiU1BFRVJNSfxOVHY/gE+BX4JvVf+Hr3+Iv4nPWjM3cLwwRLBIEGf/ MRA3gcPg4ZKVwKiCXDQlSP837rxROMHhAZfxnzGLD4wf+40vjj99T7FvObyQW+OoYP+zUVCRvGGG r5UPlh+XL4rv/5tfnG+df56Pn5+gr6G/osL+X6dfqG+pOqMPpB+lL6Y/j7IA/+JH8NChbWFprEH/ 4VCsQNdAqk+rX6xvrX+uiKRAaX7QZi7k4Gev/1+xD7Ifsy+i/HDxPOJwaBFHoGY9InGgdHBzcDov L3e7wHYgtOYvc68yrzBuL6+yXwDpwC+7cVCutSK2qbWAXqBlK1AdtYJmK1BfANdAe0hZyYYgUkyG cEsguz+8T3m9Xn19vwErUJOQuPBc8GNmMVwrQLdAt9fA73/B/71scZdxhzvwyM877jnxZ8A8L2G2 oMtPvaHSUNe2qcqftcY1tlEv6cC0sCPN/88PZzI0upFvOvJwzH0yNcwi00NxlrlS38lYt6i5Q7ev uLY3zCLTbq/J4blv2j+15DC6kS9G8P520M/X39uP31/cX91v3n8n4N/kr7WYNTjMMWJvvGR5037m b+j/0oY3zDEvcaLMfXrw6pR97dAAAAMADTT9PwUAAwAPNP0/BQACARQ0AQAAABAAAABUlKHAKX8Q G6WHCAArKiUXHgD6PwEAAAANAAAAUm9zZW4sIEJyaWFuAAAAAAIB4mUBAAAAFAAAAGHMxtIrYcdB q84B6sEz5rAAA9DAAgHjZQEAAAAVAAAAFGHMxtIrYcdBq84B6sEz5rAAA9DAAAAAAgF/AAEAAACN AAAAMDAwMDAwMDBFQUNCNTYxQjlGRDQ4RDRBQUU5OUQxNzg5MDk5QzVERTA3MDBFRDA4ODdBRUI1 OTVGNzREQjc0OTM0RjRDMzdDMDhEQzAwMDAwMTBEMUZGNjAwMDA2MkI4OTQ5MkIxMzBBNzQwQTQ4 Q0VFMzIyNzE3NEQ5RDAwMDJDRDExNjAwNDAwMDAAAAAAAwAGEG02h/oDAAcQeggAAAMAEBAAAAAA AwAREAAAAAAeAAgQAQAAAGUAAABUSElTSVNUSEUiQ0xVQlJPT00iRU5WSVJPTk1FTlRJUlVOQVBF RVJJTkdTRVJWSUNFSU9OTFlMRVRZT1VJTlRPTVlQRUVSSU5HRkFCUklDVU5ERVJDT05UUk9MTEVE Q09ORElUAAAAAJ+a ------=_NextPart_000_0699_01C65FC9.16319050 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_000_0699_01C65FC9.16319050-- From speermint-bounces@ietf.org Fri Apr 14 13:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSIj-0003DR-0I; Fri, 14 Apr 2006 13:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSIi-0003DM-Cx for speermint@ietf.org; Fri, 14 Apr 2006 13:41:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSIh-0001Ik-3H for speermint@ietf.org; Fri, 14 Apr 2006 13:41:44 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2006 10:41:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="25924419:sNHT41302032" 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 k3EHfaTL010016; Fri, 14 Apr 2006 13:41:36 -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.211); Fri, 14 Apr 2006 13:41:36 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 13:41:35 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301570704@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZfx9mbI1e558tVS7a1nyNEKfv8awAHFS7AAAEkLUA= From: "Michael Hammer \(mhammer\)" To: "Malas, Daryl" , "Richard Shockey" X-OriginalArrivalTime: 14 Apr 2006 17:41:36.0786 (UTC) FILETIME=[ADB3B720:01C65FEA] X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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, When you see a sip URI of form local@domainB, only domain B really knows for sure how to handle the local part (it may not be DN). If in fact the DN is owned by companyB, for companyA to assert ownership of that number might run afoul of national numbering authority regulations. Best not to go there. Even if not, it could insert confusion into systems that see or store such information. It may be better to keep the targeting of the request in the Request-URI separate from the routing of the message that can be done by the Route header. What you seem to be reaching for is the additional query capability, that in cases where the ENUM returns a sip:local@domainB.com and you can't get to domainB for some reason is the ability to look up domainB and find some intermediary domainC through which the call could be routed: R-URI: sip:DN@domainB.com (I made it so A and B number are from and to) From: sip:DN@domainA Route: domainC (C is "transit" L5 carrier) Although, domainB should be routable at L3 once the DNS dip tells you what the IP address is, perhaps there are some business reasons for not going direct. But, if we do our job well, that should be for some function beyond just routing. Mike > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com]=20 > Sent: Friday, April 14, 2006 1:05 PM > To: Richard Shockey; Michael Hammer (mhammer) > Cc: Stastny Richard; henry@pulver.com; Reinaldo Penno;=20 > speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > I don't really have a strong argument against this, so=20 > perhaps it was a bad example in the beginning....and not=20 > specifically intended or specified in the draft. =20 >=20 > One wild thought, which may have multiple solutions already=20 > available... >=20 > I was thinking in line with a TN located in the user part of=20 > the SIP URI. An ENUM server could respond with this type of=20 > information in the SIP URI, such as,=20 > sip:3035551212@companyA.com...companyA.com may be acting as=20 > an IXC in order to reach user 3035551212, when in fact the=20 > user actually exists at 3035551212@companyB.com; however, I > (companyC.com) am not directly peered to companyB.com.=20 > CompanyA.com may be peered with CompanyB.com, and provides a=20 > least cost route instead of terminating over the PSTN.=20 >=20 > Perhaps it is a funky, edge example...but I can foresee this=20 > occurring. >=20 > --Daryl M. >=20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, April 14, 2006 7:31 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Malas, Daryl; henry@pulver.com; Reinaldo=20 > Penno; speermint@ietf.org > Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows >=20 > Michael Hammer (mhammer) wrote: > > I agree. This should not be about reaching some PSTN number. And=20 > > presumably, you are contacting this peering point because a previous > DNS > > or equivalent dip has indicated that a particular domain can be > reached > > through this peering point. >=20 >=20 > Correct... the translation of the PSTN number to some URI is=20 > the ENUM function.=20 > Now that said in those countries with full database number=20 > portability such as the US you cannot effectively delegate on=20 > 10,000 or 1,000 number blocks. > The > resolution to point of interconnection must be at the full=20 > E.164 number. >=20 >=20 >=20 >=20 > >=20 > > Mike > > =20 > >=20 >=20 > --=20 >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; =20 > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 13:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSOK-0006J6-J6; Fri, 14 Apr 2006 13:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSOJ-0006J1-DZ for speermint@ietf.org; Fri, 14 Apr 2006 13:47:31 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSOJ-0001OA-0r for speermint@ietf.org; Fri, 14 Apr 2006 13:47:31 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3EHlTGp005162; Fri, 14 Apr 2006 10:47:29 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k3EHlT6c005161; Fri, 14 Apr 2006 10:47:29 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Apr 2006 10:47:29 -0700 From: David Meyer To: Patrick Melampy Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Message-ID: <20060414174729.GA5019@1-4-5.net> References: <20060414170643.GB1551@1-4-5.net> <027b01c65fe7$a50cee50$6701a8c0@acmepacket.com> Mime-Version: 1.0 In-Reply-To: <027b01c65fe7$a50cee50$6701a8c0@acmepacket.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: f66b12316365a3fe519e75911daf28a8 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: , Content-Type: multipart/mixed; boundary="===============2083933309==" Errors-To: speermint-bounces@ietf.org --===============2083933309== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Let's see... > Assume the following 4 bi-lateral agreements >=20 > A---B B---C >=20 > B---D >=20 > B---E >=20 > What your saying, is that B's bilateral agreements with C, D, and E do not > have any value to the bilateral relationship B has with A. Well, that would certainly be the case for L3 peering, and in practice, what it would mean is that A wouldn't to say, C, D and E; in fact, this is what the so-called tier-1's peering policies are in many cases designed to implment (i.e., you want connectivity to my customers, that's fine, let me sign you up as a transit customer; that's how the game works at L3). The "transitiveness" of the relationhsip (like (A,B) ^ (B,C) =3D> (A,C)) is just another way of saying A and C are transit customers of B (and BTW, A nd C are not tier-1 providers in this case; check with A and C's marketing departments to see if this is satisfactory). Now, in the L5 case, there is no (physical) barrier to a transitive trust relationship A and C, or if A "trusts" B, then A anyone else in the universe that B has connectivity might have (L5) connectivty (B is any one or more of the billion kinds of proxy we've been discussing here). You need something like the latter to get the "value" you're talking about.=20 > I would argue that this is not true. Since your accepting of the notion t= hat > bilateral agreements make sense, its clear that many bilateral agreements > will exist.=20 Yes, bilats will (continue to) exist. > The aggregation of bi-lateral agreements defines logically a > "transit" carrier.=20 I'm not sure what you mean by transit here, but if we're talking about L3 connectivity, no. See above. > If "B" were the public internet, then A would have to > have a contract and business terms with C, D, and E. This would include m= any > complex business issues which are definitely out of scope. I don't see how the fact that B is the public Internet (v. some private network/interconnect) effects the fact that business relationships would be required; B seems to be proxying those issues to in the transitive models we've been talking about. As far a OOS goes, definitely. =09 > I think that the very presence of bilateral agreements for VOIP implies t= hat > carriers like B will exist. B in this case is a L5 transit provider (aming other things), which is what we're debating. My sense: just don't require it. Dave --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFEP+AxORgD1qCZ2KcRAh/dAJ909X61x+GdLRgNwBhJlpIwsm4d5QCWIT9h Ju2Kx04bPqXYfOiFjXzlSA== =wjvv -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- --===============2083933309== 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 --===============2083933309==-- From speermint-bounces@ietf.org Fri Apr 14 13:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTy-0001bz-UM; Fri, 14 Apr 2006 13:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTx-0001bu-DB for speermint@ietf.org; Fri, 14 Apr 2006 13:53:21 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSTv-0001Xp-VR for speermint@ietf.org; Fri, 14 Apr 2006 13:53:21 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3EHrJ8K005209; Fri, 14 Apr 2006 10:53:19 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k3EHrJUP005208; Fri, 14 Apr 2006 10:53:19 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 14 Apr 2006 10:53:19 -0700 From: David Meyer To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transit vs peering Message-ID: <20060414175319.GB5019@1-4-5.net> References: <32755D354E6B65498C3BD9FD496C7D463C4EC2@oefeg-s04.oefeg.loc> <44353325.5080802@shockey.us> <20060406154408.GE12968@nic.at> <20060414170643.GB1551@1-4-5.net> <20060414172416.GD28504@nic.at> Mime-Version: 1.0 In-Reply-To: <20060414172416.GD28504@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: 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: , Content-Type: multipart/mixed; boundary="===============0091006825==" Errors-To: speermint-bounces@ietf.org --===============0091006825== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 14, 2006 at 07:24:16PM +0200, Otmar Lendl wrote: > On 2006/04/14 19:04, David Meyer wrote: > > On Thu, Apr 06, 2006 at 05:44:08PM +0200, Otmar Lendl wrote: > > > On 2006/04/06 17:04, Richard Shockey wrote: > > > > Stastny Richard wrote: > > > > >The problem I have with the FCC definition is that > > > > >is states that peering is always bi-lateral > > > > > > > > > >The major reason for setting up SPEERMINT was that > > > > >everybody seems at least to agree that bi-lateral > > > > >peering does not scale globally. > > > >=20 > > > > All peering arrangements among IP backbones are bi-lateral and the = Internet=20 > > > > seems to have scaled reasonably well. > > >=20 > > > The reason for that is "transit". It is thus not necessary that > > > any Autonomous Systems peers with all other AS. > >=20 > > We might also want to stay away from the term transit, > > since it doesn't really exist (at least in the L3 > > internet).=20 >=20 > Hm? >=20 > Back in the days when I was working for a big ISPs we used to > call the product "I'll connect your small network to the world" > "IP transit". That's synonymous to "IP upstream". You sell transit, that doesn't mean (if you're a tier-1) that transit exists. > (see. e.g. http://en.wikipedia.org/wiki/IP_Transit_%28Internet%29 ) Oh yes, its in the wikipedia, must be right (not that I don't love the random article feature). > That contrasts to IP peering where both sides just give each > other access to the own network (+customers) but not upstream. i.e, transith is the sum over all of these. If you buy transit, you're buying the set of peering relationships your provider has. But this is ancient stuff. > On the protocol level, both are BGP links. It's just the > configuration of the route filters which make the difference. > (plus of course the commercial side) So? > > > I think we should define the difference between "Peering" and > > > "Interconnection" (which in my mind also allows for transit). > > >=20 > > > Bi-lateral peering alone will definitly not solve the world-wide > > > reachability problem. > >=20 > > Other than the (obvious) scaling problems, why not? OTOH, > > if I don't have a route to you, I don't have a route to > > you. How do I get your routes? I peer with you.=20 >=20 > *If* you can solve the scaling, then yes, you're correct. >=20 > It will depend on how the VoIP business evolves. I may well be that > all corporate PBX will act as their own independent VoIP operators > who want to peer with each other directly. (Just as the corporate > mailservers connect to each other without the help of a carrier's > mailserver.) Sure, understand that. > >From the point of view of a corporate PBX: using a VoIP service > provider to connect to some other corporate PBX is to use them=20 > as a transit network. >=20 > As I see the problem, you will have thousands (if not millions) > peering partners to get universal connectivity without resorting > to transit networks. That's only manageable by automatic ad-hoc > peering.=20 Well now, that is interesting. Is universal connectivity a requirement? Clearly, a desireable feature (I want to be able to call you, for example). But does the architecture have to implement it? In the Internet, such connectivity is implemented via the sum of the peering relationships; its not built into, say, BGP. Dave --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEP+GPORgD1qCZ2KcRAsEIAKCThtYnqWeyZCnMTWVY4FX9TIV4+gCgh/EB Mc53oFTLZbnHkL8ZnD33XIY= =56V7 -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- --===============0091006825== 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 --===============0091006825==-- From speermint-bounces@ietf.org Fri Apr 14 14:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSd9-000324-Nu; Fri, 14 Apr 2006 14:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSd8-000318-DX for speermint@ietf.org; Fri, 14 Apr 2006 14:02:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSd8-000208-3I for speermint@ietf.org; Fri, 14 Apr 2006 14:02:50 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2006 11:02:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="25925738:sNHT25012796" 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 k3EI2jTL013555; Fri, 14 Apr 2006 14:02:45 -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.211); Fri, 14 Apr 2006 14:02:45 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 14:02:44 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301570719@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbwAAS/2TAAB2Lu0AAAtU6Q From: "Michael Hammer \(mhammer\)" To: "Pfautz, Penn L, NEO" , X-OriginalArrivalTime: 14 Apr 2006 18:02:45.0473 (UTC) FILETIME=[A1E5FD10:01C65FED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Penn, I think it stems from the underlying requirement that before establishing communications (signaling) to a peer, one needs to know who they are talking to. The two general options are: 1) through the use of some type of PKI that anyone can trace back through to some certificate chain to a trusted root certificate authority, or 2) through bi-lateral agreements between peers (and associated out-of-band exchange of symmetric keying material). In the former case, there will be arguments over who gets to be the root, and what happens if there are multiple roots. (Just like with ENUM :) In the latter case, billions of customers are proxied by hundreds of thousands of organizations. But, if there are hundreds of "transit L5 providers" that are willing and able to be the "truested third party" between proxy A and B, who both have bilateral agreements to transit C, but not directly to each other, then a workable solution is possible. The hundreds of L5 transit providers in turn may come to some bilateral agrements with each other to reach universal reachability.=20 You can guess at who the transit L5 players will be. :) The market will decide which case is more efficient from a business standpoint. There may end up being a mixture of both. Mike > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20 > Sent: Friday, April 14, 2006 1:34 PM > To: speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > Hmm... Maybe my mind is already on the weekend but how does=20 > all this authorization and authentication fit in with the=20 > scaling concerns people keep expressing? Are we driving back=20 > to a bilateral process?=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, April 14, 2006 1:27 PM > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows=20 >=20 > Hi Michael, comments inline... >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, April 14, 2006 7:50 AM > > To: Hadriel Kaplan; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture=20 > Message Flows > >=20 > > I think we want this exchange to be between peers. Registration is > more > > subordinate to superior. You don't normally see SIP Proxies > registering > > to their client phones. >=20 > Nor do they generate such register requests anyway. They'd=20 > have to have a UA component to do it, and act as a registrar=20 > on the other side, and registration is not the semantics you=20 > want anyway. > =20 > > In both cases, there is an authentication and authorization, so the > key > > mangement issues will be there in both cases. I don't see=20 > that as a=20 > > discriminating factor. >=20 > Indeed, that's why I said the sub/notify did not resolve my confusion. > In > either method the auth problems are not solved, assuming you=20 > meant the Subscribe would be challenged as the auth=20 > mechanism. If you just meant the xml contents would be used=20 > to provide some auth mechanism, then that's different. >=20 >=20 > > In passing some type of session key to the requestor, I saw a more=20 > > general need to pass parameter values regarding the interconnection=20 > > scheme. Suggesting XML bodies to do that was simply making the=20 > > mechanism more general. While we are still in the stages=20 > of trying to=20 > > figure out what information needs to be exchanged between peers,=20 > > generality seems useful. >=20 > Agreed, as I said I assumed sub/notify would be proposed for=20 > policy exchanges at some point in this WG. It was the=20 > proposed proxy-proxy authentication idea in the draft that=20 > confuses me. >=20 > -hadriel >=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 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 14:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSjB-0001Ox-0H; Fri, 14 Apr 2006 14:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSj8-0001Os-Um for speermint@ietf.org; Fri, 14 Apr 2006 14:09:03 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSj6-0002R9-LB for speermint@ietf.org; Fri, 14 Apr 2006 14:09:00 -0400 Received: from PMelampy [10.0.200.157] by acmepacket.com with ESMTP (SMTPD-9.02) id A53B079C; Fri, 14 Apr 2006 14:08:59 -0400 From: "Patrick Melampy" To: "'David Meyer'" Subject: RE: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Date: Fri, 14 Apr 2006 14:08:59 -0400 Message-ID: <02bd01c65fee$80f3e300$6701a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZf63+jCW/Y8zO+QqCnydGB10rg0gAASzdQ In-Reply-To: <20060414174729.GA5019@1-4-5.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Considering 4 bilateral agreements again ... A---B B---C B---D B---E You wrote... Now, in the L5 case, there is no (physical) barrier to a transitive trust relationship A and C, or if A "trusts" B, then A anyone else in the universe that B has connectivity might have (L5) connectivty (B is any one or more of the billion kinds of proxy we've been discussing here). You need something like the latter to get the "value" you're talking about. You are correct. The very nature of SIPS chains of trust can easily traverse these 4 bilateral relationships. This not only possible but preferred. And yes B would have to be a PROXY of some type to enable this chain of trust. What would we call B? Is B a "transit carrier"? Is B an "aggregator". I think Speermint should define what we call B, and consider the role of B at L5. Specific questions come to mind for B's role: 1.) What types of data associated with these bilateral exchanges would enable this type of aggregation? 2.) What are the L5 routing issues? 3.) How can we manage congestion and fairness? 4.) When if ever does the media need to follow the signaling? When? Why? As soon as an entity has more than one bi-lateral agreement, it is quite likely these issues will start to occur. Maybe we should ask our carrier friends -- do they expect to have more than one bilateral agreement? -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net] Sent: Friday, April 14, 2006 1:47 PM To: Patrick Melampy Cc: 'Otmar Lendl'; speermint@ietf.org Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Let's see... > Assume the following 4 bi-lateral agreements > > A---B B---C > > B---D > > B---E > > What your saying, is that B's bilateral agreements with C, D, and E do not > have any value to the bilateral relationship B has with A. Well, that would certainly be the case for L3 peering, and in practice, what it would mean is that A wouldn't to say, C, D and E; in fact, this is what the so-called tier-1's peering policies are in many cases designed to implment (i.e., you want connectivity to my customers, that's fine, let me sign you up as a transit customer; that's how the game works at L3). The "transitiveness" of the relationhsip (like (A,B) ^ (B,C) => (A,C)) is just another way of saying A and C are transit customers of B (and BTW, A nd C are not tier-1 providers in this case; check with A and C's marketing departments to see if this is satisfactory). Now, in the L5 case, there is no (physical) barrier to a transitive trust relationship A and C, or if A "trusts" B, then A anyone else in the universe that B has connectivity might have (L5) connectivty (B is any one or more of the billion kinds of proxy we've been discussing here). You need something like the latter to get the "value" you're talking about. > I would argue that this is not true. Since your accepting of the notion that > bilateral agreements make sense, its clear that many bilateral agreements > will exist. Yes, bilats will (continue to) exist. > The aggregation of bi-lateral agreements defines logically a > "transit" carrier. I'm not sure what you mean by transit here, but if we're talking about L3 connectivity, no. See above. > If "B" were the public internet, then A would have to > have a contract and business terms with C, D, and E. This would include many > complex business issues which are definitely out of scope. I don't see how the fact that B is the public Internet (v. some private network/interconnect) effects the fact that business relationships would be required; B seems to be proxying those issues to in the transitive models we've been talking about. As far a OOS goes, definitely. > I think that the very presence of bilateral agreements for VOIP implies that > carriers like B will exist. B in this case is a L5 transit provider (aming other things), which is what we're debating. My sense: just don't require it. Dave _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 14 14:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTFt-0001GK-4i; Fri, 14 Apr 2006 14:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTFs-0001GF-7i for speermint@ietf.org; Fri, 14 Apr 2006 14:42:52 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUTFr-0003nA-Fa for speermint@ietf.org; Fri, 14 Apr 2006 14:42:52 -0400 Received: from HKaplan [10.0.200.145] by acmepacket.com with ESMTP (SMTPD-9.02) id AD290440; Fri, 14 Apr 2006 14:42:49 -0400 From: "Hadriel Kaplan" To: "'Michael Hammer \(mhammer\)'" , "'Pfautz, Penn L, NEO'" , Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 14:42:58 -0400 Message-ID: <008901c65ff3$403c67b0$91c8000a@acmepacket.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: AcZZkYOcA08HWr6HQfGDr9/mSqMb9wACf1pAAAFJvOAAAiJOEAABDZiwAABcABAAAIu+0AAAZ4BQAADfH8AAANBGIAAGSD0wABonafAAC9zEQAAChn+AAAAohbAAAF+yMAApTk6wAG6BEAAAKqlagAAAXNXAAAdWDKAABGDfYAAhRvYQAAMvDtAAAR7yUAAAteFAAAOHrXAABbOS8AAquuGAAAKKRfAAD5ZjEAAVhkbwAAS/2TAAB2Lu0AAAtU6QAADUIsA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301570719@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 Yup, agreed - but even in the bi-lat case one could use mutual-TLS instead of digest/challenge, and just have the certs be created/rooted by one of the sides. (e.g., the transit provider) Or one could accept self-signed certs, and use a pre-shared password for challenge/response but without sending extraneous messages to do so. For example, just proxy-challenge the initial Invite request using something like AKA. (though it would require some changes to enable a proxy to do challenge/response) The advantage then is for the duration of the TLS session you do not need to re-auth at a higher layer. And for a tiered bi-lat relationship model you're probably going to want to keep these "connections" alive all the time. -hadriel > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, April 14, 2006 2:03 PM > To: Pfautz, Penn L, NEO; speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > Penn, > > I think it stems from the underlying requirement that before > establishing communications (signaling) to a peer, one needs to know who > they are talking to. The two general options are: > > 1) through the use of some type of PKI that anyone can trace back > through to some certificate chain to a trusted root certificate > authority, or > > 2) through bi-lateral agreements between peers (and associated > out-of-band exchange of symmetric keying material). > > In the former case, there will be arguments over who gets to be the > root, and what happens if there are multiple roots. (Just like with > ENUM :) > > In the latter case, billions of customers are proxied by hundreds of > thousands of organizations. But, if there are hundreds of "transit L5 > providers" that are willing and able to be the "truested third party" > between proxy A and B, who both have bilateral agreements to transit C, > but not directly to each other, then a workable solution is possible. > The hundreds of L5 transit providers in turn may come to some bilateral > agrements with each other to reach universal reachability. > > You can guess at who the transit L5 players will be. :) > > The market will decide which case is more efficient from a business > standpoint. There may end up being a mixture of both. > > Mike > > > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Friday, April 14, 2006 1:34 PM > > To: speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > Hmm... Maybe my mind is already on the weekend but how does > > all this authorization and authentication fit in with the > > scaling concerns people keep expressing? Are we driving back > > to a bilateral process? > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Friday, April 14, 2006 1:27 PM > > To: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > > > Hi Michael, comments inline... > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Friday, April 14, 2006 7:50 AM > > > To: Hadriel Kaplan; speermint@ietf.org > > > Subject: RE: [Speermint] SPEERMINT Routing Architecture > > Message Flows > > > > > > I think we want this exchange to be between peers. Registration is > > more > > > subordinate to superior. You don't normally see SIP Proxies > > registering > > > to their client phones. > > > > Nor do they generate such register requests anyway. They'd > > have to have a UA component to do it, and act as a registrar > > on the other side, and registration is not the semantics you > > want anyway. > > > > > In both cases, there is an authentication and authorization, so the > > key > > > mangement issues will be there in both cases. I don't see > > that as a > > > discriminating factor. > > > > Indeed, that's why I said the sub/notify did not resolve my confusion. > > In > > either method the auth problems are not solved, assuming you > > meant the Subscribe would be challenged as the auth > > mechanism. If you just meant the xml contents would be used > > to provide some auth mechanism, then that's different. > > > > > > > In passing some type of session key to the requestor, I saw a more > > > general need to pass parameter values regarding the interconnection > > > scheme. Suggesting XML bodies to do that was simply making the > > > mechanism more general. While we are still in the stages > > of trying to > > > figure out what information needs to be exchanged between peers, > > > generality seems useful. > > > > Agreed, as I said I assumed sub/notify would be proposed for > > policy exchanges at some point in this WG. It was the > > proposed proxy-proxy authentication idea in the draft that > > confuses me. > > > > -hadriel > > > > > > > > _______________________________________________ > > 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 Fri Apr 14 14:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTTv-0001gT-E4; Fri, 14 Apr 2006 14:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUTTt-0001gO-Ee for speermint@ietf.org; Fri, 14 Apr 2006 14:57:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUTTr-00041t-Ke for speermint@ietf.org; Fri, 14 Apr 2006 14:57:21 -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] SPEERMINT Routing Architecture Message Flows Date: Fri, 14 Apr 2006 21:00:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4991@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] SPEERMINT Routing Architecture Message Flows Thread-Index: AcZfx9mbI1e558tVS7a1nyNEKfv8awAHFS7AAAEkLUAAAztrCA== From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Malas, Daryl" , "Richard Shockey" X-Spam-Score: 0.5 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 would like to add regarding ENUM: =20 We need to distinguish which type of ENUM we are talking about: In User ENUM it is the end-user who enters the SIP AoR (if he gets one = from his provider ;-) in public infrastructure ENUM it is the CoR hosting the number in = question He is entering what he wants that somebody elso should see: =20 1. he may enter the public user identity aka AoR,=20 2. but he may also enter the ingress point of a transit network, it is = his decision =20 How the transit network then routes the call to the final destination = network is up to=20 the transit network, they may use a private ENUM =20 What is entered into private ENUMs is private. =20 Richard ________________________________ Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Gesendet: Fr 14.04.2006 19:41 An: Malas, Daryl; Richard Shockey Cc: Stastny Richard; henry@pulver.com; Reinaldo Penno; = speermint@ietf.org Betreff: RE: [Speermint] SPEERMINT Routing Architecture Message Flows Daryl, When you see a sip URI of form local@domainB, only domain B really knows for sure how to handle the local part (it may not be DN). If in fact the DN is owned by companyB, for companyA to assert ownership of that number might run afoul of national numbering authority regulations. Best not to go there. Even if not, it could insert confusion into systems that see or store such information. It may be better to keep the targeting of the request in the Request-URI separate from the routing of the message that can be done by the Route header. What you seem to be reaching for is the additional query capability, that in cases where the ENUM returns a sip:local@domainB.com and you can't get to domainB for some reason is the ability to look up domainB and find some intermediary domainC through which the call could be routed: R-URI: sip:DN@domainB.com (I made it so A and B number are from and to) From: sip:DN@domainA Route: domainC (C is "transit" L5 carrier) Although, domainB should be routable at L3 once the DNS dip tells you what the IP address is, perhaps there are some business reasons for not going direct. But, if we do our job well, that should be for some function beyond just routing. Mike > -----Original Message----- > From: Malas, Daryl [mailto:Daryl.Malas@Level3.com] > Sent: Friday, April 14, 2006 1:05 PM > To: Richard Shockey; Michael Hammer (mhammer) > Cc: Stastny Richard; henry@pulver.com; Reinaldo Penno; > speermint@ietf.org > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows > > I don't really have a strong argument against this, so > perhaps it was a bad example in the beginning....and not > specifically intended or specified in the draft.=20 > > One wild thought, which may have multiple solutions already > available... > > I was thinking in line with a TN located in the user part of > the SIP URI. An ENUM server could respond with this type of > information in the SIP URI, such as, > sip:3035551212@companyA.com...companyA.com may be acting as > an IXC in order to reach user 3035551212, when in fact the > user actually exists at 3035551212@companyB.com; however, I > (companyC.com) am not directly peered to companyB.com. > CompanyA.com may be peered with CompanyB.com, and provides a > least cost route instead of terminating over the PSTN. > > Perhaps it is a funky, edge example...but I can foresee this > occurring. > > --Daryl M. > > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, April 14, 2006 7:31 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Malas, Daryl; henry@pulver.com; Reinaldo > Penno; speermint@ietf.org > Subject: Re: [Speermint] SPEERMINT Routing Architecture Message Flows > > Michael Hammer (mhammer) wrote: > > I agree. This should not be about reaching some PSTN number. And > > presumably, you are contacting this peering point because a previous > DNS > > or equivalent dip has indicated that a particular domain can be > reached > > through this peering point. > > > Correct... the translation of the PSTN number to some URI is > the ENUM function. > Now that said in those countries with full database number > portability such as the US you cannot effectively delegate on > 10,000 or 1,000 number blocks. > The > resolution to point of interconnection must be at the full > E.164 number. > > > > > > > > Mike > >=20 > > > > -- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > ENUM +87810-13313-31331 > PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > Fax: +1 815.333.1237 > or > > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 17 13:05:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXAb-0000YQ-9a; Mon, 17 Apr 2006 13:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXAa-0000YL-Js for speermint@ietf.org; Mon, 17 Apr 2006 13:05:48 -0400 Received: from mail.canc.com ([66.219.34.86] helo=billyjoe.canc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXAa-0000pI-7X for speermint@ietf.org; Mon, 17 Apr 2006 13:05:48 -0400 Received: from localhost (localhost [127.0.0.1]) by billyjoe.canc.com (Postfix) with ESMTP id C7C8BA924; Mon, 17 Apr 2006 12:05:47 -0500 (CDT) Received: from billyjoe.canc.com ([127.0.0.1]) by localhost (billyjoe [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01051-03; Mon, 17 Apr 2006 12:05:47 -0500 (CDT) Received: by billyjoe.canc.com (Postfix, from userid 1015) id 97726A90D; Mon, 17 Apr 2006 12:05:47 -0500 (CDT) Date: Mon, 17 Apr 2006 12:05:47 -0500 From: jjackson@billyjoe.canc.com To: Patrick Melampy Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - transitvs peering Message-ID: <20060417170547.GA1090@billyjoe.canc.com> References: <20060414174729.GA5019@1-4-5.net> <02bd01c65fee$80f3e300$6701a8c0@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <02bd01c65fee$80f3e300$6701a8c0@acmepacket.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at canc.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 I agree that we should analyze the L5 transit case a bit more. In reality, = L5 transit will be somewhat crippled compared to L3 transit since we're not= talking about actual L5 routing protocols. One key question should be "wha= t is the key driver for L5 transit ?". I don't believe that QoS should be a= driver - this can be solved at L3. I don't believe that an L5 peering fabr= ic needs to be involved at L5 any more than an L3 peering fabric needs to b= e involved at L3. I don't believe that L5 transit needs to exist to help sc= ale the peering relationships. That leaves business relationships (and prob= ably some other drivers that I'm missing). If we get into the same L3 games= of looking at ratios etc. as a basis for peering (which at L3 could be set= tlement-free or paid - do we consider OSP etc ?) the L5 transit provider st= arts to make more sense. One of the key issues for L5 transit would be "how= do you convey that A is reachable via B ?". Keep in mind that as with L3, = A could be using transit from B to get to C, D, and E, while using direct p= eering relationships to get to F, G, and H. I apologize if I'm beating the dead horse... I'm joining this a bit late. James On Fri, Apr 14, 2006 at 02:08:59PM -0400, Patrick Melampy wrote: > Considering 4 bilateral agreements again ... >=20 > A---B B---C >=20 > B---D >=20 > B---E > You wrote...=09 > Now, in the L5 case, there is no (physical) barrier to a > transitive trust relationship A and C, or if A "trusts" > B, then A anyone else in the universe that B has > connectivity might have (L5) connectivty (B is any one or > more of the billion kinds of proxy we've been discussing > here). You need something like the latter to get the > "value" you're talking about. >=20 > You are correct. The very nature of SIPS chains of trust can easily trave= rse > these 4 bilateral relationships. This not only possible but preferred. And > yes B would have to be a PROXY of some type to enable this chain of trust. >=20 > What would we call B? Is B a "transit carrier"? Is B an "aggregator". I > think Speermint should define what we call B, and consider the role of B = at > L5. Specific questions come to mind for B's role: >=20 > 1.) What types of data associated with these bilateral exchanges would > enable this type of aggregation? > 2.) What are the L5 routing issues? > 3.) How can we manage congestion and fairness? > 4.) When if ever does the media need to follow the signaling? When? Why? >=20 > As soon as an entity has more than one bi-lateral agreement, it is quite > likely these issues will start to occur. Maybe we should ask our carrier > friends -- do they expect to have more than one bilateral agreement? >=20 >=20 > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Friday, April 14, 2006 1:47 PM > To: Patrick Melampy > Cc: 'Otmar Lendl'; speermint@ietf.org > Subject: Re: [Speermint] RE: Background Reading on NGN Interconnect - > transitvs peering >=20 > Let's see... >=20 > > Assume the following 4 bi-lateral agreements > >=20 > > A---B B---C > >=20 > > B---D > >=20 > > B---E > >=20 > > What your saying, is that B's bilateral agreements with C, D, and E do = not > > have any value to the bilateral relationship B has with A. >=20 > Well, that would certainly be the case for L3 peering, > and in practice, what it would mean is that A wouldn't to > say, C, D and E; in fact, this is what the so-called > tier-1's peering policies are in many cases designed to > implment (i.e., you want connectivity to my customers, > that's fine, let me sign you up as a transit customer; > that's how the game works at L3). The "transitiveness" of > the relationhsip (like (A,B) ^ (B,C) =3D> (A,C)) is just > another way of saying A and C are transit customers of B > (and BTW, A nd C are not tier-1 providers in this case; > check with A and C's marketing departments to see if this > is satisfactory). >=20 > Now, in the L5 case, there is no (physical) barrier to a > transitive trust relationship A and C, or if A "trusts" > B, then A anyone else in the universe that B has > connectivity might have (L5) connectivty (B is any one or > more of the billion kinds of proxy we've been discussing > here). You need something like the latter to get the > "value" you're talking about.=20 >=20 > > I would argue that this is not true. Since your accepting of the notion > that > > bilateral agreements make sense, its clear that many bilateral agreemen= ts > > will exist.=20 >=20 > Yes, bilats will (continue to) exist. >=20 > > The aggregation of bi-lateral agreements defines logically a > > "transit" carrier.=20 >=20 > I'm not sure what you mean by transit here, but if we're > talking about L3 connectivity, no. See above. >=20 > > If "B" were the public internet, then A would have to > > have a contract and business terms with C, D, and E. This would include > many > > complex business issues which are definitely out of scope. >=20 > I don't see how the fact that B is the public Internet > (v. some private network/interconnect) effects the fact > that business relationships would be required; B seems to > be proxying those issues to in the transitive models > we've been talking about. >=20 > As far a OOS goes, definitely. > =09 > > I think that the very presence of bilateral agreements for VOIP implies > that > > carriers like B will exist. >=20 > B in this case is a L5 transit provider (aming other > things), which is what we're debating. My sense: just > don't require it. >=20 > Dave >=20 >=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 Apr 20 11:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbVg-0006WC-5s; Thu, 20 Apr 2006 11:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbVe-0006Rh-TQ for speermint@ietf.org; Thu, 20 Apr 2006 11:55:58 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbVd-0007Ii-Lt for speermint@ietf.org; Thu, 20 Apr 2006 11:55:58 -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" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Apr 2006 11:55:29 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247F7C@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 66 Location Announced Thread-Index: AcZkjqg1etqwsLNfQxe8a1c5Zu9fug== From: "Livingood, Jason" To: X-OriginalArrivalTime: 20 Apr 2006 15:55:30.0291 (UTC) FILETIME=[D9742C30:01C66492] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Speermint] IETF 66 Location Announced 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 See http://www.ietf.org/meetings/IETF-66.html for location and hotel information, as well as to register to attend. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 20 12:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbpV-00068M-P8; Thu, 20 Apr 2006 12:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbpV-000689-4E for speermint@ietf.org; Thu, 20 Apr 2006 12:16:29 -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 1FWbAj-00065Y-CJ for speermint@ietf.org; Thu, 20 Apr 2006 11:34:21 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWaxZ-0002S9-4x for speermint@ietf.org; Thu, 20 Apr 2006 11:20:46 -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" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Apr 2006 11:19:00 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7305247F75@PACDCEXCMB01.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG Statement: Normative and Informative References Thread-Index: AcZjuJS7bqC4CHwZSq2N2xviKNfxlgA1RJRg From: "Livingood, Jason" To: X-OriginalArrivalTime: 20 Apr 2006 15:20:21.0740 (UTC) FILETIME=[F0A8D2C0:01C6648D] X-Spam-Score: -2.5 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Speermint] FW: IESG Statement: Normative and Informative References 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 FYI=20 -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 Sent: Wednesday, April 19, 2006 9:50 AM To: IETF Announcement list Subject: IESG Statement: Normative and Informative References=20 Normative and Informative References Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC. There are many styles for references, and the RFCs have one of their own. Please follow the reference style used in recent RFCs. Please note that for documents that have been assigned an STD or BCP number, the number must be included in the reference. Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC. Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. Note 2: It is not considered necessary to cite basic specifications that may be safely assumed to be known to practitioners (for example, RFC 791 need not be cited in every specification that mentions IPv4). Note 3: The normative/informative distinction is relevant in any document that amounts to a technical specification, even if its intended status is Experimental or Informational. Note 4: Normative references in RFCs cannot be to "work in progress" documents such as Internet Drafts. Drafts with such references will not be published as RFCs until the references are also published. The distinction between normative and informative references is often important. The IETF standards process according to RFC 2026 and RFC 3967, and the RFC Editor publication process, both need to know whether a reference to a work in progress is normative. An RFC cannot be published until all of the documents that it lists as normative references have been published. In practice, this often results in the simultaneous publication of a group of interrelated RFCs. For these reasons, the IESG and the RFC Editor have established guidelines that will request separate reference lists for normative and informative references in Internet Drafts and RFCs. For example, if both types are present, there would be two reference subsections, numbered s.1 and s.2 for example: s.1. Normative References xxx ... xxx s.2. Informative References xxx ... xxx Of course, if there is only one type of reference, only one section is needed. The IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint