From ram-bounces@iab.org Mon Jan 01 04:52:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Jon-0005ti-LH; Mon, 01 Jan 2007 04:50:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Jok-0005ta-LY for ram@iab.org; Mon, 01 Jan 2007 04:50:55 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Joj-0001QF-07 for ram@iab.org; Mon, 01 Jan 2007 04:50:54 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id WAA07962; Mon, 1 Jan 2007 22:50:46 +1300 In-Reply-To: <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 22:50:54 +1300 To: Roland Dobbins X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It occurs to me that the principle difference between those two cases is that the home user is very unlikely to have more than one in-house link (or at least, isn't using IP routing). Home networks are more likely to be doing link aggregation at the 802 level... I hope. Andrew On 01/01/2007, at 5:39 AM, Roland Dobbins wrote: > > On Dec 31, 2006, at 8:31 AM, marcelo bagnulo braun wrote: > >> That is why i am proposing to identify different type of >> multihomed sites and find different solutions for them > > This certainly makes sense, but how do we identify 'types' of > multihomed sites other than by some arbitrary criteria of scale > (and of which things - number of endpoints, number of PoPs, number > of transit links, etc.)? Within the current IPv4 and IPv6 > paradigms, can we identify *qualitative* differences between a home > user with a /24 and two T1s to different SPs and a large > multinational corporation with multiple PoPs/SPs on multiple > continents? > > > ---------------------------------------------------------------------- > - > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 06:25:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LH2-0000mJ-Bq; Mon, 01 Jan 2007 06:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1LH1-0000lp-6v for ram@iab.org; Mon, 01 Jan 2007 06:24:11 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1LGz-0007An-Kt for ram@iab.org; Mon, 01 Jan 2007 06:24:11 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B237A54C57; Mon, 1 Jan 2007 12:24:08 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp03.uc3m.es (Postfix) with ESMTP id 0F47154C6B; Mon, 1 Jan 2007 12:24:06 +0100 (CET) In-Reply-To: <8F443235-B93F-4AFD-853F-1DAFAC4B7353@cisco.com> References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> <4850f4e3cc56ede84e46bb30ea711f64@it.uc3m.es> <8F443235-B93F-4AFD-853F-1DAFAC4B7353@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <972f4e1e2f1b595b8a6c076a4d07fd66@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 12:24:01 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 01/01/2007, a las 1:59, Tony Li escribi=F3: > >>> A middle box implies state already. >> >> GSE doesn't and that it is the beauty of it, but it doesn't work as=20= >> such (that was my only point actually) > > > Ummm... I'm not Mike O'Dell, but I respectfully disagree. > > It is not a first-order clear requirement of the spec, but someone,=20 > somewhere still needs to deal with destination locator selection. You=20= > can do it in the host, or in the border, and we know what folks think=20= > about doing it in the host. > ok, let me rephrase I think you can do the locator selection in the host or in the border=20 router. I think you can also let either the host or the border to border router=20= to handle the rest of the protocol stuff that is needed (security of=20 the id-loc binding, reachability verification, exploration of=20 alternative paths and so on) However, what i don't know how to do, is to do everything in the border=20= router without requiring any specific id-locator context state (i.e.=20 per communication state) in the border router, like GSE does it. I mean=20= GSE just knows the globally routable prefix and simply rewrite the=20 source prefix and the hosts are practically unaware (i.e. they are not=20= involved in the creation of any state in the border router using a=20 protocol, neither with the border router nor with the peer). In the=20 case of GSE, it does not require any per connection state and does not=20= require any protocol with any other element to create any state, (for=20 instance for security reasons). I don't see how you can do this,=20 securely. I see how you can do this, if you run a protocol between the border=20 routers or between the border router and a third element (like a third=20= trusted party) that is used to create a per id/locator binding state.=20 this will not be as nice or as simple as the GSE proposal currently is. i am not saying i not ok with this, just want to make sure we are on=20 the same page about the expected complexity of the resulting solution regards, marcelo > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 09:55:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1OZ5-0002zq-5n; Mon, 01 Jan 2007 09:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1OZ3-0002zl-Lz for ram@iab.org; Mon, 01 Jan 2007 09:55:01 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1OYx-0001En-C3 for ram@iab.org; Mon, 01 Jan 2007 09:55:01 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id DD0163400C; Mon, 1 Jan 2007 09:54:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 09:54: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: filters and ACLs on identifiers? (was Re: other requirement?(wasRe: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 09:54:51 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FCFEA@tayexc14.americas.cpqcorp.net> In-Reply-To: <16C8375B-ACD3-46E3-8030-764A753E0203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: filters and ACLs on identifiers? (was Re: other requirement?(wasRe: [RAM] Traffic Engineering Thread-Index: AcctHPRHT8sEtDlnQCmhGrUm3r8aAQAVhUew From: "Bound, Jim" To: "Roland Dobbins" , X-OriginalArrivalTime: 01 Jan 2007 14:54:52.0546 (UTC) FILETIME=[CAF05620:01C72DB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > It's also important to note that the conflation of=20 > encryption/ obfuscation with 'security' has in fact been=20 > harmful by a) providing the incorrect impression that all one=20 > has to do to secure one's host/ application/network is to=20 > encrypt various random things, with no thought or effort=20 > required apart from that, and b) encouraging the overuse of=20 > encryption where it really isn't needed, with the net effect=20 > that opsec personnel end up losing the ability to analyze and=20 > filter undesirable network traffic. So, we should work to=20 > avoid promulgating a misimpression similar to that in which=20 > some folks drew the incorrect inference that because of=20 > 'mandated' IPSEC that IPv6 is magically 'secure'. Exactly and I agree with the other input you have suggested on this long set of mail threads over the Holidays :--). That we must break the architecture down to component layers and not complicate traffic engineering as one example below. >From Dobbins Roland "It's somewhat easier for folks to understand, operate, and administer endpoints with multiple logical network addresses which correspond with multiple media (including varying flavors of wireless), or even on the same media with logical partitioning a la VLANs, than a single interface on the same physical network which carries multiple logical network overlays. Doing things like maintaining ACLs, firewall rules, and the various traffic engineering tweaks which sparked this topic rapidly becomes difficult, if not impossible." End from Dobbins Roland But I do think we need to discuss further the new routing layer not in the context of endpoints, routers, or middle boxes for this new architecture. For example I think some of the conversation is missing the advantage value proposition SHIM6 proposes for this new architecture, and I believing if we are to deploy 5 years from now, we must use our current work and evolve it. Assuming SHIM6 adopts the new transport model where only transport-identifiers are used by a new transport that do not even use locators then SHIM6 in fact helps multihoming as follows. When the end node is notified through ICMPvX that connection cannot be made it trys another transsport-identifier. This reduces the routing entropy (and I agreed with Ran's definition) to maintain routes to other Network Service Providers. How the locators are determined from the destination routing-namespace-identifier from transport-namespace-identifiers as the packet is passed down the implemented IP stack is conversation that will be required at some point. Today I still believe an IPvX destination address is an orthogonal discussion to the new transport model. The node will have to select the locators after the new transport model processing within the IP stack and that should not be discussed in the context of the current model if we are to evolve initially, and then we can back track to see how we can transition current models. Regarding routing intelligence on nodes lets not even go there right now. There will always be business case even for handhelds (e.g. radios for military, first responders, Intelligent PDAs, data center access to situational awareness feed, etc) to have knowledge of location at the layer that determines next hop node. That is a market and business issue for implementation we should not assume a fixed set of notions about who, what, why, or how implementations use the architecture for now IMHO.=20 >=20 > [ Of course, one operator's undesirable network traffic is=20 > another customer's BitTorrent, but that's a different=20 > discussion for a different forum, heh. ] Agree and that hopefully would be better defined with the new architecture model. Best, /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 09:58:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Ocb-0003g6-6P; Mon, 01 Jan 2007 09:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1OcZ-0003fs-Km for ram@iab.org; Mon, 01 Jan 2007 09:58:39 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1OcU-00029c-Dz for ram@iab.org; Mon, 01 Jan 2007 09:58:39 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1566C3400C; Mon, 1 Jan 2007 09:58:36 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 09:58: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: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 09:58:32 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FCFEB@tayexc14.americas.cpqcorp.net> In-Reply-To: <7d2996140081b03193d4f16ae9d69f02@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Thread-Index: AcctJLdhDfjGk0cXRWGs/TeTWAdP6gAUWXqA From: "Bound, Jim" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 01 Jan 2007 14:58:34.0043 (UTC) FILETIME=[4EF618B0:01C72DB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > > It is not trusting the routing system but the entire notion of the=20 > > network security system using Intrusion Detection. IMHO it is=20 > > un-necessary to secure the identifiers (whether transport=20 > or routing=20 > > name space in the model emerging here) cryptographically=20 > (and I do not=20 > > believe it will ever scale from engineering view point). Access to=20 > > the identifiers is what must be secured and then if they change as=20 > > stated above. Anything else is overhead. > > >=20 > exactly, hence, it is not obvious to me if we can assume that=20 > a middle box will be able to even see the identifier in order=20 > to use them in filters and ACLs, right? Thats my assumption today and has to be for end-to-end encryption of the IP layer or the transport layer. There are products that perform what is called deep packet inspection (DPI), far beyond what traditional routers are capable of today in their fast path, on the market today and could with security offload processers perform a decrypt and re-encrypt at the edge and maintain line rates, thus that is an option in the market but not our concern as the IETF SDO working on this new architecture. /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 16:45:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1UwR-0000OG-3q; Mon, 01 Jan 2007 16:43:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1UwP-0000Ig-TI for ram@iab.org; Mon, 01 Jan 2007 16:43:33 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1UwN-00023G-Mo for ram@iab.org; Mon, 01 Jan 2007 16:43:33 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 609B686AE4; Mon, 1 Jan 2007 16:43:20 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20070101214320.609B686AE4@mercury.lcs.mit.edu> Date: Mon, 1 Jan 2007 16:43:20 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Tony Li >> because of TCP checksum issues; the border router can only do so much, >> unless the host is in on it too. (Which is why GSE proposed to make >> the TCP checksum cover only the ID half, but that horse is long-gone, >> alas...) > I sincerely hope that we can rein in that horse and reconsider it. > Otherwise the entire concept of a host/locator split ends up looking > wholly like NAT, either in the host or in the middle box. Tony (et al), would it be possible to do something where the host emits the packet with the high halves (the routing-goop) of the IPv6 addresses all zero, and then the border router fills them in for while the packet is in transit, and then the last-hop router (or perhaps the border router at the destination) clears them? That way, the TCP checksum wouldn't have to be modified (either in the code, or in packets in flight), and the hosts wouldn't have to be in on the act. (Yes, I know there's still a security issue with the binding of the RG part to the endpoint-indentity part; I'm leaving off thinking about that until I make sure the first step works.) Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 16:50:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1V2z-0005ST-5v; Mon, 01 Jan 2007 16:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1V2y-0005SO-Jw for ram@iab.org; Mon, 01 Jan 2007 16:50:20 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1V2x-0004pU-ED for ram@iab.org; Mon, 01 Jan 2007 16:50:20 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3D39886AE4; Mon, 1 Jan 2007 16:50:19 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Date: Mon, 1 Jan 2007 16:50:19 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Tony Li > Architecturally, sites that simply differ in traffic volume or internal > complexity shouldn't be dealt with separately. Thus, a 'clean' solution > should not require entirely different solutions for different market > sub-segments. Tony, a nice goal, but I wonder... I think there's something to the line of reasoning (well put by Marcelo) that says that big sites probably have important differences which may have to be reflected in the mechanisms. (Size does matter in computer science! :-) I wonder if perhaps there's some way to have our cake and eat it too; have the same basic architecture (and therefore support substrate, like identity/location separation), but make the engineering mechanisms different in the two cases, to take into account scale differences? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 17:11:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1VNS-0001C9-DR; Mon, 01 Jan 2007 17:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1VNR-0001C2-5I for ram@iab.org; Mon, 01 Jan 2007 17:11:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1VNO-0001zz-Eo for ram@iab.org; Mon, 01 Jan 2007 17:11:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Jan 2007 17:11:24 -0500 X-IronPort-AV: i="4.12,223,1165208400"; d="scan'208"; a="110675601:sNHT47785256" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l01MBNAW012382 for ; Mon, 1 Jan 2007 17:11:23 -0500 Received: from [192.168.1.101] (rtp-vpn4-101.cisco.com [10.82.208.101]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l01MBNgT027210 for ; Mon, 1 Jan 2007 17:11:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> References: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 14:11:01 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2324; t=1167689483; x=1168553483; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=2GZ5JZjPqmxchw4fr6EDHV3sWCtUrMS4Tww9YH4ZDks=; b=jVg8waHuL1Cxc8B4IC93z1dFikaJlr5UixN2DuZLzwaVFRLkpcKZiV57hdVYtljD0opuC+8i zRJuFL22XQaPe2k3OkvSaWz27a9vCCCqqEOMvObYOinNyT3v0j2gyuLH; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 1, 2007, at 1:50 PM, Noel Chiappa wrote: > Tony, a nice goal, but I wonder... I think there's something to the > line of > reasoning (well put by Marcelo) that says that big sites probably have > important differences which may have to be reflected in the > mechanisms. (Size > does matter in computer science! :-) While Marcelo's assumptions in that regard are perfectly reasonable and understandable, the differences aren't as large as one would think; and enterprises actively wish to minimize those differences further, if they can (in the direction of lesser complexity, obviously). Other than size/volume and internal complexity, I can't really think of any qualitative differences of a significant and consistent enough nature to be used as any sort of objective criteria on which to predicate a split. Perhaps others may have thoughts they can contribute? > I wonder if perhaps there's some way to have our cake and eat it > too; have > the same basic architecture (and therefore support substrate, like > identity/location separation), but make the engineering mechanisms > different > in the two cases, to take into account scale differences? This isn't desirable, but it may be less undesirable than other alternatives which have been put forth to date. However, I strongly agree with tli that identifying a scalable solution which doesn't operate differently based upon volume or internal complexity is an important principle to maintain, if at all possible. Somewhat significant differences between singlehomed and multihomed sites is acceptable; we've that today with the requirement for BGP. But significant differences between dual-homed sites and a quad-homed sites, for example, is highly undesirable, and should be avoided if it's possible to do so. [ I write this understanding that in the final analysis, it may be impossible to maintain this principle, but I think it's really, really important that we try to do so. It would be one of the last principles I'd discard, given any choice at all. ] ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 17:23:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1VYU-000861-0q; Mon, 01 Jan 2007 17:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1VYS-00081V-V6 for ram@iab.org; Mon, 01 Jan 2007 17:22:52 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1VYR-00060y-Oo for ram@iab.org; Mon, 01 Jan 2007 17:22:52 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5713D86AE4; Mon, 1 Jan 2007 17:22:47 -0500 (EST) To: ram@iab.org Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> Date: Mon, 1 Jan 2007 17:22:47 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: marcelo bagnulo braun > you cannot make filers and ACL based on identifiers unless you can > trust them. In the case of routing names, you can have some level of > trust, because, if you trust the routing system, then you know this > packet will only be delivered to the destiantion locator. But you can't really trust the source locator, of course; all it takes is a few sites which don't do source-address filtering, and bogons can appear at any given destination. So you can't reliably filter anything you are basing in part on the source locator. > However, you do not have this level of trust if you use identifiers and > you need to provide additional mechanism (that result in additional > overhead or state) to achieve it Hmm. Well, that's a point worth thinking about. I think you probably can trust the destination ID, because if that destination is really at the place the packet got to, and the packet is delivered to that destination, it will presumably recognize that the packet is not for it, and reject it. And of course, as discussed above, you can't really trust source addresses now. So, it's not clear to me that we are any worse off than we are now. Am I missing something? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 17:29:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Vf1-0002oZ-0C; Mon, 01 Jan 2007 17:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Vez-0002oR-Mm for ram@iab.org; Mon, 01 Jan 2007 17:29:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Vey-0007ln-0P for ram@iab.org; Mon, 01 Jan 2007 17:29:37 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 Jan 2007 14:29:36 -0800 X-IronPort-AV: i="4.12,223,1165219200"; d="scan'208"; a="49797073:sNHT43995468" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l01MTZvN017605 for ; Mon, 1 Jan 2007 17:29:35 -0500 Received: from [192.168.1.101] (rtp-vpn4-101.cisco.com [10.82.208.101]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l01MTZgT007251 for ; Mon, 1 Jan 2007 17:29:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> References: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C491CD6-DE67-4592-A65B-40AB96C0C291@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 14:29:13 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1132; t=1167690575; x=1168554575; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=o9QxnV/BjTapbMK85sTDOv4XomQZpAjffL9Nur9ehXk=; b=oJAKYGPBoM7LvmHRJtx877Zk7+qxOCCooYF8kp0iFXedyhRc+yTnR4DKuS5D//gxfZ66qzae RWY0OYe7+NqV5Y/+RXbxDGn8yeM9c8NNIulY9oqWDEmk9qgE5X1ZPjHW; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 1, 2007, at 2:22 PM, Noel Chiappa wrote: > I think you probably can trust the destination ID, because if that > destination is really at the place the packet got to, and the > packet is > delivered to that destination, it will presumably recognize that > the packet > is not for it, and reject it. One consideration in this general area is reflection attacks; I know they don't bear directly upon what's being discussed, but it's arguable that they represent one class of traffic in which the *ultimate* desired destination for packets is 'spoofed', too, as it were. Another consideration would be a scenario in which an attacker knows (or could reasonably infer) that there is some mechanism which will end up redirecting packets ostensibly destined for A over to B and/or C. Again, this is probably not germane to the discussion, but I point it out for the sake of completeness. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 18:12:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJc-00029M-Ma; Mon, 01 Jan 2007 18:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJb-000272-28 for ram@iab.org; Mon, 01 Jan 2007 18:11:35 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1WJZ-00016q-P6 for ram@iab.org; Mon, 01 Jan 2007 18:11:35 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Jan 2007 15:11:33 -0800 X-IronPort-AV: i="4.12,223,1165219200"; d="scan'208"; a="454514908:sNHT44532316" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l01NBXt5008140; Mon, 1 Jan 2007 15:11:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l01NBWPn015294; Mon, 1 Jan 2007 15:11:32 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:11:31 -0800 Received: from [192.168.0.101] ([10.21.120.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:11:31 -0800 In-Reply-To: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> References: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 15:11:38 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 23:11:31.0646 (UTC) FILETIME=[2C9625E0:01C72DFA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1167693093; x=1168557093; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=zgP0ilmKLN+cvG5UCiqSir7rNX3XDTrGJye4sNqtUv0=; b=TucKRJW0MMxgy1JNZft8oqUnXZaBzkHbbCnZ4N9ieFsroGuH/eazzPslCBUWGn6sAU5HAQ3m ZT8KrMxHbqJD4hCYwXXPFS7DFPL/uTDWDWFr66cDY9M1gWnoemIhTbCS; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Architecturally, sites that simply differ in traffic volume or >> internal >> complexity shouldn't be dealt with separately. Thus, a 'clean' >> solution >> should not require entirely different solutions for different market >> sub-segments. > > Tony, a nice goal, but I wonder... I think there's something to the > line of > reasoning (well put by Marcelo) that says that big sites probably have > important differences which may have to be reflected in the > mechanisms. (Size > does matter in computer science! :-) > > I wonder if perhaps there's some way to have our cake and eat it > too; have > the same basic architecture (and theFrom ram-bounces@iab.org Mon Jan 01 18:12:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJc-00029M-Ma; Mon, 01 Jan 2007 18:11:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJb-000272-28 for ram@iab.org; Mon, 01 Jan 2007 18:11:35 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1WJZ-00016q-P6 for ram@iab.org; Mon, 01 Jan 2007 18:11:35 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Jan 2007 15:11:33 -0800 X-IronPort-AV: i="4.12,223,1165219200"; d="scan'208"; a="454514908:sNHT44532316" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l01NBXt5008140; Mon, 1 Jan 2007 15:11:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l01NBWPn015294; Mon, 1 Jan 2007 15:11:32 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:11:31 -0800 Received: from [192.168.0.101] ([10.21.120.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:11:31 -0800 In-Reply-To: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> References: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 15:11:38 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 23:11:31.0646 (UTC) FILETIME=[2C9625E0:01C72DFA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1167693093; x=1168557093; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=zgP0ilmKLN+cvG5UCiqSir7rNX3XDTrGJye4sNqtUv0=; b=TucKRJW0MMxgy1JNZft8oqUnXZaBzkHbbCnZ4N9ieFsroGuH/eazzPslCBUWGn6sAU5HAQ3m ZT8KrMxHbqJD4hCYwXXPFS7DFPL/uTDWDWFr66cDY9M1gWnoemIhTbCS; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Architecturally, sites that simply differ in traffic volume or >> internal >> complexity shouldn't be dealt with separately. Thus, a 'clean' >> solution >> should not require entirely different solutions for different market >> sub-segments. > > Tony, a nice goal, but I wonder... I think there's something to the > line of > reasoning (well put by Marcelo) that says that big sites probably have > important differences which may have to be reflected in the > mechanisms. (Size > does matter in computer science! :-) > > I wonder if perhaps there's some way to have our cake and eat it > too; have > the same basic architecture (and therefore support substrate, like > identity/location separation), but make the engineering mechanisms > different > in the two cases, to take into account scale differences? I could be convinced by concrete counter examples, but the only distinctions that I can see are: a) sites that have exactly one ASBR b) sites that have more than one ASBR Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 18:12:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJ8-0001ho-0x; Mon, 01 Jan 2007 18:11:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJ7-0001hd-2g for ram@iab.org; Mon, 01 Jan 2007 18:11:05 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1WJ5-00010w-OY for ram@iab.org; Mon, 01 Jan 2007 18:11:05 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Jan 2007 15:11:03 -0800 X-IronPort-AV: i="4.12,223,1165219200"; d="scan'208"; a="354262934:sNHT51153724" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l01NB36S019848; Mon, 1 Jan 2007 15:11:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l01NAvPn014273; Mon, 1 Jan 2007 15:11:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:10:57 -0800 Received: from [192.168.0.101] ([10.21.120.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:10:57 -0800 In-Reply-To: <20070101214320.609B686AE4@mercury.lcs.mit.edu> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <793406F5-5767-4374-A1C9-3B9D1394D043@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 15:11:03 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 23:10:57.0473 (UTC) FILETIME=[1837C310:01C72DFA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1935; t=1167693063; x=1168557063; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=FE9VMOo2//AfuThV7maHS6FjmV37drNffm9kJhUtIn4=; b=g3X8YNbRQVD9aBsTbZSBjLQlzjxsizr+ObdfOtEt1Hzs+5RQW2bcAGGVl8VPjGDAbtehdD06 G1LshMZzwQEIOKc34wDrhCBoFTPElv+ISklTXf7ZUxHdNnVuOlvwQIF1; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel, >>> because of TCP checksum issues; the border router can only do so >>> much, >>> unless the host is in on it too. (Which is why GSE proposed to make >>> the TCP checksum cover only the ID half, but that horse is long- >>> gone, >>> alas...) >refore support substrate, like > identity/location separation), but make the engineering mechanisms > different > in the two cases, to take into account scale differences? I could be convinced by concrete counter examples, but the only distinctions that I can see are: a) sites that have exactly one ASBR b) sites that have more than one ASBR Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 18:12:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJ8-0001ho-0x; Mon, 01 Jan 2007 18:11:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WJ7-0001hd-2g for ram@iab.org; Mon, 01 Jan 2007 18:11:05 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1WJ5-00010w-OY for ram@iab.org; Mon, 01 Jan 2007 18:11:05 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Jan 2007 15:11:03 -0800 X-IronPort-AV: i="4.12,223,1165219200"; d="scan'208"; a="354262934:sNHT51153724" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l01NB36S019848; Mon, 1 Jan 2007 15:11:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l01NAvPn014273; Mon, 1 Jan 2007 15:11:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:10:57 -0800 Received: from [192.168.0.101] ([10.21.120.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:10:57 -0800 In-Reply-To: <20070101214320.609B686AE4@mercury.lcs.mit.edu> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <793406F5-5767-4374-A1C9-3B9D1394D043@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 15:11:03 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 23:10:57.0473 (UTC) FILETIME=[1837C310:01C72DFA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1935; t=1167693063; x=1168557063; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=FE9VMOo2//AfuThV7maHS6FjmV37drNffm9kJhUtIn4=; b=g3X8YNbRQVD9aBsTbZSBjLQlzjxsizr+ObdfOtEt1Hzs+5RQW2bcAGGVl8VPjGDAbtehdD06 G1LshMZzwQEIOKc34wDrhCBoFTPElv+ISklTXf7ZUxHdNnVuOlvwQIF1; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel, >>> because of TCP checksum issues; the border router can only do so >>> much, >>> unless the host is in on it too. (Which is why GSE proposed to make >>> the TCP checksum cover only the ID half, but that horse is long- >>> gone, >>> alas...) > >> I sincerely hope that we can rein in that horse and reconsider it. >> Otherwise the entire concept of a host/locator split ends up looking >> wholly like NAT, either in the host or in the middle box. > > Tony (et al), would it be possible to do something where the host > emits the > packet with the high halves (the routing-goop) of the IPv6 > addresses all > zero, and then the border router fills them in for while the packet > is in > transit, and then the last-hop router (or perhaps the border router > at the > destination) clears them? That way, the TCP checksum wouldn't have > to be > modified (either in the code, or in packets in flight), and the hosts > wouldn't have to be in on the act. In principle, yes I think that something like that is possible. I think that there are some significant details that we would have to get into regarding where you draw the routing goop line, and how much of the routing goop the host has to see. I think that there needs to be some "local" routing goop within a routing domain so that you can scale your IGP. If that overlaps with the "global" routing goop, then I think that the finesse that you're proposing will fail. I also think you'll probably want different constants in the routing goop for "external" and "internal", and possibly other routing goop bits to select your ASBR. These of course are dirty little details that need to be ironed out. It is because of them that I'm in favor of restricting the header checksum rather than just forcing the RG to a constant. But that's just me, trying to do something 'cleaner'. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram >> I sincerely hope that we can rein in that horse and reconsider it. >> Otherwise the entire concept of a host/locator split ends up looking >> wholly like NAT, either in the host or in the middle box. > > Tony (et al), would it be possible to do something where the host > emits the > packet with the high halves (the routing-goop) of the IPv6 > addresses all > zero, and then the border router fills them in for while the packet > is in > transit, and then the last-hop router (or perhaps the border router > at the > destination) clears them? That way, the TCP checksum wouldn't have > to be > modified (either in the code, or in packets in flight), and the hosts > wouldn't have to be in on the act. In principle, yes I think that something like that is possible. I think that there are some significant details that we would have to get into regarding where you draw the routing goop line, and how much of the routing goop the host has to see. I think that there needs to be some "local" routing goop within a routing domain so that you can scale your IGP. If that overlaps with the "global" routing goop, then I think that the finesse that you're proposing will fail. I also think you'll probably want different constants in the routing goop for "external" and "internal", and possibly other routing goop bits to select your ASBR. These of course are dirty little details that need to be ironed out. It is because of them that I'm in favor of restricting the header checksum rather than just forcing the RG to a constant. But that's just me, trying to do something 'cleaner'. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 18:17:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WPR-0006gT-HV; Mon, 01 Jan 2007 18:17:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1WPQ-0006g4-FS for ram@iab.org; Mon, 01 Jan 2007 18:17:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1WPO-0002Bh-4l for ram@iab.org; Mon, 01 Jan 2007 18:17:36 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 01 Jan 2007 15:17:33 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l01NHXaf020212; Mon, 1 Jan 2007 15:17:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l01NHSDi021813; Mon, 1 Jan 2007 15:17:29 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:17:28 -0800 Received: from [192.168.0.101] ([10.21.120.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 15:17:27 -0800 In-Reply-To: <972f4e1e2f1b595b8a6c076a4d07fd66@it.uc3m.es> References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> <4850f4e3cc56ede84e46bb30ea711f64@it.uc3m.es> <8F443235-B93F-4AFD-853F-1DAFAC4B7353@cisco.com> <972f4e1e2f1b595b8a6c076a4d07fd66@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 15:17:33 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 23:17:28.0025 (UTC) FILETIME=[01014490:01C72DFB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2153; t=1167693453; x=1168557453; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=1kvgPOkYekYwDWUaqxJ8IUSLj3KyWNJWnhN8tFP6zpQ=; b=b2SQpU4lW0xynXVtr20d8ZkiZXtjkx1cjZpO0G20rFo1a2nN5MocwOR74UY0SQK3IShcYhRK 15iqnms76hibSuV3jwXT57l2KOxbeZSvc3GNPS42W1xlGgsj353caLas; Authentication-Results: sj-dkim-5; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Marcelo, > I think you can do the locator selection in the host or in the > border router. > I think you can also let either the host or the border to border > router to handle the rest of the protocol stuff that is needed > (security of the id-loc binding, reachability verification, > exploration of alternative paths and so on) I agree with that much. > However, what i don't know how to do, is to do everything in the > border router without requiring any specific id-locator context > state (i.e. per communication state) in the border router, like GSE > does it. I mean GSE just knows the globally routable prefix and > simply rewrite the source prefix and the hosts are practically > unaware (i.e. they are not involved in the creation of any state in > the border router using a protocol, neither with the border router > nor with the peer). In the case of GSE, it does not require any per > connection state and does not require any protocol with any other > element to create any state, (for instance for security reasons). I > don't see how you can do this, securely. So, I think we should make a big distinction between per-connection state and other 'soft state' in the border router. I agree that you can probably do a border solution without per-connection state. However, for security reasons and for locator selection reasons, I think that you're minimally going to end up with a cache inside of the border router. > I see how you can do this, if you run a protocol between the border > routers or between the border router and a third element (like a > third trusted party) that is used to create a per id/locator > binding state. this will not be as nice or as simple as the GSE > proposal currently is. Well, GSE is certainly missing the security paraphernalia. I think that we all pretty much agree on that. > i am not saying i not ok with this, just want to make sure we are > on the same page about the expected complexity of the resulting > solution I think we're pretty much in violent agreement. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 01 20:39:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Ybw-0006Pr-OV; Mon, 01 Jan 2007 20:38:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Ybv-0006Pl-FJ for ram@iab.org; Mon, 01 Jan 2007 20:38:39 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Ybp-0000ZT-KQ for ram@iab.org; Mon, 01 Jan 2007 20:38:39 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc11) with SMTP id <2007010201383301100po21je>; Tue, 2 Jan 2007 01:38:33 +0000 Message-ID: <029b01c72e0e$37e93a40$6a01a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Mon, 1 Jan 2007 19:34:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Happy New Year. Sorry for the slow response. From: "Noel Chiappa" To: Cc: Sent: Sunday, December 31, 2006 8:07 AM Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering > > From: "Spencer Dawkins" > > > if path selection is under host control, > > Multiple routing-names for a destination is not really general "path > selection"; it does provide a small amount of influence on the path a > packet takes, but that's a long way from general path control (a la > "source route" options, etc). Yes, I agree (not general "path selection"), the concern was something more along the lines of someone who thought it would be fun to switch all the sites with DSL "backup" links to using their DSL as primary links, just to see what would happen, for example. If your network is the one getting flogged, the fact that it's not possible to flog other networks is less interesting, I guess. Also please notice that I missed the last two NANOGs and didn't speak for an operator before that - if someone else has a clearer vison of the stated concern, this would be a lovely time to share it! Thanks, Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 00:56:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ccf-00041m-TU; Tue, 02 Jan 2007 00:55:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1cce-00041d-So for ram@iab.org; Tue, 02 Jan 2007 00:55:40 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ccd-0001dB-4n for ram@iab.org; Tue, 02 Jan 2007 00:55:40 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id SAA21954; Tue, 2 Jan 2007 18:55:24 +1300 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FCFEB@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC011FCFEB@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19FCC19F-E001-46A6-A13B-0AEC5C0F811C@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 18:55:33 +1300 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org That middleboxes should be able to determine the identifiers in use was a design decision in HIP; perhaps unfortunately, they're compressed into an SPI, so the middlebox does have to keep state to do it. The state is just a binding between identifier, known locators and SPIs, however, and the protocol is designed to make it fairly convenient and secure (in the sense that spoofing is extremely difficult) for a middlebox to maintain that. Andrew On 02/01/2007, at 3:58 AM, Bound, Jim wrote: > >>> It is not trusting the routing system but the entire notion of the >>> network security system using Intrusion Detection. IMHO it is >>> un-necessary to secure the identifiers (whether transport >> or routing >>> name space in the model emerging here) cryptographically >> (and I do not >>> believe it will ever scale from engineering view point). Access to >>> the identifiers is what must be secured and then if they change as >>> stated above. Anything else is overhead. >>> >> >> exactly, hence, it is not obvious to me if we can assume that >> a middle box will be able to even see the identifier in order >> to use them in filters and ACLs, right? > > Thats my assumption today and has to be for end-to-end encryption > of the > IP layer or the transport layer. There are products that perform what > is called deep packet inspection (DPI), far beyond what traditional > routers are capable of today in their fast path, on the market > today and > could with security offload processers perform a decrypt and re- > encrypt > at the edge and maintain line rates, thus that is an option in the > market but not our concern as the IETF SDO working on this new > architecture. > > /jim > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 08:25:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jdo-0006iM-PG; Tue, 02 Jan 2007 08:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1jdo-0006iG-H4 for ram@iab.org; Tue, 02 Jan 2007 08:25:20 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1jdh-0008Q6-M0 for ram@iab.org; Tue, 02 Jan 2007 08:25:20 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 257D534017; Tue, 2 Jan 2007 08:25:09 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 08:25:08 -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: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 08:25:07 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD0B7@tayexc14.americas.cpqcorp.net> In-Reply-To: <20070101214320.609B686AE4@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: other requirement? (was Re: [RAM] Traffic Engineering Thread-Index: Acct7hjmNvxCM0XZSCqwRC18LQig3wAgoaXA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 02 Jan 2007 13:25:08.0818 (UTC) FILETIME=[6C666320:01C72E71] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel, I agree with Tony. As example if the routing-namespace-identifier was used in for transport layer then the low order EUI of v6 could be used for transport protocols. For ICMPv6 same could be done. Note v6 don't do checksum enroute to the end-node, and only at transport and icmp. If we moved to new transport identifiers that did not use locators (routing-namespace-identifiers) then the point becomes moot for transport, except for icmp. Noting in my response your caveat to not worry about e2e dst SPI example. Or if we did more to this model then do we need a new checksum in the new layer at some point in the path but not at the end node. Uggh need to think about packet e2e fragmentation reassembly at some point too :--). /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Monday, January 01, 2007 4:43 PM > To: ram@iab.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering >=20 > > From: Tony Li >=20 > >> because of TCP checksum issues; the border router can=20 > only do so much, > >> unless the host is in on it too. (Which is why GSE=20 > proposed to make > >> the TCP checksum cover only the ID half, but that=20 > horse is long-gone, > >> alas...) >=20 > > I sincerely hope that we can rein in that horse and=20 > reconsider it. > > Otherwise the entire concept of a host/locator split=20 > ends up looking > > wholly like NAT, either in the host or in the middle box. >=20 > Tony (et al), would it be possible to do something where the=20 > host emits the packet with the high halves (the routing-goop)=20 > of the IPv6 addresses all zero, and then the border router=20 > fills them in for while the packet is in transit, and then=20 > the last-hop router (or perhaps the border router at the > destination) clears them? That way, the TCP checksum wouldn't=20 > have to be modified (either in the code, or in packets in=20 > flight), and the hosts wouldn't have to be in on the act. >=20 > (Yes, I know there's still a security issue with the binding=20 > of the RG part to the endpoint-indentity part; I'm leaving=20 > off thinking about that until I make sure the first step works.) >=20 > Noel >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:02:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1m5G-0002FA-O2; Tue, 02 Jan 2007 11:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1m5F-0002F2-Aj for ram@iab.org; Tue, 02 Jan 2007 11:01:49 -0500 Received: from elle.sprintlink.net ([199.0.234.34] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1m5E-0004aw-2j for ram@iab.org; Tue, 02 Jan 2007 11:01:49 -0500 Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id l02FqfY29396; Tue, 2 Jan 2007 10:52:41 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id LAA29691; Tue, 2 Jan 2007 11:05:09 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Tue, 2 Jan 2007 11:05:09 -0500 (EST) From: Ted Seely X-X-Sender: To: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Marcelo, On Sun, 31 Dec 2006, marcelo bagnulo braun wrote: > > El 31/12/2006, a las 16:13, Roland Dobbins escribi=F3: > > > I believe that 'the IPv6 mulithoming solution' ought to be > > generalizable and scalable to sites of all sizes. > > This is exactly where we disagree. I think this is very hard because if > you add up all the requirements of all type of potential multihomed > sites, from a unmanaged lan with a couple of PCs to a highly managed > huge corporation site, and you also add al the border constratints, > like scalability of the routing system, then you have very very > difficult problem > > > That is why i am proposing to identify different type of multihomed > sites and find different solutions for them not that i'm disagreeing with you, but would this lead to multiple solutions? i think the last thing we all want is ala carte protocols based on the criteria a site fits into. i'm afraid this leads to the sqaure peg protocol for the square peg sites, and round ones for round sites. do we really want to paint ouselves into this corner? this sounds less flexible to me than what we have today. -ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mr1-0003xJ-0C; Tue, 02 Jan 2007 11:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mr0-0003xD-Ax for ram@iab.org; Tue, 02 Jan 2007 11:51:10 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mqz-00059l-0E for ram@iab.org; Tue, 02 Jan 2007 11:51:10 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 729DB53ABE; Tue, 2 Jan 2007 17:51:08 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id E938B54ACB; Tue, 2 Jan 2007 17:51:05 +0100 (CET) In-Reply-To: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> References: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:42:25 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 01/01/2007, a las 22:50, Noel Chiappa escribi=F3: >> From: Tony Li > >> Architecturally, sites that simply differ in traffic volume or=20 >> internal >> complexity shouldn't be dealt with separately. Thus, a 'clean'=20 >> solution >> should not require entirely different solutions for different market >> sub-segments. > > Tony, a nice goal, but I wonder... I think there's something to the=20 > line of > reasoning (well put by Marcelo) that says that big sites probably have > important differences which may have to be reflected in the=20 > mechanisms. (Size > does matter in computer science! :-) > > I wonder if perhaps there's some way to have our cake and eat it too;=20= > have > the same basic architecture (and therefore support substrate, like > identity/location separation), but make the engineering mechanisms=20 > different > in the two cases, to take into account scale differences? > yes, maybe this is a nice way of seeing it... maybe there are some optional features that could be left out for very=20= simple sites, or we could have default configurations that are defined=20= for the simple sites and thay would require additional tunning for more=20= complex sites... Again, for me one of the biggest differences is that in small sites we=20= cannot assume that there we qualified people to configure the solution. regards, marcelo > Noel > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mqx-0003we-Od; Tue, 02 Jan 2007 11:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mqw-0003wX-Qt for ram@iab.org; Tue, 02 Jan 2007 11:51:06 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mqv-00059S-G7 for ram@iab.org; Tue, 02 Jan 2007 11:51:06 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E9D78547BE; Tue, 2 Jan 2007 17:51:04 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id CFF3653ABE; Tue, 2 Jan 2007 17:51:01 +0100 (CET) In-Reply-To: References: <20070101215019.3D39886AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:50:55 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 0:11, Tony Li escribi=F3: > >>> Architecturally, sites that simply differ in traffic volume or=20 >>> internal >>> complexity shouldn't be dealt with separately. Thus, a 'clean'=20 >>> solution >>> should not require entirely different solutions for different market >>> sub-segments. >> >> Tony, a nice goal, but I wonder... I think there's something to the=20= >> line of >> reasoning (well put by Marcelo) that says that big sites probably = have >> important differences which may have to be reflected in the=20 >> mechanisms. (Size >> does matter in computer science! :-) >> >> I wonder if perhaps there's some way to have our cake and eat it too;=20= >> have >> the same basic architecture (and therefore support substrate, like >> identity/location separation), but make the engineering mechanisms=20 >> different >> in the two cases, to take into account scale differences? > > > I could be convinced by concrete counter examples, but the only=20 > distinctions that I can see are: > > a) sites that have exactly one ASBR > b) sites that have more than one ASBR > that certainly makes things easier, i guess that the sites with more=20 than one exit router may need additional protocol/mechanisms (it is=20 certainly the case for shim6) So, i think this could be one case of having optional mechanisms for=20 more complex setups. Regards, marcelo > Tony > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mqu-0003w1-Gh; Tue, 02 Jan 2007 11:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mqt-0003vv-9R for ram@iab.org; Tue, 02 Jan 2007 11:51:03 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mqr-00059M-NV for ram@iab.org; Tue, 02 Jan 2007 11:51:03 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CAC9A549D1; Tue, 2 Jan 2007 17:51:00 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id DD43653FD5; Tue, 2 Jan 2007 17:50:56 +0100 (CET) In-Reply-To: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> References: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <29d42eceb83f66f9de98dc4cd070f118@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:46:41 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 01/01/2007, a las 23:22, Noel Chiappa escribi=F3: >> From: marcelo bagnulo braun > >> you cannot make filers and ACL based on identifiers unless you can >> trust them. In the case of routing names, you can have some level of >> trust, because, if you trust the routing system, then you know this >> packet will only be delivered to the destiantion locator. > > But you can't really trust the source locator, of course; all it takes=20= > is a > few sites which don't do source-address filtering, and bogons can=20 > appear at > any given destination. So you can't reliably filter anything you are=20= > basing > in part on the source locator. > agree, >> However, you do not have this level of trust if you use identifiers=20= >> and >> you need to provide additional mechanism (that result in additional >> overhead or state) to achieve it > > Hmm. Well, that's a point worth thinking about. > > I think you probably can trust the destination ID, because if that > destination is really at the place the packet got to, i am not sure... the packet really goes to the destiantion _locator_ not to the=20 destiantion identifier.So you can trust the destiantion locator, but if=20= you carry in the packet both the destiantion locator and the=20 destiantion identifier, you can only trust the destiantion locator and=20= not the destiantion identifier. > and the packet is > delivered to that destination, it will presumably recognize that the=20= > packet > is not for it, and reject it. And of course, as discussed above, you=20= > can't > really trust source addresses now. So, it's not clear to me that we=20 > are any > worse off than we are now. > i am not sure what attacks are we considering, but including a=20 destiantion identifier that is accepted by the ACLs and including a=20 destiantion locator of another machine, is a simple way to bypass the=20 ACL and being able to send packets towards a machine that the ACL=20 doesn't want you to. Not sure if this is a relevant attack though... Regards, marcelo > Am I missing something? > > Noel > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mr7-0003xw-8W; Tue, 02 Jan 2007 11:51:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mr5-0003xq-Sy for ram@iab.org; Tue, 02 Jan 2007 11:51:15 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mr4-0005AK-D9 for ram@iab.org; Tue, 02 Jan 2007 11:51:15 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CCA4153ABE; Tue, 2 Jan 2007 17:51:13 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id 6EB0B53BF8; Tue, 2 Jan 2007 17:51:08 +0100 (CET) In-Reply-To: <19FCC19F-E001-46A6-A13B-0AEC5C0F811C@indranet.co.nz> References: <816DD9299957E547B5D758D7F977D6DC011FCFEB@tayexc14.americas.cpqcorp.net> <19FCC19F-E001-46A6-A13B-0AEC5C0F811C@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:01:26 +0100 To: Andrew McGregor X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "Bound, Jim" , Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Yes, i think we can learn from the HIP work on firewall traversal.=20 AFAIK, the middle box keeps track of the HIP base exchange, and then it=20= learns what identifiers match to following data packets, right? So, you can do filtering based on HITs, but you need to allow the=20 middle box to keep track of the hip base exchange and you need to=20 distribute that information through all potentail middel boxes that=20 following packets can traverse (due to a path change) I think hip work has done the first thing (allow middle boxes to keep=20 track of the hip base exchange) but not the second one (deal with path=20= changes), right? in any case, i think their experience is very useful to have a fleshed=20= example of how to do this and the complexity involved (which is one of=20= the prices to pay to allow portability based on PI identifiers) Regards, marcelo El 02/01/2007, a las 6:55, Andrew McGregor escribi=F3: > That middleboxes should be able to determine the identifiers in use=20 > was a design decision in HIP; perhaps unfortunately, they're=20 > compressed into an SPI, so the middlebox does have to keep state to do=20= > it. The state is just a binding between identifier, known locators=20 > and SPIs, however, and the protocol is designed to make it fairly=20 > convenient and secure (in the sense that spoofing is extremely=20 > difficult) for a middlebox to maintain that. > > Andrew > > On 02/01/2007, at 3:58 AM, Bound, Jim wrote: > >> >>>> It is not trusting the routing system but the entire notion of the >>>> network security system using Intrusion Detection. IMHO it is >>>> un-necessary to secure the identifiers (whether transport >>> or routing >>>> name space in the model emerging here) cryptographically >>> (and I do not >>>> believe it will ever scale from engineering view point). Access to >>>> the identifiers is what must be secured and then if they change as >>>> stated above. Anything else is overhead. >>>> >>> >>> exactly, hence, it is not obvious to me if we can assume that >>> a middle box will be able to even see the identifier in order >>> to use them in filters and ACLs, right? >> >> Thats my assumption today and has to be for end-to-end encryption of=20= >> the >> IP layer or the transport layer. There are products that perform = what >> is called deep packet inspection (DPI), far beyond what traditional >> routers are capable of today in their fast path, on the market today=20= >> and >> could with security offload processers perform a decrypt and=20 >> re-encrypt >> at the edge and maintain line rates, thus that is an option in the >> market but not our concern as the IETF SDO working on this new >> architecture. >> >> /jim >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram >> > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mrP-0004Oc-60; Tue, 02 Jan 2007 11:51:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mrM-0004Ez-Mo for ram@iab.org; Tue, 02 Jan 2007 11:51:33 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mrL-0005Bn-6v for ram@iab.org; Tue, 02 Jan 2007 11:51:32 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A6A9A54B60; Tue, 2 Jan 2007 17:51:30 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id CC06854867; Tue, 2 Jan 2007 17:51:27 +0100 (CET) In-Reply-To: <20070101214320.609B686AE4@mercury.lcs.mit.edu> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <759dc0f38a77039aef34c6521043f232@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:40:05 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 01/01/2007, a las 22:43, Noel Chiappa escribi=F3: >> From: Tony Li > >>> because of TCP checksum issues; the border router can only do so=20 >>> much, >>> unless the host is in on it too. (Which is why GSE proposed to make >>> the TCP checksum cover only the ID half, but that horse is = long-gone, >>> alas...) > >> I sincerely hope that we can rein in that horse and reconsider it. >> Otherwise the entire concept of a host/locator split ends up looking >> wholly like NAT, either in the host or in the middle box. > > Tony (et al), would it be possible to do something where the host=20 > emits the > packet with the high halves (the routing-goop) of the IPv6 addresses=20= > all > zero, and then the border router fills them in for while the packet is=20= > in > transit, and then the last-hop router (or perhaps the border router at=20= > the > destination) clears them? That way, the TCP checksum wouldn't have to=20= > be > modified (either in the code, or in packets in flight), and the hosts > wouldn't have to be in on the act. well, my personal preference would be not to leave the prefix to zero,=20= because if we do that, this means that the identifier is the lower 64=20 bits and we need to create the means to provide global uniqueness to=20 the 64 iid name space. I think it would be much easier to go for 128 bits identifiers,=20 reserving a /8 global prefix for the identifier name space (something=20 like the globally managed ULAs, but maybe with some differences on the=20= cost structure) Then these would be local addresses, that the host will use to generate=20= packet and these are valid in the local domain. when the packet reaches=20= the border of the local domain, the border router rewrites the source=20 and/or destiantion prefix with a globally routable prefix and routes it=20= through the internet. When the packet reaches the destiantion domain,=20 the border router of the destination domain rewrites the prefixes of=20 the destiantion and/or the source address, restoring the identifiers to=20= the packet. Of course, in order to do this, state about the mapping between the=20 identifiers and the locators must be securely placed in the border=20 routers bottom line: i would go for 128 bit long identifiers (rather than 64=20 bit long identifiers) because we already have the means to provide=20 global uniqqueness for 128 bit long strings and maybe some other=20 reasons that i am forgetting right now... Regards, marcelo > > (Yes, I know there's still a security issue with the binding of the RG=20= > part > to the endpoint-indentity part; I'm leaving off thinking about that=20 > until I > make sure the first step works.) > > Noel > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:51:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mrR-0004Rd-GD; Tue, 02 Jan 2007 11:51:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mrR-0004RY-0Z for ram@iab.org; Tue, 02 Jan 2007 11:51:37 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mrP-0005CH-Fd for ram@iab.org; Tue, 02 Jan 2007 11:51:36 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D6B5553D8B; Tue, 2 Jan 2007 17:51:34 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp03.uc3m.es (Postfix) with ESMTP id A07AB54B81; Tue, 2 Jan 2007 17:51:31 +0100 (CET) In-Reply-To: <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:51:42 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 31/12/2006, a las 23:35, Roland Dobbins escribi=F3: > > On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote: > >> big sites have professional network admins that can configure complex=20= >> protocols (e.g. bgp) Moreover, because of that they are likely to=20 >> want some centralized way to enforce the configurations. > > One would think that larger enterprises would have these sorts of=20 > folks available, but it isn't always true (not even predominantly=20 > true, IMHO), and even when people with those skillsets are on staff,=20= > there are generally only a few of them and this sort of thing may not=20= > be their only responsibility, either. > > Larger enterprises typically do have configuration-management systems=20= > of one sort or another, but (again, like most SPs), they're often=20 > fairly basic systems in that they allow for automatic provisioning and=20= > config versioning, but there's not a lot of logic present which=20 > automates the development of the config itself, in most cases (this is=20= > one of the main motivating factors behind the development of NETCONF).=20= > One partial exception to this observation is in the generation of=20 > ACLs, but the automation for most ACL-generation systems in use today=20= > is limited and somewhat brittle, at best, and often does not take into=20= > differences in platform capabilities/performance/resources. > > [ Come to think of it, this all sounds remarkably similar to a lot of=20= > SPs, doesn't it? ;> ] > >> A home network does not have a network admin (ir the network admin=20= >> is the user) and it is likely he is not able to do complex=20 >> configurations. > > Most large enterprises don't handle complex configurations well,=20 > either - see above. They often end up building unnecessarily complex=20= > networks for various reasons, but that's not the same thing, heh. > ok, i think we may have different definitions of complex here... I have worked in network administration of two networks: - the postal service network , with several hundreds of network=20 geographcially distributed. they do have a net amdin staff and while i=20= agree they don't like complex setups, they are able of doing what i=20 call quite complex stuff, as oposed to the other network that i reffer=20= next... - my dad's home network. He doesn't even know what an IP address is, so=20= he is not able to do any configuration at all. However, he is able to=20 use his netwrok and it is likely he may become multihomed in some=20 future, because the CATV guys may offer it for free, or the electricity=20= company or some other commodity provider. So, i can certainly see that the network admin staff of a company can=20 deal with more "complex" configuration than normal home users and they=20= are likely to have more requirements and they are likely to want to be=20= in control of what is going on in the network. A home user normally=20 doesn't even know the difference. I think this is a qualitative=20 difference that should be taken into account. It may be perfectly ok to=20= define that we will be defining a solution for users that have some=20 basic knowledge and that won't work fully autoamtically. Regards, marcelo >> I think this is (may be) an important difference > > In my experience, the difference isn't as great as one would think,=20 > IMHO. > > = ----------------------------------------------------------------------- > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 11:56:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mwA-0006qj-MR; Tue, 02 Jan 2007 11:56:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mw8-0006qb-TH for ram@iab.org; Tue, 02 Jan 2007 11:56:28 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mw7-00064f-Iw for ram@iab.org; Tue, 02 Jan 2007 11:56:28 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A395ACE720; Tue, 2 Jan 2007 17:56:26 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp02.uc3m.es (Postfix) with ESMTP id 0654ACE6B7; Tue, 2 Jan 2007 17:56:23 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 17:56:35 +0100 To: Ted Seely X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 17:05, Ted Seely escribi=F3: > > Hi Marcelo, > > On Sun, 31 Dec 2006, marcelo bagnulo braun wrote: > >> >> El 31/12/2006, a las 16:13, Roland Dobbins escribi=F3: >> >>> I believe that 'the IPv6 mulithoming solution' ought to be >>> generalizable and scalable to sites of all sizes. >> >> This is exactly where we disagree. I think this is very hard because=20= >> if >> you add up all the requirements of all type of potential multihomed >> sites, from a unmanaged lan with a couple of PCs to a highly managed >> huge corporation site, and you also add al the border constratints, >> like scalability of the routing system, then you have very very >> difficult problem >> >> >> That is why i am proposing to identify different type of multihomed >> sites and find different solutions for them > > not that i'm disagreeing with you, but would this lead to multiple > solutions? i think the last thing we all want is ala carte protocols > based on the criteria a site fits into. i'm afraid this leads to > the sqaure peg protocol for the square peg sites, and round ones for=20= > round > sites. do we really want to paint ouselves into this corner? this=20 > sounds > less flexible to me than what we have today. > i agree that this is not the best possible outcome my only concern is that if we try to find one solution that fits all=20 the requirements of all possible scenario, the solution space may be=20 nil but we can try with Noel suggestion and see if we manage to do some=20 progress with this strategy Regards, marcelo > -ted > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 12:01:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1n0z-0000jW-2E; Tue, 02 Jan 2007 12:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1n0y-0000hQ-7L for ram@iab.org; Tue, 02 Jan 2007 12:01:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1n0w-00077c-Uq for ram@iab.org; Tue, 02 Jan 2007 12:01:28 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Jan 2007 12:01:24 -0500 X-IronPort-AV: i="4.12,227,1165208400"; d="scan'208"; a="110713131:sNHT44019448" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02H1OBF009675 for ; Tue, 2 Jan 2007 12:01:24 -0500 Received: from [192.168.1.101] (rtp-vpn3-578.cisco.com [10.82.218.69]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02H1OgT001513 for ; Tue, 2 Jan 2007 12:01:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 09:01:23 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1033; t=1167757284; x=1168621284; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=1ZfqpTZbxMvD3EsWBCTHSeV42/aRC9e8wk21nDTVMJU=; b=HJ5hgoelmPOOxXSEdArBsjIi/TUjmgkr6fJB0KiYJTIfGTB7krKNWRBERmEDtGs7U0KAlmQ3 pu445fnSHj1N3yf73gu/KPPaYm6hq0aYCWvb2euYu9RgEGfo/UWBzClS; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 8:51 AM, marcelo bagnulo braun wrote: > So, i can certainly see that the network admin staff of a company > can deal with more "complex" configuration than normal home users > and they are likely to have more requirements and they are likely > to want to be in control of what is going on in the network. The enterprise folks who're the most skilled at enterprise networking are mainly in the financial services sector along some tech companies and military, IMHO; again, they have skilled folks, but not many of them, and they're looking for ways to avoid complexity if at all possible. So, we come back to the question - besides scale and internal complexity, what's the difference? Is there some set of objective criteria we can come up with on which to predicate a split? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 12:16:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nEh-0001Ze-EI; Tue, 02 Jan 2007 12:15:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nEg-0001ZY-KR for ram@iab.org; Tue, 02 Jan 2007 12:15:38 -0500 Received: from web58714.mail.re1.yahoo.com ([66.196.100.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1nEe-0000tV-8N for ram@iab.org; Tue, 02 Jan 2007 12:15:38 -0500 Received: (qmail 72812 invoked by uid 60001); 2 Jan 2007 17:15:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=gn+V8Yds5pkYWpv4C7bf2xxAmyFw9WqlwKjznCv6HXiTLcvmp7/uF1qVQWOrQxToWAhlTDMZRyz3XKFSl1UgtpB+XaVLm+a62khFHt/jMa/ex/4A7ERv0Fqz6Cip85I0MsRtSeXHG/4ufrsZbvIbP3jP614sUzukAhiUfdaxdSI=; X-YMail-OSG: Pa.D8m0VM1nQSZFT05vRpWIN6Y7tbBeCqLhLHNYsIBAAy75M3pYFwQrwCaiohGNcqnnhpWen5FETIfwansZjemNoeKOhA8kxJ.GciSi5DzU_2sruneE6ph6p.7zXSYAHpp7O_3PDA5kI4v10s7g.JtlUn0BZ79qJbFaRbwqbWHMRE0wzG210AytLGdw- Received: from [207.107.50.100] by web58714.mail.re1.yahoo.com via HTTP; Tue, 02 Jan 2007 09:15:30 PST Date: Tue, 2 Jan 2007 09:15:30 -0800 (PST) From: Peter Sherbin Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering To: Noel Chiappa , ram@iab.org In-Reply-To: <20061231155233.DC40E872D4@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <116770.72086.qm@web58714.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > (If someone has an idea which is neither of these two...) 1. LAN = current routing 2. LAN address= /32, e.g. ::0123:EUI-64 3. WAN = hierarchy of network access points with 1 AP per e.g. 30 sq miles 4. WAN address (is created at AP) = 32-bit ASN + LAN address 5. Address = topological locator 6. Interface/node ID comes from an independent pool of numbers, e.g. RFID Thanks, Peter For packet to get through WAN ASN is added into address --- Noel Chiappa wrote: > > From: Roland Dobbins > > > the proposed SHIM6 solution is iatrogenic in nature due to the reasons > > outlined previously. > > Well, perhaps it is fatally flawed, but if so, we need to figure out why, and > then work on how to overcome those issues. > > > Look, as far as I can work out, there are basically two classes of solution > to providing widespread multi-homing. > > The first is "let the routing do it". Alas, within the current routing > architecture, that amounts to "forcing every router in the entire > default-free zone to carry an advertisement for site X's PI-address", which > is widely seen (although not universally, q.v. that address registry meeting > where they approved the PI proposal) as non-workable. > > So, that leave us with "other", which as far as I can work out, means some > form of "multiple routing-names for each connected entity", because I can't > think of any other. (If someone has an idea which is neither of these two, > please speak up!) So now the only question is the engineering details: who > picks, when they are added, where they are carried, etc, etc. > > > > I don't know what the right solution is, yet. > > Well, a lot of people have been struggling with this for a long time. There > is no easy solution, or somebody would probably have figured it out by now. > > It's easy to sit back and say "solution A has problem X" and "solution B has > problem Y". That sort of situation, where there is no perfect solution, is > almost inevitable when we're trying to upgrade a large, deployed system. > Heck, I could come up with a great design for multi-homing, *if I had a blank > sheet of paper*. > > The problem here is that if we start out with a solution-space of size A, and > then start enumerating constraints, what happens is that each constraint > chops off a piece of solution space, until eventually we're caught in a > pretty small piece of solution-space. Apply enough constraints, and you're > probably tiled the entire solution-space. Something - or somebody - has got > to give. > > > > this class of proposals cannot be realistically considered for 'the > > IPv6 multihoming solution'. > > What exactly are you including in "this class"? Because if you're including > all solutions in which things have more than one routing-name, we've just > ruled out the entire solution-space (other than "let the routing do it"). > > If you are OK with the general concept, but just think the particular details > of SHIM6 have problems, yeah, could be. Explain what they are, and we can see > if there's a way to change things to overcome them. TLi explained some of the > constraints that got applied which reduced the solution-space - perhaps we > need to go back and re-examine whether some of them need to be reconsidered. > > But if you're against all solutions of the form "multiple routing-names", > what's left, other than "let the routing do it"? > > Noel > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 12:59:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nue-0008Vv-Hy; Tue, 02 Jan 2007 12:59:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1nud-0008TI-61 for ram@iab.org; Tue, 02 Jan 2007 12:58:59 -0500 Received: from web58710.mail.re1.yahoo.com ([66.196.100.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1nub-0007og-KB for ram@iab.org; Tue, 02 Jan 2007 12:58:59 -0500 Received: (qmail 34059 invoked by uid 60001); 2 Jan 2007 17:58:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=E6+vyy9sQtc3IYn6i3d4aXTolj37RWKMH8ANnMH41tCr8sQQuy22sOg9UIWnqWcQ4QsixjZKLqWV64NC/+bHP7ZMheZYHdLP2rYikfh8p79Rj01rfBW+KzGoNIsEfBDkcUTRdEdhO329M59vNnppOHr95Fdd8WanYyeRftpmeMw=; X-YMail-OSG: gYzcIQYVM1l1gJqRVtwu3CeUM.B86ceFFstKpH3L Received: from [207.107.50.100] by web58710.mail.re1.yahoo.com via HTTP; Tue, 02 Jan 2007 09:58:46 PST Date: Tue, 2 Jan 2007 09:58:46 -0800 (PST) From: Peter Sherbin Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering To: Roland Dobbins , ram@iab.org In-Reply-To: <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <127190.31968.qm@web58710.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > So, we come back to the question - besides scale and internal > complexity, what's the difference? We could look at it from the market perspective where a household is an ultimate consumption unit. Each housedhold needs addresses for millions of items down to a body cell level (this was not possible with IPv4 but it is a clear opportunity with IPv6). For redundancy households need multihoming. Hence by the magnitude of required addressing space a household easily meets and / or exceeds an enterprise requirement. Thanks, Peter --- Roland Dobbins wrote: > > On Jan 2, 2007, at 8:51 AM, marcelo bagnulo braun wrote: > > > So, i can certainly see that the network admin staff of a company > > can deal with more "complex" configuration than normal home users > > and they are likely to have more requirements and they are likely > > to want to be in control of what is going on in the network. > > The enterprise folks who're the most skilled at enterprise networking > are mainly in the financial services sector along some tech companies > and military, IMHO; again, they have skilled folks, but not many of > them, and they're looking for ways to avoid complexity if at all > possible. > > So, we come back to the question - besides scale and internal > complexity, what's the difference? Is there some set of objective > criteria we can come up with on which to predicate a split? > > ----------------------------------------------------------------------- > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 13:45:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ocx-00008x-Nj; Tue, 02 Jan 2007 13:44:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ocw-00008s-OH for ram@iab.org; Tue, 02 Jan 2007 13:44:46 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ocv-0008I2-A2 for ram@iab.org; Tue, 02 Jan 2007 13:44:46 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E3A1421313C; Tue, 2 Jan 2007 20:44:36 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8C30121312B; Tue, 2 Jan 2007 20:44:36 +0200 (EET) In-Reply-To: <759dc0f38a77039aef34c6521043f232@it.uc3m.es> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> <759dc0f38a77039aef34c6521043f232@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0070E430-BDD4-449C-8436-91233DE15521@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [RAM] About identifiers and rewriting choices (was Re: other requirement? (was Re: Traffic Engineering) Date: Tue, 2 Jan 2007 20:44:32 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Tony (et al), would it be possible to do something where the host >> emits the >> packet with the high halves (the routing-goop) of the IPv6 >> addresses all >> zero, and then the border router fills them in for while the >> packet is in >> transit, and then the last-hop router (or perhaps the border >> router at the >> destination) clears them? That way, the TCP checksum wouldn't have >> to be >> modified (either in the code, or in packets in flight), and the hosts >> wouldn't have to be in on the act. > > well, my personal preference would be not to leave the prefix to > zero, because if we do that, this means that the identifier is the > lower 64 bits and we need to create the means to provide global > uniqueness to the 64 iid name space. > > I think it would be much easier to go for 128 bits identifiers, > reserving a /8 global prefix for the identifier name space > (something like the globally managed ULAs, but maybe with some > differences on the cost structure) For the record, draft-laganier-ipv6-khi-05.txt originally proposed such a space. However, the originally proposed /8 was changed to a / 28, for a number of reasons. Reading the int-area archives for the argumentation is instructive; as you know some of that was repeated in architecture-discuss. > Then these would be local addresses, that the host will use to > generate packet and these are valid in the local domain. when the > packet reaches the border of the local domain, the border router > rewrites the source and/or destiantion prefix with a globally > routable prefix and routes it through the internet. When the packet > reaches the destiantion domain, the border router of the > destination domain rewrites the prefixes of the destiantion and/or > the source address, restoring the identifiers to the packet. As I wrote at the architecture-discuss list, in those solutions that are based on rewriting identifiers to locators and vice versa, there are two "architectural" dimensions: 1. Where the rewriting is done logically: "above" transport, somewhere within transport and/or host part of IP, or "below" the host part of IP, i.e., as a part of the "routing" system. 2. Where the rewriting is done physically: in an application, at the host (in a library, stack, or close to the device driver), or in the network Those two dimensions are pretty independent, though not absolutely orthogonal. For example, even if the architectural solution would be based on rewriting at the host (like in HIP and SHIM6, among others), the rewriting can be implemented in a separate box. Likewise, even if the rewriting was logically done below the host part of IP, as a part of the routing system, hosts could still implement it "close to the device driver". I'm writing a draft outlining how to do that, what are the security implications, and what are the basic details in each of the nine different cases. However, don't hold your breath; I've also got other things to do. Though, the main message is that these two dimensions are pretty independent, and can be varied from site to site, depending on operational demands. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 14:03:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ouK-00035V-UM; Tue, 02 Jan 2007 14:02:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ouJ-00031m-Ez for ram@iab.org; Tue, 02 Jan 2007 14:02:43 -0500 Received: from elle.sprintlink.net ([199.0.234.34] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ouI-0003Gg-6Q for ram@iab.org; Tue, 02 Jan 2007 14:02:43 -0500 Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id l02IrfH14353; Tue, 2 Jan 2007 13:53:41 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id OAA02734; Tue, 2 Jan 2007 14:06:09 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Tue, 2 Jan 2007 14:06:09 -0500 (EST) From: Ted Seely X-X-Sender: To: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Marcelo, On Tue, 2 Jan 2007, marcelo bagnulo braun wrote: > > El 31/12/2006, a las 23:35, Roland Dobbins escribi=F3: > > > > > On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote: > > > >> big sites have professional network admins that can configure complex > >> protocols (e.g. bgp) Moreover, because of that they are likely to > >> want some centralized way to enforce the configurations. > > > > One would think that larger enterprises would have these sorts of > > folks available, but it isn't always true (not even predominantly > > true, IMHO), and even when people with those skillsets are on staff, > > there are generally only a few of them and this sort of thing may not > > be their only responsibility, either. > > > > Larger enterprises typically do have configuration-management systems > > of one sort or another, but (again, like most SPs), they're often > > fairly basic systems in that they allow for automatic provisioning and > > config versioning, but there's not a lot of logic present which > > automates the development of the config itself, in most cases (this is > > one of the main motivating factors behind the development of NETCONF). > > One partial exception to this observation is in the generation of > > ACLs, but the automation for most ACL-generation systems in use today > > is limited and somewhat brittle, at best, and often does not take into > > differences in platform capabilities/performance/resources. > > > > [ Come to think of it, this all sounds remarkably similar to a lot of > > SPs, doesn't it? ;> ] > > > >> A home network does not have a network admin (ir the network admin > >> is the user) and it is likely he is not able to do complex > >> configurations. > > > > Most large enterprises don't handle complex configurations well, > > either - see above. They often end up building unnecessarily complex > > networks for various reasons, but that's not the same thing, heh. > > > > ok, i think we may have different definitions of complex here... > > I have worked in network administration of two networks: > - the postal service network , with several hundreds of network > geographcially distributed. they do have a net amdin staff and while i > agree they don't like complex setups, they are able of doing what i > call quite complex stuff, as oposed to the other network that i reffer > next... undeniably a very valid example of a large organization that is able to support a large and complex network. However, there is a distinct difference in what commercial organizations can and want to support versus government organizations. one gets paid for regardless (called taxes and being able to print your own money :), the other has to stay in business and fund its own. having done both in a previous life, it is a day and night difference between the commercial sector and the government sector. we have to keep in mind that the small to mid size company, which make up the large majority of companies, do not have a lot of in house expertise, nor are their networks a focus of their business. sorry to continue to beat that horse. but... your dad sure sounds a lot like mine too. :-) > - my dad's home network. He doesn't even know what an IP address is, so > he is not able to do any configuration at all. However, he is able to > use his netwrok and it is likely he may become multihomed in some > future, because the CATV guys may offer it for free, or the electricity > company or some other commodity provider. and i sure hope that my dad isn't offerd a choice, because he won't know what to do with it, nor does he care. :) -ted k _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 14:14:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1p5s-0001Ud-6S; Tue, 02 Jan 2007 14:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1p5q-0001US-CY for ram@iab.org; Tue, 02 Jan 2007 14:14:38 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1p5o-0005gT-SG for ram@iab.org; Tue, 02 Jan 2007 14:14:38 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net[24.125.117.214]) by comcast.net (alnrmhc12) with SMTP id <20070102191435b1200dda92e>; Tue, 2 Jan 2007 19:14:36 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6EF58C67-E41C-4E71-82CB-257ACC65754B@eyeconomics.com> Content-Transfer-Encoding: quoted-printable From: tvest@eyeconomics.com Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 14:14:24 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 2:06 PM, Ted Seely wrote: > > Marcelo, > > On Tue, 2 Jan 2007, marcelo bagnulo braun wrote: > >> >> El 31/12/2006, a las 23:35, Roland Dobbins escribi=F3: >> >>> >>> On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote: >>> >>>> big sites have professional network admins that can configure =20 >>>> complex >>>> protocols (e.g. bgp) Moreover, because of that they are likely to >>>> want some centralized way to enforce the configurations. >>> >>> One would think that larger enterprises would have these sorts of >>> folks available, but it isn't always true (not even predominantly >>> true, IMHO), and even when people with those skillsets are on staff, >>> there are generally only a few of them and this sort of thing may =20= >>> not >>> be their only responsibility, either. >>> >>> Larger enterprises typically do have configuration-management =20 >>> systems >>> of one sort or another, but (again, like most SPs), they're often >>> fairly basic systems in that they allow for automatic =20 >>> provisioning and >>> config versioning, but there's not a lot of logic present which >>> automates the development of the config itself, in most cases =20 >>> (this is >>> one of the main motivating factors behind the development of =20 >>> NETCONF). >>> One partial exception to this observation is in the generation of >>> ACLs, but the automation for most ACL-generation systems in use =20 >>> today >>> is limited and somewhat brittle, at best, and often does not take =20= >>> into >>> differences in platform capabilities/performance/resources. >>> >>> [ Come to think of it, this all sounds remarkably similar to a =20 >>> lot of >>> SPs, doesn't it? ;> ] >>> >>>> A home network does not have a network admin (ir the network admin >>>> is the user) and it is likely he is not able to do complex >>>> configurations. >>> >>> Most large enterprises don't handle complex configurations well, >>> either - see above. They often end up building unnecessarily =20 >>> complex >>> networks for various reasons, but that's not the same thing, heh. >>> >> >> ok, i think we may have different definitions of complex here... >> >> I have worked in network administration of two networks: >> - the postal service network , with several hundreds of network >> geographcially distributed. they do have a net amdin staff and =20 >> while i >> agree they don't like complex setups, they are able of doing what i >> call quite complex stuff, as oposed to the other network that i =20 >> reffer >> next... > > undeniably a very valid example of a large organization that is =20 > able to > support a large and complex network. However, there is a distinct > difference in what commercial organizations can and want to support =20= > versus > government organizations. one gets paid for regardless (called =20 > taxes and > being able to print your own money :), the other has to stay in =20 > business > and fund its own. having done both in a previous life, it is a day =20= > and > night difference between the commercial sector and the government =20 > sector. > we have to keep in mind that the small to mid size company, which =20 > make up > the large majority of companies, do not have a lot of in house =20 > expertise, > nor are their networks a focus of their business. sorry to =20 > continue to > beat that horse. > > but... your dad sure sounds a lot like mine too. :-) > >> - my dad's home network. He doesn't even know what an IP address =20 >> is, so >> he is not able to do any configuration at all. However, he is able to >> use his netwrok and it is likely he may become multihomed in some >> future, because the CATV guys may offer it for free, or the =20 >> electricity >> company or some other commodity provider. > > and i sure hope that my dad isn't offerd a choice, because he won't =20= > know > what to do with it, nor does he care. :) I'm a dad, and I care now -- will certainly care in the years to =20 come, when the oldtimer references on this list are about us! (i.e., when any of this might plausibly be implemented) TV _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 14:30:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pKK-0000vg-Ua; Tue, 02 Jan 2007 14:29:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pKK-0000vb-1e for ram@iab.org; Tue, 02 Jan 2007 14:29:36 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1pKJ-0007aM-C8 for ram@iab.org; Tue, 02 Jan 2007 14:29:36 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 866E921313C for ; Tue, 2 Jan 2007 21:29:34 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E4F2721312B for ; Tue, 2 Jan 2007 21:29:33 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: Pekka Nikander Date: Tue, 2 Jan 2007 21:29:29 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [RAM] An attempt to summarise the "Traffic Engineering" discussion so far X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Having read through the various sub-threads in the "TE" discussion, and re-read about 15 messages that seemed to have the most informed content to me, I'm foolishly trying to summarise what I see, with an architectural twinkle in my eye. I hope this helps the community. However, before going to that, I really recommend people to re-read Elwyn's recent and very good analysis on how TE and multi-homing can be viewed as a single phenomenon: http://www1.ietf.org/mail-archive/web/ram/current/msg00102.html At the same time I would recommend people to remember that Elwyn's analysis is only one way of looking at the problem domain; it can also be divided in a few other ways. A brief and (hopefully) balanced summary: One main theme was mostly concerned about the costs (hardware/ software/administration), with a few folks arguing that because of this any solution that mandates (as a non-optional feature) multiple globally routable IP addresses to each multi-homed host is a non- starter. This argument was countered by splitting the identifier and locator roles of addresses and arguing that the costs will not be that big since the hosts will still have just one identifier. A second overall theme cornered around who (which node) should have the control over path selection. Obviously, the operators and folks with experience on TE and complex site multi-homing abhor each host being empowered to do the decision. Almost as obviously, people working with mobile hosts with multiple radio interfaces consider it natural that hosts make the choice between the interfaces. Architecturally, there seems to be different kinds of path selection: one kind that Elwyn excellently described in his note, and another kind that is more related to mobility and hosts or sub-networks that are both mobile and multi-homed. A third theme considered whether there should be only one multi- homing solution, or perhaps many of them. Towards the end of this theme, it was suggested that perhaps there could be an architectural solution that could be implemented in a way that would fit both large and small multi-homed sites. A more detailed and slightly opinionated summary: The discussion was started by RJA's request to the operators to enumerate the ways TE is being used: http://www1.ietf.org/mail-archive/web/ram/current/msg00123.html From there on, the discussion seemed to converge to pretty opinionated message exchange around the following topics: 1. Embedding of today's IP addresses in ACLs, firewall rules, ASICs that implement them, etc. The crux of this argument seems to be that adding multiple globally routable IP addresses to each host at large multi-homed sites multiplies the related hardware and software costs. The counter argument is that with a properly implemented identifier / locator split, it is the identifiers that are stored in ACLs, firewall rules, etc, not the locators. Consequently, there is no additional hardware/ software cost here. The main caveat here is "properly implemented". Firstly, that may require adding (soft) state at the filtering devices, if the packets only carry the locator or if the identifiers are encrypted. Secondly, depending on the solution, the administrative costs of upgrading the information from current addresses to future identifiers may become a major upgrade barrier. I think Noel summarised this thread nicely here: http://www1.ietf.org/mail-archive/web/ram/current/msg00169.html Marcelo added nicely some details about the implementation and state: http://www1.ietf.org/mail-archive/web/ram/current/msg00178.html http://www1.ietf.org/mail-archive/web/ram/current/msg00193.html Finally, Roland added some (IMHO) very important thoughts about IDs and privacy: http://www1.ietf.org/mail-archive/web/ram/current/msg00211.html 2. Troubleshooting, help desk, and other similar problems related to multiple IP addresses. Even if there was an id/loc split in place that relieved the above burden from filtering and other configuration, having multiple locators per each host may still cause additional cost in troubleshooting, help desk, etc. The counter argument is that with proper tools (which of course don't exist yet) the costs may be pushed back to their current levels. Additionally, depending on the types of the identifiers, the IDs may be engineered to further help troubleshooting. http://www1.ietf.org/mail-archive/web/ram/current/msg00160.html 3. Problems with botnets I think Marshall Eubanks noticed this potential problem first, but opinions differ whether this is really a problem or not. Basically, the claim is that if hosts have multiple globally routable IP addresses, botnet operators would benefit since they would have more control on how to route the traffic when leaving the individual bots. The counter arguments include that many hosts will anyway include multiple addresses since they will have multiple interfaces and that simple source address selection does not equal with full path selection. http://www1.ietf.org/mail-archive/web/ram/current/msg00154.html http://www1.ietf.org/mail-archive/web/ram/current/msg00164.html 4. Who is trusted or empowered to do path selection A central issue in the discussion seems to be whether path selection should be done in hosts or in routers. Some people argue, apparently validly, that there are installations where it is practically impossible (given today's technology) to do it in the host, and would be a waste of resources anyway. Igor's message outlined it pretty nicely: http://www1.ietf.org/mail-archive/web/ram/current/msg00145.html Later on, Roland made some important points: http://www1.ietf.org/mail-archive/web/ram/current/msg00195.html To me, there seems to be an underlying issue which perhaps didn't come out properly in the discussion so far. Namely, there is only a relatively little amount of dependency between where the path selection is done *logically* in the host or not, and whether is is done *physically* in the host or not. Even in the case that hosts were logically empowered to do some part of the path selection by making them logically visible through several distinct globally routable IP addresses, that functionality can be delegated to the network. The solution smells and looks a little bit like NAT, but so what any solution that rewrites the address fields in the IP header. Personally, I tried to make this distinction clear in my other message (which is not in the Web archive at this writing.) A perhaps even more fundamental problem is related to trust: who is trusted to make the path selection. This was not taken up directly, but the botnet thread was clearly related. W.r.t to SHIM6 in this respect, David Conrad explained the history succinctly: http://www1.ietf.org/mail-archive/web/ram/current/msg00177.html As a response to that, the details of how to make SHIM6 into a proper site-multi-homing technology, where the locator selection is done as a site-wide function and not in individual hosts, hasn't really been worked out. But IMHO they could. 5. Do we need multiple or just one solution A larger part of the discussion seemed to circle around whether we could live with just one solution for multi-homing, or whether there should be separate solutions for "large sites" and small, SO-HO type sites. Obviously, some effort was spent (in vain) to define where the border line would be. In the end, Noel suggested that perhaps there could be an architectural solution that would fit into the two different sets of requirements through differently engineered implementations: http://www1.ietf.org/mail-archive/web/ram/current/msg00234.html -------- I'm sure I missed some threads; sorry for that. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 16:28:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rAb-0001Ws-Jn; Tue, 02 Jan 2007 16:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rAa-0001Wk-TG for ram@iab.org; Tue, 02 Jan 2007 16:27:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rAY-00029Z-Iq for ram@iab.org; Tue, 02 Jan 2007 16:27:40 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2007 13:27:38 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02LRb69006292; Tue, 2 Jan 2007 13:27:37 -0800 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 l02LRGnc022693; Tue, 2 Jan 2007 13:27:16 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 13:27:14 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 13:27:14 -0800 In-Reply-To: <759dc0f38a77039aef34c6521043f232@it.uc3m.es> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> <759dc0f38a77039aef34c6521043f232@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EE07C1B-BE59-48B4-ABC4-094A89B64A34@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 13:27:10 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Jan 2007 21:27:14.0292 (UTC) FILETIME=[C5537340:01C72EB4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1018; t=1167773257; x=1168637257; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=su9EPh2av/AobqsTnApXAX4xGU/0t1tJCbCkqyR/SHQ=; b=qnOUG4/x//n2kQEqrQiFHDPL05QpfkE3jy3EP6vvjdC85V2XBfdM+AFa5avHQ4dhN43/PKsV 5nhNoc6W19PAKmVa4HznMuFj+eLlnCJ691HTNyigIiZ4SPDYqS6ZrZqg; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 8:40 AM, marcelo bagnulo braun wrote: > if we do that, this means that the identifier is the lower 64 bits > and we need to create the means to provide global uniqueness to the > 64 iid name space. If you want a field that is semantically an 'identifier', it needs to be unique. Or at the very least statistically unique. > I think it would be much easier to go for 128 bits identifiers, > reserving a /8 global prefix for the identifier name space > (something like the globally managed ULAs, but maybe with some > differences on the cost structure) > Then these would be local addresses, that the host will use to > generate packet and these are valid in the local domain. when the > packet reaches the border of the local domain, the border router > rewrites the source and/or destiantion prefix with a globally > routable prefix and routes it through the internet. This would be NAT. If we're doing NAT, why not just stay with IPv4? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 16:39:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rLU-0006yc-Hb; Tue, 02 Jan 2007 16:38:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rLT-0006yP-C8 for ram@iab.org; Tue, 02 Jan 2007 16:38:55 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1rLN-0004zq-8n for ram@iab.org; Tue, 02 Jan 2007 16:38:55 -0500 Received: from webmail53.lax.untd.com (webmail51.lax.untd.com [10.131.27.191]) by smtpout02.lax.untd.com with SMTP id AABC3XWFQAMWMKCA for (sender ); Tue, 2 Jan 2007 13:37:50 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKVlh1kDCGkF/IEentxNZ4kw== Received: (from fergdawg@netzero.net) by webmail51.lax.untd.com (jqueuemail) id MA42Y4LT; Tue, 02 Jan 2007 13:37:30 PST Received: from [168.61.0.42] by webmail51.lax.untd.com with HTTP: Tue, 2 Jan 2007 21:37:08 GMT X-Originating-IP: [168.61.0.42] Mime-Version: 1.0 From: "Fergie" Date: Tue, 2 Jan 2007 21:37:08 GMT To: tli@cisco.com Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070102.133730.2521.1821830@webmail51.lax.untd.com> X-ContentStamp: 10:5:2094454857 X-MAIL-INFO: 03700065d4d45d40f4d434c444ed19117d797474c1e9557104 X-UNTD-Peer-Info: 10.131.27.191|webmail51.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Tony Li wrote: >> I think it would be much easier to go for 128 bits identifiers, = >> reserving a /8 global prefix for the identifier name space = >> (something like the globally managed ULAs, but maybe with some = >> differences on the cost structure) >> Then these would be local addresses, that the host will use to = >> generate packet and these are valid in the local domain. when the = >> packet reaches the border of the local domain, the border router = >> rewrites the source and/or destiantion prefix with a globally = >> routable prefix and routes it through the internet. > > >This would be NAT. If we're doing NAT, why not just stay with IPv4? > Works for me. Really. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFmtB5q1pz9mNUZTMRAg3mAKC4y8nTjw3z+1TWQSPfbkpGwgyTQgCg4Iy/ aBAY9f2RL6e7fL1O6fiL6Ss=3D =3DDXFT -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 17:09:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ron-00040A-MD; Tue, 02 Jan 2007 17:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rom-0003zz-2K for ram@iab.org; Tue, 02 Jan 2007 17:09:12 -0500 Received: from centrmmtao04.cox.net ([70.168.83.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1roi-0002sZ-OP for ram@iab.org; Tue, 02 Jan 2007 17:09:12 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070102220906.NYTD5993.centrmmtao04.cox.net@eastrmimpo02.cox.net> for ; Tue, 2 Jan 2007 17:09:06 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 6N7k1W00Q0pnMhQ0000000; Tue, 02 Jan 2007 17:07:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 2 Jan 2007 17:09:05 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [RAM] Destination Locator selection X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org People seem to view the alternatives as either: origin host selects which destination Locator to put in packet XOR some router selects which destination Locator to put in packet I respectfully submit that this is a false choice and that this misconception is hindering the discussions here. Another, IMHO preferable, approach is to have the origin host put both source Locator and destination Locator into the packet, but do not make it illegal/impossible for some router along the path to re-write/modify either Locator iff that router really has enough knowledge to do so in some thoughtful way. Not all routers in the world might have enough knowledge to do so. Not all routers in the world might choose to do so. By having the origin host put in a valid destination Locator, but avoiding precluding routers along the path from applying better information, we can have the best of both worlds, IMHO. To some extent, any NAT-compatible approach will at least not preclude routers on the path from updating the destination Locator. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 17:15:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ruo-000867-CZ; Tue, 02 Jan 2007 17:15:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rum-000862-Ta for ram@iab.org; Tue, 02 Jan 2007 17:15:24 -0500 Received: from centrmmtao03.cox.net ([70.168.83.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rul-0004NA-K3 for ram@iab.org; Tue, 02 Jan 2007 17:15:24 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070102221523.IFIV13993.centrmmtao03.cox.net@eastrmimpo02.cox.net> for ; Tue, 2 Jan 2007 17:15:23 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 6NE11W00S0pnMhQ0000000; Tue, 02 Jan 2007 17:14:01 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <6CD3B854-F172-4408-AC73-8DF6D4C47240@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 2 Jan 2007 17:15:22 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [RAM] aside Re: HIP X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I think HIP is really great research. I am not quite as enthusiastic about HIP as an operational solution. My main concern is that with HIP, when one's public key is compromised (and, yes, that is always a WHEN, not an IF), one always necessarily loses one's Identifier. This seems pretty undesirable to me. HIP-like solutions that don't have issues of that sort are pretty different from any of the currently available HIP specifications. Yes, the HIP authors/editors left the door open a crack, but AFAIK there isn't any proposal for how to make an Identifier workable if the Identifier is not derived from one's public key. Also, for moderate threat environments, I think all the HIP cryptography is overkill and computationally expensive. I'd prefer to have the option for a less computationally intense and less comprehensive security mechanism for moderate threat environments. (Something that merely prevented off-path attacks seems possible to me and might be interesting to have as a deployment option.) Sigh. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 17:16:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rwD-00016D-0Y; Tue, 02 Jan 2007 17:16:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rwC-000168-4M for ram@iab.org; Tue, 02 Jan 2007 17:16:52 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rw9-0004dF-QY for ram@iab.org; Tue, 02 Jan 2007 17:16:52 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Jan 2007 14:16:49 -0800 X-IronPort-AV: i="4.12,227,1165219200"; d="scan'208"; a="757934174:sNHT42083472" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l02MGnaZ012437; Tue, 2 Jan 2007 14:16:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l02MGnPn006181; Tue, 2 Jan 2007 14:16:49 -0800 (PST) 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.1830); Tue, 2 Jan 2007 14:16:48 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 14:16:48 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 14:16:45 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Jan 2007 22:16:48.0774 (UTC) FILETIME=[B2416260:01C72EBB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=675; t=1167776209; x=1168640209; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20; bh=skxLFI9aexZSv6aBAlS5y7o2mQ0cK2DaoNgjwjpxSQI=; b=NEFUQknMa8X+8pkTK2XySBEFUO/7MoXQRCNBk+R5s+8A4Zp9MGaQAFp0hZve0V3+dK+pCEkm ttkmtxkctF4vX9lqaZDe+xTx8nM/1PT9lMyrMCBm/h62fZPqmo561MO0; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Another, IMHO preferable, approach is to have the origin host > put both source Locator and destination Locator into the packet, > but do not make it illegal/impossible for some router along the > path to re-write/modify either Locator iff that router really has > enough knowledge to do so in some thoughtful way. Not all routers > in the world might have enough knowledge to do so. Not all routers > in the world might choose to do so. By having the origin host put > in a valid destination Locator, but avoiding precluding routers along > the path from applying better information, we can have the best of > both worlds, IMHO. Works for me. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 17:32:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1sAp-0002Uw-Hu; Tue, 02 Jan 2007 17:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1sAo-0002UO-4v for ram@iab.org; Tue, 02 Jan 2007 17:31:58 -0500 Received: from centrmmtao04.cox.net ([70.168.83.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1sAm-0006Ln-AV for ram@iab.org; Tue, 02 Jan 2007 17:31:57 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070102223154.OMRF5993.centrmmtao04.cox.net@eastrmimpo02.cox.net> for ; Tue, 2 Jan 2007 17:31:54 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 6NWY1W00W0pnMhQ0000000; Tue, 02 Jan 2007 17:30:32 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <840284D3-2C53-4ED1-B4C3-65797ABB77BD@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 2 Jan 2007 17:31:53 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [RAM] Aside: Home LANs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org % It occurs to me that the principle difference between those two cases % is that the home user is very unlikely to have more than one in-house % link (or at least, isn't using IP routing). Home networks are more likely % to be doing link aggregation at the 802 level... I hope. I think that multi-homed residential networks will become increasingly common. There is a fair bit of interesting stuff happening in some little villages in Cambridgeshire. In one place, people with various uplinks (DSL, cable modem, dialup) are also running wireless Ethernet among themselves. One of these people was a networking researcher. So there is some pretty interesting work in "village area networking" being undertaken in the UK these days. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 17:35:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1sEb-0004Kd-Ru; Tue, 02 Jan 2007 17:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1sEb-0004KY-8Z for ram@iab.org; Tue, 02 Jan 2007 17:35:53 -0500 Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1sEa-0006ql-0R for ram@iab.org; Tue, 02 Jan 2007 17:35:53 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070102223545.TZD27968.eastrmmtao04.cox.net@eastrmimpo02.cox.net> for ; Tue, 2 Jan 2007 17:35:45 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 6NaQ1W0080pnMhQ0000000; Tue, 02 Jan 2007 17:34:24 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 2 Jan 2007 17:35:44 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [RAM] GSE security X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org % Well, GSE is certainly missing the security paraphernalia. % I think that we all pretty much agree on that. I'd rephrase the first sentence as: The existing published GSE Internet-Drafts did not go into detail about how information might be authenticated. And then I'd note that not having written the security paraphernalia down is wildly different from "it is impossible to secure". Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 18:18:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ssc-00062E-HM; Tue, 02 Jan 2007 18:17:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ssb-00061R-Io for ram@iab.org; Tue, 02 Jan 2007 18:17:13 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ssZ-0005lV-2Y for ram@iab.org; Tue, 02 Jan 2007 18:17:13 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l02NH6Vm018494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jan 2007 17:17:06 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 17:17:05 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 4:09 PM, RJ Atkinson wrote: > > People seem to view the alternatives as either: > origin host selects which destination Locator to put in packet > XOR > some router selects which destination Locator to put in packet > > I respectfully submit that this is a false choice and that > this misconception is hindering the discussions here. One more option for discussion might be for the origin host to put multiple destination locators in the packet. After all, it already likely has that information after a DNS lookup etc. And multiple destination locators in the packet might make it easier for routers to do what you mention below? > > Another, IMHO preferable, approach is to have the origin host > put both source Locator and destination Locator into the packet, > but do not make it illegal/impossible for some router along the > path to re-write/modify either Locator iff that router really has > enough knowledge to do so in some thoughtful way. Not all routers > in the world might have enough knowledge to do so. Not all routers > in the world might choose to do so. By having the origin host put > in a valid destination Locator, but avoiding precluding routers along > the path from applying better information, we can have the best of > both worlds, IMHO. > > To some extent, any NAT-compatible approach will at least > not preclude routers on the path from updating the destination > Locator. > > Yours, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 18:23:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1syR-0001za-AX; Tue, 02 Jan 2007 18:23:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1syP-0001zO-9y for ram@iab.org; Tue, 02 Jan 2007 18:23:13 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1syO-000714-3r for ram@iab.org; Tue, 02 Jan 2007 18:23:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Jan 2007 18:23:10 -0500 X-IronPort-AV: i="4.12,228,1165208400"; d="scan'208"; a="110741636:sNHT41616740" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02NN94J015979 for ; Tue, 2 Jan 2007 18:23:09 -0500 Received: from [68.26.62.166] (rtp-vpn3-483.cisco.com [10.82.217.229]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02NN7gT027722 for ; Tue, 2 Jan 2007 18:23:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 15:23:04 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=427; t=1167780189; x=1168644189; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=O9KWQggSTKFVTvseVUYS2kkv/HZnVtqUpLDwuMfYdik=; b=pOhPLFwWErf1Xv59wVSetBxxUNMR+SGliuoHYtOLtSMRBvSlI8wducskjIvXpvlefvD14+DG t1v2OeveIr3aICMJxhvDvgZiGyEqcjT4GicU7PafyyFkbEr850rQ7uTk; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 3:17 PM, Bruce Curtis wrote: > After all, it already likely has that information after a DNS > lookup etc. A surprising amount of IP-based communication takes place without DNS lookups at all. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 18:27:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t2B-0004ov-Nl; Tue, 02 Jan 2007 18:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1t2A-0004oq-7q for ram@iab.org; Tue, 02 Jan 2007 18:27:06 -0500 Received: from [2a01:d0::6:2] (helo=master.netassist.kiev.ua) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1t24-0008GK-GY for ram@iab.org; Tue, 02 Jan 2007 18:27:06 -0500 Received: from [195.214.209.43] (helo=[192.168.253.3]) by master.netassist.kiev.ua with esmtpa (Exim 4.60 and XAMS 0.0.13) id 1H1sz0-0006cF-8q for ram@iab.org; Wed, 03 Jan 2007 01:23:50 +0200 Message-ID: <459AEA23.1020807@netassist.kiev.ua> Date: Wed, 03 Jan 2007 01:26:27 +0200 From: Max Tulyev User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [RAM] End-user multihoming idea X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi All, I think it is a good idea to use DNS names as a kind of "route identifiers" for end-users. The only you need is two (or more) connections to different ISPs and specially crafted DNS server that generates non-cacheable (TTL=1) replies using extra data (i.e. source address of querier, channels load statistics, is the particular channel in use or broken now, etc). It will be good enough for stable access to the site and services (www.foo.com, mail.foo.com, ...) with back-ups and load ballancing - the only thing most people expect from multihoming. Yes, it doesn't help for hardcoded IP services, and established connections will be lost (but probably restores with new IP) when one of channels went down, but most of users will experience no problems at all. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 18:38:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tCP-00034K-PW; Tue, 02 Jan 2007 18:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tCO-00034A-Bm for ram@iab.org; Tue, 02 Jan 2007 18:37:40 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1tCN-0002x7-0F for ram@iab.org; Tue, 02 Jan 2007 18:37:40 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l02NbcCm019553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jan 2007 17:37:38 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 17:37:37 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 5:23 PM, Roland Dobbins wrote: > > On Jan 2, 2007, at 3:17 PM, Bruce Curtis wrote: > >> After all, it already likely has that information after a DNS >> lookup etc. > > A surprising amount of IP-based communication takes place without > DNS lookups at all. But for the amount that does happen based on DNS the end host is more likely to already have the required information than a middle box. I think the most interesting case is the other side of the connection, the host receiving the connection request won't know the multiple locators of the originating host unless it does a reverse DNS lookup and then a forward (or something similar which it likely doesn't do today) or the information about the originating host's multiple locators is also in the packet. > ---------------------------------------------------------------------- > - > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 18:47:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tLL-0000kl-PF; Tue, 02 Jan 2007 18:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tLL-0000kg-Cp for ram@iab.org; Tue, 02 Jan 2007 18:46:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1tLJ-0005B9-5Z for ram@iab.org; Tue, 02 Jan 2007 18:46:55 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 15:46:53 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49863960:sNHT43497480" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02Nkqnm021530 for ; Tue, 2 Jan 2007 18:46:52 -0500 Received: from [68.26.62.166] (rtp-vpn3-483.cisco.com [10.82.217.229]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l02NkoG9005034 for ; Tue, 2 Jan 2007 18:46:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 15:46:47 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1061; t=1167781612; x=1168645612; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=xYUXN8r00SYWfwCPCRrNP3nwLvb/EkIMmbtW2j1lYno=; b=WM5ZjBDE1V2UGIhj/GXrenvRpCCP+QKAWzErbrRq7agHX/gSxkuDg8EVQHAQcnl5KFhmutEn 5Z6q5HxT9GxD80Qs69RPQ/eudxsPMyCY7/KPoh0oCvF2KmmaS1x476YM; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 3:37 PM, Bruce Curtis wrote: > I think the most interesting case is the other side of the > connection, the host receiving the connection request won't know > the multiple locators of the originating host unless it does a > reverse DNS lookup and then a forward (or something similar which > it likely doesn't do today) or the information about the > originating host's multiple locators is also in the packet. This is a very astute observation; I don't believe we can count on DNS being available for a number of reasons (hosts without DNS mappings, broken/incomplete PTR records, DoS attacks, whatever). I also don't think we can seriously consider imposing such an additional query-burden on the global DNS infrastructure without serious consideration of and discussion of the consequences thereof. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 19:04:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tbe-0002Kg-Ta; Tue, 02 Jan 2007 19:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tba-0002DS-Eb for ram@iab.org; Tue, 02 Jan 2007 19:03:42 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1tP7-0005rE-49 for ram@iab.org; Tue, 02 Jan 2007 18:50:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Jan 2007 18:50:49 -0500 X-IronPort-AV: i="4.12,228,1165208400"; d="scan'208"; a="110742796:sNHT45328790" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l02NommV024703 for ; Tue, 2 Jan 2007 18:50:48 -0500 Received: from [68.26.62.166] (rtp-vpn3-483.cisco.com [10.82.217.229]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l02NokG9005704 for ; Tue, 2 Jan 2007 18:50:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 15:50:43 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=634; t=1167781848; x=1168645848; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=/a204jID3z8Sg1CVwgxybMKe6DuJ6Yzk1RLCDQDvcAc=; b=LoJRMUeHPbtPahuDdgknLwMLfpYTJc58exwUnLZRqhB2EKVdYGBwAsM4Swkt5pFxs8jZBkOw yCVZelHMWwjtEtcv/Dv/khxugGbVPLuxCMypUVMMJ4FUKtHVsMam+z7N; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 3:46 PM, Roland Dobbins wrote: > I also don't think we can seriously consider imposing such an > additional query-burden on the global DNS infrastructure without > serious consideration of and discussion of the consequences thereof. And per my reply to Max, I believe very strongly that IP networks, including multihomed ones, must be able to function in the absence of any naming system at all. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 19:06:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1te7-0003mD-4E; Tue, 02 Jan 2007 19:06:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1te6-0003lz-27 for ram@iab.org; Tue, 02 Jan 2007 19:06:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1tNZ-0005Mx-Pv for ram@iab.org; Tue, 02 Jan 2007 18:49:14 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 15:49:13 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49864085:sNHT42396700" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l02NnDX9024327 for ; Tue, 2 Jan 2007 18:49:13 -0500 Received: from [68.26.62.166] (rtp-vpn3-483.cisco.com [10.82.217.229]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02NnBgT002030 for ; Tue, 2 Jan 2007 18:49:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <459AEA23.1020807@netassist.kiev.ua> References: <459AEA23.1020807@netassist.kiev.ua> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] End-user multihoming idea Date: Tue, 2 Jan 2007 15:49:08 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=702; t=1167781753; x=1168645753; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20End-user=20multihoming=20idea |Sender:=20 |To:=20ram@iab.org; bh=ztSaiLl5RmJAzJK2Z4z0yo5kF3BtekUC/H6K2UkK6RY=; b=YYLjUYwu99xsLKXKglrksgFlD01yW6L4uqsEV2QP/UxGreqFds9RYuP3xyWQNFVMRpnVq2JQ FSM73S2aWSVscpZvgem5DG75mBP1wxj2RXX8AJ/89nkuOm1H4MSMP9Hc; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 3:26 PM, Max Tulyev wrote: > I think it is a good idea to use DNS names as a kind of "route > identifiers" for end-users. I understand your logic, but we can't count on DNS services being available due to a number of factors (misconfiguration, lack of DNS mappings, DDoS, etc.), nor can we just arbitrarily impose than kind of burden on the global DNS infrastructure. Multihomed IP networks must function in the complete absence of any naming system at all. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 19:31:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1u1I-000222-K3; Tue, 02 Jan 2007 19:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1u1H-00021w-4c for ram@iab.org; Tue, 02 Jan 2007 19:30:15 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1u1F-0004XA-3J for ram@iab.org; Tue, 02 Jan 2007 19:30:14 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l030M40f094029; Tue, 2 Jan 2007 16:22:05 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 02 Jan 2007 16:29:52 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 02 Jan 2007 16:29:52 -0800 In-Reply-To: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> From: David Conrad Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 16:29:50 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > And per my reply to Max, I believe very strongly that IP networks, > including multihomed ones, must be able to function in the absence > of any naming system at all. Why? Thanks, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 19:39:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1u99-0008MK-CV; Tue, 02 Jan 2007 19:38:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1u98-0008MC-NI for ram@iab.org; Tue, 02 Jan 2007 19:38:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1u97-0006jl-Gi for ram@iab.org; Tue, 02 Jan 2007 19:38:22 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 16:38:21 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49865732:sNHT43883728" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l030cLxZ001744 for ; Tue, 2 Jan 2007 19:38:21 -0500 Received: from [192.168.1.101] (rtp-vpn1-153.cisco.com [10.82.224.153]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l030cLgT009081 for ; Tue, 2 Jan 2007 19:38:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 16:38:19 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=808; t=1167784701; x=1168648701; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=03EN7E+9Ws/I82qs3fP41f9FT5BT7us9s6U6Fq2MuUk=; b=tT5vAsx8VTQJOiQvnaPMlDpYOycEM6HLAl7Ti3O5qvXoUBzx8ECU6avMSORC5REMwvSlborE TxS1RWQNP4knhBYxLmNEcCYpU5XTux16k/XmQ9O5EJ5/CYKH7pwRCKH7; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 4:29 PM, David Conrad wrote: > Why? Because we simply cannot arrogate it upon ourselves to introduce such a dependency. People want and/or need the ability to run IP networks in environments in which no DNS is present (or perhaps some other naming system is in use), and we simply cannot take that choice away from them (or force them to use DNS in lieu of whatever else they're using). And in terms of the public Internet, we simply cannot arbitrarily impose such a burden on the DNS infrastructure, which in many cases is both brittle and underprovisioned. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 20:08:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ubd-0000pj-Ep; Tue, 02 Jan 2007 20:07:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ubc-0000pe-87 for ram@iab.org; Tue, 02 Jan 2007 20:07:48 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1uba-0000fF-Mf for ram@iab.org; Tue, 02 Jan 2007 20:07:48 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l030xj0f094093; Tue, 2 Jan 2007 16:59:45 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 02 Jan 2007 17:07:32 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 02 Jan 2007 17:07:32 -0800 In-Reply-To: <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> From: David Conrad Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 17:07:31 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Roland, On Jan 2, 2007, at 4:38 PM, Roland Dobbins wrote: >> Why? > Because we simply cannot arrogate it upon ourselves to introduce > such a dependency. The dependency already exists. If you don't believe me and you are a service provider, turn off your caching servers and block port 53 and see what happens. > People want and/or need the ability to run IP networks in > environments in which no DNS is present (or perhaps some other > naming system is in use), and we simply cannot take that choice > away from them (or force them to use DNS in lieu of whatever else > they're using). Can you name one that isn't within a closed network? > And in terms of the public Internet, we simply cannot arbitrarily > impose such a burden on the DNS infrastructure, which in many cases > is both brittle and underprovisioned. I personally believe the most likely solution that addresses the largest number of requirements with the lowest cost will require some sort of mapping between an end point identifier and a routing locator. There are a variety of ways to do this mapping, while the DNS is not ideal, it does have the advantage that it works (after a fashion). I think it would be a mistake to take a large number of possible solutions off the table simply because we don't want to impose a dependency that is, in reality, already existent and satisfied. The fact that some branches of the DNS are brittle and underprovisioned is not really a good argument: this problem would like remedy itself when people became aware of the need to have a non- brittle and well provisioned DNS so they could download their porn. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 20:26:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1usu-00033A-8H; Tue, 02 Jan 2007 20:25:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ust-0002zu-Ez for ram@iab.org; Tue, 02 Jan 2007 20:25:39 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1uss-0006xe-6O for ram@iab.org; Tue, 02 Jan 2007 20:25:39 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Jan 2007 20:25:38 -0500 X-IronPort-AV: i="4.12,228,1165208400"; d="scan'208"; a="110746042:sNHT48330184" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l031Pcmn011543 for ; Tue, 2 Jan 2007 20:25:38 -0500 Received: from [192.168.1.101] (rtp-vpn1-153.cisco.com [10.82.224.153]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l031PbG9021467 for ; Tue, 2 Jan 2007 20:25:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 17:25:35 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3119; t=1167787538; x=1168651538; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=dihORqJYce3QhooGb7DNGcrSFsUt2qrclT4ZXLo3cUg=; b=wiTEZqMRlCS6neu21hZWlUXaW+D2SSdhCWe0XmnRsyPrPG5RJMqf+BvVPqZNGbs+DHx9nZmq x+8KAKfstgZP1uKnnuNqn6wR+ZtPp1r16zzKd0E96U/zKCqOYivGttxR; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 5:07 PM, David Conrad wrote: > The dependency already exists. If you don't believe me and you are > a service provider, turn off your caching servers and block port 53 > and see what happens. There are a number of things which don't have this dependency, especially not on a 'per-transaction' basis. > Can you name one that isn't within a closed network? What does that matter? The multihoming solution we come up with ought to work just as well on closed networks (or networks using alternate naming systems) as on the global Internet. I don't think it's in anyone's best interests to tie IP networking to any particular naming system, for all the reasons already listed, for reasons of futureproofing, etc. I believe it is in fact a Very Bad Idea. > I personally believe the most likely solution that addresses the > largest number of requirements with the lowest cost will require > some sort of mapping between an end point identifier and a routing > locator. There are a variety of ways to do this mapping, while the > DNS is not ideal, it does have the advantage that it works (after a > fashion). Ah, but it doesn't work as quickly and reliably and dependably and universally as is needed for a system of the type you describe to count on it. What we do here must be entirely self-contained, IMHO. > I think it would be a mistake to take a large number of possible > solutions off the table simply because we don't want to impose a > dependency that is, in reality, already existent and satisfied. I think taking impractical and unworkable solutions off the table is a great idea, because it means we don't waste any further time on them. Making DNS a dependency in this instance is a layering violation of the first water (remember, the current paradigm for IP networking is a very loosely-coupled system), it is a classic exercise in cost-shifting, and it is just plain lazy, IMHO. [ This is a matter of personal technical philosophy, but besides the architectural and operational reasons why this is a Very Bad Idea, it really seems wrong to try and foist our problems off on the naming- system people. This is our mess; we ought to clean it up ourselves, IMHO. ] > > The fact that some branches of the DNS are brittle and > underprovisioned is not really a good argument: this problem would > like remedy itself when people became aware of the need to have a > non-brittle and well provisioned DNS so they could download their > porn. While I agree with your sentiment, I believe the outcome of introducing such a dependency would be rather different - I believe that when it started non-deterministically breaking because of DNS issues, deployment would halt and we would all be strung up from the nearest lampposts (and justifiably so, heh). ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:06:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWQ-0003qD-Qr; Tue, 02 Jan 2007 21:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWP-0003q8-7M for ram@iab.org; Tue, 02 Jan 2007 21:06:29 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vWN-0006ES-Sq for ram@iab.org; Tue, 02 Jan 2007 21:06:29 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 501811222D1; Wed, 3 Jan 2007 03:06:27 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp01.uc3m.es (Postfix) with ESMTP id E81BA1222E0; Wed, 3 Jan 2007 03:06:24 +0100 (CET) In-Reply-To: <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 02:49:24 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 18:01, Roland Dobbins escribi=F3: > > On Jan 2, 2007, at 8:51 AM, marcelo bagnulo braun wrote: > >> So, i can certainly see that the network admin staff of a company can=20= >> deal with more "complex" configuration than normal home users and=20 >> they are likely to have more requirements and they are likely to want=20= >> to be in control of what is going on in the network. > > The enterprise folks who're the most skilled at enterprise networking=20= > are mainly in the financial services sector along some tech companies=20= > and military, IMHO; again, they have skilled folks, but not many of=20 > them, and they're looking for ways to avoid complexity if at all=20 > possible. > agree but they are willing to deal with the complexity if that is what=20= it takes to tune their network wto make perform as they want (clear=20 example of this is BGP TE setups) agree? Regards, marcelo > So, we come back to the question - besides scale and internal=20 > complexity, what's the difference? Is there some set of objective=20 > criteria we can come up with on which to predicate a split? > > = ----------------------------------------------------------------------- > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:06:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWN-0003pU-Ay; Tue, 02 Jan 2007 21:06:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWL-0003pK-QP for ram@iab.org; Tue, 02 Jan 2007 21:06:25 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vWK-0006EJ-FY for ram@iab.org; Tue, 02 Jan 2007 21:06:25 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CEDBF1222D1; Wed, 3 Jan 2007 03:06:23 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp01.uc3m.es (Postfix) with ESMTP id 9B6571222A6; Wed, 3 Jan 2007 03:06:21 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] GSE security Date: Wed, 3 Jan 2007 03:06:05 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 23:35, RJ Atkinson escribi=F3: > % Well, GSE is certainly missing the security paraphernalia. > % I think that we all pretty much agree on that. > > I'd rephrase the first sentence as: > The existing published GSE Internet-Drafts did not go into > detail about how information might be authenticated. > > And then I'd note that not having written the security paraphernalia > down is wildly different from "it is impossible to secure". > fully agree but do we also agree that when security is included in GSE, the result=20= is not nearly as nice as the current GSe proposal? I mean, what i really find attractive of the current GSE proposal is=20 that the routers that perform the rewriting are almost stateless. They=20= only need to know the globally routable prefix they need to rewrite the=20= source address with and that's it. I don't think this is possible when you include the security. In this=20 case, you would need some state associated to the particular identifier=20= and its associated locator set as well as the security information to=20 bind them But again i am assuming a certain threat model and from previous emails=20= with you, i am not sure we are making the same assumption here, so=20 maybe we should first start to discuss what threats do we want to=20 protect any solution from... Regards, marcelo > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:06:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vW8-0003mF-0n; Tue, 02 Jan 2007 21:06:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vW7-0003iq-4C for ram@iab.org; Tue, 02 Jan 2007 21:06:11 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vW5-0006Dl-H6 for ram@iab.org; Tue, 02 Jan 2007 21:06:11 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 773EB1222A6; Wed, 3 Jan 2007 03:06:08 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp01.uc3m.es (Postfix) with ESMTP id C47C2122258; Wed, 3 Jan 2007 03:06:04 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8d33bfdf734af3d838f5e98c851d23c0@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 02:55:04 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 23:09, RJ Atkinson escribi=F3: > > People seem to view the alternatives as either: > origin host selects which destination Locator to put in packet > XOR > some router selects which destination Locator to put in packet > > I respectfully submit that this is a false choice and that > this misconception is hindering the discussions here. > > Another, IMHO preferable, approach is to have the origin host > put both source Locator and destination Locator into the packet, > but do not make it illegal/impossible for some router along the > path to re-write/modify either Locator iff that router really has > enough knowledge to do so in some thoughtful way. Not all routers > in the world might have enough knowledge to do so. Not all routers > in the world might choose to do so. By having the origin host put > in a valid destination Locator, but avoiding precluding routers along > the path from applying better information, we can have the best of > both worlds, IMHO. > just a subtle point here.... from the way you put it, it seems to me that you would require that all=20= the hosts must support whatever new thing/protocol that is necesary to=20= allow this rewriting I would argue that this would make deployment more difficult I would then suggest that both the host or the host can do the locator=20= selection and all the rest of the functions required to support this=20 (allowing both routers and hosts to support the needed functions) and=20 also that a host that is selecting the locators can communicate with a=20= peer that is being served by a router that performs the locator=20 selection and associated required features. Hope this is minimally clear... Regards, marcelo > To some extent, any NAT-compatible approach will at least > not preclude routers on the path from updating the destination = Locator. > > Yours, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:06:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWV-0003sF-3W; Tue, 02 Jan 2007 21:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWT-0003rn-R2 for ram@iab.org; Tue, 02 Jan 2007 21:06:33 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vWS-0006Ec-As for ram@iab.org; Tue, 02 Jan 2007 21:06:33 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B11FD1222A6; Wed, 3 Jan 2007 03:06:31 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp01.uc3m.es (Postfix) with ESMTP id 4F5A2122227; Wed, 3 Jan 2007 03:06:27 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5da9e3472ce652e2e532f6a58fa541fe@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 02:47:19 +0100 To: Ted Seely X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 20:06, Ted Seely escribi=F3: > > Marcelo, > > On Tue, 2 Jan 2007, marcelo bagnulo braun wrote: > >> >> El 31/12/2006, a las 23:35, Roland Dobbins escribi=F3: >> >>> >>> On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote: >>> >>>> big sites have professional network admins that can configure=20 >>>> complex >>>> protocols (e.g. bgp) Moreover, because of that they are likely to >>>> want some centralized way to enforce the configurations. >>> >>> One would think that larger enterprises would have these sorts of >>> folks available, but it isn't always true (not even predominantly >>> true, IMHO), and even when people with those skillsets are on staff, >>> there are generally only a few of them and this sort of thing may = not >>> be their only responsibility, either. >>> >>> Larger enterprises typically do have configuration-management = systems >>> of one sort or another, but (again, like most SPs), they're often >>> fairly basic systems in that they allow for automatic provisioning=20= >>> and >>> config versioning, but there's not a lot of logic present which >>> automates the development of the config itself, in most cases (this=20= >>> is >>> one of the main motivating factors behind the development of=20 >>> NETCONF). >>> One partial exception to this observation is in the generation of >>> ACLs, but the automation for most ACL-generation systems in use = today >>> is limited and somewhat brittle, at best, and often does not take=20 >>> into >>> differences in platform capabilities/performance/resources. >>> >>> [ Come to think of it, this all sounds remarkably similar to a lot = of >>> SPs, doesn't it? ;> ] >>> >>>> A home network does not have a network admin (ir the network admin >>>> is the user) and it is likely he is not able to do complex >>>> configurations. >>> >>> Most large enterprises don't handle complex configurations well, >>> either - see above. They often end up building unnecessarily = complex >>> networks for various reasons, but that's not the same thing, heh. >>> >> >> ok, i think we may have different definitions of complex here... >> >> I have worked in network administration of two networks: >> - the postal service network , with several hundreds of network >> geographcially distributed. they do have a net amdin staff and while = i >> agree they don't like complex setups, they are able of doing what i >> call quite complex stuff, as oposed to the other network that i = reffer >> next... > > undeniably a very valid example of a large organization that is able = to > support a large and complex network. However, there is a distinct > difference in what commercial organizations can and want to support=20 > versus > government organizations. one gets paid for regardless (called taxes=20= > and > being able to print your own money :), the other has to stay in=20 > business > and fund its own. having done both in a previous life, it is a day = and > night difference between the commercial sector and the government=20 > sector. > we have to keep in mind that the small to mid size company, which make=20= > up > the large majority of companies, do not have a lot of in house=20 > expertise, > nor are their networks a focus of their business. sorry to continue = to > beat that horse. but someone there do configure BGP today for multihoming, right? BGP multihoming would be non starter in a home network imho do you=20 agree? So my only point is that these a qualitative different... Regards, marcelo > > but... your dad sure sounds a lot like mine too. :-) > >> - my dad's home network. He doesn't even know what an IP address is,=20= >> so >> he is not able to do any configuration at all. However, he is able to >> use his netwrok and it is likely he may become multihomed in some >> future, because the CATV guys may offer it for free, or the=20 >> electricity >> company or some other commodity provider. > > and i sure hope that my dad isn't offerd a choice, because he won't=20 > know > what to do with it, nor does he care. :) > > -ted > > k > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:06:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWZ-0003uw-CR; Tue, 02 Jan 2007 21:06:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vWX-0003sl-HZ for ram@iab.org; Tue, 02 Jan 2007 21:06:37 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vWW-0006En-39 for ram@iab.org; Tue, 02 Jan 2007 21:06:37 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 833E41222A6; Wed, 3 Jan 2007 03:06:35 +0100 (CET) Received: from [163.117.203.162] (unknown [163.117.203.162]) by smtp01.uc3m.es (Postfix) with ESMTP id C9F17122227; Wed, 3 Jan 2007 03:06:32 +0100 (CET) In-Reply-To: <1EE07C1B-BE59-48B4-ABC4-094A89B64A34@cisco.com> References: <20070101214320.609B686AE4@mercury.lcs.mit.edu> <759dc0f38a77039aef34c6521043f232@it.uc3m.es> <1EE07C1B-BE59-48B4-ABC4-094A89B64A34@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <457c99813e9f4c959ec40e0703b47716@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 02:43:14 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 02/01/2007, a las 22:27, Tony Li escribi=F3: > > On Jan 2, 2007, at 8:40 AM, marcelo bagnulo braun wrote: > >> if we do that, this means that the identifier is the lower 64 bits=20 >> and we need to create the means to provide global uniqueness to the=20= >> 64 iid name space. > > > If you want a field that is semantically an 'identifier', it needs to=20= > be unique. Or at the very least statistically unique. > >> I think it would be much easier to go for 128 bits identifiers,=20 >> reserving a /8 global prefix for the identifier name space (something=20= >> like the globally managed ULAs, but maybe with some differences on=20 >> the cost structure) >> Then these would be local addresses, that the host will use to=20 >> generate packet and these are valid in the local domain. when the=20 >> packet reaches the border of the local domain, the border router=20 >> rewrites the source and/or destiantion prefix with a globally=20 >> routable prefix and routes it through the internet. > > > This would be NAT. If we're doing NAT, why not just stay with IPv4? > no, NAT would be much more simple, attractive and easier to deploy and=20= adopt This would be a double nat, one when we leave the source site and the=20 reverse operation when the packet reaches the destiantion site. The result is that from the endpoint perspective, the packet is=20 received exactly the same as it was generated from the source. So apps=20= can include address information in the payload and this will be =20 coherent with what is actually included in the IP header, Actually it=20 would be exactly like a compressed tunnel, just that actual local=20 addresses are not included in the actual packet (note that i mean local=20= addresses because they are locally routable but globally unique) So, no, it is not like nat because it lacks of the great deployment=20 incentive where the one that has to deploy stuff is the one that gets=20 the benefits. In this case both ends need to deploy stuff and only one=20= ends gets the benefits (but this is needed in order to get the e2e=20 transparency) Regards, marcelo > > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:07:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vXo-00058w-Ci; Tue, 02 Jan 2007 21:07:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vXn-00058r-11 for ram@iab.org; Tue, 02 Jan 2007 21:07:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vXl-0006VK-Qy for ram@iab.org; Tue, 02 Jan 2007 21:07:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 18:07:53 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49868713:sNHT42736324" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0327r3r019594 for ; Tue, 2 Jan 2007 21:07:53 -0500 Received: from [192.168.1.101] (rtp-vpn1-153.cisco.com [10.82.224.153]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0327r2k023374 for ; Tue, 2 Jan 2007 21:07:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 18:07:50 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=687; t=1167790073; x=1168654073; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=ke9NcnlXTEwvEZ/+soKL7/KXfaCry3Nn8J4kCughtLQ=; b=YDllWiW9GfizG/SbvgX+VABkho26QT46n+SYlTb6a0O+EDqfAjouA61D1tX7SV/wBovS64hs fZcKoQDeUJO/ev9XIszsF4CCBAXdGVa1i0DKkIR+YbHYcqRb5sAIfxuY; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 11:06 AM, Ted Seely wrote: > However, there is a distinct > difference in what commercial organizations can and want to support > versus > government organizations. one gets paid for regardless (called > taxes and > being able to print your own money :), the other has to stay in > business > and fund its own. It's also worth noting that there's a wide variation in terms of capabilities and resources within the governmental sphere, as well. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:13:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vdB-0008Le-0v; Tue, 02 Jan 2007 21:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vd9-0008L2-Jx for ram@iab.org; Tue, 02 Jan 2007 21:13:27 -0500 Received: from web58712.mail.re1.yahoo.com ([66.196.100.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1vd8-0006qv-Av for ram@iab.org; Tue, 02 Jan 2007 21:13:27 -0500 Received: (qmail 19733 invoked by uid 60001); 3 Jan 2007 02:13:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=aFNCXz6d9qvmwr5aEha80iNNYkifRVWZRuvVcczk03tcBjqUfUwnO5ji5JQsu9q7eGP0IpHEQrZ7IgG5iSLAlP92apOjx18aocuesahxyHKOJwCYzs6XAG9shys2JRFHF8iMyCjKpPPdY1XsE0X2hPN3DC7VNWaE8xQr21Hzr/g=; X-YMail-OSG: T4AZaVMVM1kSC0anqrKjb4XXuU_8hxBuVbIw3XUhoDkQZfE1M2NM.66_BtLFngyZvg-- Received: from [74.111.124.141] by web58712.mail.re1.yahoo.com via HTTP; Tue, 02 Jan 2007 18:13:18 PST Date: Tue, 2 Jan 2007 18:13:18 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] Destination Locator selection To: David Conrad , Roland Dobbins In-Reply-To: <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <848393.9676.qm@web58712.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Because DNS has a very limited use where humans are involved, while the vast majority of communicating machines need only IP numbers. Thanks, Peter --- David Conrad wrote: > > And per my reply to Max, I believe very strongly that IP networks, > > including multihomed ones, must be able to function in the absence > > of any naming system at all. > > Why? > > Thanks, > -drc > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:22:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vlr-0005uQ-9K; Tue, 02 Jan 2007 21:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vlq-0005uL-EP for ram@iab.org; Tue, 02 Jan 2007 21:22:26 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vlo-0007YD-Lg for ram@iab.org; Tue, 02 Jan 2007 21:22:26 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l032EM0f094254; Tue, 2 Jan 2007 18:14:23 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 02 Jan 2007 18:22:10 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 02 Jan 2007 18:22:10 -0800 In-Reply-To: <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 18:22:08 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Roland, On Jan 2, 2007, at 5:25 PM, Roland Dobbins wrote: >> I personally believe the most likely solution that addresses the >> largest number of requirements with the lowest cost will require >> some sort of mapping between an end point identifier and a routing >> locator. There are a variety of ways to do this mapping, while the >> DNS is not ideal, it does have the advantage that it works (after >> a fashion). > Ah, but it doesn't work as quickly and reliably and dependably and > universally as is needed for a system of the type you describe to > count on it. Quickly, reliably, dependably: sure it can, assuming you can tolerate an increased latency with the first packet of a "unidirectional flow". As for universality, not every computer on the Internet speaks BGP, yet the Internet seems to work. One way of solving the routing scalability problem is to create a layer of indirection, having routing done in one "identity universe" and end point identification done in another "identity universe" with a mapping mechanism that allows a "border device" (where 'border" can be anything from the site edge to the host edge and anywhere in between) to take the end point identifier and do a lookup to find the one or more routing locators currently serving as the network attachment point(s) for the end point identifier. This layer of indirection gives you the ability to change "location" (that is, where the end point is attached to the network) transparently to the end point, permitting renumbering, mobility, and multi-homing. The downside, as with all added layers of indirection, is added latency -- you need to do the lookup in some mapping table. If the mapping table is propagated via some push mechanism (e.g., BGP attributes), the additional latency will be minimal albeit updates to the mapping table would need to be constrained. If the mapping table is propagated via some pull mechanism (e.g., something like the DNS), the additional latency (on the initial packet, assuming you have a reasonable caching scheme) will be significant, but table updates are less of an issue. Generalizing a bit, one could imagine layering IP headers with the lowest layer corresponding to end point identification and subsequent higher layers corresponding to traffic engineering dictated network topology location. At each network attachment 'edge' the packet traverses, a new layer could be added to determine where the packet should go, e.g. (looking at a packet in the middle of a transit AS): [src: A'', dst: B''=lookup(ISP_TE_MAP,B')] [src: A', dst: B'=lookup(GLOBAL_MAP,B)] [src: A, dst: B] [payload] where: A is the source endpoint identifier B is the destination endpoint identifier A' is the globally unique locator by which you reach A B' is the globally unique locator by which you reach B A'' is the ISP-specific locator used to direct traffic to the appropriate destination to reach A' within the ISP's network B'' is the ISP-specific locator used to direct traffic to the appropriate destination to reach B' within the ISP's network This sort of scheme gives you the ability to do arbitrary traffic engineering, have multi-homing, renumbering (in the sense of changing your location in the network topology), and mobility (if the tables can be updated fast enough and/or you have some sort of forwarding mechanism), but obviously it needs a mapping mechanism. > What we do here must be entirely self-contained, IMHO. I remain highly skeptical we'll be able to deploy IPv7 before either we start prefix length filtering off significant portions of the Internet or NAT becomes the accepted solution to the routing scalability problem. I believe an approach that leverages as much of the existing _deployed_ infrastructure with as few changes as possible is the most likely to end up actually being used. But maybe I'm too pessimistic (or cynical). Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:35:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vxu-0004kj-W1; Tue, 02 Jan 2007 21:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1vxu-0004ke-7e for ram@iab.org; Tue, 02 Jan 2007 21:34:54 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1vxs-0001RT-Q6 for ram@iab.org; Tue, 02 Jan 2007 21:34:54 -0500 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l032Qv0f094283; Tue, 2 Jan 2007 18:26:57 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 02 Jan 2007 18:34:44 -0800 X-PGP-Universal: processed; by terminus.local on Tue, 02 Jan 2007 18:34:44 -0800 In-Reply-To: <848393.9676.qm@web58712.mail.re1.yahoo.com> References: <848393.9676.qm@web58712.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <98242693-FE2B-4F24-93F6-DD7238E7A594@virtualized.org> From: David Conrad Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 18:34:43 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 6:13 PM, Peter Sherbin wrote: > Because DNS has a very limited use where humans are involved, while > the vast > majority of communicating machines need only IP numbers. The DNS provides a way of mapping one string of bytes into another string of bytes. While it is true that in the past the vast majority of these mappings were for mapping a human-intended name into an IPv4 address, I suspect the future will be a bit different (e.g., see the use of NAPTR and SRV RRs). To be clear, I'm quite well aware of the limitations and warts the DNS has as well as those in mapping-based schemes in general and would be happy to see an alternative. I'm just not too sure a reasonable alternative can be deployed in a reasonable timeframe. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:57:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wIh-0000sJ-4e; Tue, 02 Jan 2007 21:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wIe-0000s4-5C for ram@iab.org; Tue, 02 Jan 2007 21:56:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1wIb-0005oY-Qv for ram@iab.org; Tue, 02 Jan 2007 21:56:20 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2007 18:56:17 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l032uG08020544; Tue, 2 Jan 2007 18:56:16 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l032uGIl023100; Tue, 2 Jan 2007 18:56:16 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:56:15 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:56:15 -0800 In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81D1F978-B756-4CF2-B794-808202045901@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 18:56:12 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jan 2007 02:56:15.0723 (UTC) FILETIME=[BC22C3B0:01C72EE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=907; t=1167792976; x=1168656976; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=3JyNZrSmAoTggPUSLi19tKWcRQuZRsm2/OM1CHRgTOs=; b=mlCEsZBBOs7E/gh9t/BDWy+gj5UP60gR/KivylQnX4ifouE18KRRPjUfzFAcRIAPaENsiCl4 auXvu4oCz7UA373VXjIuo3tcop/TaQH8qXz8YpFeXa8D2PSn/uOrZOzx; Authentication-Results: sj-dkim-6; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> The enterprise folks who're the most skilled at enterprise >> networking are mainly in the financial services sector along some >> tech companies and military, IMHO; again, they have skilled folks, >> but not many of them, and they're looking for ways to avoid >> complexity if at all possible. > > agree but they are willing to deal with the complexity if that is > what it takes to tune their network wto make perform as they want > (clear example of this is BGP TE setups) agree? Largely, no. It's an enormous burden on them. Keeping a firewall up and running is about the peak of enterprise expertise today. I think you're greatly overestimating what the average enterprise can and will be able to support. Note that BGP TE is done mostly by ISPs today, not end user sites. There are, of course, exceptions, but they are very much in the noise. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 21:59:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wLt-0003oC-06; Tue, 02 Jan 2007 21:59:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wLs-0003o7-2w for ram@iab.org; Tue, 02 Jan 2007 21:59:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1wLq-0006FR-Op for ram@iab.org; Tue, 02 Jan 2007 21:59:40 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Jan 2007 18:59:38 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l032xcZp019587; Tue, 2 Jan 2007 18:59:38 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l032xblb018380; Tue, 2 Jan 2007 18:59:37 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:59:37 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 18:59:37 -0800 In-Reply-To: <5da9e3472ce652e2e532f6a58fa541fe@it.uc3m.es> References: <5da9e3472ce652e2e532f6a58fa541fe@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Tue, 2 Jan 2007 18:59:34 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jan 2007 02:59:37.0038 (UTC) FILETIME=[3420FEE0:01C72EE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1381; t=1167793178; x=1168657178; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=ScH6H2UyHL0NfpBB3BhvQlMCXOhRH/g76QdCCtWUL68=; b=IPJCkGehtAZ4RU3ci0CjEV8Yciv/UeKkByMvOthd+kcwpDYBftXOt+k6fmLSwYg9/TU2QWcC epKe2YUMH5V74pAYpwKHPsxCbVw5j3kODMStN2gokF2qcbSft+vL0658; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> undeniably a very valid example of a large organization that is >> able to >> support a large and complex network. However, there is a distinct >> difference in what commercial organizations can and want to >> support versus >> government organizations. one gets paid for regardless (called >> taxes and >> being able to print your own money :), the other has to stay in >> business >> and fund its own. having done both in a previous life, it is a >> day and >> night difference between the commercial sector and the government >> sector. >> we have to keep in mind that the small to mid size company, which >> make up >> the large majority of companies, do not have a lot of in house >> expertise, >> nor are their networks a focus of their business. sorry to >> continue to >> beat that horse. > > but someone there do configure BGP today for multihoming, right? > > BGP multihoming would be non starter in a home network imho do you > agree? > > So my only point is that these a qualitative different... Today, yes. However, if we do the locator/identifier split properly, multihoming should be possible without any BGP configuration, for SOHO or a medium-to-large enterprise. Again, I'm not finding ANY qualitative difference beyond what I suggested before: a) 1 ASBR b) more than one ASBR Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 22:05:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wRG-0006f1-5S; Tue, 02 Jan 2007 22:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wRD-0006ew-Jv for ram@iab.org; Tue, 02 Jan 2007 22:05:11 -0500 Received: from web58713.mail.re1.yahoo.com ([66.196.100.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1wRD-00073S-4k for ram@iab.org; Tue, 02 Jan 2007 22:05:11 -0500 Received: (qmail 77221 invoked by uid 60001); 3 Jan 2007 03:05:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=5D2s1F3WsEq3T9FElK+xueAaYM5KUGoNG6Fd3JD7G/wkqUkOHkJFP+DVr5Fc4kdSWwzppOgrANHs8JibIVYLybxL9Fh4JY17c+RTW/l9bA1jovTO3jn9xQTwtZpzqPOHQfspHVchLlZPr9rl5jeVlZ7aweU0kp937gMRWMk3ffU=; X-YMail-OSG: Qab_nDAVM1krw25BQz7Pe.dlCan_Z5xLJt_2z0Oq Received: from [74.111.124.141] by web58713.mail.re1.yahoo.com via HTTP; Tue, 02 Jan 2007 19:05:10 PST Date: Tue, 2 Jan 2007 19:05:10 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] An attempt to summarise the "Traffic Engineering" discussion so far To: Pekka Nikander , ram@iab.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <944766.77052.qm@web58713.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org This is a very good summary. For the new architecture please consider the following: 1. Internet shall scale on a hard-surfaced body of any size (physics permitting) and in space 2. The urgent task in space is to network/monitor neighboring asteroids 3. Other tasks require networks on Moon and Mars (with no ISPs or easy cabling) 4. Even with 2/3 under water Earth still is a fair testing ground for the Internet Thanks, Peter --- Pekka Nikander wrote: > Having read through the various sub-threads in the "TE" discussion, > and re-read about 15 messages that seemed to have the most informed > content to me, I'm foolishly trying to summarise what I see, with an > architectural twinkle in my eye. I hope this helps the community. > However, before going to that, I really recommend people to re-read > Elwyn's recent and very good analysis on how TE and multi-homing can > be viewed as a single phenomenon: > > http://www1.ietf.org/mail-archive/web/ram/current/msg00102.html > > At the same time I would recommend people to remember that Elwyn's > analysis is only one way of looking at the problem domain; it can > also be divided in a few other ways. > > > A brief and (hopefully) balanced summary: > > One main theme was mostly concerned about the costs (hardware/ > software/administration), with a few folks arguing that because of > this any solution that mandates (as a non-optional feature) multiple > globally routable IP addresses to each multi-homed host is a non- > starter. This argument was countered by splitting the identifier and > locator roles of addresses and arguing that the costs will not be > that big since the hosts will still have just one identifier. > > A second overall theme cornered around who (which node) should have > the control over path selection. Obviously, the operators and folks > with experience on TE and complex site multi-homing abhor each host > being empowered to do the decision. Almost as obviously, people > working with mobile hosts with multiple radio interfaces consider it > natural that hosts make the choice between the interfaces. > Architecturally, there seems to be different kinds of path selection: > one kind that Elwyn excellently described in his note, and another > kind that is more related to mobility and hosts or sub-networks that > are both mobile and multi-homed. > > A third theme considered whether there should be only one multi- > homing solution, or perhaps many of them. Towards the end of this > theme, it was suggested that perhaps there could be an architectural > solution that could be implemented in a way that would fit both large > and small multi-homed sites. > > > A more detailed and slightly opinionated summary: > > The discussion was started by RJA's request to the operators to > enumerate the ways TE is being used: > http://www1.ietf.org/mail-archive/web/ram/current/msg00123.html > > From there on, the discussion seemed to converge to pretty > opinionated message exchange around the following topics: > > > 1. Embedding of today's IP addresses in ACLs, firewall rules, ASICs > that implement them, etc. > > The crux of this argument seems to be that adding multiple globally > routable IP addresses to each host at large multi-homed sites > multiplies the related hardware and software costs. The counter > argument is that with a properly implemented identifier / locator > split, it is the identifiers that are stored in ACLs, firewall rules, > etc, not the locators. Consequently, there is no additional hardware/ > software cost here. > > The main caveat here is "properly implemented". Firstly, that may > require adding (soft) state at the filtering devices, if the packets > only carry the locator or if the identifiers are encrypted. > Secondly, depending on the solution, the administrative costs of > upgrading the information from current addresses to future > identifiers may become a major upgrade barrier. > > I think Noel summarised this thread nicely here: > http://www1.ietf.org/mail-archive/web/ram/current/msg00169.html > > Marcelo added nicely some details about the implementation and state: > http://www1.ietf.org/mail-archive/web/ram/current/msg00178.html > http://www1.ietf.org/mail-archive/web/ram/current/msg00193.html > > Finally, Roland added some (IMHO) very important thoughts about IDs > and privacy: > http://www1.ietf.org/mail-archive/web/ram/current/msg00211.html > > > 2. Troubleshooting, help desk, and other similar problems related to > multiple IP addresses. > > Even if there was an id/loc split in place that relieved the above > burden from filtering and other configuration, having multiple > locators per each host may still cause additional cost in > troubleshooting, help desk, etc. The counter argument is that with > proper tools (which of course don't exist yet) the costs may be > pushed back to their current levels. Additionally, depending on the > types of the identifiers, the IDs may be engineered to further help > troubleshooting. > > http://www1.ietf.org/mail-archive/web/ram/current/msg00160.html > > > 3. Problems with botnets > > I think Marshall Eubanks noticed this potential problem first, but > opinions differ whether this is really a problem or not. Basically, > the claim is that if hosts have multiple globally routable IP > addresses, botnet operators would benefit since they would have more > control on how to route the traffic when leaving the individual > bots. The counter arguments include that many hosts will anyway > include multiple addresses since they will have multiple interfaces > and that simple source address selection does not equal with full > path selection. > > http://www1.ietf.org/mail-archive/web/ram/current/msg00154.html > http://www1.ietf.org/mail-archive/web/ram/current/msg00164.html > > > 4. Who is trusted or empowered to do path selection > > A central issue in the discussion seems to be whether path selection > should be done in hosts or in routers. Some people argue, apparently > validly, that there are installations where it is practically > impossible (given today's technology) to do it in the host, and would > be a waste of resources anyway. Igor's message outlined it pretty > nicely: > > http://www1.ietf.org/mail-archive/web/ram/current/msg00145.html > > Later on, Roland made some important points: > > http://www1.ietf.org/mail-archive/web/ram/current/msg00195.html > > To me, there seems to be an underlying issue which perhaps didn't > come out properly in the discussion so far. Namely, there is only a > relatively little amount of dependency between where the path > selection is done *logically* in the host or not, and whether is is > done *physically* in the host or not. Even in the case that hosts > were logically empowered to do some part of the path selection by > making them logically visible through several distinct globally > routable IP addresses, that functionality can be delegated to the > network. The solution smells and looks a little bit like NAT, but so > what any solution that rewrites the address fields in the IP header. > Personally, I tried to make this distinction clear in my other > message (which is not in the Web archive at this writing.) > > A perhaps even more fundamental problem is related to trust: who is > trusted to make the path selection. This was not taken up directly, > but the botnet thread was clearly related. > > W.r.t to SHIM6 in this respect, David Conrad explained the history > succinctly: > > http://www1.ietf.org/mail-archive/web/ram/current/msg00177.html > > As a response to that, the details of how to make SHIM6 into a proper > site-multi-homing technology, where the locator selection is done as > a site-wide function and not in individual hosts, hasn't really been > worked out. But IMHO they could. > > > 5. Do we need multiple or just one solution > > A larger part of the discussion seemed to circle around whether we > could live with just one solution for multi-homing, or whether there > should be separate solutions for "large sites" and small, SO-HO type > sites. Obviously, some effort was spent (in vain) to define where > the border line would be. In the end, Noel suggested that perhaps > there could be an architectural solution that would fit into the two > different sets of requirements through differently engineered > implementations: > > http://www1.ietf.org/mail-archive/web/ram/current/msg00234.html > > > -------- > > I'm sure I missed some threads; sorry for that. > > --Pekka Nikander > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 22:13:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wZA-00033F-6W; Tue, 02 Jan 2007 22:13:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wZ8-00033A-Ty for ram@iab.org; Tue, 02 Jan 2007 22:13:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1wZ7-00007G-N8 for ram@iab.org; Tue, 02 Jan 2007 22:13:22 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 19:13:21 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49870832:sNHT44253408" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l033DLVd032240 for ; Tue, 2 Jan 2007 22:13:21 -0500 Received: from [192.168.1.101] (rtp-vpn1-153.cisco.com [10.82.224.153]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l033DL2k003512 for ; Tue, 2 Jan 2007 22:13:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <98242693-FE2B-4F24-93F6-DD7238E7A594@virtualized.org> References: <848393.9676.qm@web58712.mail.re1.yahoo.com> <98242693-FE2B-4F24-93F6-DD7238E7A594@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 19:13:19 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1230; t=1167794001; x=1168658001; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=dZG1NOt4e35IUOQ8Rf/NEHpbRJVeAK66lQS5G1zqBYM=; b=vJEyfBIPsJ4YIqzMmOr38B2ykQkk4eU4iTl1dOQnfk6TCpQUbIGhttFtRCWSiwsAM9Zj5sAx E+S1HZ+0BWHk9srq5F44PvIzHXtbUWd3rx/bKhWJbU2ELDHK1w6DVsMC; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 6:34 PM, David Conrad wrote: > To be clear, I'm quite well aware of the limitations and warts the > DNS has as well as those in mapping-based schemes in general and > would be happy to see an alternative. I'm just not too sure a > reasonable alternative can be deployed in a reasonable timeframe. The DNS is eminently unsuitable for what you're proposing, because it wasn't designed with this sort of requirement in mind, hasn't been deployed with this kind of requirement in mind, and cannot be expected to fulfill this kind of requirement without such wide- reaching and fundamental changes that it would no longer be DNS, but Something Else. Now, there's an argument which can be made that we need Something Else; I think that's perhaps a worthwhile discussion to have. Something decentralized, along the lines of PNRP or somesuch. The question is, do we want to strap that on as part of this effort, or is that too far out-of-scope to even seriously discuss? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 22:37:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wwi-0000nc-IT; Tue, 02 Jan 2007 22:37:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1wwh-0000nX-9k for ram@iab.org; Tue, 02 Jan 2007 22:37:43 -0500 Received: from web58706.mail.re1.yahoo.com ([66.196.100.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1wwg-0004Ii-1h for ram@iab.org; Tue, 02 Jan 2007 22:37:43 -0500 Received: (qmail 36215 invoked by uid 60001); 3 Jan 2007 03:37:41 -0000 Message-ID: <20070103033741.36213.qmail@web58706.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=CUQT8uJeMubjgaE+ndGRYyJYxre23nYupAFTvP4VmtcHZ38vdeJ7lEDs6DvvRo9MZ/zUPVtG3gIXNER7+S58iSLQ5TMk4Hy7WJoqLYIJ0M47TyWMxialNFh9J4aRo6jeeuOHbv0jsYm8cMKOGTgi6MiuX/5nLt1EUQEDy1jHqno=; X-YMail-OSG: UoYHvBgVM1niyNNmfj6PcfCSbBqBkuHW1EWnG7SSXCX36n1Ji9DrjApGNTc8gK4HX05EAqcFmL1JtMiI_871MnXohptCgL9QPqSFr9X_3kVJ_sYjVCiAGLqWWHhpQhYiKbKPJry_JvNskaVTUAQXiT_QDXmeAJecnD8_SuLbIDZRZGc8aJYVGW0_F.I- Received: from [74.111.124.141] by web58706.mail.re1.yahoo.com via HTTP; Tue, 02 Jan 2007 19:37:41 PST Date: Tue, 2 Jan 2007 19:37:41 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] Destination Locator selection To: David Conrad In-Reply-To: <98242693-FE2B-4F24-93F6-DD7238E7A594@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > To be clear, I'm quite well aware of the limitations and warts the > DNS has as well as those in mapping-based schemes in general and > would be happy to see an alternative. IMO there are very few instances (about two) where human use of words as pointers on the Internet is appropriate: 1. in e-mail address (for now) 2. in search engines (the route-cause driver behind the net) E.g. a user does not even need URL. Search engine points to a site, which I can select and store under a name I assign to it in the browser Favorites. All human requirements can and should be resolved at application layer with no need to rely on human language pointers for any routing task. I.e. DNS is not a concern of the Internet architecture. Thanks, Peter --- David Conrad wrote: > On Jan 2, 2007, at 6:13 PM, Peter Sherbin wrote: > > Because DNS has a very limited use where humans are involved, while > > the vast > > majority of communicating machines need only IP numbers. > > The DNS provides a way of mapping one string of bytes into another > string of bytes. > > While it is true that in the past the vast majority of these mappings > were for mapping a human-intended name into an IPv4 address, I > suspect the future will be a bit different (e.g., see the use of > NAPTR and SRV RRs). > > To be clear, I'm quite well aware of the limitations and warts the > DNS has as well as those in mapping-based schemes in general and > would be happy to see an alternative. I'm just not too sure a > reasonable alternative can be deployed in a reasonable timeframe. > > Rgds, > -drc > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:13:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xUz-0006Mo-JA; Tue, 02 Jan 2007 23:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xUx-0006J6-KU for ram@iab.org; Tue, 02 Jan 2007 23:13:07 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xUs-0002HC-CY for ram@iab.org; Tue, 02 Jan 2007 23:13:07 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A537E3411C; Tue, 2 Jan 2007 23:12:57 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 23:12:57 -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: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 23:12:56 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD62E@tayexc14.americas.cpqcorp.net> In-Reply-To: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Destination Locator selection Thread-Index: Accuu9o+T7M0a9GOTyK4UTGBQiNSrwAMW8kQ From: "Bound, Jim" To: "Tony Li" , "RJ Atkinson" X-OriginalArrivalTime: 03 Jan 2007 04:12:57.0443 (UTC) FILETIME=[72F98330:01C72EED] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: Tony Li [mailto:tli@cisco.com]=20 > Sent: Tuesday, January 02, 2007 5:17 PM > To: RJ Atkinson > Cc: ram@iab.org > Subject: Re: [RAM] Destination Locator selection >=20 >=20 > > Another, IMHO preferable, approach is to have the=20 > origin host put=20 > > both source Locator and destination Locator into the packet, but do=20 > > not make it illegal/impossible for some router along the path to=20 > > re-write/modify either Locator iff that router really has enough=20 > > knowledge to do so in some thoughtful way. Not all routers in the=20 > > world might have enough knowledge to do so. Not all routers in the=20 > > world might choose to do so. By having the origin host put=20 > in a valid=20 > > destination Locator, but avoiding precluding routers along the path=20 > > from applying better information, we can have the best of=20 > both worlds,=20 > > IMHO. >=20 >=20 > Works for me. Me to with the caveat that if the dst locator is part of any security index might not be able to rewrite that but that I think is covered under "the router" has enough knowledge for current architecture state. /jim >=20 > Tony >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:15:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xWx-00009w-TU; Tue, 02 Jan 2007 23:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xWw-00009n-JB for ram@iab.org; Tue, 02 Jan 2007 23:15:10 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xWr-0002nQ-Ah for ram@iab.org; Tue, 02 Jan 2007 23:15:10 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 17C8634109; Tue, 2 Jan 2007 23:15:05 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 23:15:04 -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: [RAM] End-user multihoming idea Date: Tue, 2 Jan 2007 23:15:03 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD62F@tayexc14.americas.cpqcorp.net> In-Reply-To: <459AEA23.1020807@netassist.kiev.ua> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] End-user multihoming idea Thread-Index: AccuxY0swAZhamIKS0ety6vQ3jT0CAAKAbzw From: "Bound, Jim" To: "Max Tulyev" , X-OriginalArrivalTime: 03 Jan 2007 04:15:04.0847 (UTC) FILETIME=[BEE9D1F0:01C72EED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Folks, I think this is getting to detailed for now. But if we go here I will argue do not use DNS. But I won't do that now but just pointing it out for the future how to engineering the solution architecture. /jim=20 > -----Original Message----- > From: Max Tulyev [mailto:maxtul@netassist.kiev.ua]=20 > Sent: Tuesday, January 02, 2007 6:26 PM > To: ram@iab.org > Subject: [RAM] End-user multihoming idea >=20 > Hi All, >=20 > I think it is a good idea to use DNS names as a kind of=20 > "route identifiers" for end-users. The only you need is two=20 > (or more) connections to different ISPs and specially crafted=20 > DNS server that generates non-cacheable (TTL=3D1) replies using=20 > extra data (i.e. source address of querier, channels load=20 > statistics, is the particular channel in use or broken now, etc). >=20 > It will be good enough for stable access to the site and=20 > services (www.foo.com, mail.foo.com, ...) with back-ups and=20 > load ballancing - the only thing most people expect from multihoming. >=20 > Yes, it doesn't help for hardcoded IP services, and=20 > established connections will be lost (but probably restores=20 > with new IP) when one of channels went down, but most of=20 > users will experience no problems at all. >=20 > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:17:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xZ7-00029u-S3; Tue, 02 Jan 2007 23:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xZ5-00026m-Kj for ram@iab.org; Tue, 02 Jan 2007 23:17:23 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xZ0-0003Jv-2M for ram@iab.org; Tue, 02 Jan 2007 23:17:23 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id C61343410B; Tue, 2 Jan 2007 23:17:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 23:17:17 -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: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 23:17:16 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD631@tayexc14.americas.cpqcorp.net> In-Reply-To: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Destination Locator selection Thread-Index: Accuyrg9xyugR8/iTxezGBySofy6yQAIxppw From: "Bound, Jim" To: "Roland Dobbins" , X-OriginalArrivalTime: 03 Jan 2007 04:17:17.0454 (UTC) FILETIME=[0DF40AE0:01C72EEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > Sent: Tuesday, January 02, 2007 6:51 PM > To: ram@iab.org > Subject: Re: [RAM] Destination Locator selection >=20 >=20 > On Jan 2, 2007, at 3:46 PM, Roland Dobbins wrote: >=20 > > I also don't think we can seriously consider imposing such an=20 > > additional query-burden on the global DNS infrastructure without=20 > > serious consideration of and discussion of the consequences thereof. >=20 > And per my reply to Max, I believe very strongly that IP=20 > networks, including multihomed ones, must be able to function=20 > in the absence of any naming system at all. Putting the architecture discussion hat on only I would not entirely agree given how we have been using the term 'namespace', but I do see the concern and point. To find compromise I would suggest we do need to be concerned about the principle of "discovery" within the new architecture model.=20 Best, /jim >=20 > -------------------------------------------------------------- > --------- > Roland Dobbins // 408.527.6376 voice >=20 > All battles are perpetual. >=20 > -- Milton Friedman >=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:21:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xcc-0004Ec-LE; Tue, 02 Jan 2007 23:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xca-0004EA-VX for ram@iab.org; Tue, 02 Jan 2007 23:21:00 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xcZ-0004nJ-P9 for ram@iab.org; Tue, 02 Jan 2007 23:21:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Jan 2007 20:21:00 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="49872901:sNHT42327660" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l034KxHI011944 for ; Tue, 2 Jan 2007 23:20:59 -0500 Received: from [192.168.1.101] (rtp-vpn1-153.cisco.com [10.82.224.153]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l034Kx7f020468 for ; Tue, 2 Jan 2007 23:20:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FD631@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC011FD631@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D4F8E9A-973B-4AC5-A608-B2985A51A7DF@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Tue, 2 Jan 2007 20:20:56 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=727; t=1167798059; x=1168662059; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=Qln4OUb9CmVAu0ZTn35CySrSqj/PdAm2+/xuAqIfQUs=; b=Isq5XOWIFPXaqKQlvnIIT5jtUQfDntm/IuNT4Os8my+no3oEtiKUJrdQfQOD+n7ZLVNmhLvS l8D8iC7fMawSgQJOcU3Y02CK4oqwq7VoSAyUjqxh+fuMlOajMi85XgvP; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: > Putting the architecture discussion hat on only I would not entirely > agree given how we have been using the term 'namespace', but I do see > the concern and point. To find compromise I would suggest we do > need to > be concerned about the principle of "discovery" within the new > architecture model. Thanks for the clarification; in this particular case it was a semantic issue, but one to which attention must be paid, lest (further) confusion ensue. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:43:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xxs-0001fS-O1; Tue, 02 Jan 2007 23:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1xxr-0001fK-I3 for ram@iab.org; Tue, 02 Jan 2007 23:42:59 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1xxm-0000TR-8S for ram@iab.org; Tue, 02 Jan 2007 23:42:59 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 049CB34116; Tue, 2 Jan 2007 23:42:53 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 23:42:53 -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 Date: Tue, 2 Jan 2007 23:42:53 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD63A@tayexc14.americas.cpqcorp.net> In-Reply-To: <3D4F8E9A-973B-4AC5-A608-B2985A51A7DF@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Discovery Thread-Index: Accu7pzi+jWzXR4FRyCPa9w6qMxGXwAAEdxA From: "Bound, Jim" To: "Roland Dobbins" , X-OriginalArrivalTime: 03 Jan 2007 04:42:53.0768 (UTC) FILETIME=[A1AAF480:01C72EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [RAM] Discovery X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Just for thinking there is a set of principles used by U.S. DOD and NATO and others called net centricity. My reference to this work is the computer science term and not applied with terms like net centric warfare or net centric ops, but rather a set of pre-conditions to achieve net centricity from models to implementations. But it is beginning to permeate out of the classic military environment and the core principles I extrapolate and test I use for any architecture and for implementation are does the networking result provide: connectivity, interoperability, security, discovery, QoS, and end-to-end (meaning two peers can communicate without middle boxes and packets could be encrypted so only the current IP header is in the clear). The point of discovery is quite important as that is how the network learns of parameters and information required. And does need some thought while developing an architecture. If any of these pre-conditions are missing above (and some add others as a note) net centricity can be negatively impacted, including discovery. What the answer is for our work here for discovery is entirely premature to discuss (e.g. DNS, LDAP, UDDI, LDAP+UDDI, SLP, SOAP, etc). Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka Best, /jim > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > Sent: Tuesday, January 02, 2007 11:21 PM > To: ram@iab.org > Subject: Re: [RAM] Destination Locator selection >=20 >=20 > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: >=20 > > Putting the architecture discussion hat on only I would not=20 > entirely=20 > > agree given how we have been using the term 'namespace',=20 > but I do see=20 > > the concern and point. To find compromise I would suggest=20 > we do need=20 > > to be concerned about the principle of "discovery" within the new=20 > > architecture model. >=20 > Thanks for the clarification; in this particular case it was=20 > a semantic issue, but one to which attention must be paid, lest > (further) confusion ensue. >=20 >=20 > -------------------------------------------------------------- > --------- > Roland Dobbins // 408.527.6376 voice >=20 > All battles are perpetual. >=20 > -- Milton Friedman >=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 02 23:50:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1y53-00069l-FH; Tue, 02 Jan 2007 23:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1y52-00069g-U9 for ram@iab.org; Tue, 02 Jan 2007 23:50:24 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1y51-0002BR-7E for ram@iab.org; Tue, 02 Jan 2007 23:50:24 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id RAA10266; Wed, 3 Jan 2007 17:50:16 +1300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 17:50:32 +1300 To: Roland Dobbins X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org While working on HIP we concluded that this all has to be explicitly signalled; putting it in the DNS is OK for seeding things, but all locators are subject to change, and the endpoint is the only place in the network that can be expected to have reasonably reliable information as to what locators work right now, let alone what are permitted within its knowledge of policy. Note that policy imposed by firewalls and the like simply shows up as the end-host noticing that certain candidate locators don't work or have reduced performance. Andrew On 03/01/2007, at 12:46 PM, Roland Dobbins wrote: > > On Jan 2, 2007, at 3:37 PM, Bruce Curtis wrote: > >> I think the most interesting case is the other side of the >> connection, the host receiving the connection request won't know >> the multiple locators of the originating host unless it does a >> reverse DNS lookup and then a forward (or something similar which >> it likely doesn't do today) or the information about the >> originating host's multiple locators is also in the packet. > > This is a very astute observation; I don't believe we can count on > DNS being available for a number of reasons (hosts without DNS > mappings, broken/incomplete PTR records, DoS attacks, whatever). I > also don't think we can seriously consider imposing such an > additional query-burden on the global DNS infrastructure without > serious consideration of and discussion of the consequences thereof. > > ---------------------------------------------------------------------- > - > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 01:11:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1zKj-0006VO-1a; Wed, 03 Jan 2007 01:10:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1zKh-0006VJ-SR for ram@iab.org; Wed, 03 Jan 2007 01:10:39 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1zKg-0003U1-Bl for ram@iab.org; Wed, 03 Jan 2007 01:10:39 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6DCEC213146; Wed, 3 Jan 2007 08:10:34 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1967521313C; Wed, 3 Jan 2007 08:10:34 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 08:10:28 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > People seem to view the alternatives as either: > origin host selects which destination Locator to put in packet > XOR > some router selects which destination Locator to put in packet > > I respectfully submit that this is a false choice and that > this misconception is hindering the discussions here. I concur. > Another, IMHO preferable, approach is to have the origin host > put both source Locator and destination Locator into the packet, > but do not make it illegal/impossible for some router along the > path to re-write/modify either Locator iff that router really has > enough knowledge to do so in some thoughtful way. Not all routers > in the world might have enough knowledge to do so. Not all routers > in the world might choose to do so. By having the origin host put > in a valid destination Locator, but avoiding precluding routers along > the path from applying better information, we can have the best of > both worlds, IMHO. Architecturally, I agree. But I'd also like to see the possibility of the origin host delegating *) the initial job to a box in the network. That is, iff there is such a box in the local network, the end hosts would be permitted to emit packets with identifiers in the packet. Anyway, the tricky things here are security and trust. At minimum, we need some way to know that we continue to talk to the same host, even if the locators change. Otherwise there is the possibility of a malicious party claiming that a host is "better" reachable through another locator, leading to a DoS or traffic hijacking. In an architecturally host-centric solution (akin HIP/SHIM6), we can apparently rely on the hosts to present themselves as integral entities, i.e., asserting that a given set of locators belong to them **). In an architecturally network-centric solution (akin Noel's "jack up"), apparently we have to somehow be able to trust the network, as the host has no idea of which locators it has... (I smell a canned tin of worms here.) In a host-centric architecture, the basic choices seem to be between return routability and something stronger. In other words, return routability seems like the minimum baseline. Personally, I'd like to see the possibility of using something stronger, such as hash chains or public keys. If not as a mandatory-to-use feature, then at least as a mandatory-to-implement and optional-to-use feature. *) Note that I really think that the right approach is for the host to _delegate_ the job to the network. IMHO, a solution where the function is primarily performed by the network and a host can implement it only by "becoming" a part of the network seems to have more potential security problems. **) It is not as simple as a host asserting that it has a set of locators, I know. The host can lie. But those details are well known and worked out at least for HIP and SHIM6, probably for a few other solutions, too. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 01:31:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ze0-0003DN-NZ; Wed, 03 Jan 2007 01:30:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1zdy-0003DH-T3 for ram@iab.org; Wed, 03 Jan 2007 01:30:34 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1zdt-0007m5-9A for ram@iab.org; Wed, 03 Jan 2007 01:30:34 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA663213146; Wed, 3 Jan 2007 08:30:25 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9603E21313C; Wed, 3 Jan 2007 08:30:25 +0200 (EET) In-Reply-To: <6CD3B854-F172-4408-AC73-8DF6D4C47240@extremenetworks.com> References: <6CD3B854-F172-4408-AC73-8DF6D4C47240@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] aside Re: HIP Date: Wed, 3 Jan 2007 08:30:19 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I think HIP is really great research. I am not quite > as enthusiastic about HIP as an operational solution. I don't think anyone has really worked out the operational details for HIP. Partially the HIP folks have had too much to do to get the basic ideas to work, partially they have seen the SHIM6 folks doing good job that could be adopted to HIP, and partially it has just been a problem of few if any operational folks within the HIP community. That said, a few things have been considered: 1. Firewall details. E. Vehmersalo, Host Identity Protocol Enabled Firewall: A Prototype Implementation and Analysis, Master's thesis, September 2005. http://infrahip.hiit.fi/papers/essi_dippa.pdf 2. Privacy. L. Takkinen, Host Identity Protocol Privacy Management, Master's thesis, March 2006. Also Janne Lindqvist and Laura Takkinen, Privacy Management for Secure Mobility, ACM CCS Workshop on Privacy in Electronic Society WPES 2006, Alexandria VA, USA, October 30, 2006. http://portal.acm.org/citation.cfm?doid=1179601.1179612 3. Legacy NATs and architected NATs. See the various WG and RG drafts. > My main concern is that with HIP, when one's public key > is compromised (and, yes, that is always a WHEN, not an IF), > one always necessarily loses one's Identifier. This seems > pretty undesirable to me. I cannot but agree. Currently, there are two known remedies: 1. Identity delegation with HIP allows you to leave your "primary identity" off-line, using only a temporary public key on-line. This reduces the probability of the "primary identity" getting compromised. BTW, the same approach seems to be sufficient for CA keys, but then there the keys are not used as identifiers. 2. There is a variant of HIP called lightweight HIP (LHIP), which doesn't use public keys. Tobias Heer worked out the details as his thesis; unfortunately I wasn't able to find it online. > Also, for moderate threat environments, I think all the > HIP cryptography is overkill and computationally expensive. I'd > prefer to have the option for a less computationally intense and > less comprehensive security mechanism for moderate threat > environments. LHIP uses hash chains, IIRC. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 06:26:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24FK-000162-LF; Wed, 03 Jan 2007 06:25:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24FJ-00015w-HW for ram@iab.org; Wed, 03 Jan 2007 06:25:25 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24FI-0005gI-AW for ram@iab.org; Wed, 03 Jan 2007 06:25:25 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id F2F7A59FAC; Wed, 3 Jan 2007 06:22:58 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 03 Jan 2007 06:22:59 -0500 X-Sasl-enc: T2K4OasbpfU8gQxpT6LXD3bbSv9Dhy/zjaCMEjVQtOCC 1167823369 Received: from [127.0.0.1] (debi.vmri.hu [193.225.208.141]) by mail.messagingengine.com (Postfix) with ESMTP id 0BB4825F74; Wed, 3 Jan 2007 06:22:31 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: Roland Dobbins In-Reply-To: <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> Content-Type: text/plain Date: Wed, 03 Jan 2007 12:24:16 +0100 Message-Id: <1167823456.25062.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, 2007-01-02 at 17:25 -0800, Roland Dobbins wrote: > On Jan 2, 2007, at 5:07 PM, David Conrad wrote: > > I personally believe the most likely solution that addresses the > > largest number of requirements with the lowest cost will require > > some sort of mapping between an end point identifier and a routing > > locator. There are a variety of ways to do this mapping, while the > > DNS is not ideal, it does have the advantage that it works (after a > > fashion). > > Ah, but it doesn't work as quickly and reliably and dependably and > universally as is needed for a system of the type you describe to > count on it. What we do here must be entirely self-contained, IMHO. > Self-contained, to which extent? Do you also disqualify the distributed lookup/cache that is performed in common RIB/FIB constructs in routers today? What if such lookups were implemented (but invisible) and working using one of your disqualified technologies? What if two chassis are interconnected with a bus-extender sharing one routing table? Is that an accepted form of resource distribution? If the bus-extender is replaced with IP over 10GE, does that change anything? My point is that I believe it is a mistake to think in terms of physical boxes when high-level architectural principles are discussed. Practical constraints such as bandwidth-requirements, response-time, latency (limited by the speed of light) etc still apply though. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 06:31:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24Kt-0004PS-7j; Wed, 03 Jan 2007 06:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24Kr-0004O5-KQ for ram@iab.org; Wed, 03 Jan 2007 06:31:09 -0500 Received: from ronin.4ever.de ([195.34.187.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24Kq-0007Cv-C6 for ram@iab.org; Wed, 03 Jan 2007 06:31:09 -0500 Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1H24Kd-000MLn-5W for ram@iab.org; Wed, 03 Jan 2007 12:30:55 +0100 Date: Wed, 3 Jan 2007 12:30:55 +0100 From: "Elmar K. Bins" To: ram@iab.org Subject: Re: [RAM] Destination Locator selection Message-ID: <20070103113054.GM23876@ronin.4ever.de> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167823456.25062.14.camel@localhost.localdomain> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org heldal@eml.cc (Per Heldal) wrote: > On Tue, 2007-01-02 at 17:25 -0800, Roland Dobbins wrote: > > On Jan 2, 2007, at 5:07 PM, David Conrad wrote: > > > I personally believe the most likely solution that addresses the > > > largest number of requirements with the lowest cost will require > > > some sort of mapping between an end point identifier and a routing > > > locator. There are a variety of ways to do this mapping, while the > > > DNS is not ideal, it does have the advantage that it works (after a > > > fashion). > > > > Ah, but it doesn't work as quickly and reliably and dependably and > > universally as is needed for a system of the type you describe to > > count on it. What we do here must be entirely self-contained, IMHO. > > Self-contained, to which extent? Having the lookup depend on the same mechanism (meaning: having DNS requests routed over the Internet) it is a solution to is not a good idea. Elmar. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 06:51:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24ec-0000GE-AR; Wed, 03 Jan 2007 06:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24ea-0000G8-Rz for ram@iab.org; Wed, 03 Jan 2007 06:51:32 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24eZ-0003xU-M8 for ram@iab.org; Wed, 03 Jan 2007 06:51:32 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 490745A704; Wed, 3 Jan 2007 06:49:08 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 03 Jan 2007 06:49:08 -0500 X-Sasl-enc: ekFNUsjSk3QuwtxDqYYKJ+5GSrIrWgWHD3lXERG8jkyh 1167824937 Received: from [127.0.0.1] (slovakia.medvecky.net [81.0.246.9]) by mail.messagingengine.com (Postfix) with ESMTP id 442BF25FE9; Wed, 3 Jan 2007 06:48:47 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: "Elmar K. Bins" In-Reply-To: <20070103113054.GM23876@ronin.4ever.de> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> Content-Type: text/plain Date: Wed, 03 Jan 2007 12:48:35 +0100 Message-Id: <1167824915.25062.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > > Self-contained, to which extent? > > Having the lookup depend on the same mechanism (meaning: having DNS > requests routed over the Internet) it is a solution to is not a good > idea. Did anybody suggest to remove local DNS-cache and local/internal DNS or other local name-mapping mechanisms? The point was that not everything has to be done within one box. Putting your DNS somewhere on the opposite side of the globe is a whole different story. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 06:58:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24ks-0004Kt-P2; Wed, 03 Jan 2007 06:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24kr-0004Ko-No for ram@iab.org; Wed, 03 Jan 2007 06:58:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24kq-0004u8-Dv for ram@iab.org; Wed, 03 Jan 2007 06:58:01 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2007 03:57:59 -0800 X-IronPort-AV: i="4.12,231,1165219200"; d="scan'208"; a="454820554:sNHT47101520" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03BvxpH017352; Wed, 3 Jan 2007 03:57:59 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03BvwZH020172; Wed, 3 Jan 2007 03:57:59 -0800 (PST) Received: from [212.254.247.5] ([10.61.80.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l03BfD7K021257; Wed, 3 Jan 2007 03:41:13 -0800 Message-ID: <459B9A44.4080400@cisco.com> Date: Wed, 03 Jan 2007 12:57:56 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: David Conrad Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering References: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> In-Reply-To: <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1905; t=1167825479; x=1168689479; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=yefNd3eHh86Ky0AP2rmCjh5KsvQkjlLO9A1iMe/g7wQ=; b=naW+eUXOxIB5kMpdCIr3NmVBDosvYBH3L0mC3TlCeXLq2NXPQuJQdAzPvlN0fKDOupe2TOmV BzVOQ6Kac38h+GHQ0J52UgDEGLgdkmPwquqQZE7zF8DyCDxMySvVC4ZW; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1905; t=1167824475; x=1168688475; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20David=20Conrad=20; bh=yefNd3eHh86Ky0AP2rmCjh5KsvQkjlLO9A1iMe/g7wQ=; b=LcvwpnPnJbqpqaIcO3lf489vqbGrTTPyBqEJwQH0NmwLmm7ISAlfgf6uWXr6sGJoSenoRohX X8j2jBosQh+XN/ZTlnoB9cx7ziuHTAD6S++jCOjXZuWN5fWgl/Bbzn8A; Authentication-Results: sj-dkim-1; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, > In my opinion, shim6 as it stands is not a _site_ multi-homing > technology, rather it is a _host_ multi-homing technology. It also > doesn't help with "transparent renumbering" and I believe people have > argued that it makes the traffic engineering problem worse (at least > from the perspective of ISPs). Several points: 1. Elwyn Davis has already made a strong argument that even if enterprises fully deployed SHIM6 or were otherwise completely single homed then we would still have a problem to discuss on this list because of traffic engineering. That is - sources and transit providers will continue to manipulate locater routing information for their own purposes. 2. I fail to see how SHIM6 either helps or hurts this problem. To me the discussion of SHIM6 (or HIP, for that matter) is a canard given (1). While I believe there is a tremendous amount of FUD generated about a relatively non-existent mechanism that argues strongly for correction, so far as I can tell that takes us away from the purpose of this list. 3. It seems to me that Ran and others are correct to focus on entropy within the core. It would be extremely useful to have some sort of bibliography so that the community could better understand how the core behaves today. Tony's analysis of where the pain points are largely speaking revolves around memory access times and being on the technology knee. That being the case, I wonder about the nature of BGP updates today that we can reduce those updates. 4. Size probably also matters but my figuring from this discussion is that the reasonable assumption is that it matters because it's believed to be positively correlated to entropy. Is there any other reason to believe size matters? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 07:39:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25OU-0004Lo-56; Wed, 03 Jan 2007 07:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25OS-0004Kv-VE for ram@iab.org; Wed, 03 Jan 2007 07:38:56 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H25OR-00038g-PD for ram@iab.org; Wed, 03 Jan 2007 07:38:56 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id D392C5AFE0; Wed, 3 Jan 2007 07:36:29 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 03 Jan 2007 07:36:29 -0500 X-Sasl-enc: z03pVZEbN00IJNaIiAN3X3JRv+mAR18V6+q0t7P7x5AA 1167827775 Received: from [127.0.0.1] (241-254-235-64.lax01.niuhi.com [64.235.254.241]) by mail.messagingengine.com (Postfix) with ESMTP id AB0AB26104; Wed, 3 Jan 2007 07:36:04 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: "Elmar K. Bins" In-Reply-To: <1167824915.25062.35.camel@localhost.localdomain> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 03 Jan 2007 13:38:06 +0100 Message-Id: <1167827886.25062.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, 2007-01-03 at 12:48 +0100, Per Heldal wrote: > > > Self-contained, to which extent? > > > > Having the lookup depend on the same mechanism (meaning: having DNS > > requests routed over the Internet) it is a solution to is not a good > > idea. > > Did anybody suggest to remove local DNS-cache and local/internal DNS or > other local name-mapping mechanisms? The point was that not everything > has to be done within one box. Putting your DNS somewhere on the > opposite side of the globe is a whole different story. Btw, why this sudden obsession with DNS? Suggested MH-solutions with multiple addresses per host only rely on DNS for seeding. I.e. one reachable (possible limitation) locator for the destination host must be in DNS in order to establish a connection. Further exchange of locators happen directly between the endpoints. Besides, there's nothing that prevents the use of locally cached or even static information in the absence of working global DNS. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:11:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25tK-0007lQ-RZ; Wed, 03 Jan 2007 08:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25tJ-0007lL-Dj for ram@iab.org; Wed, 03 Jan 2007 08:10:49 -0500 Received: from eastrmmtao02.cox.net ([68.230.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H25tH-0000Ye-Md for ram@iab.org; Wed, 03 Jan 2007 08:10:48 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070103131042.VUVQ9317.eastrmmtao02.cox.net@eastrmimpo01.cox.net> for ; Wed, 3 Jan 2007 08:10:42 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 6d9R1W00a0pnMhQ0000000; Wed, 03 Jan 2007 08:09:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> References: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] GSE security Date: Wed, 3 Jan 2007 08:10:40 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2 Jan 2007, at 21:06, marcelo bagnulo braun wrote: > do we also agree that when security is included in GSE, > the result is not nearly as nice as the current GSe proposal? No scientific case has been made here that detailing how GSE can be authenticated necessarily proves the resulting form of GSE is "not nearly as nice". If someone wants to try to make such a case on list, that would be fine. I suspect that it is hard to prove that for the universe of all possible security approaches, GSE ends up being "not nearly so nice". I'd also submit that "not nearly so nice" is a pretty subjective criterion. I'd prefer that we operate with more objective and measurable criteria. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:14:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25we-0002Cx-4x; Wed, 03 Jan 2007 08:14:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H25wd-0002Cs-Mu for ram@iab.org; Wed, 03 Jan 2007 08:14:15 -0500 Received: from centrmmtao05.cox.net ([70.168.83.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H25wb-0001Ts-Cr for ram@iab.org; Wed, 03 Jan 2007 08:14:15 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070103131410.UXUO11822.centrmmtao05.cox.net@eastrmimpo01.cox.net> for ; Wed, 3 Jan 2007 08:14:10 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 6dCt1W00n0pnMhQ0000000; Wed, 03 Jan 2007 08:12:53 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <8d33bfdf734af3d838f5e98c851d23c0@it.uc3m.es> References: <8d33bfdf734af3d838f5e98c851d23c0@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EA470F6-1521-49CD-9D56-33BDB6C115DC@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 08:14:09 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2 Jan 2007, at 20:55, marcelo bagnulo braun wrote: > just a subtle point here.... > from the way you put it, it seems to me that you would require that > all the hosts must support whatever new thing/protocol that is > necesary to allow this rewriting It is not obvious to me that your assertion is necessarily true. > I would argue that this would make deployment more difficult Given that no specific mechanism has been proposed, that argument isn't very credible right now. > I would then suggest that both the host or the host can do the > locator selection and all the rest of the functions required to > support this (allowing both routers and hosts to support the needed > functions) and also that a host that is selecting the locators can > communicate with a peer that is being served by a router that > performs the locator selection and associated required features. That is not identical to the abstract concept I've suggested, not least because it has more implementation detail than anything I've been talking about. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:34:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26GG-00072Q-RY; Wed, 03 Jan 2007 08:34:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26GF-00071c-4n for ram@iab.org; Wed, 03 Jan 2007 08:34:31 -0500 Received: from ronin.4ever.de ([195.34.187.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26GC-0006XR-3P for ram@iab.org; Wed, 03 Jan 2007 08:34:31 -0500 Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1H26GB-0002gd-KV for ram@iab.org; Wed, 03 Jan 2007 14:34:27 +0100 Date: Wed, 3 Jan 2007 14:34:27 +0100 From: "Elmar K. Bins" To: ram@iab.org Subject: Re: [RAM] Destination Locator selection Message-ID: <20070103133427.GQ23876@ronin.4ever.de> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167824915.25062.35.camel@localhost.localdomain> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org heldal@eml.cc (Per Heldal) wrote: > > > Self-contained, to which extent? > > > > Having the lookup depend on the same mechanism (meaning: having DNS > > requests routed over the Internet) it is a solution to is not a good > > idea. > > Did anybody suggest to remove local DNS-cache and local/internal DNS or > other local name-mapping mechanisms? The point was that not everything > has to be done within one box. Putting your DNS somewhere on the > opposite side of the globe is a whole different story. I'm not sure whether or not one should decide here what one wants: - a local lookup (hence a local database, whatever it may be) - a global lookup (like DNS would provide) - something else? The word "DNS" is loaded, and if it's being used in a discussion, it brings a lot of implications with it. Yours, Elmar. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:54:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26Yj-0002BB-CI; Wed, 03 Jan 2007 08:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26Yi-0002B6-H3 for ram@iab.org; Wed, 03 Jan 2007 08:53:36 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26Ye-0002D4-58 for ram@iab.org; Wed, 03 Jan 2007 08:53:36 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 05:53:32 -0800 X-IronPort-AV: i="4.12,231,1165219200"; d="scan'208"; a="49901326:sNHT44589324" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03DrVWI030758 for ; Wed, 3 Jan 2007 08:53:31 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03DrV2k015953 for ; Wed, 3 Jan 2007 08:53:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1167823456.25062.14.camel@localhost.localdomain> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AF08C47-A280-4F70-891A-205BFA34B33B@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 05:53:29 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=645; t=1167832411; x=1168696411; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=tK6nRauZgdAUQ4nr+874wcChdENgMCQDmstD4xc8waY=; b=bWtbGf23yG2DGp5IAaOkETevGkN1M/iTk7CSq5Bnaedb13l0QROCwlamKdlbbXkcrin9Qxtt ib9yIfaWN8i6ePdxfm89THZMt4cBbZEuLHp5N0NsCMMWB5FoUMSddCpD; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 3:24 AM, Per Heldal wrote: > My point is that I believe it is a mistake to think in terms of > physical > boxes when high-level architectural principles are discussed. > Practical > constraints such as bandwidth-requirements, response-time, latency > (limited by the speed of light) etc still apply though. Self-contained with respect to not relying on layer-7. I agree with your sentiment expressed here. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:55:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26aE-0003DA-CB; Wed, 03 Jan 2007 08:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26aD-0003Cx-4Q for ram@iab.org; Wed, 03 Jan 2007 08:55:09 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26aB-0002PD-Ul for ram@iab.org; Wed, 03 Jan 2007 08:55:09 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 69CF05A660; Wed, 3 Jan 2007 08:52:43 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 03 Jan 2007 08:52:43 -0500 X-Sasl-enc: Kf94vV66FUxrl/vuNYi36SaEgKLdHHPjUqKxItOrKzaH 1167832362 Received: from [127.0.0.1] (miller.polymathic.net [193.110.91.7]) by mail.messagingengine.com (Postfix) with ESMTP id EA86723993; Wed, 3 Jan 2007 08:52:40 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: "Elmar K. Bins" In-Reply-To: <20070103133427.GQ23876@ronin.4ever.de> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> <20070103133427.GQ23876@ronin.4ever.de> Content-Type: text/plain Date: Wed, 03 Jan 2007 14:54:56 +0100 Message-Id: <1167832496.25062.60.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, 2007-01-03 at 14:34 +0100, Elmar K. Bins wrote: > The word "DNS" is loaded, and if it's being used in a discussion, it brings > a lot of implications with it. As written elsewhere in the thread: why this sudden obsession with DNS? This thread was about the selection between multiple locators, which to me seem to have much more in common with current router's selection of outbound interface than name-mapping. Site-wide coordination and policy-control (TE requirements) would require some form of query-response service to advice/force the selection-process on individual hosts. Implementation-details like choice of protocol for such have not yet been discussed. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 08:56:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26bE-0003e0-1t; Wed, 03 Jan 2007 08:56:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26bC-0003dv-Kz for ram@iab.org; Wed, 03 Jan 2007 08:56:10 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26bB-0002cp-Eb for ram@iab.org; Wed, 03 Jan 2007 08:56:10 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 05:56:09 -0800 X-IronPort-AV: i="4.12,231,1165219200"; d="scan'208"; a="49901522:sNHT41719472" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03Du77m031643 for ; Wed, 3 Jan 2007 08:56:07 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03Du62k016593 for ; Wed, 3 Jan 2007 08:56:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <6AF08C47-A280-4F70-891A-205BFA34B33B@cisco.com> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <6AF08C47-A280-4F70-891A-205BFA34B33B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <084112BD-F7B3-4692-B097-DE760F4F65D8@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 05:56:04 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=387; t=1167832567; x=1168696567; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=yfLIbXeTLY9GCE9NAM1W3eTzM2UY7UwkDMI8P6pW4mc=; b=pgm+iPlVJRJNUo5+oGq0tidC/LWfu9ESqeOSGWrIYagrhfORYhG7HtIG0sDw2u69P7gH0zjL VjIAnUbmuSZyVtRyTDzust5TO+CeWlLUVBlPmRoHnW4nBIZ3FwHM9hmb; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 5:53 AM, Roland Dobbins wrote: > Self-contained with respect to not relying on layer-7. Make that, 'layer-7 things which have nothing to do with routing'. ;> ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 09:07:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26m9-0001yl-JD; Wed, 03 Jan 2007 09:07:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H26m8-0001yf-CP for ram@iab.org; Wed, 03 Jan 2007 09:07:28 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H26m7-0005Is-01 for ram@iab.org; Wed, 03 Jan 2007 09:07:28 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l03E6FkM006556; Wed, 3 Jan 2007 14:06:15 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l03E6EPY006555; Wed, 3 Jan 2007 14:06:14 GMT Date: Wed, 3 Jan 2007 14:06:14 +0000 From: bmanning@karoshi.com To: Per Heldal Subject: Re: [RAM] Destination Locator selection Message-ID: <20070103140614.GA6401@vacation.karoshi.com.> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> <20070103133427.GQ23876@ronin.4ever.de> <1167832496.25062.60.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167832496.25062.60.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, Jan 03, 2007 at 02:54:56PM +0100, Per Heldal wrote: > On Wed, 2007-01-03 at 14:34 +0100, Elmar K. Bins wrote: > > > The word "DNS" is loaded, and if it's being used in a discussion, it brings > > a lot of implications with it. > > As written elsewhere in the thread: why this sudden obsession with DNS? > > //per > don't really know. DNS, as Mr Conrad points out, sort of works. In this context it does have a few warts: 1) where do you find the DNS servers if you don't have a route? 2) is there any value to using the same namespace, if so, where would you anchor it? (e.g. ip6.arpa, e164.arpa, rdi.int?) 3) given the (generally) limited number of possible forwarding paths, it would seem that a localized view might be preferable... (as you mentioned) YMMV of course --bill _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 09:33:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27An-0001Kb-1P; Wed, 03 Jan 2007 09:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27Am-0001KW-4N for ram@iab.org; Wed, 03 Jan 2007 09:32:56 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27Ak-0002k4-88 for ram@iab.org; Wed, 03 Jan 2007 09:32:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l03EWgjs010582; Wed, 3 Jan 2007 16:32:42 +0200 Date: Wed, 3 Jan 2007 16:32:42 +0200 (EET) From: Pekka Savola To: Noel Chiappa Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> Message-ID: References: <20070101222247.5713D86AE4@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2408/Wed Jan 3 02:04:22 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS, TW_GW autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, 1 Jan 2007, Noel Chiappa wrote: > > From: marcelo bagnulo braun > > you cannot make filers and ACL based on identifiers unless you can > > trust them. In the case of routing names, you can have some level of > > trust, because, if you trust the routing system, then you know this > > packet will only be delivered to the destiantion locator. > > But you can't really trust the source locator, of course; all it takes is a > few sites which don't do source-address filtering, and bogons can appear at > any given destination. So you can't reliably filter anything you are basing > in part on the source locator. The situation is not necessarily quite that bad. For connections that both originate and terminate inside a trusted part of the network, source IP address filtering can be rather reliable. See section 1.2 of draft-savola-rtgwg-backbone-attacks-02.txt. For example, if an ISP implements ingress filtering at all of its borders, and an access list only allows access from a couple of management LANs inside that ISP's network, if someone in the Internet spoofs source addresses of the LAN destined to the ISP, they will be dropped at the border. This is one weakness of GSE-like solutions (a minor variation of this exists in SHIM6 as well): you may not be able to effectively drop packets which spoof your host identities at the border of your {site,other trust border}. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 09:50:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27Qk-0002TN-JD; Wed, 03 Jan 2007 09:49:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27Qi-0002TH-Vt for ram@iab.org; Wed, 03 Jan 2007 09:49:24 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27Qd-0007yk-G5 for ram@iab.org; Wed, 03 Jan 2007 09:49:24 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 18E8534143; Wed, 3 Jan 2007 09:49:19 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 09:49:18 -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: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 09:49:17 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD753@tayexc14.americas.cpqcorp.net> In-Reply-To: <9EA470F6-1521-49CD-9D56-33BDB6C115DC@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Destination Locator selection Thread-Index: AccvOR1YuuShv72PR12EIpFkSmbcVgADKQjw From: "Bound, Jim" To: "RJ Atkinson" , X-OriginalArrivalTime: 03 Jan 2007 14:49:18.0884 (UTC) FILETIME=[58E30E40:01C72F46] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Folks, Ran, Noel, Tony L., John L, Dobbins R, and others are trying to give us abstractions for Model and Architecture yet folks keep going down to details and trying to pin a solution to the abstractions (e.g. DNS, SHIM6, HIP). We need to get beyond that to get an architecture done here. It is good to provide architectural tenets from ongoing IETF work (for example I think NSIS architecture helps us with distributing computing of knowledge for discovery requirements), but discussing implementation details or ones favorite solution is simply going to slow us down to move forward with archetype and abstractions to get forward progress. My .46 cents, /jim > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com]=20 > Sent: Wednesday, January 03, 2007 8:14 AM > To: ram@iab.org > Subject: Re: [RAM] Destination Locator selection >=20 >=20 > On 2 Jan 2007, at 20:55, marcelo bagnulo braun wrote: > > just a subtle point here.... > > from the way you put it, it seems to me that you would require that=20 > > all the hosts must support whatever new thing/protocol that is=20 > > necesary to allow this rewriting >=20 > It is not obvious to me that your assertion is necessarily true. >=20 > > I would argue that this would make deployment more difficult >=20 > Given that no specific mechanism has been proposed, that=20 > argument isn't very credible right now. >=20 > > I would then suggest that both the host or the host can do=20 > the locator=20 > > selection and all the rest of the functions required to=20 > support this=20 > > (allowing both routers and hosts to support the needed > > functions) and also that a host that is selecting the locators can=20 > > communicate with a peer that is being served by a router=20 > that performs=20 > > the locator selection and associated required features. >=20 > That is not identical to the abstract concept I've suggested,=20 > not least because it has more implementation detail than=20 > anything I've been talking about. >=20 > Ran >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 09:57:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27Y3-0006Od-Nw; Wed, 03 Jan 2007 09:56:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27Y2-0006OE-0S for ram@iab.org; Wed, 03 Jan 2007 09:56:58 -0500 Received: from elle.sprintlink.net ([199.0.234.34] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27Y0-0001V4-Ol for ram@iab.org; Wed, 03 Jan 2007 09:56:57 -0500 Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id l03Eltu23215; Wed, 3 Jan 2007 09:47:55 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id KAA10746; Wed, 3 Jan 2007 10:00:24 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Wed, 3 Jan 2007 10:00:24 -0500 (EST) From: Ted Seely X-X-Sender: To: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: <5da9e3472ce652e2e532f6a58fa541fe@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > > > > undeniably a very valid example of a large organization that is able to > > support a large and complex network. However, there is a distinct > > difference in what commercial organizations can and want to support > > versus > > government organizations. one gets paid for regardless (called taxes > > and > > being able to print your own money :), the other has to stay in > > business > > and fund its own. having done both in a previous life, it is a day and > > night difference between the commercial sector and the government > > sector. > > we have to keep in mind that the small to mid size company, which make > > up > > the large majority of companies, do not have a lot of in house > > expertise, > > nor are their networks a focus of their business. sorry to continue to > > beat that horse. > > but someone there do configure BGP today for multihoming, right? yes, or they pay consultants to do it, and in either case they are typically very rudimentary and not complex. this may have changed, but that was my observation from 10+ years ago. now that being said, perhaps the observation is not current enough to matter. i leave that to others still more involved in that space to provide input. > > BGP multihoming would be non starter in a home network imho do you > agree? today yes, 10 years from now, for whatever this my evolve into, I don't know. as someone pointed out earlier in this thread, that will be us eventually. :) > > So my only point is that these a qualitative different... agree based on today's requirements, and i use that term very loosely. -ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:05:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27gM-0003OJ-QM; Wed, 03 Jan 2007 10:05:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27gL-0003OD-Kt for ram@iab.org; Wed, 03 Jan 2007 10:05:33 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27gK-0004PK-Dv for ram@iab.org; Wed, 03 Jan 2007 10:05:33 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 07:05:32 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="49907367:sNHT44814040" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l03F5WZd028728 for ; Wed, 3 Jan 2007 10:05:32 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03F5R7f020155 for ; Wed, 3 Jan 2007 10:05:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 07:05:25 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1431; t=1167836732; x=1168700732; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=ULcwsF1MnV0/16znUFOH2gK/rVWLb8EjRkDp/ZecoCU=; b=StljxZOnEPLsQVsfPo+ylsYCDuJQGCXL59suC0PrJ02h8XcnU/KKUp3CoSuLludcQIYx4zXm euXf6vRDfQmz7+7uYCJhr62vGJ1gfhq5Qv9dM6zK4fWPN8j21gqp5uFw; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 6:41 AM, Pekka Savola wrote: > Maybe you should elaborate in which ways exactly the pain will get > significantly (more than double) worse than it currently is. 1. Multihoming doesn't necessarily mean just two connections - it means => 2. 2. Hardware capacity isn't unlimited (isn't that one of the reasons why we're all here in the first place, heh?) 3. Besides the multiple-IP issue and having to maintain 2 or more ACEs or firewall rules or whatever for each host (and QoS mappings, etc.), there's the issue of being forced to renumber and churn all those things based upon the vicissitudes of transient business relationships with various SPs. And of course the TE issue internal to the enterprise itself. 4. Even if the pain were only to double, that's not within our remit. Our goal must be to fix this problem in our own backyards, without unduly burdening the multihoming customer base. SHIM6 is a classic example of cost-shifting in terms of OPEX, CAPEX, complexity, and supportability. It's simply not practical from either a technical or an economic standpoint, and enterprises (i.e., the multihoming customer base) won't hold still for it. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:07:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27iT-0003ol-Kz; Wed, 03 Jan 2007 10:07:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27iS-0003og-Ux for ram@iab.org; Wed, 03 Jan 2007 10:07:44 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27JU-0005qo-Qn for ram@iab.org; Wed, 03 Jan 2007 09:41:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l03EfrJn010782; Wed, 3 Jan 2007 16:41:53 +0200 Date: Wed, 3 Jan 2007 16:41:53 +0200 (EET) From: Pekka Savola To: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: Message-ID: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2408/Wed Jan 3 02:04:22 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_05, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Sun, 31 Dec 2006, Roland Dobbins wrote: > I mean 'mandating multiple identifiers of the type which go into ACLs, > firewall rules, QoS rules, etc. for filtering/matching packets' is out. Being a network administrator myself, I have to deal with IP addresses and update them regularly a lot -- I agree this is a significant pain. But I have difficulty seeing why a model with multiple addresses would be _signficantly_ worse than the current one. Aren't we just talking about (roughly) two times the number of ACL entries, firewall rules, QoS entries, etc.. Doubling (at most: in many cases both would be updated at the same time, reducing the burden) an effort is still in the same order of magnitude. In the end, this might even encourage better automation of places where IP addresses are managed so you might even save some time ;-) In my book, if the pain is currently 'huge', double the pain is still just 'huge' pain. Maybe you should elaborate in which ways exactly the pain will get significantly (more than double) worse than it currently is. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:10:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27ko-0004Vw-8w; Wed, 03 Jan 2007 10:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27km-0004Vr-Pc for ram@iab.org; Wed, 03 Jan 2007 10:10:08 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27kl-00073w-Gj for ram@iab.org; Wed, 03 Jan 2007 10:10:08 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 5950425; Wed, 03 Jan 2007 10:10:07 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09CC0494-8DAB-4645-B755-D7EC97317931@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 10:10:03 -0500 To: Ted Seely X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 10:00 AM, Ted Seely wrote: >>> >>> undeniably a very valid example of a large organization that is >>> able to >>> support a large and complex network. However, there is a distinct >>> difference in what commercial organizations can and want to support >>> versus >>> government organizations. one gets paid for regardless (called >>> taxes >>> and >>> being able to print your own money :), the other has to stay in >>> business >>> and fund its own. having done both in a previous life, it is a >>> day and >>> night difference between the commercial sector and the government >>> sector. >>> we have to keep in mind that the small to mid size company, which >>> make >>> up >>> the large majority of companies, do not have a lot of in house >>> expertise, >>> nor are their networks a focus of their business. sorry to >>> continue to >>> beat that horse. >> >> but someone there do configure BGP today for multihoming, right? > > yes, or they pay consultants to do it, and in either case they are > typically very rudimentary and not complex. this may have changed, > but > that was my observation from 10+ years ago. now that being said, > perhaps > the observation is not current enough to matter. i leave that to > others > still more involved in that space to provide input. I think that your observation is still correct. > >> >> BGP multihoming would be non starter in a home network imho do you >> agree? > > today yes, 10 years from now, for whatever this my evolve into, I > don't > know. as someone pointed out earlier in this thread, that will be us > eventually. :) ASNs 1880, 1881 and 1882 come to mind, for some reason. Regards Marshall > >> >> So my only point is that these a qualitative different... > > agree based on today's requirements, and i use that term very loosely. > > -ted > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:17:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27sA-0000yF-BU; Wed, 03 Jan 2007 10:17:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27s8-0000y9-T6 for ram@iab.org; Wed, 03 Jan 2007 10:17:44 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27s2-0001Ky-JW for ram@iab.org; Wed, 03 Jan 2007 10:17:44 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 12C2A34099; Wed, 3 Jan 2007 10:17:38 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 10:17:37 -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: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering Date: Wed, 3 Jan 2007 10:17:24 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD7AF@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering Thread-Index: AccvSKvYBjQ14qenTuyeoId4l69JLwAAYlOQ From: "Bound, Jim" To: "Roland Dobbins" , X-OriginalArrivalTime: 03 Jan 2007 15:17:37.0847 (UTC) FILETIME=[4D8C3C70:01C72F4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Roland, Your not arguing that hosts should only have one set of locators are you? Just checking? thanks /jim=20 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > Sent: Wednesday, January 03, 2007 10:05 AM > To: ram@iab.org > Subject: Re: one size doesn' fit all (was Re: other=20 > requirement? (was Re:[RAM] Traffic Engineering >=20 >=20 > On Jan 3, 2007, at 6:41 AM, Pekka Savola wrote: >=20 > > Maybe you should elaborate in which ways exactly the pain will get=20 > > significantly (more than double) worse than it currently is. >=20 > 1. Multihoming doesn't necessarily mean just two connections - it =20 > means =3D> 2. >=20 > 2. Hardware capacity isn't unlimited (isn't that one of=20 > the reasons =20 > why we're all here in the first place, heh?) >=20 > 3. Besides the multiple-IP issue and having to maintain 2 or more =20 > ACEs or firewall rules or whatever for each host > (and QoS mappings, etc.), there's the issue of being=20 > forced to renumber and churn all those things based upon > the vicissitudes of transient business relationships=20 > with various SPs. And of course the TE issue internal > to the enterprise itself. >=20 > 4. Even if the pain were only to double, that's not within our =20 > remit. Our goal must be to fix this problem in our own > backyards, without unduly burdening the multihoming=20 > customer base. >=20 > SHIM6 is a classic example of cost-shifting in terms of OPEX,=20 > CAPEX, complexity, and supportability. It's simply not=20 > practical from either a technical or an economic standpoint,=20 > and enterprises (i.e., the multihoming customer base) won't=20 > hold still for it. >=20 > -------------------------------------------------------------- > --------- > Roland Dobbins // 408.527.6376 voice >=20 > All battles are perpetual. >=20 > -- Milton Friedman >=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:19:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27tT-0001Le-1h; Wed, 03 Jan 2007 10:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27tS-0001LZ-8W for ram@iab.org; Wed, 03 Jan 2007 10:19:06 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27tR-0001XC-2Q for ram@iab.org; Wed, 03 Jan 2007 10:19:06 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 07:19:05 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="49908663:sNHT41211812" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03FJ43c032185 for ; Wed, 3 Jan 2007 10:19:04 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03FJ47f023780 for ; Wed, 3 Jan 2007 10:19:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FD7AF@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC011FD7AF@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering Date: Wed, 3 Jan 2007 07:19:02 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=425; t=1167837544; x=1168701544; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=+C/kpNa2qztbYYvyo9S5MHDPS4AXAAKzO7kw/FrBFmA=; b=qnHyEi20gCMIYAIvZSVkcjT+h07B+u8WjxC3CUZWRH8xD2UtC4dFv1i251Ly9pzZmKFzcpRm DHCNu5kutexKXF4heYaKqKZ8xYZMw+W4GSuXLyLTy4WbY3iZxgRigE4u; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 7:17 AM, Bound, Jim wrote: > Your not arguing that hosts should only have one set of locators are > you? No - just one set of 'things which must go into ACLs, firewall rules, QoS policies', etc. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:20:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27uz-0002wB-Eo; Wed, 03 Jan 2007 10:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27uy-0002w6-8L for ram@iab.org; Wed, 03 Jan 2007 10:20:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27uw-0001lz-Ty for ram@iab.org; Wed, 03 Jan 2007 10:20:40 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2007 07:20:37 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l03FKcEP008004; Wed, 3 Jan 2007 07:20:38 -0800 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 l03FKWJ9025766; Wed, 3 Jan 2007 07:20:37 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 10:20:33 -0500 Received: from 10.86.240.238 ([10.86.240.238]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Jan 2007 15:20:33 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Wed, 03 Jan 2007 10:20:31 -0500 Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering From: Ralph Droms To: Pekka Savola , Roland Dobbins Message-ID: Thread-Topic: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Thread-Index: AccvSrTB8xVdLJs9Edu76gARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 15:20:33.0732 (UTC) FILETIME=[B6622840:01C72F4A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1746; t=1167837638; x=1168701638; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=0A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=DxsedLbdQQoy1MHTDu7tc5FxpRxUZTzLbF4TGk2pBAg=; b=nw3PKs+dbzUJdt+khIUCxnM9FOPt3kWYiHn3uH1ioUc5EsA8tc9x/7XS662PS0LM5n713cDr HKMhpRgWLqohGRH8CQivc9kXrblLNSfEpC7To+HYxAQEtTUu3g7GjcPn; Authentication-Results: sj-dkim-7; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Might be a problem if the multiplier is > 2 (suppose the organization uses ULAs, too; throw some VPNs in the mix?). Hm, I wonder if the problem might be n^2 counting src/dst pairs? Roland - are you supposing that multiplying the number of addresses managed in network elements by n (where n is a small integer) might start to exceed some internal limits in the network elements. Are customers going to have to come back to us (Cisco) for more memory? Or is it an administrative headache that could be managed with better NM tools? - Ralph On 1/3/07 9:41 AM, "Pekka Savola" wrote: > On Sun, 31 Dec 2006, Roland Dobbins wrote: >> I mean 'mandating multiple identifiers of the type which go into ACLs, >> firewall rules, QoS rules, etc. for filtering/matching packets' is out. > > Being a network administrator myself, I have to deal with IP addresses > and update them regularly a lot -- I agree this is a significant pain. > > But I have difficulty seeing why a model with multiple addresses would > be _signficantly_ worse than the current one. Aren't we just talking > about (roughly) two times the number of ACL entries, firewall rules, > QoS entries, etc.. Doubling (at most: in many cases both would be > updated at the same time, reducing the burden) an effort is still in > the same order of magnitude. In the end, this might even encourage > better automation of places where IP addresses are managed so you > might even save some time ;-) > > In my book, if the pain is currently 'huge', double the pain is still > just 'huge' pain. > > Maybe you should elaborate in which ways exactly the pain will get > significantly (more than double) worse than it currently is. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:28:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H282Z-0005a5-43; Wed, 03 Jan 2007 10:28:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H282X-0005ZI-I6 for ram@iab.org; Wed, 03 Jan 2007 10:28:29 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H282X-00065q-1Q for ram@iab.org; Wed, 03 Jan 2007 10:28:29 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l03FSObn011951; Wed, 3 Jan 2007 17:28:24 +0200 Date: Wed, 3 Jan 2007 17:28:24 +0200 (EET) From: Pekka Savola To: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: Message-ID: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2408/Wed Jan 3 02:04:22 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, 3 Jan 2007, Roland Dobbins wrote: > On Jan 3, 2007, at 6:41 AM, Pekka Savola wrote: >> Maybe you should elaborate in which ways exactly the pain will get >> significantly (more than double) worse than it currently is. > > 1. Multihoming doesn't necessarily mean just two connections - it means > => 2. In most cases, I suspect two covers 95%+ of multihomers. The rest are certain to get PI based solution in any case so for them the number is likely 1. > 2. Hardware capacity isn't unlimited (isn't that one of the reasons why > we're all here in the first place, heh?) When you push the limits of your hardware, you'll either justify better vendor or hardware or change the design (e.g., to use jumphosts for infrastructure ACLs etc) to accommodate the hardware restrictions. Again, if we are talking about merely doubling the size, this is not a concern. This mailing list would not have been set up if folks were pissing their pants by the prospect of 400K routes (and that's it) in their routers. Churn and 1M, 10M or 100M is more of a corcern. > 3. Besides the multiple-IP issue and having to maintain 2 or more ACEs > or firewall rules or whatever for each host > (and QoS mappings, etc.), there's the issue of being forced to > renumber and churn all those things based upon > the vicissitudes of transient business relationships with various > SPs. And of course the TE issue internal > to the enterprise itself. "Don't push if there's resistance". You make it sound like frequent renumbering, just to save 100$ a month or year by switching SPs once a year (or even more frequently) is a good idea. Guess what -- that's the tradeoff. Some folks in fact do calculate that switching SPs (and getting savings) is not worth the cost of renumbering and hence don't switch SPs (or do so in a manner that doesn't require renumbering). In any case, renumbering already applies in those SOHO like contexts today with IPv4 and I see no difference in this context. Big sites use PI space or maybe ULAs. Some SME-like enterprises are likely happy enough with their PA space and don't renumber frequently. > 4. Even if the pain were only to double, that's not within our remit. > Our goal must be to fix this problem in our own > backyards, without unduly burdening the multihoming customer base. As already discussed, there's already pain somewhere else. Currently some folks are pushing their pain to the routing system. Shim6 is trying to help a subset of multihomers by offering another choice. Whichever approach is chosen by the site is mostly up to the site. Maybe you missed the news that SHIM6 doesn't solve -- and isn't intended to solve -- every site's multihoming problems. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:29:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2837-0006np-Eu; Wed, 03 Jan 2007 10:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2836-0006f9-6f for ram@iab.org; Wed, 03 Jan 2007 10:29:04 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2834-0006pf-UW for ram@iab.org; Wed, 03 Jan 2007 10:29:04 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 07:29:03 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="49909461:sNHT45553520" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03FT2lG003376 for ; Wed, 3 Jan 2007 10:29:02 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03FT27f026131 for ; Wed, 3 Jan 2007 10:29:02 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 07:29:00 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1361; t=1167838142; x=1168702142; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=eLLUC9f/V44LSZHTQ8g47hd+La2WSUN2p+DmrGBNPIw=; b=iuLbPELx188Aqa/XK6MQgTEhysfx5FLe/S6w+C+Al2/GDMUl+x9DLGzUL0udY5EvVLFjJK6r yZqSBlQQwDEATCjiXV5/PVBM/9Jo1BGEmZ55O5JSURqiIPAM/8hFADnR; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 7:20 AM, Ralph Droms wrote: > Roland - are you supposing that multiplying the number of addresses > managed > in network elements by n (where n is a small integer) might start > to exceed > some internal limits in the network elements. Are customers going > to have > to come back to us (Cisco) for more memory? Yes, for all vendors. Memory, TCAM capacity for processing of ACLs in hardware, whatever. In many cases, things which aren't field- upgradable except via forklift. > Or is it an administrative > headache that could be managed with better NM tools? Yes, but since there aren't adequate NM tools for the numbers of ACLs/ firewall rules/QoS policies/etc. we have today, it's hard to extrapolate that those tools will sprint into existence tomorrow which will help solve this problem for even larger numbers of those things, either, heh. With SHIM6, CAPEX, OPEX, and complexity costs (along with loss of TE capabilities) are simply shifted from SPs to their multihomed enterprise customers. It is not a real solution, and enterprises won't go for it because of these reasons. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:33:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H286w-0001SI-A0; Wed, 03 Jan 2007 10:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H286v-0001SD-3Z for ram@iab.org; Wed, 03 Jan 2007 10:33:01 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H286p-0000XG-SK for ram@iab.org; Wed, 03 Jan 2007 10:33:01 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 7520834097; Wed, 3 Jan 2007 10:32:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 10:32:55 -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: one size doesn' fit all (was Re: other requirement? (was Re:[RAM]Traffic Engineering Date: Wed, 3 Jan 2007 10:32:53 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FD7DC@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one size doesn' fit all (was Re: other requirement? (was Re:[RAM]Traffic Engineering Thread-Index: AccvSpiHoka+flBXQu6GMwYAUtvL9QAAdQAw From: "Bound, Jim" To: "Roland Dobbins" , X-OriginalArrivalTime: 03 Jan 2007 15:32:55.0184 (UTC) FILETIME=[7052C100:01C72F4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks /jim=20 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > Sent: Wednesday, January 03, 2007 10:19 AM > To: ram@iab.org > Subject: Re: one size doesn' fit all (was Re: other=20 > requirement? (was Re:[RAM]Traffic Engineering >=20 >=20 > On Jan 3, 2007, at 7:17 AM, Bound, Jim wrote: >=20 > > Your not arguing that hosts should only have one set of=20 > locators are=20 > > you? >=20 > No - just one set of 'things which must go into ACLs,=20 > firewall rules, QoS policies', etc. >=20 > -------------------------------------------------------------- > --------- > Roland Dobbins // 408.527.6376 voice >=20 > All battles are perpetual. >=20 > -- Milton Friedman >=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:34:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H288U-00021M-7w; Wed, 03 Jan 2007 10:34:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H288S-00020M-KJ for ram@iab.org; Wed, 03 Jan 2007 10:34:36 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H288R-0001QW-8T for ram@iab.org; Wed, 03 Jan 2007 10:34:36 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l03FYToF007965; Wed, 3 Jan 2007 07:34:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l03FYSYS007960; Wed, 3 Jan 2007 07:34:28 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 3 Jan 2007 07:34:28 -0800 From: David Meyer To: "Chris L. Morrow" Subject: Re: [RAM] Terminology: Routing Entropy Message-ID: <20070103153425.GA6947@1-4-5.net> References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@1-4-5.net> 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: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0270724159==" Errors-To: ram-bounces@iab.org --===============0270724159== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 30, 2006 at 03:16:49AM +0000, Chris L. Morrow wrote: >=20 >=20 > On Fri, 29 Dec 2006, David Meyer wrote: > > > > Now, at the very least, such a result would be useful in > > thinking about the burstiness of the Internet's UPDATE > > stream, and corresponding architecture/protocol > > mechanisms that might be used to control that burstiness > > (if indeed that is an issue; intuitively the burstiness > > of the UPDATE stream "seems" problematic, but I think > > we'd all like to have a better, more quantative > > understanding of what's really going on). >=20 > I'd like to see if there is a dampening effect in the burstiness as well, > is viewing the overall change rate/state from route-views better or worse > than a single edge device with a misbehaving customer set?=20 Not sure. I want to see if we have appropriate data sets (given our "passive instrument"). There are all kinds of issues with the data we have/collect, but I'm at a somewhat more primitive state (in my thinking, anyway): I just want to understand if such a study is feasible given the data we have. If so, then we'll need to study the biases in our various data sets too. > Ho w much information is damped out before it exists that ASN? > (some of this is surely dependent upon the specific > configurations, but this gets back to 'the DFZ' is not the most > hurtful number, the core/internal routetable(s) are hurting > providers even more than the public view of things).=20 Again, not sure. But your point is well taken. And as I said earlier, I'm not sure what data would be best for such a study, and the data sets we do have a (inherently) biased, but the BGP data we have seems a reasonable place to start. --dmm --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFm80BORgD1qCZ2KcRArC+AJ9Yz7zdbwjHRVMfRoXF5nFR3GGZMQCdFsKc jV8lA11uYUyLFZIKCgs2bnQ= =8Bk3 -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- --===============0270724159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0270724159==-- From ram-bounces@iab.org Wed Jan 03 10:39:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28Cg-0003TK-7Z; Wed, 03 Jan 2007 10:38:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28Ce-0003Sk-Cx for ram@iab.org; Wed, 03 Jan 2007 10:38:56 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28Cd-0003zV-14 for ram@iab.org; Wed, 03 Jan 2007 10:38:56 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l03FcsaB008210; Wed, 3 Jan 2007 07:38:54 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l03Fcsu9008209; Wed, 3 Jan 2007 07:38:54 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 3 Jan 2007 07:38:54 -0800 From: David Meyer To: "Chris L. Morrow" Subject: Re: [RAM] Traffic Engineering Message-ID: <20070103153854.GB6947@1-4-5.net> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> <1C49B8A2-3F3D-40A5-916C-EDF429BB52F0@cisco.com> <400F21D4-E2A6-424F-B783-BD6F4F034C14@ndsu.edu> 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1327278146==" Errors-To: ram-bounces@iab.org --===============1327278146== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 30, 2006 at 04:14:23AM +0000, Chris L. Morrow wrote: >=20 > would it be possible to not have html email on this list? :) it's just > ugly and unnecessary. I would appreciate that as well. While I can get mutt to display html -- .muttrc: auto_view text/html application/x-X-sun-attachment=20 .mailcap: text/html; lynx -dump -force_html %s; \ needsterminal; copiousoutput;=20 its still not pretty. --dmm =09 --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFm84OORgD1qCZ2KcRAgXGAJ9MMZPKaD0C578JVJqKrtepj1BXCQCeN8OD /fRJvpuRPTvYgWiyRKXQ5SQ= =aZBB -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- --===============1327278146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1327278146==-- From ram-bounces@iab.org Wed Jan 03 10:42:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28G7-0005H6-Qf; Wed, 03 Jan 2007 10:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28G7-0005Gr-90 for ram@iab.org; Wed, 03 Jan 2007 10:42:31 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28G6-0005Ge-0u for ram@iab.org; Wed, 03 Jan 2007 10:42:31 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 07:42:30 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="49910801:sNHT45585228" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03FgTY2014663 for ; Wed, 3 Jan 2007 10:42:29 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03FgS2k013059 for ; Wed, 3 Jan 2007 10:42:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 07:42:26 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1817; t=1167838949; x=1168702949; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=idihR0hT6N12K+PmreyO95y6IOOfmsgnny33lgsk8EI=; b=PewvHkmJ/Zmew7hOOVSpRTSAjMAeUik8zXK+1IYq4ln09lBOBOM/6is30FKYGMWucuDHlkx6 sAHGwL1H2kZl4LQ1SkOJcddduh/qLdF1kwzlpwQl9KI3gq3o3iXcycWz; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 7:28 AM, Pekka Savola wrote: > Again, if we are talking about merely doubling the size, this is > not a concern. This mailing list would not have been set up if > folks were pissing their pants by the prospect of 400K routes (and > that's it) in their routers. Churn and 1M, 10M or 100M is more of > a corcern. Maybe it's not a concern for -you-. But we can't blithely say that it isn't a concern for others - quite the opposite, in fact. And as Ralph points out, this can end up being an n^2 problem quite easily. It's also important to remember that there's an OPEX/admin/helpdesk problem here, too. [ Some folks on this list have already gone through outages and hardware churn triggered when the global routing table exceeded 128K; they're not going to be pleased when they hit other limitations in other hardware from various vendors, either, at thresholds which are still lower than even 1M. ] As tli already pointed out, it's highly desirable to have a solution which works for all classes of sites, if size and internal complexity are the only differentiators we can identify. So far, no one's put forth any objective criteria upon which to predicate a split. The sudden tolerance for PI space gratifies/puzzles me, though - I thought it was anathema, and that folks here aren't't in the main amused that PI space is being allocated. If PI space is now tolerable, then we can all go home and call it a day, and wait on Moore's Law (along with open chequebooks) to save us. I doubt that's the case, though. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 10:52:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28Om-0001d1-Gp; Wed, 03 Jan 2007 10:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28Ol-0001ch-Lg for ram@iab.org; Wed, 03 Jan 2007 10:51:27 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28Ok-0007Ib-A5 for ram@iab.org; Wed, 03 Jan 2007 10:51:27 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l03FpPC3008446; Wed, 3 Jan 2007 07:51:25 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l03FpPXX008445; Wed, 3 Jan 2007 07:51:25 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 3 Jan 2007 07:51:25 -0800 From: David Meyer To: "Chris L. Morrow" Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070103155125.GC6947@1-4-5.net> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514795232==" Errors-To: ram-bounces@iab.org --===============0514795232== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris/all, > I think what's been said loudly and often by larger network operators and > content providers is that SHIM6 isn't solving the problem(s) they see, > it's not even attempting to address those problems. So, they require > something else to do multihoming, they also realize that that 'something > else' may require radical changes, and will have to scale to very large > numbers over the next 10-15 years. I think this is key. Namely, that shim6 is solving a different problem than what the backbone operators are seeing. Now, one can argue to what degree there is a different problem, and to what degree shim6 whould solve such a problem, but all of that is defocusing. So, here's proposal: =20 How about we just stipulate that shim6 (et al) doesn't address (nor solve) the problem set the backbone operators are dealing with, and move on.=20 =20 Why? Well, first, the IETF *is* developing SHIM6/HIP/..., and from all the evidence I can see, that will continue (no value judgement, just so that is clear). Second, what I'm hoping this activitiy leads to is a scalable routing (and addressing) system for the Internet (big I).=20 Note that such a system will might need to interact with whatever the hosts are doing in this domain (e.g., hip, shim6, maybe even things like softwires), hopefully in some aggregated way (if at all), and it would be reasonable to understand those interactions (if any) as part of any future architecture/design. =20 --dmm --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFm9D9ORgD1qCZ2KcRAr3OAJwLxS/tH3kTXkjqvoP+A8OKTqP6KQCePyLL t/uEhrjDYXMlHz+kwO9l6wM= =1xq/ -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- --===============0514795232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0514795232==-- From ram-bounces@iab.org Wed Jan 03 11:05:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28bg-0003zv-Uc; Wed, 03 Jan 2007 11:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28bf-0003yx-H3 for ram@iab.org; Wed, 03 Jan 2007 11:04:47 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28be-0003Vk-4M for ram@iab.org; Wed, 03 Jan 2007 11:04:47 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l03G4hCw008620; Wed, 3 Jan 2007 08:04:43 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l03G4hLU008619; Wed, 3 Jan 2007 08:04:43 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 3 Jan 2007 08:04:43 -0800 From: David Meyer To: Noel Chiappa Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070103160443.GE6947@1-4-5.net> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> 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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336724234==" Errors-To: ram-bounces@iab.org --===============1336724234== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="10jrOL3x2xqLmOsH" Content-Disposition: inline --10jrOL3x2xqLmOsH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 31, 2006 at 09:07:12AM -0500, Noel Chiappa wrote: > > From: "Spencer Dawkins" >=20 > > if path selection is under host control, >=20 > Multiple routing-names for a destination is not really general "path > selection"; it does provide a small amount of influence on the path a > packet takes, but that's a long way from general path control (a la > "source route" options, etc). This is one of the shim6 arguments I never did buy, for exactly the reasons you mention. Its more like "optimized" egress selection (where "egress" is egress from the site). > And as I just pointed out, while it does allow hosts at multi-homed sites > to select their link to a particular ISP, if the link to one ISP is down, > you'd *better* be able to select the link to another ISP.... I suppose there are corner cases in which you wouldn't want to do so (but it would seem that those would be infrequent). =20 > If people wanted (for a variety of reasons, which might include > management control, defense against crackers, etc) a solution where the > decision on "use ISP P, not ISP Q" was in the hands of some site-wide > networking agent, as opposed to being a per-host choice, people should > have gone for a solution which puts that choice in the border router (or > some other device with site-wide authority). Again, would seem so, for predictability/management reasons alone.=20 > However, I gather that class of solutions is somewhat constrained because > of TCP checksum issues; the border router can only do so much, unless the > host is in on it too. (Which is why GSE proposed to make the TCP checksum > cover only the ID half, but that horse is long-gone, alas...) Hence TLi's > comment about "too NAT-like", I suspect... Is it? Real question. Its not clear to me (yet) what the architectural design constraints we're working with here are. --dmm --10jrOL3x2xqLmOsH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFm9QbORgD1qCZ2KcRAktMAJ49TyuCfUWkrxGdwzcwI3UcvQB3JQCfakcZ cjIWzyG8QOoWlb3RB0VUerY= =wLjR -----END PGP SIGNATURE----- --10jrOL3x2xqLmOsH-- --===============1336724234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1336724234==-- From ram-bounces@iab.org Wed Jan 03 11:12:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28jH-0000OT-29; Wed, 03 Jan 2007 11:12:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28jG-0000Hv-1W for ram@iab.org; Wed, 03 Jan 2007 11:12:38 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28jE-0005aM-Oj for ram@iab.org; Wed, 03 Jan 2007 11:12:38 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 03 Jan 2007 08:12:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l03GCZ0b017865; Wed, 3 Jan 2007 08:12:35 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l03GCYUg020106; Wed, 3 Jan 2007 08:12:34 -0800 (PST) Received: from [212.254.247.5] ([10.61.66.90]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l03FtlqW031816; Wed, 3 Jan 2007 07:55:48 -0800 Message-ID: <459BD5EF.20708@cisco.com> Date: Wed, 03 Jan 2007 17:12:31 +0100 From: Eliot Lear User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1039; t=1167840755; x=1168704755; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=0A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=njohjBjG+D+xtzztnfbhlCBYspH1UgDWb3LuU/fjR6g=; b=j9A4QQHkbqO5U7YqqOkAtJ8xKXxW6QgcCNT3m0XuKEznrF4WueyDpgejvCz6T9e2q7RIhEaS BbzYyddXd/SzKnVTZnSuYOrCB8ET0LqOHtK0ZI2uAF01vMRBatSanCLG; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1039; t=1167839749; x=1168703749; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=0A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20Roland=20Dobbins=20; bh=njohjBjG+D+xtzztnfbhlCBYspH1UgDWb3LuU/fjR6g=; b=c2mhClET47T4JgJMosd9U9nW5ooPtGe6XyrvRAGDOIJ46Uj6coDU1G+IuGvpHhWu+L5uX7k4 AxWqzX8Sm8rTnd7bxDxGj9j7Iwx9ybd25paNYc7HR7wHGUsy0173Ey0K; Authentication-Results: sj-dkim-4; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Roland Dobbins wrote: > Yes, but since there aren't adequate NM tools for the numbers of > ACLs/firewall rules/QoS policies/etc. we have today, it's hard to > extrapolate that those tools will sprint into existence tomorrow which > will help solve this problem for even larger numbers of those things, > either, heh. > > With SHIM6, CAPEX, OPEX, and complexity costs (along with loss of TE > capabilities) are simply shifted from SPs to their multihomed > enterprise customers. It is not a real solution, and enterprises > won't go for it because of these reasons. Let me say this again: SHIM6 is NOT what will cause your TCAMs to explode in size. It is the act of multihoming itself and propagating a new prefix that does that. In fact WITHOUT multihoming multiple prefixes are likely to be propagated. In fact the problems that you mention exist in any circumstance in which a network will be renumbered. No one can reasonably expect to renumber anything beyond a SOHO network all at once. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 11:21:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28rG-0005EF-Gz; Wed, 03 Jan 2007 11:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28rF-0005EA-UH for ram@iab.org; Wed, 03 Jan 2007 11:20:53 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28rE-0007Xp-NJ for ram@iab.org; Wed, 03 Jan 2007 11:20:53 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2007 11:20:53 -0500 X-IronPort-AV: i="4.12,233,1165208400"; d="scan'208"; a="110792788:sNHT45387232" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03GKqae030810 for ; Wed, 3 Jan 2007 11:20:52 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03GKp7f010511 for ; Wed, 3 Jan 2007 11:20:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <459BD5EF.20708@cisco.com> References: <459BD5EF.20708@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <417F5C56-98D0-4A39-87FC-0DC0DF2F768E@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 08:20:50 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1609; t=1167841252; x=1168705252; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=BrFisK+4E0d5sXO5rl1XcWb6TR1hY2z78IKGmvJrKA8=; b=VyMeOwgnv4r+SSgr6SC3stUueahJjhH89+HhybUT7uANWeIfFCU/2fkq2SHSBFD4EoBa/zsn /wl2+AZBYvzM2u1kEiHUDAUJh8dzgU4ddA3ibtIzTLqFBn8Vgr1PIVaP; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 8:12 AM, Eliot Lear wrote: > Let me say this again: SHIM6 is NOT what will cause your TCAMs to > explode in size. If we force enterprises to double/treble/n^2 the number of ACLs/ firewall rules/QoS policies they have, it will cause -their- TCAMs to explode, -their- memory to be exhausted, etc. If you don't believe me, we can sit down in a lab and push the maximum number of ACL entries into any platform/linecard you like, and then we can shove enough additional ACEs into it that it either a) starts software-switching or b) somewhat non-deterministically decides which entries to shove out in order to make room for the new ones. I've experienced both in production networks, and wasn't amused - and that's without SHIM6. This isn't a Cisco-specific issue; all hardware has limitations of one type or another, at one scaling-factor or another, no one's hardware has infinite capacity for -anything-, including ACEs/ firewall rules/QoS policies/etc. The focus on IPv6 multihoming has been pretty much exclusively on the hardware costs an exploding routing table would impose upon SPs; my point is that SHIM6 simply shifts those costs, with a bit of transmutation, onto the bank accounts of enterprises. And everyone's support-desk costs will go up due to the additional complexity, in addition to all the other issues. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 11:24:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28ua-0007RZ-GZ; Wed, 03 Jan 2007 11:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28uY-0007RU-Pg for ram@iab.org; Wed, 03 Jan 2007 11:24:18 -0500 Received: from web58707.mail.re1.yahoo.com ([66.196.100.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H28uX-0008Uz-Cu for ram@iab.org; Wed, 03 Jan 2007 11:24:18 -0500 Received: (qmail 98195 invoked by uid 60001); 3 Jan 2007 16:24:12 -0000 Message-ID: <20070103162412.98193.qmail@web58707.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=aqnoK+7UxztPqT54An7OZakOUPPtKKTZzx3E229FkN4NF1WJxesBLLbb5ww3UqtX9R5SQnE67tnSxSFDlYhnKpWis4FWWW31C0KUaBJqlr8IdgGrKkuJNtSLwVU9Qz9LNHFrXsjPGSMftRGPR4/nGR42usoS6+QVpcEOOpF5Xs8=; X-YMail-OSG: OeOjOJMVM1mq20yNRVmzTKGqbigzU9nijcA2kxmssY0_Qg5VYtHwK.76Yn8XP7DdlkUpm7GN5i2WaJ5DupaulF05WaWSnOP9Gku1HnNSrrU6Q0pLbI0pkkipe0rhCPe40hKZClg0u8dI0Q-- Received: from [207.107.50.100] by web58707.mail.re1.yahoo.com via HTTP; Wed, 03 Jan 2007 08:24:11 PST Date: Wed, 3 Jan 2007 08:24:11 -0800 (PST) From: Peter Sherbin Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering To: Roland Dobbins , ram@iab.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > The sudden tolerance for PI space gratifies/puzzles me Is there anything fundamentally wrong with AS hierarchy edged by PoPs/APs(wired/wireless) where ASN is added to a source PI address for global routing? Thanks, Peter --- Roland Dobbins wrote: > > On Jan 3, 2007, at 7:28 AM, Pekka Savola wrote: > > > Again, if we are talking about merely doubling the size, this is > > not a concern. This mailing list would not have been set up if > > folks were pissing their pants by the prospect of 400K routes (and > > that's it) in their routers. Churn and 1M, 10M or 100M is more of > > a corcern. > > Maybe it's not a concern for -you-. But we can't blithely say that > it isn't a concern for others - quite the opposite, in fact. And as > Ralph points out, this can end up being an n^2 problem quite easily. > It's also important to remember that there's an OPEX/admin/helpdesk > problem here, too. > > [ Some folks on this list have already gone through outages and > hardware churn triggered when the global routing table exceeded 128K; > they're not going to be pleased when they hit other limitations in > other hardware from various vendors, either, at thresholds which are > still lower than even 1M. ] > > As tli already pointed out, it's highly desirable to have a solution > which works for all classes of sites, if size and internal complexity > are the only differentiators we can identify. So far, no one's put > forth any objective criteria upon which to predicate a split. > > The sudden tolerance for PI space gratifies/puzzles me, though - I > thought it was anathema, and that folks here aren't't in the main > amused that PI space is being allocated. If PI space is now > tolerable, then we can all go home and call it a day, and wait on > Moore's Law (along with open chequebooks) to save us. I doubt that's > the case, though. > > ----------------------------------------------------------------------- > Roland Dobbins // 408.527.6376 voice > > All battles are perpetual. > > -- Milton Friedman > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 11:46:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Ff-0002Ak-E0; Wed, 03 Jan 2007 11:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Fd-0002AD-FY for ram@iab.org; Wed, 03 Jan 2007 11:46:05 -0500 Received: from ronin.4ever.de ([195.34.187.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29Fc-00057k-7X for ram@iab.org; Wed, 03 Jan 2007 11:46:05 -0500 Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1H29FY-000Ci6-Mu for ram@iab.org; Wed, 03 Jan 2007 17:46:00 +0100 Date: Wed, 3 Jan 2007 17:46:00 +0100 From: "Elmar K. Bins" To: ram@iab.org Subject: Re: [RAM] Destination Locator selection Message-ID: <20070103164600.GT23876@ronin.4ever.de> References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> <20070103133427.GQ23876@ronin.4ever.de> <1167832496.25062.60.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167832496.25062.60.camel@localhost.localdomain> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org heldal@eml.cc (Per Heldal) wrote: > Implementation-details like choice of protocol for > such have not yet been discussed. Then I need to ask back: Why write "DNS" in the first place? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 11:53:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Ln-0005sO-AN; Wed, 03 Jan 2007 11:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Ll-0005s7-MY for ram@iab.org; Wed, 03 Jan 2007 11:52:25 -0500 Received: from ronin.4ever.de ([195.34.187.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29Lj-00068G-VG for ram@iab.org; Wed, 03 Jan 2007 11:52:25 -0500 Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1H29Lh-000Czy-8I for ram@iab.org; Wed, 03 Jan 2007 17:52:21 +0100 Date: Wed, 3 Jan 2007 17:52:21 +0100 From: "Elmar K. Bins" To: ram@iab.org Subject: Re: [RAM] Destination Locator selection Message-ID: <20070103165221.GU23876@ronin.4ever.de> References: <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> <1167823456.25062.14.camel@localhost.localdomain> <20070103113054.GM23876@ronin.4ever.de> <1167824915.25062.35.camel@localhost.localdomain> <20070103133427.GQ23876@ronin.4ever.de> <1167832496.25062.60.camel@localhost.localdomain> <20070103164600.GT23876@ronin.4ever.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070103164600.GT23876@ronin.4ever.de> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org elmi@4ever.de (Elmar K. Bins) wrote: > heldal@eml.cc (Per Heldal) wrote: > > > Implementation-details like choice of protocol for > > such have not yet been discussed. > > Then I need to ask back: Why write "DNS" in the first place? Alright, scrap that. Let's get back to architecture :) Elmar. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 12:12:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29eu-0000mM-4r; Wed, 03 Jan 2007 12:12:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29er-0000kU-Rg for ram@iab.org; Wed, 03 Jan 2007 12:12:09 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29eq-0001tz-MP for ram@iab.org; Wed, 03 Jan 2007 12:12:09 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 37CA686ADB; Wed, 3 Jan 2007 12:12:06 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20070103171206.37CA686ADB@mercury.lcs.mit.edu> Date: Wed, 3 Jan 2007 12:12:06 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: David Meyer > Its not clear to me (yet) what the architectural design constraints > we're working with here are. Sadly, I suspect the engineering constaints (from legacy/interoperability/etc) are likely to be far more significant than architectural ones... :-( Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 12:39:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2A54-0006l2-T9; Wed, 03 Jan 2007 12:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2A52-0006jl-Vy for ram@iab.org; Wed, 03 Jan 2007 12:39:12 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2A50-0006g3-KN for ram@iab.org; Wed, 03 Jan 2007 12:39:12 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l03Hcr6l009067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2007 09:38:58 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l03Hcqdp017261; Wed, 3 Jan 2007 09:38:52 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l03HcoKg017181; Wed, 3 Jan 2007 09:38:52 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 09:38:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] aside Re: HIP Date: Wed, 3 Jan 2007 09:38:12 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2FAB9@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <6CD3B854-F172-4408-AC73-8DF6D4C47240@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] aside Re: HIP Thread-Index: Accuu4gVbVpZTcDDS6+sHTnwZxFt4gAnXdRA From: "Henderson, Thomas R" To: "RJ Atkinson" , X-OriginalArrivalTime: 03 Jan 2007 17:38:45.0762 (UTC) FILETIME=[04D18620:01C72F5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com]=20 > Sent: Tuesday, January 02, 2007 2:15 PM > To: ram@iab.org > Subject: [RAM] aside Re: HIP >=20 >=20 > I think HIP is really great research. I am not quite > as enthusiastic about HIP as an operational solution. >=20 > My main concern is that with HIP, when one's public key > is compromised (and, yes, that is always a WHEN, not an IF), > one always necessarily loses one's Identifier. This seems > pretty undesirable to me. >=20 > HIP-like solutions that don't have issues of that sort > are pretty different from any of the currently available HIP > specifications. Yes, the HIP authors/editors left the door open > a crack, but AFAIK there isn't any proposal for how to make an =20 > Identifier > workable if the Identifier is not derived from one's public key. Ram, Is your concern that HIP has not explicitly considered what to do when an identifier is compromised, or that solutions that actually do adequately treat situations for which an identifier is compromised are necessarily much different from HIP design? If the latter, can you provide a pointer? What do you view as the operational requirements on the security and permanence of a network-level identifier? Note that there have been differing views on this; for instance, the identifiers could be transient and anonymous, or semi-permanent and public, or even securing the channel bindings for higher-layer protocol security. Each of these use cases has different operational implications for how seriously to protect the identifier from compromise and undo the damage when compromised. To this point, HIP has deliberately avoided choosing one of the above use cases, and may be why these solutions are underdeveloped for HIP. >=20 > Also, for moderate threat environments, I think all the > HIP cryptography is overkill and computationally expensive. I'd > prefer to have the option for a less computationally intense and > less comprehensive security mechanism for moderate threat=20 > environments. > (Something that merely prevented off-path attacks seems possible > to me and might be interesting to have as a deployment option.) >=20 Pekka made reference to lightweight HIP using hash chains; although I can't find the thesis, there is an expired internet draft with earlier work: http://tools.ietf.org/html/draft-nikander-multi6-hip-01=20 which referenced the WIMP-F hash chain proposal for multi6: http://tools.ietf.org/html/draft-ylitalo-multi6-wimp-01 Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 13:32:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Aua-0001k7-Lz; Wed, 03 Jan 2007 13:32:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2AuZ-0001k2-Le for ram@iab.org; Wed, 03 Jan 2007 13:32:27 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2AuY-00079Z-8l for ram@iab.org; Wed, 03 Jan 2007 13:32:27 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id l03IVIkM008719; Wed, 3 Jan 2007 18:31:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id l03IVHAe008718; Wed, 3 Jan 2007 18:31:17 GMT Date: Wed, 3 Jan 2007 18:31:17 +0000 From: bmanning@karoshi.com To: Noel Chiappa Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070103183117.GA8627@vacation.karoshi.com.> References: <20070103171206.37CA686ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070103171206.37CA686ADB@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, Jan 03, 2007 at 12:12:06PM -0500, Noel Chiappa wrote: > > From: David Meyer > > > Its not clear to me (yet) what the architectural design constraints > > we're working with here are. > > Sadly, I suspect the engineering constaints (from legacy/interoperability/etc) > are likely to be far more significant than architectural ones... :-( > > Noel lessons from NIMROD aside, what would you do TODAY, knowing what we know about the existing systems, the scalability properties and projected growth/traffic patterns? Radia and others have recently been dabbling w/ the ideas of grafting some of the old bridging/arp techniques into the routing system. Such a thing might be very useful, esp if one wants to do things like make multicast a first-class player - presuming flooding techniques. And _IF_ those kinds of assumptions hold, then existing/legacy/interop considerations maybe less important. YMMV of course. Strawpoll... What percentage of IP process stacks will be "untethered", mobile, and only "on" for a percentage of their lifespan in 10, 15, 20 years? What percentage will be fixed, tethered, and always on for a percentage of their lifetime in the next 10, 15, 20 years? --bill _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 14:12:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BXC-0008Ef-Au; Wed, 03 Jan 2007 14:12:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BXB-0008Ea-LN for ram@iab.org; Wed, 03 Jan 2007 14:12:21 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2BXA-0004Mr-AW for ram@iab.org; Wed, 03 Jan 2007 14:12:21 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l03JCBPX021401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 3 Jan 2007 13:12:14 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 13:12:10 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 8:41 AM, Pekka Savola wrote: > > > But I have difficulty seeing why a model with multiple addresses > would be _signficantly_ worse than the current one. Aren't we just > talking about (roughly) two times the number of ACL entries, > firewall rules, QoS entries, etc.. Doubling (at most: in many > cases both would be updated at the same time, reducing the burden) > an effort is still in the same order of magnitude. In the end, > this might even encourage better automation of places where IP > addresses are managed so you might even save some time ;-) And might it be possible for a vendor to implement a macro or variable that is used in rules or ACLs to represent the multiple prefixes? If so the number of rules that humans must work with would not necessarily double. (But the equipment may still need to deal with double the memory etc.) --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 14:19:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bdn-0003ro-SO; Wed, 03 Jan 2007 14:19:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bdl-0003pz-TS for ram@iab.org; Wed, 03 Jan 2007 14:19:09 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Bdj-0005j1-Hf for ram@iab.org; Wed, 03 Jan 2007 14:19:09 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2007 14:19:07 -0500 X-IronPort-AV: i="4.12,233,1165208400"; d="scan'208"; a="110805910:sNHT44299756" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03JJ6Ue028381 for ; Wed, 3 Jan 2007 14:19:06 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03JJ67f022519 for ; Wed, 3 Jan 2007 14:19:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73F080A8-5D0A-4565-88F0-3CD332E43ABF@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 11:19:02 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1115; t=1167851946; x=1168715946; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=c/wYv7QDGGlL7NAwakTRqUIHKQ/DoU+QfsLulyHiI4U=; b=kHJQSf0+y/ObjdWmYiZeJQ2RS1aGlagnm1Iv6kyUiXCbGJvbqERMNXw0YcWdz+tqveqv11Ev 25c0lRmJ6Mw8C7hz0IrPXsXMlcQx2o8CeJP0wGg3b0YZ60J7AXu+FqcZ; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 11:12 AM, Bruce Curtis wrote: > If so the number of rules that humans must work with would not > necessarily double. (But the equipment may still need to deal with > double the memory etc.) The number of representational objects or attributes of said objects humans must account for would certainly double or treble or n^2 or what-have-you, and the equipment must have sufficient resources to handle the additional entries/representations, as you indicate. But this is an implementation issue which will vary from vendor to vendor, platform to platform. Not all vendors/platforms will have such capabilities, and the resource issue remains the same, so we really can't push a solution which imposes this kind of burden. That's OK, though, because it sounds as if some of the models folks are beginning to think about wouldn't impose this sort of burden. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice All battles are perpetual. -- Milton Friedman _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 14:19:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bdx-00043R-5D; Wed, 03 Jan 2007 14:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bdw-00041H-8U for ram@iab.org; Wed, 03 Jan 2007 14:19:20 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Bdv-0005kL-8K for ram@iab.org; Wed, 03 Jan 2007 14:19:20 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l03JJIQw022412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 3 Jan 2007 13:19:18 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Destination Locator selection Date: Wed, 3 Jan 2007 13:19:17 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 2, 2007, at 8:22 PM, David Conrad wrote: > > Generalizing a bit, one could imagine layering IP headers with the > lowest layer corresponding to end point identification and > subsequent higher layers corresponding to traffic engineering > dictated network topology location. At each network attachment > 'edge' the packet traverses, a new layer could be added to > determine where the packet should go, e.g. (looking at a packet in > the middle of a transit AS): > > [src: A'', dst: B''=lookup(ISP_TE_MAP,B')] > [src: A', dst: B'=lookup(GLOBAL_MAP,B)] > [src: A, dst: B] > [payload] > > where: > > A is the source endpoint identifier > B is the destination endpoint identifier > A' is the globally unique locator by which you reach A > B' is the globally unique locator by which you reach B > A'' is the ISP-specific locator used to direct traffic to the > appropriate destination to reach A' within the ISP's network > B'' is the ISP-specific locator used to direct traffic to the > appropriate destination to reach B' within the ISP's network > > This sort of scheme gives you the ability to do arbitrary traffic > engineering, have multi-homing, renumbering (in the sense of > changing your location in the network topology), and mobility (if > the tables can be updated fast enough and/or you have some sort of > forwarding mechanism), but obviously it needs a mapping mechanism. Do you envision the lookup and mapping happening at only the first ISP in the path between endpoints or potentially at every interface between multiple ISPs in the path? --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 03 16:35:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DlA-0006YI-QA; Wed, 03 Jan 2007 16:34:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Dl7-0006Xt-Cp for ram@iab.org; Wed, 03 Jan 2007 16:34:53 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Dl6-0004nO-1i for ram@iab.org; Wed, 03 Jan 2007 16:34:53 -0500 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id z.cd5.4e4529d (57293); Wed, 3 Jan 2007 16:34:31 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Wed, 3 Jan 2007 16:34:28 EST Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering To: dmm@1-4-5.net, christopher.morrow@verizonbusiness.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0633427368==" Errors-To: ram-bounces@iab.org --===============0633427368== Content-Type: multipart/alternative; boundary="-----------------------------1167860068" -------------------------------1167860068 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In response to the email below: =20 I think, developing a new routing model for 'internet-2" would be an=20 exciting task. There is no reason to be pessimistic. Look, for comparison, the traveling =20 salesman problem has been known as one of the NP-hardest problems. But, last= =20 October some guys came up with a respective solution which infers: P =3D NP=20= !!! So, don't worry, progress is all around. =20 Heiner =20 =20 =20 =20 =20 =20 In einer eMail vom 03.01.2007 16:51:55 Westeurop=E4ische Normalzeit schreibt= =20 dmm@1-4-5.net: > I think what's been said loudly and often by larger network operators an= d > content providers is that SHIM6 isn't solving the problem(s) they see, > it's not even attempting to address those problems. So, they require > something else to do multihoming, they also realize that that 'something > else' may require radical changes, and will have to scale to very large > numbers over the next 10-15 years. I think this is key. Namely, that shim6 is solving a different problem than what the backbone operators are seeing. Now, one can argue to what degree there is a different problem, and to what degree shim6 whould solve such a problem, but all of that is defocusing. So, here's proposal: =20 How about we just stipulate that shim6 (et al) doesn't address (nor solve) the problem set the backbone operators are dealing with, and move on.=20 Why? Well, first, the IETF *is* developing SHIM6/HIP/..., and from all the evidence I can see, that will continue (no value judgement, just so that is clear). Second, what I'm hoping this activitiy leads to is a scalable routing (and addressing) system for the Internet (big I). =20 Note that such a system will might need to interact with whatever the hosts are doing in this domain (e.g., hip, shim6, maybe even things like softwires), hopefully in some aggregated way (if at all), and it would be reasonable to understand those interactions (if any) as part of any future architecture/design. =20 --dmm _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -------------------------------1167860068 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In response to the email below:
 
I think, developing a new  routing model for 'internet-2" wou= ld=20 be an exciting task.
There is no reason to be pessimistic. Look, for comparison, the traveli= ng=20 salesman problem has been known as one of the NP-hardest problems. But, last= =20 October some guys came up with a respective solution which infers: P =3D NP=20 !!!
So, don't worry, progress is all around.
 
Heiner
 
 
 
 
 
 
In einer eMail vom 03.01.2007 16:51:55 Westeurop=E4ische Normalzeit sch= reibt=20 dmm@1-4-5.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>> I=20 think what's been said loudly and often by larger network operators=20 and
> content providers is that SHIM6 isn't solving the problem(s) t= hey=20 see,
> it's not even attempting to address those problems. So, they=20 require
> something else to do multihoming, they also realize that t= hat=20 'something
> else' may require radical changes, and will have to sca= le=20 to very large
> numbers over the next 10-15 years.

  &nb= sp;=20 I think this is key. Namely, that shim6 is solving a
   =20 different problem than what the backbone operators are
   =20 seeing. Now, one can argue to what degree there is a
   =20 different problem, and to what degree shim6 whould solve
   =20= such=20 a problem, but all of that is defocusing. So, here's
   =20 proposal: 

    How about we just stipulate that shi= m6=20 (et al) doesn't
    address (nor solve) the problem set the=20 backbone
    operators are dealing with, and move on.
&nb= sp;=20  
    Why? Well, first, the IETF *is* developing=20 SHIM6/HIP/...,
    and from all the evidence I can see, that=20= will=20 continue
    (no value judgement, just so that is clear). Sec= ond,=20 what
    I'm hoping this activitiy leads to is a scalable=20 routing
    (and addressing) system for the Internet (big I).= =20

    Note that such a system will might need to interact=20 with
    whatever the hosts are doing in this domain (e.g.,=20 hip,
    shim6, maybe even things like softwires), hopefully=20 in
    some aggregated way (if at all), and it would be
&n= bsp;=20   reasonable to understand those interactions (if any) as
 =20   part of any future architecture/design. 

   = =20 --dmm


_______________________________________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1167860068-- --===============0633427368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0633427368==-- From ram-bounces@iab.org Wed Jan 03 22:12:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2J0q-00014u-A8; Wed, 03 Jan 2007 22:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2J0o-00014p-PQ for ram@iab.org; Wed, 03 Jan 2007 22:11:26 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2J0n-00084x-2N for ram@iab.org; Wed, 03 Jan 2007 22:11:26 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id QAA28981; Thu, 4 Jan 2007 16:11:08 +1300 In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC011FCFEB@tayexc14.americas.cpqcorp.net> <19FCC19F-E001-46A6-A13B-0AEC5C0F811C@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <94E5A394-CE8E-4FB0-80A0-7CDDC0DF5114@indranet.co.nz> Content-Transfer-Encoding: quoted-printable From: Andrew McGregor Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 16:11:27 +1300 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "Bound, Jim" , Noel Chiappa , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Actually, transfer to subsequent paths does give middleboxes on the =20 new path a chance to learn identifiers, because the necessary =20 information is carried in the packets used for the return-routability =20= check. Andrew On 03/01/2007, at 5:01 AM, marcelo bagnulo braun wrote: > Yes, i think we can learn from the HIP work on firewall traversal. =20= > AFAIK, the middle box keeps track of the HIP base exchange, and =20 > then it learns what identifiers match to following data packets, =20 > right? > So, you can do filtering based on HITs, but you need to allow the =20 > middle box to keep track of the hip base exchange and you need to =20 > distribute that information through all potentail middel boxes that =20= > following packets can traverse (due to a path change) > > I think hip work has done the first thing (allow middle boxes to =20 > keep track of the hip base exchange) but not the second one (deal =20 > with path changes), right? > in any case, i think their experience is very useful to have a =20 > fleshed example of how to do this and the complexity involved =20 > (which is one of the prices to pay to allow portability based on PI =20= > identifiers) > > Regards, marcelo > > > El 02/01/2007, a las 6:55, Andrew McGregor escribi=F3: > >> That middleboxes should be able to determine the identifiers in =20 >> use was a design decision in HIP; perhaps unfortunately, they're =20 >> compressed into an SPI, so the middlebox does have to keep state =20 >> to do it. The state is just a binding between identifier, known =20 >> locators and SPIs, however, and the protocol is designed to make =20 >> it fairly convenient and secure (in the sense that spoofing is =20 >> extremely difficult) for a middlebox to maintain that. >> >> Andrew >> >> On 02/01/2007, at 3:58 AM, Bound, Jim wrote: >> >>> >>>>> It is not trusting the routing system but the entire notion of the >>>>> network security system using Intrusion Detection. IMHO it is >>>>> un-necessary to secure the identifiers (whether transport >>>> or routing >>>>> name space in the model emerging here) cryptographically >>>> (and I do not >>>>> believe it will ever scale from engineering view point). =20 >>>>> Access to >>>>> the identifiers is what must be secured and then if they change as >>>>> stated above. Anything else is overhead. >>>>> >>>> >>>> exactly, hence, it is not obvious to me if we can assume that >>>> a middle box will be able to even see the identifier in order >>>> to use them in filters and ACLs, right? >>> >>> Thats my assumption today and has to be for end-to-end encryption =20= >>> of the >>> IP layer or the transport layer. There are products that perform =20= >>> what >>> is called deep packet inspection (DPI), far beyond what traditional >>> routers are capable of today in their fast path, on the market =20 >>> today and >>> could with security offload processers perform a decrypt and re-=20 >>> encrypt >>> at the edge and maintain line rates, thus that is an option in the >>> market but not our concern as the IETF SDO working on this new >>> architecture. >>> >>> /jim >>> >>> _______________________________________________ >>> RAM mailing list >>> RAM@iab.org >>> https://www1.ietf.org/mailman/listinfo/ram >>> >> > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 04:28:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ot5-0004hS-UG; Thu, 04 Jan 2007 04:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ot5-0004gy-7U for ram@iab.org; Thu, 04 Jan 2007 04:27:51 -0500 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Ot3-00006F-N8 for ram@iab.org; Thu, 04 Jan 2007 04:27:51 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBC7M901.12M; Thu, 4 Jan 2007 10:27:45 +0100 In-Reply-To: X-Priority: 1 (High) Subject: Re: [RAM] Destination Locator selection To: Bruce Curtis , David Conrad X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 4 Jan 2007 10:27:41 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 04/01/2007 10:26:40 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org You may be interested in reading my proposal on "Tunneled Intedomain Routing" (TIDR), in which I proposed a way to map identifiers to interdomain locators by means of a new transitive BGP attribute that I've called LOCATOR: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg13203.htm= l The mapping can happen in the first ISP and also in the core, using a hierarchy of locators. Regards, Juanjo Bruce Curtis escribi=F3 el 03/01/2007 20:19:17:= > > On Jan 2, 2007, at 8:22 PM, David Conrad wrote: > > > > > Generalizing a bit, one could imagine layering IP headers with the > > lowest layer corresponding to end point identification and > > subsequent higher layers corresponding to traffic engineering > > dictated network topology location. At each network attachment > > 'edge' the packet traverses, a new layer could be added to > > determine where the packet should go, e.g. (looking at a packet in > > the middle of a transit AS): > > > > [src: A'', dst: B''=3Dlookup(ISP_TE_MAP,B')] > > [src: A', dst: B'=3Dlookup(GLOBAL_MAP,B)] > > [src: A, dst: B] > > [payload] > > > > where: > > > > A is the source endpoint identifier > > B is the destination endpoint identifier > > A' is the globally unique locator by which you reach A > > B' is the globally unique locator by which you reach B > > A'' is the ISP-specific locator used to direct traffic to the > > appropriate destination to reach A' within the ISP's network > > B'' is the ISP-specific locator used to direct traffic to the > > appropriate destination to reach B' within the ISP's network > > > > This sort of scheme gives you the ability to do arbitrary traffic > > engineering, have multi-homing, renumbering (in the sense of > > changing your location in the network topology), and mobility (if > > the tables can be updated fast enough and/or you have some sort of > > forwarding mechanism), but obviously it needs a mapping mechanism. > > Do you envision the lookup and mapping happening at only the first= > ISP in the path between endpoints or potentially at every interface > between multiple ISPs in the path? > > --- > Bruce Curtis bruce.curtis@ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 08:24:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SZm-0008Pp-7d; Thu, 04 Jan 2007 08:24:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2SZl-0008Pj-GB for ram@iab.org; Thu, 04 Jan 2007 08:24:09 -0500 Received: from xmail09.myhosting.com ([168.144.250.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2SZk-0002ye-6S for ram@iab.org; Thu, 04 Jan 2007 08:24:09 -0500 Received: (qmail 22313 invoked from network); 4 Jan 2007 13:24:01 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with SMTP for ; 4 Jan 2007 13:24:01 -0000 Message-ID: <459CFFE8.8090909@cisco.com> Date: Thu, 04 Jan 2007 08:23:52 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JUAN-JOSE.ADAN@giss.seg-social.es Subject: Re: [RAM] Destination Locator selection References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > You may be interested in reading my proposal on "Tunneled Intedomain > Routing" (TIDR), in which I proposed a way to map identifiers to > interdomain locators by means of a new transitive BGP attribute that > I've called LOCATOR: > > http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg13203.html > > The mapping can happen in the first ISP and also in the core, using > a hierarchy of locators. I have a fundamental issue with overloading identifiers with locators.... While I know that's what we are doing today, it's really what started this whole problem, and I don't see where going farther down this road really solves anything. IMHO, TIDR will increase capex and opex problems, not solve them. I'll put it another way: To scale, you must hide information. This is a fundamental rule of all large complex systems. There are two ways to hide information: o Horizontal hierarchy, where you remove information at edges within the system, topologically, if we think of routing. For instance, in your car, your brake system is, pretty much, completely independent of your engine. Increasing complexity in the braking system increases the system complexity, but doesn't increase the complexity of the engine, generally speaking. This is the theory behind OSPF areas, for instance. o Vertical hierarchy, where you remove information at layer edges in the system. For instance, the IGP/EGP split is vertical hierarchy. Both of these have their problems, advantages, and disadvantages. Underusing either one can cause a total lack of scaling. Overusing either one can make the network completely unrepairable when it fails. We can shove the problem onto "tools" all we want to, but we need to be really careful before we shove too hard in that direction. Tools are most useful when humans can understand what the tool does, are simple, low cost, etc. Tools are not a panacea. IMHO, TIDR is an extreme case of vertical hierarchy, just as many other network virtualization schemes are. They look good on the map, as long as you think you're far enough away from the little sign that says: "Here be dragons." The question is, always, how far away is far enough away? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnP/oER27sUhU9OQRAlSUAJ47tEWh1MUY1c38pEOxszxSx+5IswCg7zEw sHrchBETPAWkIPPb1K5Qi6U= =wlVD -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 09:47:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Trb-0002pI-Av; Thu, 04 Jan 2007 09:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2TrZ-0002p8-UY for ram@iab.org; Thu, 04 Jan 2007 09:46:37 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2TrX-00009q-GF for ram@iab.org; Thu, 04 Jan 2007 09:46:37 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 86318CE769; Thu, 4 Jan 2007 15:46:34 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp02.uc3m.es (Postfix) with ESMTP id 41D62CE691; Thu, 4 Jan 2007 15:46:30 +0100 (CET) In-Reply-To: <81D1F978-B756-4CF2-B794-808202045901@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Wed, 3 Jan 2007 12:54:56 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 03/01/2007, a las 3:56, Tony Li escribi=F3: > >>> The enterprise folks who're the most skilled at enterprise=20 >>> networking are mainly in the financial services sector along some=20 >>> tech companies and military, IMHO; again, they have skilled folks,=20= >>> but not many of them, and they're looking for ways to avoid=20 >>> complexity if at all possible. >> >> agree but they are willing to deal with the complexity if that is=20 >> what it takes to tune their network wto make perform as they want=20 >> (clear example of this is BGP TE setups) agree? > > > Largely, no. It's an enormous burden on them. Keeping a firewall up=20= > and running is about the peak of enterprise expertise today. I think=20= > you're greatly overestimating what the average enterprise can and will=20= > be able to support. > every feedback i get seems to point in that direction.... So, are we concluding that any solution should work in any type of site=20= without requiring configuration from the user? this seems quite a tough=20= requirement to me... Regards, marcelo > Note that BGP TE is done mostly by ISPs today, not end user sites. =20 > There are, of course, exceptions, but they are very much in the noise. > > Tony > > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 09:58:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2U38-00015F-D4; Thu, 04 Jan 2007 09:58:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2U35-00014y-Qw for ram@iab.org; Thu, 04 Jan 2007 09:58:31 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2U33-0001el-Jx for ram@iab.org; Thu, 04 Jan 2007 09:58:31 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2007 09:58:29 -0500 X-IronPort-AV: i="4.12,238,1165208400"; d="scan'208"; a="110868867:sNHT44697276" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l04EwTjV004855 for ; Thu, 4 Jan 2007 09:58:29 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l04EwS2k018054 for ; Thu, 4 Jan 2007 09:58:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 06:58:28 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=832; t=1167922709; x=1168786709; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=Z7IunSeEcEgF9IsLlsD4jqjAjxj1t8roaqD+aitjLAs=; b=SRlOK/Wvz0kJqZMJyDQ54Ks7Umk792gEGwv80SsRgWx6DdU1QCTYNJvMmc8iwc372qXN7iQl PJVPwKNbWigfdx0YNJYHGptzerzjJJ9Q6QkqB9SNDVJAa2DILSUWpNyE; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 3:54 AM, marcelo bagnulo braun wrote: > So, are we concluding that any solution should work in any type of > site without requiring configuration from the user? this seems > quite a tough requirement to me... I wouldn't go that far, but it's important to understand that what to folks on this list may seem a reasonable amount of complexity in exchange for functionality may well prove an insurmountable obstacle for enterprises, even big, sophisticated ones. [ Perhaps the points made earlier about OPEX and supportability now make more sense in light of this feedback. ] ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 10:25:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2USx-0001iD-87; Thu, 04 Jan 2007 10:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2USv-0001cG-Mf for ram@iab.org; Thu, 04 Jan 2007 10:25:13 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2USu-0005Vf-9h for ram@iab.org; Thu, 04 Jan 2007 10:25:13 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l04FPAjH034566 for ; Thu, 4 Jan 2007 15:25:10 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l04FPAgR3141848 for ; Thu, 4 Jan 2007 16:25:10 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l04FPAMe013175 for ; Thu, 4 Jan 2007 16:25:10 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l04FP96d013162; Thu, 4 Jan 2007 16:25:09 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA279638; Thu, 4 Jan 2007 16:25:08 +0100 Message-ID: <459D1C54.4000603@zurich.ibm.com> Date: Thu, 04 Jan 2007 16:25:08 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Goal: Minimising Routing Entropy References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> In-Reply-To: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2006-12-29 15:42, RJ Atkinson wrote: > > I'd like to suggest that an architectural goal > for any new effort should be to reduce/minimise Routing > Entropy. My instinct is that this is a Good Thing, but my other concern is churn rates (which are obviously related to entropy among other things). I'd rather get a handle on the dynamics before being sure whether the target should be entropy itself or some aspect of the churn. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 10:28:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UWH-0002Y8-7O; Thu, 04 Jan 2007 10:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2UWF-0002Y3-At for ram@iab.org; Thu, 04 Jan 2007 10:28:39 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2UWC-00069O-Vr for ram@iab.org; Thu, 04 Jan 2007 10:28:39 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04FSadZ032529; Thu, 4 Jan 2007 07:28:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04FSaxa032528; Thu, 4 Jan 2007 07:28:36 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 07:28:36 -0800 From: David Meyer To: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070104152836.GA32409@1-4-5.net> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> Mime-Version: 1.0 In-Reply-To: <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864925106==" Errors-To: ram-bounces@iab.org --===============1864925106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > So, we come back to the question - besides scale and internal =20 > complexity, what's the difference? Is there some set of objective =20 > criteria we can come up with on which to predicate a split? So first, scale and internal (or other) complexity are intimately related. That being said, I'm really not sure what you mean by complexity, but what I can say is that if we build a system in which there are unbounded (e.g., non-linear) effects (say, in the UPDATE stream, as I've been wanting to understand), then we will find ourselves with a network that isn't robust to exactly those situations in which we need robustness.=20 Remember that there is a (heavy-tailed) relationship between robustness and complexity (some complexity is needed to achieve robustness), and and if one goes to far down the complexity line the results can be, well, just avoid fires in train tunnels containing lots of fiber and the like. --dmm --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnR0kORgD1qCZ2KcRAtliAJ9yiKzV6sUdqnyXvlt729FSPvowMwCfQTYs h5JaSLPE1U+ZEttss2gJt2g= =RJ/1 -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- --===============1864925106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1864925106==-- From ram-bounces@iab.org Thu Jan 04 10:40:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Uhh-0002q6-Px; Thu, 04 Jan 2007 10:40:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Uhf-0002oF-Tq for ram@iab.org; Thu, 04 Jan 2007 10:40:27 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Uhd-00087V-Mh for ram@iab.org; Thu, 04 Jan 2007 10:40:27 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04FeKCI001355; Thu, 4 Jan 2007 07:40:20 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04FeGFB001351; Thu, 4 Jan 2007 07:40:16 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 07:40:16 -0800 From: David Meyer To: Ted Seely Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070104154016.GB32409@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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899809136==" Errors-To: ram-bounces@iab.org --===============1899809136== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 02, 2007 at 02:06:09PM -0500, Ted Seely wrote: >=20 > Marcelo, >=20 > On Tue, 2 Jan 2007, marcelo bagnulo braun wrote: >=20 > > > > El 31/12/2006, a las 23:35, Roland Dobbins escribi=EF=BF=BD: > > > > > > > > On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote: > > > > > >> big sites have professional network admins that can configure complex > > >> protocols (e.g. bgp) Moreover, because of that they are likely to > > >> want some centralized way to enforce the configurations. > > > > > > One would think that larger enterprises would have these sorts of > > > folks available, but it isn't always true (not even predominantly > > > true, IMHO), and even when people with those skillsets are on staff, > > > there are generally only a few of them and this sort of thing may not > > > be their only responsibility, either. > > > > > > Larger enterprises typically do have configuration-management systems > > > of one sort or another, but (again, like most SPs), they're often > > > fairly basic systems in that they allow for automatic provisioning and > > > config versioning, but there's not a lot of logic present which > > > automates the development of the config itself, in most cases (this is > > > one of the main motivating factors behind the development of NETCONF). > > > One partial exception to this observation is in the generation of > > > ACLs, but the automation for most ACL-generation systems in use today > > > is limited and somewhat brittle, at best, and often does not take into > > > differences in platform capabilities/performance/resources. > > > > > > [ Come to think of it, this all sounds remarkably similar to a lot of > > > SPs, doesn't it? ;> ] > > > > > >> A home network does not have a network admin (ir the network admin > > >> is the user) and it is likely he is not able to do complex > > >> configurations. > > > > > > Most large enterprises don't handle complex configurations well, > > > either - see above. They often end up building unnecessarily complex > > > networks for various reasons, but that's not the same thing, heh. > > > > > > > ok, i think we may have different definitions of complex here... > > > > I have worked in network administration of two networks: > > - the postal service network , with several hundreds of network > > geographcially distributed. they do have a net amdin staff and while i > > agree they don't like complex setups, they are able of doing what i > > call quite complex stuff, as oposed to the other network that i reffer > > next... >=20 > undeniably a very valid example of a large organization that is able to > support a large and complex network. However, there is a distinct > difference in what commercial organizations can and want to support versus > government organizations. one gets paid for regardless (called taxes and > being able to print your own money :), the other has to stay in business > and fund its own. having done both in a previous life, it is a day and > night difference between the commercial sector and the government sector. > we have to keep in mind that the small to mid size company, which make up > the large majority of companies, do not have a lot of in house expertise, > nor are their networks a focus of their business. sorry to continue to > beat that horse. Well, that and the fact that just because you can build something doesn't make it a good idea (tm). The fact that one can build something is almost irrelevant; we're an industrious crew, and we build a lot of things.=20 Summary: The fact that one can build and/or deploy some isn't an indication that is a good idea [0].=20 --dmm [0] Where "good" might be scalable, efficient OPEX or CAPEX profile, reliable, ... --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnR/gORgD1qCZ2KcRAuvAAJ0aK9wlbnSeRk4SIB9U2OnkcNOduACdEYhh +EJ/BSnPURmNgNZ3J9/ux/Q= =c0Mr -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- --===============1899809136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1899809136==-- From ram-bounces@iab.org Thu Jan 04 11:07:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V6z-0005qs-F6; Thu, 04 Jan 2007 11:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2V6x-0005qj-PS for ram@iab.org; Thu, 04 Jan 2007 11:06:35 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2V6v-000671-DD for ram@iab.org; Thu, 04 Jan 2007 11:06:35 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l04G6UGu129836 for ; Thu, 4 Jan 2007 16:06:30 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l04G6Rkw1437834 for ; Thu, 4 Jan 2007 16:06:28 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l04G6P8W022679 for ; Thu, 4 Jan 2007 16:06:26 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l04G6PAD022668; Thu, 4 Jan 2007 16:06:25 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA110540; Thu, 4 Jan 2007 17:06:24 +0100 Message-ID: <459D2601.2020704@zurich.ibm.com> Date: Thu, 04 Jan 2007 17:06:25 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com><7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <06e001c72bac$bb7ab960$6a01a8c0@china.huawei.com> <45962265.2050308@piuha.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2006-12-30 13:46, Marshall Eubanks wrote: ... > > I too may be missing something, but isn't the idea behind SHIM6 is that > the host > is multi-homed ? It has locators in two or more domains, so it can > select paths. > So, in principle, a botnet operator could know what paths were possible. This is nothing to do with shim6. Any IPv6 host can have multiple addresses, and many do. Any IPv4 host can have multiple addresses, for that matter (my laptop appears to have three at the moment). I'm not sure what the new threat is... Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 11:13:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VDK-0007IA-RA; Thu, 04 Jan 2007 11:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VDK-0007I0-5k for ram@iab.org; Thu, 04 Jan 2007 11:13:10 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2VDI-0007SG-VT for ram@iab.org; Thu, 04 Jan 2007 11:13:10 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2007 08:13:09 -0800 X-IronPort-AV: i="4.12,239,1165219200"; d="scan'208"; a="49997691:sNHT43587968" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l04GD8L1004085 for ; Thu, 4 Jan 2007 11:13:08 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l04GD82k007642 for ; Thu, 4 Jan 2007 11:13:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <459D2601.2020704@zurich.ibm.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com><7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <06e001c72bac$bb7ab960$6a01a8c0@china.huawei.com> <45962265.2050308@piuha.net> <459D2601.2020704@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9955468F-A5A9-40CF-9D83-A7DB7B0A132D@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 08:13:08 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=915; t=1167927188; x=1168791188; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=ZyObe3Uu5tU+zoQg1aeXK1lHIZ/6UV16hOmIjiQ6u+k=; b=qxIikf0LbDLF/Kni5Hr4WhtUFdclL0A376tsPPY1K6+SSCjcJrEhyJPtVrlV9eJJHSb1cTgw 95n4SuQjDaUhDiblZzxK+8s6+59pPA0qvyHBCqOsZjuLCd5PzDalBST/; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 8:06 AM, Brian E Carpenter wrote: > This is nothing to do with shim6. Any IPv6 host can have multiple > addresses, and many do. Any IPv4 host can have multiple addresses, > for that matter (my laptop appears to have three at the moment). I'm > not sure what the new threat is... It has everything to do with SHIM6, because the vast majority of hosts in the world do not currently have multiple IP addresses which are in active use, and it is undesirable (for the many reasons previously outlined on these threads) to try and make multiple IP addresses with dynamic host selection of the initial path for egress traffic mandatory for multihomed sites. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 11:20:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VJa-0002Jb-9L; Thu, 04 Jan 2007 11:19:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VJZ-0002JP-Ce for ram@iab.org; Thu, 04 Jan 2007 11:19:37 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2VJY-0001A3-1U for ram@iab.org; Thu, 04 Jan 2007 11:19:37 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04GJR0N002580; Thu, 4 Jan 2007 08:19:27 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04GJNUB002579; Thu, 4 Jan 2007 08:19:23 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 08:19:23 -0800 From: David Meyer To: Tony Li Subject: Re: [RAM] Destination Locator selection Message-ID: <20070104161923.GC32409@1-4-5.net> References: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.com> Mime-Version: 1.0 In-Reply-To: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.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: cab78e1e39c4b328567edb48482b6a69 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884030388==" Errors-To: ram-bounces@iab.org --===============0884030388== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S1BNGpv0yoYahz37" Content-Disposition: inline --S1BNGpv0yoYahz37 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 02, 2007 at 02:16:45PM -0800, Tony Li wrote: >=20 > > Another, IMHO preferable, approach is to have the origin host > >put both source Locator and destination Locator into the packet, > >but do not make it illegal/impossible for some router along the > >path to re-write/modify either Locator iff that router really has > >enough knowledge to do so in some thoughtful way. Not all routers > >in the world might have enough knowledge to do so. Not all routers > >in the world might choose to do so. By having the origin host put > >in a valid destination Locator, but avoiding precluding routers along > >the path from applying better information, we can have the best of > >both worlds, IMHO. >=20 >=20 > Works for me. Understand the idea, but it seems possible that if you start telling a host its locator (without any kind of indirection), you are well on your way toward loosing the ability to do topological aggregation [0]. --dmm [0] You lose that ability as no one will ever renumber (cf. today's Internet). =20 --S1BNGpv0yoYahz37 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnSkLORgD1qCZ2KcRAvU1AJ0bU2NuOCmFbtx3TsHCLDy+Rh6OHACfZ4wC MNRAJAe0BcsZ5UlRtQ9Z2FA= =24N7 -----END PGP SIGNATURE----- --S1BNGpv0yoYahz37-- --===============0884030388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0884030388==-- From ram-bounces@iab.org Thu Jan 04 11:28:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VS6-0007yl-Me; Thu, 04 Jan 2007 11:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VS5-0007yd-B3 for ram@iab.org; Thu, 04 Jan 2007 11:28:25 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2VS4-0004lf-2d for ram@iab.org; Thu, 04 Jan 2007 11:28:25 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 08:28:22 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l04GSNcC031093; Thu, 4 Jan 2007 08:28:23 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l04GSNUg013867; Thu, 4 Jan 2007 08:28:23 -0800 (PST) Received: from elear-mac.cisco.com ([10.61.80.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l04GBW8U024649; Thu, 4 Jan 2007 08:11:33 -0800 Message-ID: <459D2B22.20203@cisco.com> Date: Thu, 04 Jan 2007 17:28:18 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b1 (Macintosh/20061206) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] GSE security References: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> In-Reply-To: <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=629; t=1167928103; x=1168792103; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20GSE=20security |Sender:=20; bh=eqgMqqq8tAXk2pKWQANNZ1SIAZRK0RzZX5p2ED8Suww=; b=jbgP6xH/oEq5MbF1YUHjMQoiee8vpBYAWWt3s2dAmvaJ7pVBU6eDSOQxHO43seXiG18BUS7C czF61ysU1/ljzl3J8f8T+nHaqsTasVTBfFaQCzyHFaeD1z9fShXEAtHV; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=629; t=1167927093; x=1168791093; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20GSE=20security |Sender:=20 |To:=20RJ=20Atkinson=20; bh=eqgMqqq8tAXk2pKWQANNZ1SIAZRK0RzZX5p2ED8Suww=; b=L1K/qlvS8YGWHlKfgaMDFk/ypcbbX/okzoTjgT0K72oANh1gxOu8PoQq4nD82GDhLfprk/eI 18L+J1GSnoJu4epADHVoJnVWED7zSwGhwEgHmyyL8m+oFD6LMgd74r12; Authentication-Results: sj-dkim-1; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ran, Let's be clear about the security concerns with GSE. If someone in the middle is mucking with the RG (routing goo) is it sufficient for purposes of IPSEC to secure the lower eight bytes? I'm sure this was talked about way back when, but I don't know that it was put into print. The argument at the time as I recall it from Steve Deering was that TCP has the barest form of security through the overloading of the two name spaces with the pseudo-header checksum. If we give up on the notion that this really provides ANY security in this day and age, what is left from a security standpoint? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 12:30:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WPD-0004SQ-Cz; Thu, 04 Jan 2007 12:29:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WPC-0004Qa-JY for ram@iab.org; Thu, 04 Jan 2007 12:29:30 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WPB-0006Px-7C for ram@iab.org; Thu, 04 Jan 2007 12:29:30 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04HTJHd004116; Thu, 4 Jan 2007 09:29:19 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04HTBgx004112; Thu, 4 Jan 2007 09:29:11 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:29:11 -0800 From: David Meyer To: RJ Atkinson Subject: Re: [RAM] GSE security Message-ID: <20070104172911.GD32409@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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1364570121==" Errors-To: ram-bounces@iab.org --===============1364570121== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RYJh/3oyKhIjGcML" Content-Disposition: inline --RYJh/3oyKhIjGcML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 02, 2007 at 05:35:44PM -0500, RJ Atkinson wrote: > % Well, GSE is certainly missing the security paraphernalia. > % I think that we all pretty much agree on that. >=20 > I'd rephrase the first sentence as: > The existing published GSE Internet-Drafts did not go into > detail about how information might be authenticated. >=20 > And then I'd note that not having written the security paraphernalia > down is wildly different from "it is impossible to secure". Well said, and I'd add vastly different than "has been explored (not) and we conclude that "it is impossible to secure"". (i.e., since GSE as considered dead, people [understandably] stopped working on it). --dmm =09 --RYJh/3oyKhIjGcML Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnTlnORgD1qCZ2KcRAn1ZAJ9ys6jf3S/Ydq+nAFBYJtg85SvRtwCfd/5q nAFdF+pm3AwBWksc9BIBUBs= =Mcu/ -----END PGP SIGNATURE----- --RYJh/3oyKhIjGcML-- --===============1364570121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1364570121==-- From ram-bounces@iab.org Thu Jan 04 12:32:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WRk-0006an-J9; Thu, 04 Jan 2007 12:32:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WRj-0006aR-Ko for ram@iab.org; Thu, 04 Jan 2007 12:32:07 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WRi-0006vt-9v for ram@iab.org; Thu, 04 Jan 2007 12:32:07 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04HW4tG004177; Thu, 4 Jan 2007 09:32:04 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04HW4of004176; Thu, 4 Jan 2007 09:32:04 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:32:04 -0800 From: David Meyer To: marcelo bagnulo braun Subject: Re: [RAM] GSE security Message-ID: <20070104173204.GE32409@1-4-5.net> References: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> Mime-Version: 1.0 In-Reply-To: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1969188629==" Errors-To: ram-bounces@iab.org --===============1969188629== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gDGSpKKIBgtShtf+" Content-Disposition: inline --gDGSpKKIBgtShtf+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 03:06:05AM +0100, marcelo bagnulo braun wrote: >=20 > El 02/01/2007, a las 23:35, RJ Atkinson escribi=F3: >=20 > >% Well, GSE is certainly missing the security paraphernalia. > >% I think that we all pretty much agree on that. > > > >I'd rephrase the first sentence as: > > The existing published GSE Internet-Drafts did not go into > > detail about how information might be authenticated. > > > >And then I'd note that not having written the security paraphernalia > >down is wildly different from "it is impossible to secure". > > >=20 > fully agree >=20 > but do we also agree that when security is included in GSE, the result=20 > is not nearly as nice as the current GSe proposal? Well, that's hard to say, since GSE really hasn't been fleshed out (AFAICT). --dmm --gDGSpKKIBgtShtf+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnToUORgD1qCZ2KcRAjntAJ4jPCjALxJMNGqmRIO7gGSaqTFQ7ACgh3qq vXmh0ZqHjVpbubARhnr25Hg= =zvRv -----END PGP SIGNATURE----- --gDGSpKKIBgtShtf+-- --===============1969188629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1969188629==-- From ram-bounces@iab.org Thu Jan 04 12:44:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WdJ-00076o-UO; Thu, 04 Jan 2007 12:44:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WdH-000766-IJ for ram@iab.org; Thu, 04 Jan 2007 12:44:03 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WdB-0001A6-0B for ram@iab.org; Thu, 04 Jan 2007 12:44:03 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04HhuGv004357; Thu, 4 Jan 2007 09:43:56 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04Hhuvb004356; Thu, 4 Jan 2007 09:43:56 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:43:56 -0800 From: David Meyer To: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070104174356.GF32409@1-4-5.net> References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0074106610==" Errors-To: ram-bounces@iab.org --===============0074106610== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E7i4zwmWs5DOuDSH" Content-Disposition: inline --E7i4zwmWs5DOuDSH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > The sudden tolerance for PI space gratifies/puzzles me, though - I =20 > thought it was anathema, and that folks here aren't in the main =20 > amused that PI space is being allocated. If PI space is now =20 > tolerable, then we can all go home and call it a day, and wait on =20 > Moore's Law (along with open chequebooks) to save us. I doubt that's =20 > the case, though. I don't know who has "tolerance" for the current RIR policies; there is just little choice, as we haven't built a technology that avoids teh "tyranny of CIDR" (Vix's term, referring to CIDR provider lock). BTW, its far from clear that Moore's Law will save anything; that's different than saying that we can build (for some X; well, than and the fact that Moore's Law just an empirical observation).=20 In any event, the Moore's Law "line of reasoning" turns out to be such a massive rathole that I'd prefer we stay away from that one (again, to the extent its possible). --dmm --E7i4zwmWs5DOuDSH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnTzcORgD1qCZ2KcRAuaYAKCIUg2qM2+8TYTKfLAh/Wr8LR/rPgCfaM3K nplbsWuVD1OEULezr2O3Dj8= =ftRC -----END PGP SIGNATURE----- --E7i4zwmWs5DOuDSH-- --===============0074106610== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0074106610==-- From ram-bounces@iab.org Thu Jan 04 12:48:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WhG-0000u1-4n; Thu, 04 Jan 2007 12:48:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WhF-0000tv-48 for ram@iab.org; Thu, 04 Jan 2007 12:48:09 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WhD-0002Da-R0 for ram@iab.org; Thu, 04 Jan 2007 12:48:09 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 09:48:07 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l04Hm7B1029435; Thu, 4 Jan 2007 09:48:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04Hm5J5022345; Thu, 4 Jan 2007 09:48:07 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 09:48:02 -0800 Received: from [192.168.0.101] ([10.21.152.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 09:48:02 -0800 In-Reply-To: <20070104161923.GC32409@1-4-5.net> References: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.com> <20070104161923.GC32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46B54498-BD1C-48E5-9311-FEE1122BE4B3@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Destination Locator selection Date: Thu, 4 Jan 2007 09:48:02 -0800 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jan 2007 17:48:02.0387 (UTC) FILETIME=[7B018230:01C73028] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=487; t=1167932887; x=1168796887; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20; bh=STbp8/7hji23tXZIxN2peWYoGtT3hpOeFoXeIpeBMps=; b=OirutHGIirAx2x043xbi15Msj76MDEFyBzwdaHjWs7j9yWtwbkv/rEJybZOwoB9Q32p82QJw ep9ik2ifXVR3ZwQXW2Zlb8xcU9wrRmwzgOBm0k0HPxbQ6dRtcVhBPani; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Understand the idea, but it seems possible that if you > start telling a host its locator (without any kind of > indirection), you are well on your way toward loosing the > ability to do topological aggregation [0]. > > [0] You lose that ability as no one will ever renumber > (cf. today's Internet). Dave, If the locator is automagically and dynamically discovered by the host, do you feel that it's still an issue? For static configuration, I would agree. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 12:49:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wij-00021X-9a; Thu, 04 Jan 2007 12:49:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wii-00020U-Nm for ram@iab.org; Thu, 04 Jan 2007 12:49:40 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wih-0002JO-CH for ram@iab.org; Thu, 04 Jan 2007 12:49:40 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04HnaD6004450; Thu, 4 Jan 2007 09:49:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04HnapH004449; Thu, 4 Jan 2007 09:49:36 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:49:36 -0800 From: David Meyer To: Noel Chiappa Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070104174936.GG32409@1-4-5.net> References: <20070103171206.37CA686ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20070103171206.37CA686ADB@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1984078275==" Errors-To: ram-bounces@iab.org --===============1984078275== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kjpMrWxdCilgNbo1" Content-Disposition: inline --kjpMrWxdCilgNbo1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 03, 2007 at 12:12:06PM -0500, Noel Chiappa wrote: > > From: David Meyer >=20 > > Its not clear to me (yet) what the architectural design constraints > > we're working with here are. >=20 > Sadly, I suspect the engineering constaints (from > legacy/interoperability/etc) are likely to be far more > significant than architectural ones... :-(=20 Well, yeah, and I guess this was the point of Mark Handley's "Why the Internet only just works" [0] (i.e., that the incremental deployablity is the primary requirement for internet technologies today).=20 OTOH, maybe this is the opportunity to actually do something progressive/innovative in this space. And hey, why not?=20 So, to that end, what constraints do folks feel we are working with? --dmm [0] http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf --kjpMrWxdCilgNbo1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnT4wORgD1qCZ2KcRAt1OAJ9Azefc+EXAnbnrSq7ZQ+VL4OJKYgCgkQdV tjJnCvindwxsT+bCXahCTWI= =c7YT -----END PGP SIGNATURE----- --kjpMrWxdCilgNbo1-- --===============1984078275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1984078275==-- From ram-bounces@iab.org Thu Jan 04 12:52:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wl3-0003HG-JL; Thu, 04 Jan 2007 12:52:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wl2-0003HA-M3 for ram@iab.org; Thu, 04 Jan 2007 12:52:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wl1-0002ZQ-Cn for ram@iab.org; Thu, 04 Jan 2007 12:52:04 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2007 09:52:02 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l04Hq2G3026005; Thu, 4 Jan 2007 09:52:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04HpqIr024510; Thu, 4 Jan 2007 09:52:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 09:51:53 -0800 Received: from [192.168.0.101] ([10.21.152.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 09:51:53 -0800 In-Reply-To: <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 09:51:53 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jan 2007 17:51:53.0448 (UTC) FILETIME=[04BA9E80:01C73029] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=564; t=1167933122; x=1168797122; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=jNH7INlJSHPW2bEN6RxE0OcqVGwDRbcNXge0H6941TQ=; b=sNIMJ83n5s7Wwk0q6Mm0r/urGQUB9hJRLuLdrOWT/pLtNrDO2tV2nuB43ZHBm9VG7KEtMcwW gCgKGNTB9t4ou1Wy9yXPUHRaKaI0DXNq6Z9IeSw3chMDKJ1Ra6yynB8a; Authentication-Results: sj-dkim-6; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 3, 2007, at 3:54 AM, marcelo bagnulo braun wrote: > So, are we concluding that any solution should work in any type of > site without requiring configuration from the user? this seems > quite a tough requirement to me... No, I wouldn't go that far. I would say that we will need mechanisms that allow ASBRs to discover one another and exchange information. I think that the most that we might get is a knob flipped on the ASBR that would both enable this mechanism and advertise the capability, presumably in the IGP. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 12:54:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wmt-0004Nn-Ng; Thu, 04 Jan 2007 12:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wms-0004KJ-MC for ram@iab.org; Thu, 04 Jan 2007 12:53:58 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wmr-0002v6-AP for ram@iab.org; Thu, 04 Jan 2007 12:53:58 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04HruuH004560; Thu, 4 Jan 2007 09:53:56 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04HrtVG004559; Thu, 4 Jan 2007 09:53:55 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:53:55 -0800 From: David Meyer To: Brian E Carpenter Subject: Re: [RAM] Goal: Minimising Routing Entropy Message-ID: <20070104175355.GH32409@1-4-5.net> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> Mime-Version: 1.0 In-Reply-To: <459D1C54.4000603@zurich.ibm.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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0418663515==" Errors-To: ram-bounces@iab.org --===============0418663515== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GBDnBH7+ZvLx8QD4" Content-Disposition: inline --GBDnBH7+ZvLx8QD4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 04:25:08PM +0100, Brian E Carpenter wrote: > On 2006-12-29 15:42, RJ Atkinson wrote: > > > > I'd like to suggest that an architectural goal > >for any new effort should be to reduce/minimise Routing > >Entropy. =20 >=20 > My instinct is that this is a Good Thing, but my other concern > is churn rates (which are obviously related to entropy > among other things). I'd rather get a handle on the dynamics > before being sure whether the target should be entropy > itself or some aspect of the churn. Brian, As you might imagine, I agree with this statement. --dmm --GBDnBH7+ZvLx8QD4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnT8zORgD1qCZ2KcRAlBuAJ9E81sqGXDd44OuVN4aUwI6EJ1uwgCeL6sj edVMjlxszFRUBp8hRWf4eBE= =qhqQ -----END PGP SIGNATURE----- --GBDnBH7+ZvLx8QD4-- --===============0418663515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0418663515==-- From ram-bounces@iab.org Thu Jan 04 12:58:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wqu-0006wR-EB; Thu, 04 Jan 2007 12:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wqs-0006vp-GN for ram@iab.org; Thu, 04 Jan 2007 12:58:06 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wqr-0003Tc-5X for ram@iab.org; Thu, 04 Jan 2007 12:58:06 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04Hw35C004630; Thu, 4 Jan 2007 09:58:03 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04Hw3pA004629; Thu, 4 Jan 2007 09:58:03 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 09:58:03 -0800 From: David Meyer To: Tony Li Subject: Re: [RAM] Destination Locator selection Message-ID: <20070104175803.GI32409@1-4-5.net> References: <28FA1F9E-6524-4030-840F-7F2CB6346FCD@cisco.com> <20070104161923.GC32409@1-4-5.net> <46B54498-BD1C-48E5-9311-FEE1122BE4B3@cisco.com> Mime-Version: 1.0 In-Reply-To: <46B54498-BD1C-48E5-9311-FEE1122BE4B3@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465255389==" Errors-To: ram-bounces@iab.org --===============1465255389== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q59ABw34pTSIagmi" Content-Disposition: inline --Q59ABw34pTSIagmi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tony, >=20 > > Understand the idea, but it seems possible that if you > > start telling a host its locator (without any kind of > > indirection), you are well on your way toward loosing the > > ability to do topological aggregation [0]. > > > >[0] You lose that ability as no one will ever renumber > > (cf. today's Internet). >=20 >=20 > Dave, >=20 > If the locator is automagically and dynamically discovered by the =20 > host, do you feel that it's still an issue? > For static configuration, I would agree. I too was considering the latter case. If there is a dynamic (secure, etc) mechanism, then perhaps we'd be ok (in this regard). My argument was more along the lines of the "what about routers, NATs, firewalls, appliances of type that hold locator state, etc. arguments that we've seen over the years. =20 --dmm --Q59ABw34pTSIagmi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnUArORgD1qCZ2KcRAvRqAJ9XE5XgmEJ4Q4VEA3VspPMX8kdIUgCfVHp6 CIKqC8p+b5HPfJnPJ7JPWcM= =CB8w -----END PGP SIGNATURE----- --Q59ABw34pTSIagmi-- --===============1465255389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1465255389==-- From ram-bounces@iab.org Thu Jan 04 13:04:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WwY-0002FU-1J; Thu, 04 Jan 2007 13:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WwX-0002FN-2C for ram@iab.org; Thu, 04 Jan 2007 13:03:57 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WwU-0004F0-Or for ram@iab.org; Thu, 04 Jan 2007 13:03:57 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 5976595; Thu, 04 Jan 2007 13:03:54 -0500 In-Reply-To: <20070104174356.GF32409@1-4-5.net> References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <20070104174356.GF32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 13:03:51 -0500 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 12:43 PM, David Meyer wrote: >> The sudden tolerance for PI space gratifies/puzzles me, though - I >> thought it was anathema, and that folks here aren't in the main >> amused that PI space is being allocated. If PI space is now >> tolerable, then we can all go home and call it a day, and wait on >> Moore's Law (along with open chequebooks) to save us. I doubt that's >> the case, though. As one of the instigators of this "tolerance" (ARIN 2002-3 and 2005-1), I think that it is widely misunderstood. The contentions were that 1.) there are some small entities that needed to multi-home, and thus needed (small amounts of) PI space, 2.) that they were doing it anyway, and actually injecting at least as much and probably more into the routing tables than they would under its adoption, and also having to deal with being black-holed and other problems on an ad hoc basis and 3.) _that this was a relatively small usage that would have a small to negligible effect on the actual routing table expansion_. To date, I think that all three contentions have been proven by practice and this has worked rather well. This is discussed from time to time on the ARIN PPML, and AFAIK no data has been introduced to the contrary. This was (in my opinion) not an attempt to subvert the system, but rather to make it work better for a wider class of users. If you want to claim that this is a general threat, please produce data supporting your assertions. Regards Marshall > > I don't know who has "tolerance" for the current RIR > policies; there is just little choice, as we haven't > built a technology that avoids teh "tyranny of CIDR" > (Vix's term, referring to CIDR provider lock). BTW, its > far from clear that Moore's Law will save anything; > that's different than saying that we can build (for > some X; well, than and the fact that Moore's Law just an > empirical observation). > > In any event, the Moore's Law "line of reasoning" turns > out to be such a massive rathole that I'd prefer we stay > away from that one (again, to the extent its possible). > > --dmm > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:04:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wx8-0002l3-5O; Thu, 04 Jan 2007 13:04:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wx6-0002js-C9 for ram@iab.org; Thu, 04 Jan 2007 13:04:32 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wx4-0004Ia-Kh for ram@iab.org; Thu, 04 Jan 2007 13:04:32 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C5ADECE9BA; Thu, 4 Jan 2007 19:04:29 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp02.uc3m.es (Postfix) with ESMTP id 490F7CE985; Thu, 4 Jan 2007 19:04:22 +0100 (CET) In-Reply-To: <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> References: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7f3d58b53c528c8a7bdc594b9bb720e7@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] GSE security Date: Thu, 4 Jan 2007 18:41:52 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 03/01/2007, a las 14:10, RJ Atkinson escribi=F3: > > On 2 Jan 2007, at 21:06, marcelo bagnulo braun wrote: >> do we also agree that when security is included in GSE, >> the result is not nearly as nice as the current GSe proposal? > > No scientific case has been made here that detailing how GSE > can be authenticated necessarily proves the resulting form of GSE > is "not nearly as nice". > > If someone wants to try to make such a case on list, that would be > fine. > > I suspect that it is hard to prove that for the universe of all > possible security approaches, GSE ends up being "not nearly so nice". > > I'd also submit that "not nearly so nice" is a pretty subjective > criterion. I'd prefer that we operate with more objective and > measurable criteria. > fair enough did anyone ever provided a security architecture for GSE? if so, do you=20= have a pointer? i guess this is the first thing we need in order to be=20= able to see the full picture of GSE... Regards, marcelo > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:04:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WxF-0002t8-EN; Thu, 04 Jan 2007 13:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WxD-0002pg-HE for ram@iab.org; Thu, 04 Jan 2007 13:04:39 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2WxC-0004JB-66 for ram@iab.org; Thu, 04 Jan 2007 13:04:39 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 137D4CE979; Thu, 4 Jan 2007 19:04:37 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp02.uc3m.es (Postfix) with ESMTP id 0B802CE913; Thu, 4 Jan 2007 19:04:30 +0100 (CET) In-Reply-To: <9EA470F6-1521-49CD-9D56-33BDB6C115DC@extremenetworks.com> References: <8d33bfdf734af3d838f5e98c851d23c0@it.uc3m.es> <9EA470F6-1521-49CD-9D56-33BDB6C115DC@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1f218b3c1710315c5c56eeaeb14fb0e8@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Destination Locator selection Date: Thu, 4 Jan 2007 19:04:26 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 03/01/2007, a las 14:14, RJ Atkinson escribi=F3: > > On 2 Jan 2007, at 20:55, marcelo bagnulo braun wrote: >> just a subtle point here.... >> from the way you put it, it seems to me that you would require that=20= >> all the hosts must support whatever new thing/protocol that is=20 >> necesary to allow this rewriting > > It is not obvious to me that your assertion is necessarily true. > >> I would argue that this would make deployment more difficult > > Given that no specific mechanism has been proposed, > that argument isn't very credible right now. > well, if a solution requires support from hosts and routers then it is=20= likely to be more difficult to deploy than a solution that requires=20 updating only the routers... >> I would then suggest that both the host or the host can do the=20 >> locator selection and all the rest of the functions required to=20 >> support this (allowing both routers and hosts to support the needed=20= >> functions) and also that a host that is selecting the locators can=20 >> communicate with a peer that is being served by a router that=20 >> performs the locator selection and associated required features. > > That is not identical to the abstract concept I've suggested, > not least because it has more implementation detail than anything > I've been talking about. > my question is whether you had in mind that both hosts and routers need=20= to be involved in the solution (meaning that new mechanisms/protocols=20 are needed to be installed in them) or that only routers are involved=20 and require update (only edge routers as David C. suggests) Regards, marcelo > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:08:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X0V-0004UM-47; Thu, 04 Jan 2007 13:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X0T-0004UH-PI for ram@iab.org; Thu, 04 Jan 2007 13:08:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X0S-0004XO-Iy for ram@iab.org; Thu, 04 Jan 2007 13:08:01 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Jan 2007 10:08:00 -0800 X-IronPort-AV: i="4.12,239,1165219200"; d="scan'208"; a="50006173:sNHT42845278" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l04I805N008512 for ; Thu, 4 Jan 2007 13:08:00 -0500 Received: from [192.168.1.101] (rtp-vpn4-110.cisco.com [10.82.208.110]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l04I802k004498 for ; Thu, 4 Jan 2007 13:08:00 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <20070104174356.GF32409@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 10:07:59 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=615; t=1167934080; x=1168798080; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=DYe8Hg4q2g/8l/YpKQbS8SoR9S5IEPSN3i92G9iE0Z8=; b=LjZ0eiXX88Yig4pq+90KWH7fGFVy90uy55QaielwHFMgEDt7l7bX2aPlqd/rSAJ4pZIB8lW6 vW26HnTfejilUV4WelX/m0XTRyhdC8zrPX30mWPr9We34bYQBwtcBuFH; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 10:03 AM, Marshall Eubanks wrote: > If you want to claim that this is a general threat, please produce > data supporting your assertions. To be clear, I think this policy hack is a Good Thing, especially whilst we work on this solution-set - I was referring to apparent tolerance on the part of the poster to whom I was responding, in a TIC sort of manner. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:09:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X1e-0004tv-4c; Thu, 04 Jan 2007 13:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X1d-0004tq-Iv for ram@iab.org; Thu, 04 Jan 2007 13:09:13 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X1b-0004qr-Tv for ram@iab.org; Thu, 04 Jan 2007 13:09:13 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04I98Dh005378; Thu, 4 Jan 2007 10:09:08 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04I986K005377; Thu, 4 Jan 2007 10:09:08 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 10:09:08 -0800 From: David Meyer To: Marshall Eubanks Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-ID: <20070104180908.GA5296@1-4-5.net> References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <20070104174356.GF32409@1-4-5.net> 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: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899524930==" Errors-To: ram-bounces@iab.org --===============1899524930== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Marshall, > As one of the instigators of this "tolerance" (ARIN 2002-3 and =20 > 2005-1), I think that it is widely misunderstood. I understand. However, the fact remains that PI space is more or less readily available. What is looming then, is a swamp that has the potential to be many orders of magnitude larger than what we faced with v4 (something about learning the lessons of history comes to mind). In any event, I'm not "blaming/critizing/whatever" anyone; there just wasn't another solution available, and that (IMO) is on us.=20 =09 --dmm >=20 > The contentions were that > 1.) there are some small entities that needed to multi-home, and thus =20 > needed (small amounts of) > PI space, > 2.) that they were doing it anyway, and actually injecting at least =20 > as much and probably more into the routing tables than they would =20 > under its adoption, and also having to deal with being black-holed =20 > and other problems on an > ad hoc basis and > 3.) _that this was a relatively small usage that would have a small =20 > to negligible effect on the actual routing table expansion_. >=20 > To date, I think that all three contentions have been proven by =20 > practice and this has worked rather well. This is discussed from time =20 > to time on the ARIN PPML, and AFAIK no data has been introduced to =20 > the contrary. This was (in my opinion) not an attempt to subvert the =20 > system, but rather to make it work better for a wider class of users. >=20 > If you want to claim that this is a general threat, please produce =20 > data supporting your assertions. >=20 > Regards > Marshall >=20 >=20 > > > > I don't know who has "tolerance" for the current RIR > > policies; there is just little choice, as we haven't > > built a technology that avoids teh "tyranny of CIDR" > > (Vix's term, referring to CIDR provider lock). BTW, its > > far from clear that Moore's Law will save anything; > > that's different than saying that we can build (for > > some X; well, than and the fact that Moore's Law just an > > empirical observation). > > > > In any event, the Moore's Law "line of reasoning" turns > > out to be such a massive rathole that I'd prefer we stay > > away from that one (again, to the extent its possible). > > > > --dmm > >_______________________________________________ > >RAM mailing list > >RAM@iab.org > >https://www1.ietf.org/mailman/listinfo/ram --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnULEORgD1qCZ2KcRAjKHAJ9tD8cFRLKrc8qnWccLTzsAAWk0zACeL5eg tsm9hc1/YKS17FnqTkWOmeA= =yNS/ -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- --===============1899524930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1899524930==-- From ram-bounces@iab.org Thu Jan 04 13:10:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X2o-0005M6-9n; Thu, 04 Jan 2007 13:10:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X2n-0005Lj-9F for ram@iab.org; Thu, 04 Jan 2007 13:10:25 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X2f-00058x-TM for ram@iab.org; Thu, 04 Jan 2007 13:10:25 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04IAGtT005411; Thu, 4 Jan 2007 10:10:16 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04IACdq005410; Thu, 4 Jan 2007 10:10:12 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 10:10:12 -0800 From: David Meyer To: marcelo bagnulo braun Subject: Re: [RAM] GSE security Message-ID: <20070104181012.GB5296@1-4-5.net> References: <41062a0d8f3a7a1b24ae95d4d1830b96@it.uc3m.es> <20E2CB62-2BED-4445-BD39-47ADA080FCF8@extremenetworks.com> <7f3d58b53c528c8a7bdc594b9bb720e7@it.uc3m.es> Mime-Version: 1.0 In-Reply-To: <7f3d58b53c528c8a7bdc594b9bb720e7@it.uc3m.es> 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1890731858==" Errors-To: ram-bounces@iab.org --===============1890731858== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 06:41:52PM +0100, marcelo bagnulo braun wrote: >=20 > El 03/01/2007, a las 14:10, RJ Atkinson escribi=F3: >=20 > > > >On 2 Jan 2007, at 21:06, marcelo bagnulo braun wrote: > >>do we also agree that when security is included in GSE, > >>the result is not nearly as nice as the current GSe proposal? > > > >No scientific case has been made here that detailing how GSE > >can be authenticated necessarily proves the resulting form of GSE > >is "not nearly as nice". > > > >If someone wants to try to make such a case on list, that would be > >fine. > > > >I suspect that it is hard to prove that for the universe of all > >possible security approaches, GSE ends up being "not nearly so nice". > > > >I'd also submit that "not nearly so nice" is a pretty subjective > >criterion. I'd prefer that we operate with more objective and > >measurable criteria. > > >=20 > fair enough >=20 > did anyone ever provided a security architecture for GSE? if so, do you= =20 > have a pointer? i guess this is the first thing we need in order to be=20 > able to see the full picture of GSE... To the best of my knowledge, no. But then, as I said, people don't generally publish negative data (or work on protocols that are perceived to be dead). --dmm --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnUMEORgD1qCZ2KcRAsFcAJ0SYEOy95lOPnUjAyAScrnJf8X2zACgjguw OknKkp6tJkpOSBGYt0Mbzwo= =lirs -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- --===============1890731858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1890731858==-- From ram-bounces@iab.org Thu Jan 04 13:21:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XCu-0005GS-2l; Thu, 04 Jan 2007 13:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XCs-0005G7-4t for ram@iab.org; Thu, 04 Jan 2007 13:20:50 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2XCq-0007S6-S6 for ram@iab.org; Thu, 04 Jan 2007 13:20:50 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2007 10:20:48 -0800 X-IronPort-AV: i="4.12,239,1165219200"; d="scan'208"; a="354695970:sNHT74196690" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l04IKkv2008843; Thu, 4 Jan 2007 10:20:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l04IKjZH022325; Thu, 4 Jan 2007 10:20:45 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 10:20:44 -0800 Received: from [192.168.0.101] ([10.21.152.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 10:20:44 -0800 In-Reply-To: <20070104175355.GH32409@1-4-5.net> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Thu, 4 Jan 2007 10:20:11 -0800 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jan 2007 18:20:44.0215 (UTC) FILETIME=[0C58B470:01C7302D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=709; t=1167934846; x=1168798846; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20; bh=k0mB+5GQGdC3Nf5BNdUlKkAXlKfHgfZOqlMeW4cGhu4=; b=aZWvO9gXkhO/RF4QglxaPnZwrDxLgLNkGzDprhMwiBYNsecxSzOUK6PN6vHJ3/NB2BuxZpSb 7EenMLrIkHhtU4jsbs4nriKCB1YctXcTlw5p4dDs82DkBt1kKqFTC8Xn; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> My instinct is that this is a Good Thing, but my other concern >> is churn rates (which are obviously related to entropy >> among other things). I'd rather get a handle on the dynamics >> before being sure whether the target should be entropy >> itself or some aspect of the churn. > > As you might imagine, I agree with this statement. I'm intrigued by this. To my way of thinking, the churn rate is an artifact of BGP's design, the actual physical changes in the topology, and operational input. It doesn't really seem to be architectural, it's just a side-effect of the control plane mechanisms that we've chosen. That's not to say it's not an important issue... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:22:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XEC-0005pR-0h; Thu, 04 Jan 2007 13:22:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XEA-0005pA-Jw for ram@iab.org; Thu, 04 Jan 2007 13:22:10 -0500 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2XE9-0007zG-9s for ram@iab.org; Thu, 04 Jan 2007 13:22:10 -0500 Received: from ([10.160.67.162]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.132720962; Thu, 04 Jan 2007 13:37:16 -0500 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K05.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Jan 2007 13:21:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering Date: Thu, 4 Jan 2007 13:21:48 -0500 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DD32@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering Thread-Index: AccwKsqsB+D7W1RTQEaI2PX836vAXAAAM73w From: "Azinger, Marla" To: "Marshall Eubanks" , "David Meyer" X-OriginalArrivalTime: 04 Jan 2007 18:21:39.0244 (UTC) FILETIME=[2D2576C0:01C7302D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Comments to the email string below: PI space became a threat due to public remarks on how it "can" be = utilized. There is a difference between the Intent you display below = and the comments put forth by many that "everyone" should apply for PI = in order to get out from under the so called tyrany of upstream = providers. If everyone were to listen to the push for PI usage for = "ALL", then this policy does create yet a larger issue than the one = already at hand. I dont believe malice was the intent of this policy but = it does highlight a problem with multihoming and traffic engineering = that we need to address. And no, I dont think statics show a land rush for PI space as of yet, = but it is early. ~Marla Azinger -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Thursday, January 04, 2007 10:04 AM To: David Meyer Cc: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re:[RAM] Traffic Engineering On Jan 4, 2007, at 12:43 PM, David Meyer wrote: >> The sudden tolerance for PI space gratifies/puzzles me, though - I >> thought it was anathema, and that folks here aren't in the main >> amused that PI space is being allocated. If PI space is now >> tolerable, then we can all go home and call it a day, and wait on >> Moore's Law (along with open chequebooks) to save us. I doubt that's >> the case, though. As one of the instigators of this "tolerance" (ARIN 2002-3 and =20 2005-1), I think that it is widely misunderstood. The contentions were that 1.) there are some small entities that needed to multi-home, and thus =20 needed (small amounts of) PI space, 2.) that they were doing it anyway, and actually injecting at least =20 as much and probably more into the routing tables than they would =20 under its adoption, and also having to deal with being black-holed =20 and other problems on an ad hoc basis and 3.) _that this was a relatively small usage that would have a small =20 to negligible effect on the actual routing table expansion_. To date, I think that all three contentions have been proven by =20 practice and this has worked rather well. This is discussed from time =20 to time on the ARIN PPML, and AFAIK no data has been introduced to =20 the contrary. This was (in my opinion) not an attempt to subvert the =20 system, but rather to make it work better for a wider class of users. If you want to claim that this is a general threat, please produce =20 data supporting your assertions. Regards Marshall > > I don't know who has "tolerance" for the current RIR > policies; there is just little choice, as we haven't > built a technology that avoids teh "tyranny of CIDR" > (Vix's term, referring to CIDR provider lock). BTW, its > far from clear that Moore's Law will save anything; > that's different than saying that we can build (for > some X; well, than and the fact that Moore's Law just an > empirical observation). > > In any event, the Moore's Law "line of reasoning" turns > out to be such a massive rathole that I'd prefer we stay > away from that one (again, to the extent its possible). > > --dmm > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:23:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XFV-0006Bf-4T; Thu, 04 Jan 2007 13:23:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XFU-0006BV-2j for ram@iab.org; Thu, 04 Jan 2007 13:23:32 -0500 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2XFS-0008E3-QU for ram@iab.org; Thu, 04 Jan 2007 13:23:32 -0500 Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v38_r7.6.) id z.d07.6579134 (39331); Thu, 4 Jan 2007 13:23:15 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 4 Jan 2007 13:23:13 EST Subject: Re: [RAM] Goal: Minimising Routing Entropy To: dmm@1-4-5.net, brc@zurich.ibm.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0848651098==" Errors-To: ram-bounces@iab.org --===============0848651098== Content-Type: multipart/alternative; boundary="-----------------------------1167934993" -------------------------------1167934993 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Well, with Hierarchical Routing the routing churn rate will dramatically be=20= =20 reduced. Just consider a temporary road blockage within a city, i.e. a change insid= e=20 the city map of this city. It would not cause any change in any county/state/country/continent road ma= p=20 this city is part of. =20 Heiner =20 In einer eMail vom 04.01.2007 18:54:36 Westeurop=E4ische Normalzeit schreibt= =20 dmm@1-4-5.net: On Thu, Jan 04, 2007 at 04:25:08PM +0100, Brian E Carpenter wrote: > On 2006-12-29 15:42, RJ Atkinson wrote: > > > > I'd like to suggest that an architectural goal > >for any new effort should be to reduce/minimise Routing > >Entropy. =20 > =20 > My instinct is that this is a Good Thing, but my other concern > is churn rates (which are obviously related to entropy > among other things). I'd rather get a handle on the dynamics > before being sure whether the target should be entropy > itself or some aspect of the churn. Brian, As you might imagine, I agree with this statement. --dmm _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -------------------------------1167934993 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Well, with Hierarchical Routing the routing churn rate will dramaticall= y be=20 reduced.
Just consider a temporary road blockage within a city, i.e.=20 a  change inside the city map of this city.
It would not cause any change in any county/state/country/continent roa= d=20 map this city is part of.
 
Heiner
 
In einer eMail vom 04.01.2007 18:54:36 Westeurop=E4ische Normalzeit sch= reibt=20 dmm@1-4-5.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Thu,=20 Jan 04, 2007 at 04:25:08PM +0100, Brian E Carpenter wrote:
> On=20 2006-12-29 15:42, RJ Atkinson wrote:
> >
> >   = ;=20 I'd like to suggest that an architectural goal
> >for any new eff= ort=20 should be to reduce/minimise Routing
> >Entropy. 
>=20
> My instinct is that this is a Good Thing, but my other=20 concern
> is churn rates (which are obviously related to entropy
= >=20 among other things). I'd rather get a handle on the dynamics
> befor= e=20 being sure whether the target should be entropy
> itself or some asp= ect=20 of the churn.

    Brian,

    As you migh= t=20 imagine, I agree with this statement.

   =20 --dmm

_______________________________________________
RAM mailin= g=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1167934993-- --===============0848651098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0848651098==-- From ram-bounces@iab.org Thu Jan 04 13:28:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XKC-0000sm-1f; Thu, 04 Jan 2007 13:28:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XKA-0000qB-DC for ram@iab.org; Thu, 04 Jan 2007 13:28:22 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2XK9-0000Rj-2R for ram@iab.org; Thu, 04 Jan 2007 13:28:22 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BF45654F39; Thu, 4 Jan 2007 19:28:19 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp03.uc3m.es (Postfix) with ESMTP id DCABC54F23; Thu, 4 Jan 2007 19:28:16 +0100 (CET) In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <51f9016e69e5f299b1161557291e882f@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 19:17:01 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 04/01/2007, a las 15:58, Roland Dobbins escribi=F3: > > On Jan 3, 2007, at 3:54 AM, marcelo bagnulo braun wrote: > >> So, are we concluding that any solution should work in any type of=20 >> site without requiring configuration from the user? this seems quite=20= >> a tough requirement to me... > > I wouldn't go that far, but it's important to understand that what to=20= > folks on this list may seem a reasonable amount of complexity in=20 > exchange for functionality may well prove an insurmountable obstacle=20= > for enterprises, even big, sophisticated ones. > i agree with this indeed... i guess the difficulty is to understand=20 what acceptable cost vs. unsurmountable obstacle is... from the=20 discussion lately i think this is not an easy task... Regards, marcelo > [ Perhaps the points made earlier about OPEX and supportability now=20 > make more sense in light of this feedback. ] > > = ----------------------------------------------------------------------- > Roland Dobbins // 408.527.6376 voice > > Technology is legislation. > > -- Karl Schroeder > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 13:38:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XSq-0006Hz-TJ; Thu, 04 Jan 2007 13:37:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2XSp-0006Hu-15 for ram@iab.org; Thu, 04 Jan 2007 13:37:19 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2XSn-0002Pz-9L for ram@iab.org; Thu, 04 Jan 2007 13:37:19 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l04Ib44G006133; Thu, 4 Jan 2007 10:37:04 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l04IarkQ006132; Thu, 4 Jan 2007 10:36:53 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 4 Jan 2007 10:36:53 -0800 From: David Meyer To: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy Message-ID: <20070104183653.GA5990@1-4-5.net> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> Mime-Version: 1.0 In-Reply-To: <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0752888276==" Errors-To: ram-bounces@iab.org --===============0752888276== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 04, 2007 at 10:20:11AM -0800, Tony Li wrote: >=20 > >>My instinct is that this is a Good Thing, but my other concern > >>is churn rates (which are obviously related to entropy > >>among other things). I'd rather get a handle on the dynamics > >>before being sure whether the target should be entropy > >>itself or some aspect of the churn. > > > > As you might imagine, I agree with this statement. >=20 >=20 > I'm intrigued by this. To my way of thinking, the churn rate is an =20 > artifact of BGP's design, the actual physical changes in the =20 > topology, and operational input. It doesn't really seem to be =20 > architectural, it's just a side-effect of the control plane =20 > mechanisms that we've chosen. I think I can agree with that. My goal in studying network dynamics are two-fold: First, I'd like to build an unbiased (in the statistical sense) model (or just=20 find one) that will help us understand the dynamic nature of the BGP UPDATE stream. This may not be architectural, but these studies do help us to better understand the properties of BGP. Second, such studies would, I imagine, inform future architecture and design. As a side effect, it would be nice to have the (mathematical) machinery available to do this kind of work on whatever protocols we deploy (to the extent such machinery could be made general purpose).=20 And anyway, all of this convolves my interests in complexity, paleontology (who doesn't like dinosaurs?), and networking, and fun is allowed, right :-) =20 --dmm --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFnUlFORgD1qCZ2KcRAtT2AJ4v3SfnzeqvXzuaNKQIJY/HWeyxHwCfX7gd 652rs9GF1RcWVExZICX2YLQ= =MGUI -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- --===============0752888276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0752888276==-- From ram-bounces@iab.org Thu Jan 04 13:48:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xd0-0003ne-4C; Thu, 04 Jan 2007 13:47:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xcy-0003nU-Mv for ram@iab.org; Thu, 04 Jan 2007 13:47:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Xcx-0003yI-En for ram@iab.org; Thu, 04 Jan 2007 13:47:48 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 10:47:46 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l04Ilkvl019258 for ; Thu, 4 Jan 2007 10:47:46 -0800 Received: from [68.26.47.124] (rtp-vpn2-355.cisco.com [10.82.241.99]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l04Ilclb026453 for ; Thu, 4 Jan 2007 10:47:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Thu, 4 Jan 2007 10:47:26 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=594; t=1167936466; x=1168800466; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20; bh=B++tuxqMcsfgMPOh86DJKKnPWAX7voaxPAHYr+U1ovc=; b=aA7xkVidlZc0bVo71ewSl23jirJUqoLjeik99VZU6k2edPMzhS1f40vxBMeiQcZSkeuHfQML yjxArk0vB0nwgW/DNBzF6KiDc34PXMB/MSjWkiAKf8U55qEaRbqNvLTa; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 10:23 AM, HeinerHummel@aol.com wrote: > Just consider a temporary road blockage within a city, i.e. a > change inside the city map of this city. > It would not cause any change in any county/state/country/continent > road map this city is part of. Er, this happens all the time in real life - so, at the very least, the analogy is flawed. ;> ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 14:13:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y1C-0003ZY-Qh; Thu, 04 Jan 2007 14:12:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y1C-0003YW-97 for ram@iab.org; Thu, 04 Jan 2007 14:12:50 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Y1A-000867-PV for ram@iab.org; Thu, 04 Jan 2007 14:12:50 -0500 Received: from [10.18.2.20] (unknown [10.18.2.20]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 2EA4F7941; Thu, 4 Jan 2007 11:12:43 -0800 (PST) In-Reply-To: References: <20070104172911.GD32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] GSE security Date: Thu, 4 Jan 2007 14:11:43 -0500 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 4 Jan 2007, at 13:28, marcelo bagnulo braun wrote: > i think that in what we differ in in the view on how GSE security > would look like if done. > I have tried to figure it out and what i found is that we will need > per identifier locator binding state (including security > information) in the edge routers and that the resulting solution > differs considerably from the current GSE proposal I do not believe that per-ID/Locator binding state is needed in the edge routers to have a reasonably secure solution that is part of the GSE/8+8 class of solutions. I believe the threat analysis falls into basically 2 situations (assuming the hurdle is not set higher than we have today for the deployed IPv4 Internet). 1) Some protection against off-path active attacks (e.g. on binding updates), where that protection is not computationally expensive because the threat environment is believed low. 2) Serious cryptographic protection against all forms of forgeries, because the threat environment is believed high, where AH is an example of an existing sufficient solution. Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 14:30:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YHd-0006Wv-Vl; Thu, 04 Jan 2007 14:29:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YHc-0006Wp-Jy for ram@iab.org; Thu, 04 Jan 2007 14:29:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YHb-000311-Ap for ram@iab.org; Thu, 04 Jan 2007 14:29:48 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 11:29:42 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l04JTgqS020209; Thu, 4 Jan 2007 11:29:42 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l04JTbld005034; Thu, 4 Jan 2007 11:29:38 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:29:35 -0800 Received: from [192.168.0.101] ([10.21.152.83]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:29:35 -0800 In-Reply-To: <6dc651493418e36000c693ca35b1869e@it.uc3m.es> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> <6dc651493418e36000c693ca35b1869e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 11:29:34 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jan 2007 19:29:35.0061 (UTC) FILETIME=[AA85C850:01C73036] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=605; t=1167938982; x=1168802982; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20othe r=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=GmffZUJUgplp4hBKCdjHrM+13PgZCyv5p5YYJsObUI8=; b=YgLmfyddnlYIFNP4K9wzueF4Y8L4911vBHTbjjCwYfcww4PkKkhVR0scE+b58tCOeJ3IIN6y mY9UDqddwcAtkrlzx7LRlUOl9CDwEusdkJiuup4mUxL+QucWOtRd/ZqL; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > What about management of the solution? does the solution must work > automatically or is it possible that it requires manual > configuration? i mean are we designing for the dentists office? > > from the feedback i got so far, it seems that the solution should > work in a non managed environment... I'd have to agree with that. The size of the unmanaged SOHO segment that we should address is quite large. The juxtaposition of multiple access technologies and the near-ubiquity of wireless clearly makes multi-homing trivial in any urban or suburban environment. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 16:43:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aMa-0001E8-KC; Thu, 04 Jan 2007 16:43:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2aMa-0001E3-9h for ram@iab.org; Thu, 04 Jan 2007 16:43:04 -0500 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2aMZ-00036x-2p for ram@iab.org; Thu, 04 Jan 2007 16:43:04 -0500 Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v38_r7.6.) id c.d06.65b8045 (40520); Thu, 4 Jan 2007 16:42:56 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 4 Jan 2007 16:42:54 EST Subject: Re: [RAM] Goal: Minimising Routing Entropy To: rdobbins@cisco.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0029210070==" Errors-To: ram-bounces@iab.org --===============0029210070== Content-Type: multipart/alternative; boundary="-----------------------------1167946973" -------------------------------1167946973 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 04.01.2007 19:48:27 Westeurop=E4ische Normalzeit schreibt= =20 rdobbins@cisco.com: On Jan 4, 2007, at 10:23 AM, HeinerHummel@aol.com wrote: > Just consider a temporary road blockage within a city, i.e. a =20 > change inside the city map of this city. > It would not cause any change in any county/state/country/continent =20 > road map this city is part of. Er, this happens all the time in real life - so, at the very least, =20 the analogy is flawed. ;> I am sorry, not a single line of these upper road maps were affected. Heiner=20 =20 ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice -------------------------------1167946973 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 04.01.2007 19:48:27 Westeurop=E4ische Normalzeit sch= reibt=20 rdobbins@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Jan=20 4, 2007, at 10:23 AM, HeinerHummel@aol.com wrote:

> Just conside= r a=20 temporary road blockage within a city, i.e. a  
> change=20 inside the city map of this city.
> It would not cause any change in= any=20 county/state/country/continent 
> road map this city is part=20 of.

Er, this happens all the time in real life - so, at the very=20 least, 
the analogy is flawed.

;>
I am sorry, not a single line of these upper road maps were=20 affected.
Heiner 
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
-------------------------------------------------------------= ----------
Roland=20 Dobbins <rdobbins@cisco.com> // 408.527.6376=20 voice

 
-------------------------------1167946973-- --===============0029210070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0029210070==-- From ram-bounces@iab.org Thu Jan 04 20:35:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dyX-0005V4-Ev; Thu, 04 Jan 2007 20:34:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2dyV-0005RB-SJ for ram@iab.org; Thu, 04 Jan 2007 20:34:27 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2dyU-0004GT-EQ for ram@iab.org; Thu, 04 Jan 2007 20:34:27 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7ECEF122325; Fri, 5 Jan 2007 02:34:25 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp01.uc3m.es (Postfix) with ESMTP id 2383B122235; Fri, 5 Jan 2007 02:34:22 +0100 (CET) In-Reply-To: References: <20070104172911.GD32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] GSE security Date: Fri, 5 Jan 2007 02:34:37 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 04/01/2007, a las 20:11, RJ Atkinson escribi=F3: > > On 4 Jan 2007, at 13:28, marcelo bagnulo braun wrote: >> i think that in what we differ in in the view on how GSE security=20 >> would look like if done. >> I have tried to figure it out and what i found is that we will need=20= >> per identifier locator binding state (including security information)=20= >> in the edge routers and that the resulting solution differs=20 >> considerably from the current GSE proposal > > I do not believe that per-ID/Locator binding state is needed > in the edge routers to have a reasonably secure solution that > is part of the GSE/8+8 class of solutions. > > I believe the threat analysis falls into basically 2 situations > (assuming the hurdle is not set higher than we have today > for the deployed IPv4 Internet). > this goal makes sense to me (but we may have different perception of=20 what the current vulnerabilties are) > 1) Some protection against off-path active attacks (e.g. on binding > updates), where that protection is not computationally expensive > because the threat environment is believed low. What about the so-called time shifted attacks? And flooding attacks? Should we provide protection against those? (especially the first ones are quite tricky to protect from) (please see RFC4225 and RFC 4218 for a definition of these attacks) Regards, marcelo > 2) Serious cryptographic protection against all forms of forgeries, > because the threat environment is believed high, > where AH is an example of an existing sufficient solution. > > Ran > rja@extremenetworks.com > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 20:37:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e1P-0008Br-O0; Thu, 04 Jan 2007 20:37:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2e1O-0008Bm-EZ for ram@iab.org; Thu, 04 Jan 2007 20:37:26 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2e1N-0005VG-8X for ram@iab.org; Thu, 04 Jan 2007 20:37:26 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2007 20:37:25 -0500 X-IronPort-AV: i="4.12,240,1165208400"; d="scan'208"; a="110915109:sNHT40707292" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l051bOHI028661 for ; Thu, 4 Jan 2007 20:37:24 -0500 Received: from [192.168.1.101] (rtp-vpn2-101.cisco.com [10.82.240.101]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l051bM2k022072 for ; Thu, 4 Jan 2007 20:37:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <12B5C441-9F27-49DE-8A00-D22F8CF4D40B@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Thu, 4 Jan 2007 17:37:18 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=389; t=1167961045; x=1168825045; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20 |To:=20ram@iab.org; bh=CShzbHXjiTR+S6dJx7v1xeD0FcK7170RDHOq1/AcRyY=; b=Xxy25bfOf3cgol0dwbVj2SLteYbFLctQHVGfQPvjdIW4KJUajKolprrBSvnGQWWjI31vSUwo kYYD+9yA9GbYMAAAEug0GPm+xDHW6TGvxz7XF4+POxnTbycyHYWFyS9b; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 1:42 PM, HeinerHummel@aol.com wrote: > I am sorry, not a single line of these upper road maps were affected. Happens all the time, here. ;> ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 21:12:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eZK-0004Qa-68; Thu, 04 Jan 2007 21:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2eZJ-0004QV-Ca for ram@iab.org; Thu, 04 Jan 2007 21:12:29 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2eZH-0008Ug-Uk for ram@iab.org; Thu, 04 Jan 2007 21:12:29 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0257E122402; Fri, 5 Jan 2007 03:12:27 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp01.uc3m.es (Postfix) with ESMTP id 208AF122406; Fri, 5 Jan 2007 03:12:20 +0100 (CET) In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> <6dc651493418e36000c693ca35b1869e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Requirement unmanaged network support (was Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Fri, 5 Jan 2007 03:12:07 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 04/01/2007, a las 20:29, Tony Li escribi=F3: > >> What about management of the solution? does the solution must work=20= >> automatically or is it possible that it requires manual=20 >> configuration? i mean are we designing for the dentists office? >> >> from the feedback i got so far, it seems that the solution should=20 >> work in a non managed environment... > > > I'd have to agree with that. The size of the unmanaged SOHO segment=20= > that we should address is quite large. The juxtaposition of multiple=20= > access technologies and the near-ubiquity of wireless clearly makes=20 > multi-homing trivial in any urban or suburban environment. > i guess that there are a couple of comments to relax this requirement: - First, it only applies to the basic support (basic features) and=20 enhanced features may require additional (manual) tunning (i guess that=20= the complex issue here would be to define which are basic features and=20= which ones are enhanced, but as i see it, fault tolerance (in all its=20 flavors) is a basic feature and TE is an enhanced feature - Second, solutions may require expert configuration, but if this is=20 the case, it must be possible that the ISP configures the device=20 remotely (a currently available example of this approach would be=20 address/prefix configuration through DHCP) or that the ISP provides the=20= service for the customer (a currently available example of this would=20 be the reverse mapping of delegated addresses). Note that different=20 ISPs should not be required to cooperate Do you think this describes the unmanaged network support requirement=20 correctly? Regards, marcelo > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 21:24:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ekn-0002A2-Oc; Thu, 04 Jan 2007 21:24:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ekm-00027z-B0 for ram@iab.org; Thu, 04 Jan 2007 21:24:20 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ehB-0003ga-D1 for ram@iab.org; Thu, 04 Jan 2007 21:20:39 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2007 18:20:36 -0800 X-IronPort-AV: i="4.12,240,1165219200"; d="scan'208"; a="455298210:sNHT46338748" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l052KaQs031056; Thu, 4 Jan 2007 18:20:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l052KX04011024; Thu, 4 Jan 2007 18:20:34 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 18:20:33 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 18:20:33 -0800 In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> <6dc651493418e36000c693ca35b1869e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67604557-5484-4EE7-9F6A-29B2043AE318@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Requirement unmanaged network support (was Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 18:20:31 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jan 2007 02:20:33.0562 (UTC) FILETIME=[14226FA0:01C73070] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1277; t=1167963636; x=1168827636; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Requirement=20unmanaged=20network=20support=20(was=20 Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20other=20requireme nt?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=ZB2wbtkvvgGOpHx8fmiEu3dQYVICZLh1f8A9Wa3a0XA=; b=sgXUs11I4HVyLcfLVYiynsXekJBVS3cPyxyhdCx20C1goqG8wcpXpjjMQofVfAEwUrvW0ncT AKHN1ZKwfKjYJ9rb8Gq9HrU8wnlvgUpYPnETbYO/KHYn18yBAYxFDk/+; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > i guess that there are a couple of comments to relax this requirement: > - First, it only applies to the basic support (basic features) and > enhanced features may require additional (manual) tunning (i guess > that the complex issue here would be to define which are basic > features and which ones are enhanced, but as i see it, fault > tolerance (in all its flavors) is a basic feature and TE is an > enhanced feature > - Second, solutions may require expert configuration, but if this > is the case, it must be possible that the ISP configures the device > remotely (a currently available example of this approach would be > address/prefix configuration through DHCP) or that the ISP provides > the service for the customer (a currently available example of this > would be the reverse mapping of delegated addresses). Note that > different ISPs should not be required to cooperate > > Do you think this describes the unmanaged network support > requirement correctly? It's certainly adequate. If you buy a SOHO box today, it pretty much has NAT and DHCP already enabled by default. Certainly bells and whistles might get fancier, but that's not the real issue. The point is to solve the 90% case simply. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 04 21:24:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2elA-0002cS-Bl; Thu, 04 Jan 2007 21:24:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2el9-0002cF-JP for ram@iab.org; Thu, 04 Jan 2007 21:24:43 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2el7-00052k-CS for ram@iab.org; Thu, 04 Jan 2007 21:24:43 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jan 2007 21:24:39 -0500 X-IronPort-AV: i="4.12,240,1165208400"; d="scan'208"; a="110916790:sNHT48389032" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l052Oddl008675 for ; Thu, 4 Jan 2007 21:24:39 -0500 Received: from [192.168.1.101] (rtp-vpn2-101.cisco.com [10.82.240.101]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l052Oc7f000156 for ; Thu, 4 Jan 2007 21:24:38 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> <6dc651493418e36000c693ca35b1869e@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: Requirement unmanaged network support (was Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Thu, 4 Jan 2007 18:24:35 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=840; t=1167963879; x=1168827879; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20Requirement=20unmanaged=20network=20support=20(was=20 Re=3A=20one=20size=20doesn'=20fit=20all=20(was=20Re=3A=20other=20requireme nt?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=HjxjgWUnfaZSxXZTN22Pqlz8b1Bwucz+nxvmOHNOyqE=; b=yaeU6ZJ47V5AqWsTm5DUAfWH7ylthZCJwzhYrbJbUn7qaSElMBSJzi2H/124lM0DF6eCmKUE nDhKXZcL95JW5k6qzZ4G7eJdgq1/VrM9PM0AJLzApzZTUBZ67My6LpbD; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 4, 2007, at 6:12 PM, marcelo bagnulo braun wrote: > Do you think this describes the unmanaged network support > requirement correctly? FWIW, I like 'unmanaged' much better than 'SOHO', as it can describe an easily-agreed-upon condition and a congruent set of base capabilities, rather than attempting to define a nebulous term like 'SOHO'. If there's going to be a split (something I still don't like, but can live with if it really seems necessary), it seems that capabilities would be the only objective way to predicate the split, since one customer's SOHO is another's colo, heh. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 05:16:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2m62-0002Kw-QD; Fri, 05 Jan 2007 05:14:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2m61-0002K7-2J for ram@iab.org; Fri, 05 Jan 2007 05:14:45 -0500 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2m5x-0003fh-7M for ram@iab.org; Fri, 05 Jan 2007 05:14:45 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBE4G400.C6M; Fri, 5 Jan 2007 11:14:28 +0100 In-Reply-To: <459CFFE8.8090909@cisco.com> X-Priority: 1 (High) Subject: Re: [RAM] Destination Locator selection To: Russ White X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Fri, 5 Jan 2007 11:14:25 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 05/01/2007 11:13:17 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ, See below. Russ White escribi=F3 el 04/01/2007 14:23:52: > I have a fundamental issue with overloading identifiers with > locators.... While I know that's what we are doing today, it's really= > what started this whole problem, and I don't see where going farther > down this road really solves anything. IMHO there is a difference: - What we have today: IP address is overloaded because the locator role is statically mapped to the identifier role and cannot be changed. This is why with pure CIDR (i.e. using PA blocks) you have to renumber your network when you move to another ISP. - With a mechanism like TIDR we don't overload the identifier. We just dynamically add a locator to the identifier. And the locator will be provided by your ISP. > > IMHO, TIDR will increase capex and opex problems, not solve them. I don't know much about this. Can you explain more?. I too wonder what is the effect of other solutions, like HIP or SHIM6, to capex and opex. I think we have mainly two problems to solve: (1) scalability of the global BGP table, (2) BGP churn. See below the latest "RIPE RIS Weekly Statistics Report" <-----BEGIN-----> RIS Statistics Report (20061225-20070101) This report was generated at Mon Jan 1 00:15:01 UTC 2007. o Number of single-homed ASes. RIS rrc00 rrc01 ARIN 3916 4908 4123 APNIC 761 878 896 RIPENCC 2786 3398 3558 LACNIC 116 135 141 AFRINIC 17 17 12 IANA 0 0 0 Private 43 24 17 Others 0 0 0 Total 7639 9360 8747 o Number of multi-homed ASes. RIS rrc00 rrc01 ARIN 8300 7281 4684 APNIC 2035 1905 1649 RIPENCC 6268 5607 4709 LACNIC 159 139 110 AFRINIC 13 13 11 IANA 0 0 0 Private 28 25 8 Others 0 0 0 Total 16804 14971 11172 o Distribution of AS number wrt Leaf, Transit. RIS rrc00 rrc01 Leaf 20397 20454 16395 Transit 3917 3753 3244 Transit-only 135 129 282 Total 24449 24336 19921 <-----END-----> It roughly shows that 5 AS-es out of 6 are leaf AS-es. The important point to note here is that leaf AS-es don't really participate in true INTER-domain routing: they are just "guests" that generate a lot of BGP updates but don't move any transit packet. > I'll put it another way: To scale, you must hide information. This is= a > fundamental rule of all large complex systems. ... > o Vertical hierarchy, where you remove information at layer edges in = the > system. For instance, the IGP/EGP split is vertical hierarchy. TIDR proposes a method to base inter-domain routing on locator prefixes generated by transit AS-es by moving identifier prefixes from the RIB to a new table, the TIB. Therefore, rather than removing information TIDR assigns different roles to identifier prefixes (tunnel imposition) and locator prefixes (actual routing). In addition to this, BGP updates for identifier prefixes will be less important than BGP updates for locator prefixes in terms of the Internet routing stability. So, this fact would mitigate the effect of the BGP update churn. > IMHO, TIDR is an extreme case of vertical hierarchy, just as many oth= er > network virtualization schemes are. They look good on the map, as lon= g > as you think you're far enough away from the little sign that says: > "Here be dragons." The question is, always, how far away is far enoug= h away? I see some flaws with TIDR but I don't see the dragons yet. :-) Any clue?. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 05:21:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mCZ-0000O5-3I; Fri, 05 Jan 2007 05:21:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mCX-0000Ny-E3 for ram@iab.org; Fri, 05 Jan 2007 05:21:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mCW-0005UU-7f for ram@iab.org; Fri, 05 Jan 2007 05:21:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2007 05:21:28 -0500 X-IronPort-AV: i="4.12,242,1165208400"; d="scan'208"; a="110932423:sNHT41467352" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05ALRTX003888 for ; Fri, 5 Jan 2007 05:21:27 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05ALR2k022162 for ; Fri, 5 Jan 2007 05:21:27 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 (High) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Fri, 5 Jan 2007 02:21:21 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=471; t=1167992487; x=1168856487; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=LB86B+85SEo7/+dU7urapfzQQYbCI0eLzyPTgWSt9yY=; b=0iJczW7blBzGQyvbNLHM15Pzo+DpSEfKHqywnMjD1ic8c4Lav+V3pDjAQh8I+y+2sU0Taz/P QqtsM2Tskr7YpTrROyqUcHCYTeA7+Jy+hgcnBgineG9b+WTgczLeMI/R; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 2:14 AM, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > I too wonder > what is the effect of other solutions, like HIP or SHIM6, to capex > and opex. This has been discussed at length during the last week, it's in the list archives. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 05:37:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mS4-0008EF-Ue; Fri, 05 Jan 2007 05:37:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mS3-0008E7-QP for ram@iab.org; Fri, 05 Jan 2007 05:37:31 -0500 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mS2-0003AF-Bx for ram@iab.org; Fri, 05 Jan 2007 05:37:31 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBE5IH00.H3W; Fri, 5 Jan 2007 11:37:29 +0100 In-Reply-To: X-Priority: 1 (High) Subject: Re: [RAM] Goal: Minimising Routing Entropy To: HeinerHummel@aol.com X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Fri, 5 Jan 2007 11:37:23 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 05/01/2007 11:36:17 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Heiner, I think you are right HeinerHummel@aol.com escribi=F3 el 04/01/2007 19:23:13: > Well, with Hierarchical Routing the routing churn rate will > dramatically be reduced. I think you are right. With hierarchical routing not all parts of the network are equally important. So, an announcement or withdrawal of a peripheral prefix will be far less important than that of a prefix of the core. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 05:49:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mdS-0003to-Rk; Fri, 05 Jan 2007 05:49:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mdR-0003tM-Fr for ram@iab.org; Fri, 05 Jan 2007 05:49:17 -0500 Received: from out5.smtp.messagingengine.com ([66.111.4.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mdQ-0005GZ-9t for ram@iab.org; Fri, 05 Jan 2007 05:49:17 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 901F65C05B; Fri, 5 Jan 2007 05:46:23 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 05 Jan 2007 05:46:23 -0500 X-Sasl-enc: fNdEQZNXGzZS2Q7g8gta0rey5hR7rpeMwxUjLIRU6H8s 1167993982 Received: from [127.0.0.1] (64-191-130-57.service.qx.net [64.191.130.57]) by mail.messagingengine.com (Postfix) with ESMTP id 69EB527F92; Fri, 5 Jan 2007 05:46:20 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: Roland Dobbins In-Reply-To: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> Content-Type: text/plain Date: Fri, 05 Jan 2007 11:49:00 +0100 Message-Id: <1167994140.13954.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 2007-01-05 at 02:21 -0800, Roland Dobbins wrote: > On Jan 5, 2007, at 2:14 AM, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > > > I too wonder > > what is the effect of other solutions, like HIP or SHIM6, to capex > > and opex. > > This has been discussed at length during the last week, it's in the > list archives. Not really. We've seen a number of conclusions ("doesn't scale*, doesn't work", "unreasonable capex/opex" etc), but very few supporting factual arguments needed for others to make their own independent evaluation. At this early stage of research/specification these concerns can just as easily be interpreted as a set of requirements which have to be met for new such technologies to succeed ... with automated site-wide administration of addresses/prefixes and traffic-engineering being the 2 dominating issues. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 06:03:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mqY-0000RB-5P; Fri, 05 Jan 2007 06:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2mqW-0000Px-97 for ram@iab.org; Fri, 05 Jan 2007 06:02:48 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2mqV-0000UM-1u for ram@iab.org; Fri, 05 Jan 2007 06:02:48 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2007 06:02:47 -0500 X-IronPort-AV: i="4.12,242,1165208400"; d="scan'208"; a="110934106:sNHT42522350" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05B2kGE013229 for ; Fri, 5 Jan 2007 06:02:46 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05B2k2k029005 for ; Fri, 5 Jan 2007 06:02:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1167994140.13954.14.camel@localhost.localdomain> References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> <1167994140.13954.14.camel@localhost.localdomain> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Fri, 5 Jan 2007 03:02:42 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=557; t=1167994966; x=1168858966; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=gwAvxUkebIzyP+HPEf0oi9/tNuPoET0nS1+K/fc7YHg=; b=BqrsSvZBpc/Bv1ymzzEp+mdT1g1Ls0bKuBck4l6MUNAVfWZil2VjeF77bIedrMn9zswWYNGw iih3CuY7edNI2zdlqO0/ymoN39pz4Z6dZOGBxhidhp4PZB2nmwlmLk12; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 2:49 AM, Per Heldal wrote: > but very few supporting factual > arguments needed for others to make their own independent evaluation. This is incorrect - very specific reasons were given in terms of CAPEX, OPEX and ongoing supportability. You can of course ignore or discount them if you wish, but they're there. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 06:57:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ngS-00045d-FV; Fri, 05 Jan 2007 06:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ngP-00045W-Lq for ram@iab.org; Fri, 05 Jan 2007 06:56:25 -0500 Received: from out5.smtp.messagingengine.com ([66.111.4.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ngL-0007kg-EN for ram@iab.org; Fri, 05 Jan 2007 06:56:25 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 3B1095CCEB; Fri, 5 Jan 2007 06:53:34 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 05 Jan 2007 06:53:34 -0500 X-Sasl-enc: 0iUE/DaHBJyszhcJtaXmDJ4UKruvXjcqoLY6T4dOUOms 1167998013 Received: from [127.0.0.1] (unknown [149.9.0.57]) by mail.messagingengine.com (Postfix) with ESMTP id 8F2E028068; Fri, 5 Jan 2007 06:53:32 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: Roland Dobbins In-Reply-To: References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> <1167994140.13954.14.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 05 Jan 2007 12:56:14 +0100 Message-Id: <1167998174.13954.31.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shim6@psg.com List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 2007-01-05 at 03:02 -0800, Roland Dobbins wrote: > On Jan 5, 2007, at 2:49 AM, Per Heldal wrote: > > > but very few supporting factual > > arguments needed for others to make their own independent evaluation. > > This is incorrect - very specific reasons were given in terms of > CAPEX, OPEX and ongoing supportability. You can of course ignore or > discount them if you wish, but they're there. I still don't understand how you can make assumptions about expenses and workload without knowing how the complete toolchain will be implemented. IPv4 deployment and support without DHCP and basic tools for troubleshooting like traceroute and ping would be a pain, yet I'm not comfortable with assumption that there will be no working equivalents for a shim6-environment. Anyway, this is now quite OT this list. Further discussion should happen on the shim6-list where operational concerns are welcome. It's been suggested to create a prioritised list of such as input to the development-process. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 07:27:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oAP-0008QG-Ll; Fri, 05 Jan 2007 07:27:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oAP-0008Pn-0E for ram@iab.org; Fri, 05 Jan 2007 07:27:25 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oAN-0007gu-Ou for ram@iab.org; Fri, 05 Jan 2007 07:27:24 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 04:27:22 -0800 X-IronPort-AV: i="4.12,242,1165219200"; d="scan'208"; a="50058958:sNHT46333992" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05CRL9u030892 for ; Fri, 5 Jan 2007 07:27:21 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l05CRL7f009984 for ; Fri, 5 Jan 2007 07:27:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1167998174.13954.31.camel@localhost.localdomain> References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> <1167994140.13954.14.camel@localhost.localdomain> <1167998174.13954.31.camel@localhost.localdomain> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F47D1EF-4CDA-423E-B922-4EA8421347B4@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Destination Locator selection Date: Fri, 5 Jan 2007 04:27:17 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2272; t=1168000041; x=1168864041; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Destination=20Locator=20selection |Sender:=20 |To:=20ram@iab.org; bh=fGlzEkZKX4ulYcr7u0wuw/Q5U93dARXKTpwOxreqIu8=; b=cZn61p5jh5NhU728mcQ7vtt467xURWgXfpuKuDDHiMrjNakcleB5+3BR3AVyMboM0dUQN3Pf 2cXvEwFreHm0qkJJHjEnKUq4DF/+R2AJBVb1uRxzD0g2EkZgSPWnrUmV; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [removed shim6@psg.com] On Jan 5, 2007, at 3:56 AM, Per Heldal wrote: > I still don't understand how you can make assumptions about > expenses and > workload without knowing how the complete toolchain will be > implemented. Double or treble or n^2 the amount of ACL entries, firewall rules, QoS matching policies, etc., is still double or treble or n^2 the amount of ACL entries, firewall rules, QoS matching policies, etc. TCAM space which is not unlimited, RAM which is not unlimited, processors which are not unlimited are still TCAM space which is not unlimited, RAM which is not unlimited, processors which are not unlimited. The undesirable effects of mandating dynamic host selection of the initial path for egress packets are still the undesirable effects of mandating dynamic host selection of the initial path for egress packets. The additional support burden for/ in addition to all of the above is still the additional support burden for/in addition to all of the above. I'm also sort of confused as to how a subject which has been considered on-topic for the past week, with plenty of participants with lots of input, is now unilaterally deemed suddenly off-topic. Yes, it's somewhat redundant to have to read the same responses to the same set of questions we started with a week ago; it's also redundant to have to type them over again. So, since it has already been stipulated by multiple participants in this discussion that these issues are in fact germane and must be taken into account while working towards an operationally-feasible multihoming solution, I would ask that a) we not attempt to undo that stipulation, b) folks who're coming late to this set of threads skim through the archives to understand the points which were raised, c) when folks are directed to the archives, they aren't told that these issues haven't been discussed, because they have been discussed, and d) we not cross-post between lists, as it's considered poor form. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:14:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2otE-0004W8-Eo; Fri, 05 Jan 2007 08:13:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2otC-0004Vz-Mu for ram@iab.org; Fri, 05 Jan 2007 08:13:42 -0500 Received: from out5.smtp.messagingengine.com ([66.111.4.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2otA-0002dP-Dn for ram@iab.org; Fri, 05 Jan 2007 08:13:42 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 997F45D066; Fri, 5 Jan 2007 08:10:52 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 05 Jan 2007 08:10:52 -0500 X-Sasl-enc: Ep9b0NZjQLQmg50VI2C9ekoKlxY3DypQIpeH4Co3lIOX 1168002643 Received: from [127.0.0.1] (unknown [204.13.236.244]) by mail.messagingengine.com (Postfix) with ESMTP id 5935728130; Fri, 5 Jan 2007 08:10:33 -0500 (EST) Subject: Re: [RAM] Destination Locator selection From: Per Heldal To: Roland Dobbins In-Reply-To: <2F47D1EF-4CDA-423E-B922-4EA8421347B4@cisco.com> References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> <1167994140.13954.14.camel@localhost.localdomain> <1167998174.13954.31.camel@localhost.localdomain> <2F47D1EF-4CDA-423E-B922-4EA8421347B4@cisco.com> Content-Type: text/plain Date: Fri, 05 Jan 2007 14:12:29 +0100 Message-Id: <1168002749.13954.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shim6@psg.com List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 2007-01-05 at 04:27 -0800, Roland Dobbins wrote: > [removed shim6@psg.com] > > On Jan 5, 2007, at 3:56 AM, Per Heldal wrote: > > > I still don't understand how you can make assumptions about > > expenses and > > workload without knowing how the complete toolchain will be > > implemented. > > Double or treble or n^2 the amount of ACL entries, firewall rules, > QoS matching policies, etc., is still double or treble or n^2 the > amount of ACL entries, firewall rules, QoS matching policies, etc. Correct, but assuming there will be no shim-aware middleboxes. (which I forgot to mention in my last msg, and consider a natural development and part of the complete tool-chain for shim6). Much of today's operational mess is the result of questionable engineering practises rather than architectural deficiencies. Quite a few vendors could benefit from some redesign related to shim-support. > TCAM space which is not unlimited, RAM which is not unlimited, > processors which are not unlimited are still TCAM space which is not > unlimited, RAM which is not unlimited, processors which are not > unlimited. Hardware limitations are real, but it may also be seen as a tradeoff to be able to curb the ever increasing size of BGP-tables and route-churn. I.e. a lot like discussing horisontal vs vertical scaling in the datacenter arena. Historically it has been easier to scale at the edges of the network than in the core as the core operates closer to the limits of what is possible with current technology. > > The undesirable effects of mandating dynamic host > selection of the initial path for egress packets are still the > undesirable effects of mandating dynamic host selection of the > initial path for egress packets. The additional support burden for/ > in addition to all of the above is still the additional support > burden for/in addition to all of the above. > Again true, and especially important to bigger sites. Yet, the picture changes if you introduce some form of "policy director" to coordinate and possibly centralise path- and locator-selection and thus keep TE-management firmly in the hands of network ops. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:23:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p2P-0000G7-2y; Fri, 05 Jan 2007 08:23:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p2N-0000EA-9J for ram@iab.org; Fri, 05 Jan 2007 08:23:11 -0500 Received: from smtp.dynsipr.ucl.ac.be ([130.104.4.3] helo=smtp-3.dynsipr.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2p2K-0004O4-QX for ram@iab.org; Fri, 05 Jan 2007 08:23:11 -0500 Received: from smtp-3.dynsipr.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp-3.dynsipr.ucl.ac.be (Postfix) with ESMTP id B464E13F88; Fri, 5 Jan 2007 14:23:04 +0100 (CET) Received: from [130.104.233.97] (dhcpifsa33.fsa.ucl.ac.be [130.104.233.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp-3.dynsipr.ucl.ac.be) by smtp-3.dynsipr.ucl.ac.be (Postfix) with ESMTP; Fri, 5 Jan 2007 14:23:04 +0100 (CET) Message-ID: <459E5137.2060609@info.ucl.ac.be> Date: Fri, 05 Jan 2007 14:23:03 +0100 From: Olivier Bonaventure User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: heldal@eml.cc Subject: Re: [RAM] Destination Locator selection References: <27768723-ABE0-4460-A5CE-24C04B0D5532@cisco.com> <1167994140.13954.14.camel@localhost.localdomain> <1167998174.13954.31.camel@localhost.localdomain> <2F47D1EF-4CDA-423E-B922-4EA8421347B4@cisco.com> <1168002749.13954.65.camel@localhost.localdomain> In-Reply-To: <1168002749.13954.65.camel@localhost.localdomain> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-SGSI-MailScanner: Found to be clean X-SGSI-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-22.5, requis 5, autolearn=not spam, BAYES_00 -2.60, RCVD_AUTH_OK -20.00, SARE_FROM_SPAM_WORD3 0.10, SPF_HELO_PASS -0.00) X-SGSI-MailScanner-From: bonaventure@info.ucl.ac.be X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bonaventure@info.ucl.ac.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Per, > > >>The undesirable effects of mandating dynamic host >>selection of the initial path for egress packets are still the >>undesirable effects of mandating dynamic host selection of the >>initial path for egress packets. The additional support burden for/ >>in addition to all of the above is still the additional support >>burden for/in addition to all of the above. >> > > > Again true, and especially important to bigger sites. Yet, the picture > changes if you introduce some form of "policy director" to coordinate > and possibly centralise path- and locator-selection and thus keep > TE-management firmly in the hands of network ops. I completely agree. I don't believe that enterprise networks will leave the decision of the selection of the sourceaddress (and path) completely to the end hosts. A better approach is to have a policy director that suggests decision to the host (either by a query response protocol or other means) so that all hosts in the enterprise make approriate decisions. For a description of this approach, see : C. de Launois, O. Bonaventure, and M. Lobelle. The NAROS approach for IPv6 multihoming with traffic engineering. In 4th COST 263 International Workshop on Quality of Future Internet Services (QoFIS 2003), volume LNCS 2811, pages 112-121, Stockholm, Sweden, October 1-3rd 2003. Springer-Verlag. Available from http://totem.info.ucl.ac.be/publications.html This paper takes load balancing in a campus network as a case study and shows that a policy director can easily achieve almost perfect load balancing between its providers without an excessive load on the policy director. The same approach could be used for other policies. Best regards, Olivier -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:28:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p75-0002oJ-NW; Fri, 05 Jan 2007 08:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2p73-0002o9-TP for ram@iab.org; Fri, 05 Jan 2007 08:28:01 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2p70-0004yO-HS for ram@iab.org; Fri, 05 Jan 2007 08:28:01 -0500 Received: from [10.18.2.20] (unknown [10.18.2.20]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 3210A7941 for ; Fri, 5 Jan 2007 05:27:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <20070104172911.GD32409@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: RJ Atkinson Subject: Re: [RAM] GSE security Date: Fri, 5 Jan 2007 08:27:50 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 4 Jan 2007, at 20:34, marcelo bagnulo braun wrote: > El 04/01/2007, a las 20:11, RJ Atkinson escribi=F3: >> 1) Some protection against off-path active attacks (e.g. on binding >> updates), where that protection is not computationally expensive >> because the threat environment is believed low. > > What about the so-called time shifted attacks? > And flooding attacks? > Should we provide protection against those? > > (especially the first ones are quite tricky to protect from) > (please see RFC4225 and RFC 4218 for a definition of these attacks) It is not reasonable to require more from IPv6 or some enhancement to IPv6 than we currently require from *the deployed IPv4 Internet* with regards to various kinds of attacks. Generally speaking, security solutions for one version of IP also will apply to another version of IP. The kinds of architectural enhancements that I've seen discussed on the RAM list don't obviously change that. All of the kinds of things you cite above are possible today in the IPv4 Internet, absent using something with strong cryptography -- along the lines of ESP/AH.=20 ESP/AH are available for both IPv4 and IPv6, and presumably for any IPv6 enhancements. In fact, the original ESP/AH code at NRL was mostly the same code path, with just a few branch instructions that were based on the IP version field. So those items you cite above are not legitimately in the scope for the situations where "the threat environment is believed low". Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:49:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pRN-0002u2-My; Fri, 05 Jan 2007 08:49:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pRM-0002tx-MI for ram@iab.org; Fri, 05 Jan 2007 08:49:00 -0500 Received: from xmail08.myhosting.com ([168.144.250.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pRL-0000xK-Ci for ram@iab.org; Fri, 05 Jan 2007 08:49:00 -0500 Received: (qmail 29276 invoked from network); 5 Jan 2007 13:48:48 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with SMTP for ; 5 Jan 2007 13:48:48 -0000 Message-ID: <459E5736.1000307@cisco.com> Date: Fri, 05 Jan 2007 08:48:38 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Li Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@cisco.com> <4348C238-306E-4107-BD36-CA43A5DDF07D@cisco.com> <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@cisco.com> <21B31D0A-3C73-45C7-A029-EB86DBED9E5F@cisco.com> <81D1F978-B756-4CF2-B794-808202045901@cisco.com> <7c5d0a853a1cd13025cc2f9cbc9de9ac@it.uc3m.es> <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> In-Reply-To: <9E8E616A-C090-4C4E-8158-BE210BE0E1EC@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > No, I wouldn't go that far. I would say that we will need mechanisms > that allow ASBRs to discover one another and exchange information. I > think that the most that we might get is a knob flipped on the ASBR that > would both enable this mechanism and advertise the capability, > presumably in the IGP. While I think we need the autodiscovery, I would leave the IGP out of it if possible. IMHO, IGPs themselves are being overloaded with virtualization at a rate that's going to make them difficult to design and manage. Overloading them with EGP discovery might not be the best way of going about this. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnlc2ER27sUhU9OQRAjFRAKDHzA0gESzOAhlRuXm2e+y+dcn3ZQCg/K69 H7hNE7B2hc6YcdCSNTiUlvo= =ZoZ0 -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:51:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pU3-0003m7-Tz; Fri, 05 Jan 2007 08:51:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pU2-0003ly-DY for ram@iab.org; Fri, 05 Jan 2007 08:51:46 -0500 Received: from xmail05.myhosting.com ([168.144.250.219]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pU1-0001os-62 for ram@iab.org; Fri, 05 Jan 2007 08:51:46 -0500 Received: (qmail 16300 invoked from network); 5 Jan 2007 13:51:44 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with SMTP for ; 5 Jan 2007 13:51:44 -0000 Message-ID: <459E57E6.2050008@cisco.com> Date: Fri, 05 Jan 2007 08:51:34 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] Goal: Minimising Routing Entropy References: <12B5C441-9F27-49DE-8A00-D22F8CF4D40B@cisco.com> In-Reply-To: <12B5C441-9F27-49DE-8A00-D22F8CF4D40B@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I am sorry, not a single line of these upper road maps were affected. > > Happens all the time, here. How does a city street changing from one way to two way, or closing down, impact the topology of major highways around the city? I can see it impacting the traffic on those highways, but the physical position of the highways is certainly unchanged, isn't it? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnlfmER27sUhU9OQRAsLnAJ9whkKa3qaCjO0AOxqgTdjawZnmQACfcN36 mw59tQ3TtEvHcvrIvOk4ftM= =Ubs9 -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:54:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pWb-0005ZX-J8; Fri, 05 Jan 2007 08:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pWa-0005ZL-B7 for ram@iab.org; Fri, 05 Jan 2007 08:54:24 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pWY-0002Pi-Ul for ram@iab.org; Fri, 05 Jan 2007 08:54:24 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l05DsLjm172192 for ; Fri, 5 Jan 2007 13:54:21 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l05DsL9k1601786 for ; Fri, 5 Jan 2007 13:54:21 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l05DsKDE020190 for ; Fri, 5 Jan 2007 13:54:21 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l05DsKgG020184; Fri, 5 Jan 2007 13:54:20 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA337428; Fri, 5 Jan 2007 14:54:20 +0100 Message-ID: <459E588D.4040304@zurich.ibm.com> Date: Fri, 05 Jan 2007 14:54:21 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com><7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <06e001c72bac$bb7ab960$6a01a8c0@china.huawei.com> <45962265.2050308@piuha.net> <459D2601.2020704@zurich.ibm.com> <9955468F-A5A9-40CF-9D83-A7DB7B0A132D@cisco.com> In-Reply-To: <9955468F-A5A9-40CF-9D83-A7DB7B0A132D@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-04 17:13, Roland Dobbins wrote: > > On Jan 4, 2007, at 8:06 AM, Brian E Carpenter wrote: > >> This is nothing to do with shim6. Any IPv6 host can have multiple >> addresses, and many do. Any IPv4 host can have multiple addresses, >> for that matter (my laptop appears to have three at the moment). I'm >> not sure what the new threat is... > > It has everything to do with SHIM6, because the vast majority of hosts > in the world do not currently have multiple IP addresses which are in > active use, and it is undesirable (for the many reasons previously > outlined on these threads) to try and make multiple IP addresses with > dynamic host selection of the initial path for egress traffic mandatory > for multihomed sites. So you've asserted. But the context of my question was botnet capture. Why does shim6 increase the threat caused by botnet capture? However, I'd rather we stopped discussing shim6 here. It isn't the basic topic, and it will sink or swim on its own merits. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 08:59:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pbX-000800-EE; Fri, 05 Jan 2007 08:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pbV-0007zp-Df for ram@iab.org; Fri, 05 Jan 2007 08:59:29 -0500 Received: from xmail08.myhosting.com ([168.144.250.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2pbU-0003hi-5t for ram@iab.org; Fri, 05 Jan 2007 08:59:29 -0500 Received: (qmail 30105 invoked from network); 5 Jan 2007 13:59:28 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with SMTP for ; 5 Jan 2007 13:59:27 -0000 Message-ID: <459E59B5.5020003@cisco.com> Date: Fri, 05 Jan 2007 08:59:17 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> In-Reply-To: <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm intrigued by this. To my way of thinking, the churn rate is an > artifact of BGP's design, the actual physical changes in the topology, > and operational input. It doesn't really seem to be architectural, it's > just a side-effect of the control plane mechanisms that we've chosen. I would tend to say it's more of an artifact of the way BGP has been deployed, due to operational and financial pressures combined with the AS Path hunting effect you get when removing a destination or short path from the system. I think (?) that no matter if we got rid of BGP's hunting effect (which is possible without totally replacing BGP, I think), we would still have some measurable churn because of simple deployment issues. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnlm1ER27sUhU9OQRAqjGAJ9JLy0s0YknMQz8KiHsTjlRAmUM0gCfRXcY V44uqi57peTfWv+pV7C/TFQ= =WZ1C -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 09:13:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2pob-0004j0-9a; Fri, 05 Jan 2007 09:13:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2poZ-0004it-Rt for ram@iab.org; Fri, 05 Jan 2007 09:12:59 -0500 Received: from xmail07.myhosting.com ([168.144.250.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2poY-000767-Hh for ram@iab.org; Fri, 05 Jan 2007 09:12:59 -0500 Received: (qmail 16676 invoked from network); 5 Jan 2007 14:12:58 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with SMTP for ; 5 Jan 2007 14:12:57 -0000 Message-ID: <459E5CDF.8040302@cisco.com> Date: Fri, 05 Jan 2007 09:12:47 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JUAN-JOSE.ADAN@giss.seg-social.es Subject: Re: [RAM] Destination Locator selection References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I have a fundamental issue with overloading identifiers with >> locators.... While I know that's what we are doing today, it's really >> what started this whole problem, and I don't see where going farther >> down this road really solves anything. > > IMHO there is a difference: > - What we have today: IP address is overloaded because the > locator role is statically mapped to the identifier role > and cannot be changed. This is why with pure CIDR (i.e. > using PA blocks) you have to renumber your network when you > move to another ISP. You're looking at it from the routing perspective--from the application level, IP addresses are already overloaded as both. Overloading at the routing layer doesn't really help the problem we've hit by overloading at the application layer. > - With a mechanism like TIDR we don't overload the identifier. > We just dynamically add a locator to the identifier. And the > locator will be provided by your ISP. You're using IP addresses for both, so you're overloading the IP address space as both locators and identifiers. >> IMHO, TIDR will increase capex and opex problems, not solve them. > > I don't know much about this. Can you explain more?. I too wonder > what is the effect of other solutions, like HIP or SHIM6, to capex > and opex. There are solutions beyond HIP, SHIM6, and TIDR. We shouldn't be in the position of saying: "TIDR requires less opex than SHIM6, so we go with TIDR." We should be in the position of saying: "The amount of acceptable OPEX is X, if any solution is over X, we look for another solution." > I think we have mainly two problems to solve: (1) scalability of > the global BGP table, (2) BGP churn. TIDR "solves" both though virtualization. My point is that while this seems attractive, we must remember that we already have L3VPNs, which are the same sort of virtualization at a different level, and we're getting into heavy virtualization within enterprise networks, as well. The question is, when you start layering virtualizations on top of one another, what sort of mess do you create in terms of being able to manage and troubleshoot the layers? We've already seen that hierarchical layers of more than four or five deep can make things difficult to troubleshoot, etc, so we tend to virtualize beyond that. How many layers of virtualization will we hit before we run into the same problem? And will massive virtualization also "ossify" the network, leaving us no "out" for the next problem (not yet even imagined) we hit? In other words, virtualization isn't a panacea, any more than topological hierarchy is. Whatever we do needs to mix the two in a logical way, given current deployment patterns and current designs. > I see some flaws with TIDR but I don't see the dragons yet. :-) > Any clue?. You only see the dragons if you start to look at the virtualizations piled on top of one another. Any given virtualization might make sense, standing on its own, but building a stack of them becomes problematic. Think of a game of Jinga, I think it is, where you stack the wood blocks up, and then try to pull out the bottom ones. You can pile the blocks to make the base bigger (topological hierarchy), but, at some point, this becomes impractical. You can also pile the blocks in very inventive ways to make the stack taller, but, over time, you ossify the pile, making it harder and harder to change anything towards the bottom. At the same time, you make the stack more brittle, more prone to catastrophic failure with a single shift in a block at the bottom. Balance is what's required. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnlzfER27sUhU9OQRAigeAKCCErf3lqpzc5XopKw0AW0fy5YHyQCgpb1U zY3p2selhyhHWyRkFqdExMM= =VM2i -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 09:31:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q5r-0004Hg-I0; Fri, 05 Jan 2007 09:30:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2q5p-0004Gp-RU for ram@iab.org; Fri, 05 Jan 2007 09:30:49 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2q5o-0002wc-FV for ram@iab.org; Fri, 05 Jan 2007 09:30:49 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l05EUhaI152786 for ; Fri, 5 Jan 2007 14:30:44 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l05EUhde1323130 for ; Fri, 5 Jan 2007 14:30:43 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l05EUhr5026950 for ; Fri, 5 Jan 2007 14:30:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l05EUhVl026945 for ; Fri, 5 Jan 2007 14:30:43 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA337422 for ; Fri, 5 Jan 2007 15:30:42 +0100 Message-ID: <459E6113.9060404@zurich.ibm.com> Date: Fri, 05 Jan 2007 15:30:43 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ram@iab.org References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [RAM] PI v locator rewriting [Re: one size doesn' fit all] X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-03 16:42, Roland Dobbins wrote: ... > The sudden tolerance for PI space gratifies/puzzles me, though - I > thought it was anathema, and that folks here aren't't in the main amused > that PI space is being allocated. If PI space is now tolerable, then we > can all go home and call it a day, I think we should be clear that today we appear to have to choose between (1) PI prefixes, which break aggregation, and (2) locator rewriting, which allows aggregation. Locator rewriting comes in many forms*, some of which are still theoretical, but they are all isomorphic at some level. If anybody knows a third choice, that would be of great interest. *e.g. NAT, map and encap, GSE, shim6 Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 10:03:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qaf-0001rc-2D; Fri, 05 Jan 2007 10:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qad-0001pq-Gu for ram@iab.org; Fri, 05 Jan 2007 10:02:39 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qab-0002RW-28 for ram@iab.org; Fri, 05 Jan 2007 10:02:39 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l05F2ZdL171796 for ; Fri, 5 Jan 2007 15:02:35 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l05F2Z03593920 for ; Fri, 5 Jan 2007 16:02:35 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l05F2Yoc020298 for ; Fri, 5 Jan 2007 16:02:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l05F2Ytm020291; Fri, 5 Jan 2007 16:02:34 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA40778; Fri, 5 Jan 2007 16:02:33 +0100 Message-ID: <459E688A.1000905@zurich.ibm.com> Date: Fri, 05 Jan 2007 16:02:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] Goal: Minimising Routing Entropy References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> <20070104183653.GA5990@1-4-5.net> In-Reply-To: <20070104183653.GA5990@1-4-5.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Tony Li , RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-04 19:36, David Meyer wrote: > On Thu, Jan 04, 2007 at 10:20:11AM -0800, Tony Li wrote: >>>> My instinct is that this is a Good Thing, but my other concern >>>> is churn rates (which are obviously related to entropy >>>> among other things). I'd rather get a handle on the dynamics >>>> before being sure whether the target should be entropy >>>> itself or some aspect of the churn. >>> As you might imagine, I agree with this statement. >> >> I'm intrigued by this. To my way of thinking, the churn rate is an >> artifact of BGP's design, the actual physical changes in the >> topology, and operational input. It doesn't really seem to be >> architectural, it's just a side-effect of the control plane >> mechanisms that we've chosen. If that turns out to be true, it's excellent news - we don't need to change the architecture, we just need to fix the control plane. Seriously. > > I think I can agree with that. My goal in studying > network dynamics are two-fold: First, I'd like to build > an unbiased (in the statistical sense) model (or just > find one) that will help us understand the dynamic nature > of the BGP UPDATE stream. This may not be architectural, > but these studies do help us to better understand the > properties of BGP. Second, such studies would, I imagine, > inform future architecture and design. As a side effect, > it would be nice to have the (mathematical) machinery > available to do this kind of work on whatever protocols > we deploy (to the extent such machinery could be made > general purpose). Yes - which argues for a powerful modelling tool for a large-scale simulated BGP4ish world. Brian > > And anyway, all of this convolves my interests in > complexity, paleontology (who doesn't like dinosaurs?), > and networking, and fun is allowed, right :-) > > --dmm > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 10:32:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r2Z-0006dO-Va; Fri, 05 Jan 2007 10:31:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r2Y-0006dI-NF for ram@iab.org; Fri, 05 Jan 2007 10:31:30 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2r2X-0000xi-Gl for ram@iab.org; Fri, 05 Jan 2007 10:31:30 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 07:31:29 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="50070805:sNHT42619928" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05FVTlv023395 for ; Fri, 5 Jan 2007 10:31:29 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l05FVT7f022046 for ; Fri, 5 Jan 2007 10:31:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <459E57E6.2050008@cisco.com> References: <12B5C441-9F27-49DE-8A00-D22F8CF4D40B@cisco.com> <459E57E6.2050008@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08656389-BC82-4164-912E-9918277DCD6C@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 5 Jan 2007 07:31:24 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=739; t=1168011089; x=1168875089; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20 |To:=20ram@iab.org; bh=DAAeWhp18jyvAGDDF1Zh52qZlFlpYsiV96bvYe8Ysk0=; b=F+ZrDbRH/whrDr6gDRKq4Fi6KKKuKDdhRpGxoVgiQWWmT1+EUX8gRZJbKRq2Kaobjv4omDPi 6p9Xxmx4bOz1wOLQ3cfElIDjR7XcbKV+//QKWxzsWIiUEuDvYUv5GCZd; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 5:51 AM, Russ White wrote: > I can see > it impacting the traffic on those highways, but the physical > position of > the highways is certainly unchanged, isn't it? I've seen cases in which lanes have been added/removed by repainting, directionality of certain portions of a highway altered via said repainting, portions of highways closed, and onramps/offramps opened/ closed as second-order effects of surface-street changes; that's the kind of thing I was thinking of, heh. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 10:37:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r8M-0001QR-8u; Fri, 05 Jan 2007 10:37:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2r8L-0001Nu-Dy for ram@iab.org; Fri, 05 Jan 2007 10:37:29 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2r8J-0002Ed-TY for ram@iab.org; Fri, 05 Jan 2007 10:37:29 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l05FbNrG080288 for ; Fri, 5 Jan 2007 15:37:26 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l05FbNQq2601188 for ; Fri, 5 Jan 2007 16:37:23 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l05FbMN2032003 for ; Fri, 5 Jan 2007 16:37:22 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l05FbMRw031992; Fri, 5 Jan 2007 16:37:22 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA146816; Fri, 5 Jan 2007 16:37:21 +0100 Message-ID: <459E70B2.6010209@zurich.ibm.com> Date: Fri, 05 Jan 2007 16:37:22 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] GSE security References: <20070104172911.GD32409@1-4-5.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-05 14:27, RJ Atkinson wrote: >=20 > On 4 Jan 2007, at 20:34, marcelo bagnulo braun wrote: >> El 04/01/2007, a las 20:11, RJ Atkinson escribi=C3=B3: >>> 1) Some protection against off-path active attacks (e.g. on binding >>> updates), where that protection is not computationally expensive >>> because the threat environment is believed low. >> >> What about the so-called time shifted attacks? >> And flooding attacks? >> Should we provide protection against those? >> >> (especially the first ones are quite tricky to protect from) >> (please see RFC4225 and RFC 4218 for a definition of these attacks) >=20 > It is not reasonable to require more from IPv6 or some enhancement > to IPv6 than we currently require from *the deployed IPv4 Internet* > with regards to various kinds of attacks. Generally speaking, > security solutions for one version of IP also will apply to another > version of IP. The kinds of architectural enhancements that I've > seen discussed on the RAM list don't obviously change that. Maybe not, but possible defences may exist in IPv6 that don't exist in IPv4; at least, I don't see how you can do any kind of cryptographcally generated addresses in IPv4. Brian >=20 > All of the kinds of things you cite above are possible today in > the IPv4 Internet, absent using something with strong cryptography > -- along the lines of ESP/AH. ESP/AH are available for both IPv4 and=20 > IPv6, and presumably for > any IPv6 enhancements. In fact, the original ESP/AH code at NRL > was mostly the same code path, with just a few branch instructions > that were based on the IP version field. >=20 > So those items you cite above are not legitimately in the scope > for the situations where "the threat environment is believed low". >=20 > Ran >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 10:50:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rKW-0005oG-FN; Fri, 05 Jan 2007 10:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rKV-0005nu-Jm for ram@iab.org; Fri, 05 Jan 2007 10:50:03 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rKU-0005cu-Bg for ram@iab.org; Fri, 05 Jan 2007 10:50:03 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2007 10:50:02 -0500 X-IronPort-AV: i="4.12,243,1165208400"; d="scan'208"; a="110950982:sNHT78339408" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05Fo1t1032277 for ; Fri, 5 Jan 2007 10:50:01 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05Fo12k027001 for ; Fri, 5 Jan 2007 10:50:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070104172911.GD32409@1-4-5.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C84A3D2-C673-4E53-A67D-8C18C9A05C14@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] GSE security Date: Fri, 5 Jan 2007 07:49:56 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1428; t=1168012202; x=1168876202; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20GSE=20security |Sender:=20 |To:=20ram@iab.org; bh=mwaOVW+rx4AvCxqjuuTgcGlN8f/4cf4h3Muvqte07SQ=; b=osMAzFnucqtZdpBjgzCQBZQll+Dgk1mkK6C1iWKDP8iogFv9tyyXhsohgigpsFUKLo5rAPdi e2MjRiCZHOUYirCTvBNEGQ+SxqUbpoLTWHRSCKxPHo2kyHKu8ORItEE2; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 5:27 AM, RJ Atkinson wrote: > > It is not reasonable to require more from IPv6 or some enhancement > to IPv6 than we currently require from *the deployed IPv4 Internet* Why not? That's how it was 'sold', and that's what a large number of people seem to think, that IPv6 through the use of 'mandatory' encryption is magically more 'secure' than IPv4. What's wrong with a) expecting more from IPv6 and/or successors and b) working to provide IPv6 and/or successors with more actual security properties/ strengths/capabilities than IPv4? > security solutions for one version of IP also will apply to another > version of IP. This isn't necessarily the case - for example, the 'recommended' use of /64s for link addressing has the unintended consequence of turning every router into a sinkhole for either scanning Slammer-type malware, which could result in a DoS, or a deliberate scanning-type attack intended as a DoS. For another, the ND mechanism in IPv6 differs pretty significantly from what's present in IPv4, and there may be some additional ways to leverage that as a DoS mechanism, and thus different self-protection measures required. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 10:55:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rPK-0000Pq-Jo; Fri, 05 Jan 2007 10:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rPJ-0000Pl-UF for ram@iab.org; Fri, 05 Jan 2007 10:55:01 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rPI-00078Q-I0 for ram@iab.org; Fri, 05 Jan 2007 10:55:01 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id D89317E27 for ; Fri, 5 Jan 2007 07:54:54 -0800 (PST) Received: from JMHLap3.joelhalpern.com (pool-162-83-109-221.culp.east.verizon.net [162.83.109.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 657C97DE2 for ; Fri, 5 Jan 2007 07:54:52 -0800 (PST) Message-Id: <7.0.1.0.0.20070105104620.033ccaf0@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 05 Jan 2007 10:54:47 -0500 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] GSE security In-Reply-To: <459E70B2.6010209@zurich.ibm.com> References: <20070104172911.GD32409@1-4-5.net> <459E70B2.6010209@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=1.8 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: * X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It looks to me like people are talking past each other. So let me see if I can paraphrase several points from different people. Everyone agrees that some forms of security are needed for use with GSE style (or in fact most any style) addresss / locator separation. Exactly what needs to be secured varies from case to case, but typically, the issue is updates to the binding between identifiers and locators. Clearly, if one is really concerned about security (high threat environment, where one cares about the attacks a great deal) there are powerful mechanisms that can be applied. These range up to usage of AH-like mechanisms and/or cryptographic addresses, etc. Equally, there are lower threat environments. For example, a web server providing public service is not interested in authenticating the clients (even if the client is interested in authenticating the server by default some times.) And such services are fully prepared to invoke much stronger mechanisms (TLS, etc) when appropriate. Even then, we probably want some protections against some attacks. I read Ran's note as suggesting that for this case, something close to the current capabilities, possibly with extra strength against off-path attacks might be a quite sensible alternative. Now, if the solution we craft provides additional security in all cases, or make it available when desired, that's nice. But lets not get so caught up in our security desires that we demand the impractical. (I remember a proposal to prevent DoS on each and every link in the Internet many years ago that was clearly theoretically beautiful and powerful but was impractical to implement.) Yours, Joel M. Halpern _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 11:05:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rYk-0002i7-Tu; Fri, 05 Jan 2007 11:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rYj-0002i2-Fp for ram@iab.org; Fri, 05 Jan 2007 11:04:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rYi-0001NO-8z for ram@iab.org; Fri, 05 Jan 2007 11:04:45 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 08:04:44 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="50074177:sNHT43798180" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l05G4ife004604 for ; Fri, 5 Jan 2007 11:04:44 -0500 Received: from [192.168.1.101] (rtp-vpn4-79.cisco.com [10.82.208.79]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l05G4h7f002430 for ; Fri, 5 Jan 2007 11:04:43 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7.0.1.0.0.20070105104620.033ccaf0@joelhalpern.com> References: <20070104172911.GD32409@1-4-5.net> <459E70B2.6010209@zurich.ibm.com> <7.0.1.0.0.20070105104620.033ccaf0@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <392391D0-74E9-47E3-9E36-5B736E1999A4@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] GSE security Date: Fri, 5 Jan 2007 08:04:39 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1140; t=1168013084; x=1168877084; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20GSE=20security |Sender:=20 |To:=20ram@iab.org; bh=ftD2YrK4GpmhwH+1td3FCSNsy0q+CEJ9Sir7H1xq/fw=; b=Or+HdY1kK7XF6UQCdHlamMTxTRJU3u2jfU0UUpxhFC+doSBeNyIZe7liObdq75NvaTtSwHnC q91g3UliTThLSdQ6yYWBBgLPilVyMJQiCc+FEiGJo9kVDqiF+FWGE1m4; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 7:54 AM, Joel M. Halpern wrote: > Clearly, if one is really concerned about security (high threat > environment, where one cares about the attacks a great deal) there > are powerful mechanisms that can be applied. These range up to > usage of AH-like mechanisms and/or cryptographic addresses, etc. There's a lot more to security that crypto and auth - namely, DoS vectors/defenses/resiliency. That's a primary concern, along with the ability to provide useful encyption/auth/anonymization capabilities as is desired and is practical. > > Now, if the solution we craft provides additional security in all > cases, or make it available when desired, that's nice. But lets > not get so caught up in our security desires that we demand the > impractical. Of course; but we need to ensure the system doesn't fall over at the touch of a feather, either, heh. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 12:41:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t3z-0000cl-7W; Fri, 05 Jan 2007 12:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2t3x-0000cb-TD for ram@iab.org; Fri, 05 Jan 2007 12:41:06 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2t3w-0008VA-8p for ram@iab.org; Fri, 05 Jan 2007 12:41:05 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6746B12250D; Fri, 5 Jan 2007 18:41:03 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp01.uc3m.es (Postfix) with ESMTP id D62251224E5; Fri, 5 Jan 2007 18:40:55 +0100 (CET) In-Reply-To: References: <20070104172911.GD32409@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Should we provide protection against time shifted attacks? (was Re: [RAM] GSE security Date: Fri, 5 Jan 2007 18:40:51 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 05/01/2007, a las 14:27, RJ Atkinson escribi=F3: > > On 4 Jan 2007, at 20:34, marcelo bagnulo braun wrote: >> El 04/01/2007, a las 20:11, RJ Atkinson escribi=F3: >>> 1) Some protection against off-path active attacks (e.g. on binding >>> updates), where that protection is not computationally expensive >>> because the threat environment is believed low. >> >> What about the so-called time shifted attacks? >> And flooding attacks? >> Should we provide protection against those? >> >> (especially the first ones are quite tricky to protect from) >> (please see RFC4225 and RFC 4218 for a definition of these attacks) > > It is not reasonable to require more from IPv6 or some enhancement > to IPv6 than we currently require from *the deployed IPv4 Internet* > with regards to various kinds of attacks. agree > Generally speaking, > security solutions for one version of IP also will apply to another > version of IP. well there are some solutions that can work in only one version of IP... > The kinds of architectural enhancements that I've > seen discussed on the RAM list don't obviously change that. > > All of the kinds of things you cite above are possible today in > the IPv4 Internet, absent using something with strong cryptography > -- along the lines of ESP/AH. ESP/AH are available for both IPv4 and=20= > IPv6, and presumably for > any IPv6 enhancements. you mean time shifted attacks and flooding attacks? If you do, previous security analysis didn't came to the same=20 conclusion... AFAIK, the first analysis on redirection attacks related to some for of=20= locator id split was performed by the mobile IP community and they did=20= imho very good analysis on RFc4225. Their conclusion was that neither=20 time shifted attacks nor flooding attacks were possible in todays v4 or=20= v6 internet and that any new tool for spliting the identifier role from=20= the locator role must provide protection against those. Hence they=20 designed the return routability procedure (which is periodically=20 performed) in order to prevent those. Later on, the threat analysis for multihoming was performed and the=20 result is rfc4218 and both time shifted attacks and flooding attacks=20 were considered and it was required that solutions must provide=20 protection against those. So, having worked in finding solutions for those, i must say that it is=20= quite tricky and that a solution that is not required to address those=20= will be significantly simpler. So, should we or should we not provide protection against time shifted=20= and flooding attacks caused by id/locator split protocols? I must say that i personally think we should because i think the=20 resulting attacks are serious and are beyond what is possible in today=20= internet, but i would like hear other people's opinion on this one. (I am not 100% sure but i think that during mip design they first=20 didn't considered this type of attacks and they stated that anyone that=20= wnated more protection could simply use IPSec and the protocol was=20 returned to the wg by the security IDs because it was not secure=20 enough, maybe people that was there can expand on this....) Regards, marcelo > In fact, the original ESP/AH code at NRL > was mostly the same code path, with just a few branch instructions > that were based on the IP version field. > > So those items you cite above are not legitimately in the scope > for the situations where "the threat environment is believed low". > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 12:54:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tGV-0006BB-SQ; Fri, 05 Jan 2007 12:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tGU-0006Ai-FK for ram@iab.org; Fri, 05 Jan 2007 12:54:02 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tGS-0002uM-Vu for ram@iab.org; Fri, 05 Jan 2007 12:54:02 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2EFDD54EE8; Fri, 5 Jan 2007 18:54:00 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp03.uc3m.es (Postfix) with ESMTP id 86E6F54F23; Fri, 5 Jan 2007 18:53:55 +0100 (CET) In-Reply-To: <7.0.1.0.0.20070105104620.033ccaf0@joelhalpern.com> References: <20070104172911.GD32409@1-4-5.net> <459E70B2.6010209@zurich.ibm.com> <7.0.1.0.0.20070105104620.033ccaf0@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5ec1964f689263ced217a4e27ab686e7@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] GSE security Date: Fri, 5 Jan 2007 18:53:54 +0100 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Joel, good summary, thanks. El 05/01/2007, a las 16:54, Joel M. Halpern escribi=F3: > It looks to me like people are talking past each other. > So let me see if I can paraphrase several points from different = people. > > Everyone agrees that some forms of security are needed for use with=20 > GSE style (or in fact most any style) addresss / locator separation. =20= > Exactly what needs to be secured varies from case to case, but=20 > typically, the issue is updates to the binding between identifiers and=20= > locators. > > Clearly, if one is really concerned about security (high threat=20 > environment, where one cares about the attacks a great deal) there are=20= > powerful mechanisms that can be applied. These range up to usage of=20= > AH-like mechanisms and/or cryptographic addresses, etc. > > Equally, there are lower threat environments. For example, a web=20 > server providing public service is not interested in authenticating=20 > the clients (even if the client is interested in authenticating the=20 > server by default some times.) And such services are fully prepared=20= > to invoke much stronger mechanisms (TLS, etc) when appropriate. Even=20= > then, we probably want some protections against some attacks. I read=20= > Ran's note as suggesting that for this case, something close to the=20 > current capabilities, possibly with extra strength against off-path=20 > attacks might be a quite sensible alternative. > i agree with all your points... the next question is what is the=20 minimum level of security acceptable. Previously many folks thought=20 that providing protection against time shifted attacks and flooding=20 attacks was mandatory for the lowest level of protection... do we still=20= think this is the case or shall we go for a lower minimum? Regards, marcelo > Now, if the solution we craft provides additional security in all=20 > cases, or make it available when desired, that's nice. But lets not=20= > get so caught up in our security desires that we demand the=20 > impractical. (I remember a proposal to prevent DoS on each and every=20= > link in the Internet many years ago that was clearly theoretically=20 > beautiful and powerful but was impractical to implement.) > > Yours, > Joel M. Halpern > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 13:03:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tPH-0008RQ-8G; Fri, 05 Jan 2007 13:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tPG-0008RL-Ng for ram@iab.org; Fri, 05 Jan 2007 13:03:06 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tPF-00050w-A8 for ram@iab.org; Fri, 05 Jan 2007 13:03:06 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l05I30qr022999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Jan 2007 12:03:00 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <459E6113.9060404@zurich.ibm.com> References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] Date: Fri, 5 Jan 2007 12:02:59 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 8:30 AM, Brian E Carpenter wrote: > On 2007-01-03 16:42, Roland Dobbins wrote: > ... >> The sudden tolerance for PI space gratifies/puzzles me, though - I >> thought it was anathema, and that folks here aren't't in the main >> amused that PI space is being allocated. If PI space is now >> tolerable, then we can all go home and call it a day, > > I think we should be clear that today we appear to have to choose > between > (1) PI prefixes, which break aggregation, and (2) locator > rewriting, which > allows aggregation. Locator rewriting comes in many forms*, some of > which > are still theoretical, but they are all isomorphic at some level. > > If anybody knows a third choice, that would be of great interest. > > *e.g. NAT, map and encap, GSE, shim6 > > Brian > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram Well including all of the destination locators in a packet could work without locator rewriting in theory but I think most such proposals envision the possibility of rewriting the primary locator in at least the case of when the route to the primary locator is down for compatibility with existing equipment. Maybe (2) should be "Multiple global locators, which allows aggregation." And locator rewriting is a subset of (2) which has been most discussed. Today NAT is a sort of locator rewriting and it doesn't allow aggregation. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 13:30:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tpC-0002pt-Em; Fri, 05 Jan 2007 13:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tpB-0002pn-04 for ram@iab.org; Fri, 05 Jan 2007 13:29:53 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2tp8-00051q-NE for ram@iab.org; Fri, 05 Jan 2007 13:29:52 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6448F89840; Fri, 5 Jan 2007 20:29:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 19D8789837; Fri, 5 Jan 2007 20:29:47 +0200 (EET) Message-ID: <459E991B.1030206@piuha.net> Date: Fri, 05 Jan 2007 20:29:47 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] GSE security References: <20070104172911.GD32409@1-4-5.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ran, I agree with your principle, but I'm not sure what it has to do with Marcelo's list of vulnerabilities. I'm pretty sure whatever ID-Locator separation design we plan to have, we don't want it to open significant new vulnerabilities from what we have in the current Internet. Perhaps we'd even like it to close some existing ones, at least some designs do that (whether its worth the cost is another question). Anyway, back to the issue of not opening any new vulnerabilities: If the design allows switching hosts from one locator to another, we wouldn't like such changes to be announced by just any unrelated entity in the Internet. Similarly, we don't want the design to allow malicious hosts to be able to amplify their denial-of-service capabilities, e.g., through using redirection and third parties. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 13:56:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uEP-0004Dj-KE; Fri, 05 Jan 2007 13:55:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2uEN-0004Db-Jg for ram@iab.org; Fri, 05 Jan 2007 13:55:55 -0500 Received: from web58707.mail.re1.yahoo.com ([66.196.100.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2uEM-00047g-7I for ram@iab.org; Fri, 05 Jan 2007 13:55:55 -0500 Received: (qmail 53129 invoked by uid 60001); 5 Jan 2007 18:55:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Mpr0JyqsZjnY/jMEfCPgmlb1d0Tdhr1Re5BXgriISIyJnzy8vAjLtmThS4OcEyxOYJFUzCBzt8WlF06i2aBuEvC8BM1b2pc+CZwKxTmSiYl/ZBTbNsReW8ENMkSmqIaCaGKm4R1yZszz5c+2sAyEcFt9prmYwvcrFtjxnKgJLSM=; X-YMail-OSG: B6rlBmoVM1mSuiBP5HBGo0iU5KOZYbaOVaAwtN7SusccG9lRn8rfb93GMMffkFSruGbXfvj_dY1QUKcnnTlHL_f7I14skA9u7Ts_8EojJQjmMVb_52OtCTMDWAcla6079sFyhsetCJKDTKw2bat3YsrBimm2c8wFWl7wPQDX_qjriDjTCFxnhKKQic5gqErfkTYLGA-- Received: from [207.107.50.100] by web58707.mail.re1.yahoo.com via HTTP; Fri, 05 Jan 2007 10:55:38 PST Date: Fri, 5 Jan 2007 10:55:38 -0800 (PST) From: Peter Sherbin Subject: [RAM] PI v locator rewriting [Re: one size doesn' fit all] To: Brian E Carpenter , ram@iab.org In-Reply-To: <459E6113.9060404@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <791352.52328.qm@web58707.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > (1) PI prefixes,... (2) locator rewriting,... a third choice: All things have globally unique id/names. Only routers have aggregated addresses. A thing discloses its name to a router it is attached to. The router maintains a name database of things attached. The router advertises upstream its address only. A router on a private network presents itself to an upstream router as a thing with a name. An open contract between providers and subscribers allows billing for traffic from a given name. Subscribers change providers at will. Thanks, Peter __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 15:23:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vaY-0002w3-VC; Fri, 05 Jan 2007 15:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vaY-0002vy-8W for ram@iab.org; Fri, 05 Jan 2007 15:22:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2vaX-0001uk-1t for ram@iab.org; Fri, 05 Jan 2007 15:22:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 12:22:53 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208"; a="50095165:sNHT44154892" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l05KMqQq005764 for ; Fri, 5 Jan 2007 15:22:52 -0500 Received: from [70.6.82.197] (rtp-vpn3-360.cisco.com [10.82.217.106]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05KMo2k005082 for ; Fri, 5 Jan 2007 15:22:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> References: <20070104172911.GD32409@1-4-5.net> <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34360F3B-09C0-48DC-BE89-FA33C79F7699@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: Should we provide protection against time shifted attacks? (was Re: [RAM] GSE security Date: Fri, 5 Jan 2007 12:22:44 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=738; t=1168028572; x=1168892572; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20Should=20we=20provide=20protection=20against=20time=2 0shifted=20attacks?=20(was=20Re=3A=20[RAM]=20GSE=20security |Sender:=20 |To:=20ram@iab.org; bh=T9oVNyfl07UW1+5Dx65J8XytcNRQD1w+Ts0s56NzI7I=; b=munn1pmFz2v0iaHsOyqZhaOqvK1erQlOoJg7k1vKClm2O+6amWXAcgYCO/R8mrhrQEEpUI8o VfM/q/8BRyiKKjILo9NSj5StzWw1QA2XvVZ2e7W0vNjsZdNizp1Hyw2Q; Authentication-Results: rtp-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 9:40 AM, marcelo bagnulo braun wrote: > So, should we or should we not provide protection against time > shifted and flooding attacks caused by id/locator split protocols? > > I must say that i personally think we should because i think the > resulting attacks are serious and are beyond what is possible in > today internet, but i would like hear other people's opinion on > this one. I concur with your assessment, especially with regards to flooding attacks. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 15:58:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w8b-0007Zg-3j; Fri, 05 Jan 2007 15:58:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w8a-0007ZL-G7 for ram@iab.org; Fri, 05 Jan 2007 15:58:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2w8R-0002CW-5r for ram@iab.org; Fri, 05 Jan 2007 15:58:04 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2007 12:57:47 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05Kvk5V019624; Fri, 5 Jan 2007 12:57:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05KvZZH013855; Fri, 5 Jan 2007 12:57:35 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:57:35 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 12:57:34 -0800 In-Reply-To: <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> References: <20070104172911.GD32409@1-4-5.net> <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51E1FAA7-AF0F-47C7-86DD-7D60081AEE37@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Should we provide protection against time shifted attacks? (was Re: [RAM] GSE security Date: Fri, 5 Jan 2007 12:57:33 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jan 2007 20:57:34.0886 (UTC) FILETIME=[1FF4E460:01C7310C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=547; t=1168030666; x=1168894666; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Should=20we=20provide=20protection=20against=20time=2 0shifted=20attacks?=20(was=20Re=3A=20[RAM]=20GSE=20security |Sender:=20; bh=sHpR1oq/wwV0PoESsVOUHj/ktpRBnSaScPq69LBHgEI=; b=koI6gMjfhvkGEgh/nj1QVnigfekfZ7R8Kq/rkRF975Ee4+V8bH5iXXvZrx7fsaE5yQrwmzFj 9czNXygE3fA7Gt4ONS4i0jOO3m4pUpX5XD0ZKfBiMnbCykxJnuPLuiim; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 9:40 AM, marcelo bagnulo braun wrote: > Later on, the threat analysis for multihoming was performed and the > result is rfc4218 and both time shifted attacks and flooding > attacks were considered and it was required that solutions must > provide protection against those. Whoa. Attacks are considered, but solutions for all such attacks were not supposed to be required by 4218. In particular, attacks that exist today under IPv4 need not be solved. Well, that was the intent, anyway... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 16:04:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wEb-00028v-F1; Fri, 05 Jan 2007 16:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wEa-00028L-Fe for ram@iab.org; Fri, 05 Jan 2007 16:04:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2wEZ-0004BA-5D for ram@iab.org; Fri, 05 Jan 2007 16:04:16 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2007 13:04:12 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l05L4C3U007822; Fri, 5 Jan 2007 13:04:12 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l05L4BIl014998; Fri, 5 Jan 2007 13:04:12 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:04:11 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:04:11 -0800 In-Reply-To: <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] Date: Fri, 5 Jan 2007 13:04:09 -0800 To: Bruce Curtis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jan 2007 21:04:11.0246 (UTC) FILETIME=[0C34A0E0:01C7310D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=678; t=1168031052; x=1168895052; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20PI=20v=20locator=20rewriting=20[Re=3A=20one=2 0size=20doesn'=20fit=20all] |Sender:=20; bh=O2j2gae3EctK9xDuseTLlQGZXOojl8sjMaj+7exn7iY=; b=dkn4ooCXqXzZMXcJ8fuVoIEb0S7qKVW7KUkkPzz+dgN5oau8vek0aLZQN9h6j79Efp/dcr3J 5SfOo1R04B2HjPrEBIKRMckG/Ow7ZJt0OX1aozV86NZtofsqBII14e8f; Authentication-Results: sj-dkim-6; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 10:02 AM, Bruce Curtis wrote: > Today NAT is a sort of locator rewriting and it doesn't allow > aggregation. NAT permits most excellent aggregation as long as you're willing to deal with PA addresses. What really becomes cumbersome tho, is when multihoming is involved. Then, hosts interacting with the hosts behind the NAT aren't aware of the multiple locators allocated to their correspondent and havoc ensues. So, I'd rather say that NAT does rewrite locators, but in an uncoordinated way that defeats most of the benefits of multihoming. As such, it's pretty much useless as a long-term architectural strategy. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 16:10:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wKq-0006PU-Ex; Fri, 05 Jan 2007 16:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wKp-0006PP-Le for ram@iab.org; Fri, 05 Jan 2007 16:10:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2wKo-0005JI-BW for ram@iab.org; Fri, 05 Jan 2007 16:10:43 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2007 13:10:42 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208"; a="98531176:sNHT43988085" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l05LAfPk026170; Fri, 5 Jan 2007 13:10:41 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05LAYZH023038; Fri, 5 Jan 2007 13:10:35 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:10:34 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 13:10:34 -0800 In-Reply-To: <459E688A.1000905@zurich.ibm.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> <20070104183653.GA5990@1-4-5.net> <459E688A.1000905@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <887FB5F6-4922-4B5A-89AA-04A685AD1C79@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 5 Jan 2007 13:10:32 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jan 2007 21:10:34.0251 (UTC) FILETIME=[F07E8DB0:01C7310D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1168031441; x=1168895441; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20; bh=cyLt7RztxTJ5jRVIz7A+juEBSXBdnPEQIVm1e1oWiOQ=; b=j2FptCwqTJa0eYVYrhyTcAiiPJG2btYX1BjzdCZ+1daBA0KnI2gIG+PLesA33Hk5tYPUnUFB G4UQkKJdwEcOM4v3dp8MIPpf8x2DnuwyUNQMKcr+DMe/0qQreXgX5uxw; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 5, 2007, at 7:02 AM, Brian E Carpenter wrote: >>> I'm intrigued by this. To my way of thinking, the churn rate is >>> an artifact of BGP's design, the actual physical changes in the >>> topology, and operational input. It doesn't really seem to be >>> architectural, it's just a side-effect of the control plane >>> mechanisms that we've chosen. > > If that turns out to be true, it's excellent news - we don't > need to change the architecture, we just need to fix the > control plane. Seriously. Brian, Is there some theory, argument or position that suggests that it's architectural? If so, pointers please.... That said, I think that "just fixing the control plane" is not nearly as trivial as you make it sound. I will point out that additional hierarchy (i.e., abstraction) of routing information would certainly help the problem, but that capability is already there today (e.g., proxy aggregation) if folks could only bring themselves to use it... Regards, Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 16:44:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wqp-0003Rz-Q9; Fri, 05 Jan 2007 16:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wqo-0003Ro-Cw for ram@iab.org; Fri, 05 Jan 2007 16:43:46 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2wqm-0005AK-RB for ram@iab.org; Fri, 05 Jan 2007 16:43:46 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E2002121A71; Fri, 5 Jan 2007 22:43:43 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp01.uc3m.es (Postfix) with ESMTP id EB89F121B0F; Fri, 5 Jan 2007 22:43:40 +0100 (CET) In-Reply-To: <51E1FAA7-AF0F-47C7-86DD-7D60081AEE37@cisco.com> References: <20070104172911.GD32409@1-4-5.net> <75a062507475c7baf8f7d7c58fefe446@it.uc3m.es> <51E1FAA7-AF0F-47C7-86DD-7D60081AEE37@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0130b50e8adab835b876df35fcdfb9aa@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: Should we provide protection against time shifted attacks? (was Re: [RAM] GSE security Date: Fri, 5 Jan 2007 22:34:51 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 05/01/2007, a las 21:57, Tony Li escribi=F3: > > On Jan 5, 2007, at 9:40 AM, marcelo bagnulo braun wrote: > >> Later on, the threat analysis for multihoming was performed and the=20= >> result is rfc4218 and both time shifted attacks and flooding attacks=20= >> were considered and it was required that solutions must provide=20 >> protection against those. > > > Whoa. Attacks are considered, but solutions for all such attacks were=20= > not supposed to be required by 4218. > In particular, attacks that exist today under IPv4 need not be=20 > solved. Well, that was the intent, anyway... > > Tony > exactly that is what i am asking about time shifted attacks... i quote RFC 4218 4.1.2. Time-Shifting Attack The term "time-shifting attack" is used to describe an attacker's ability to perform an attack after no longer being on the path. Thus, the attacker would have been on the path at some point in = time, snooping and/or modifying packets; and later, when the attacker is = no longer on the path, it launches the attack. In the current Internet, it is not possible to perform such attacks to redirect packets. ... It would be reasonable to require that a multihoming solution limit the ability to redirect and/or DoS traffic to a few minutes after = the attacker has moved off the path. 4.3. Third Party Denial-of-Service Attacks .... In today's Internet, the ability to perform this type of attack is quite limited. ... Thus, the multihoming mechanism probably needs some form of defense against third party = DoS attacks, in addition to the help we can get from the transport protocols. So, rfc4218 identifies that both these attacks are not possible (or=20 limited) in today internet and that new multihoming solutions should=20 try to prevent them Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 21:23:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Cn-0007k0-Oj; Fri, 05 Jan 2007 21:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31Cm-0007jt-Fa for ram@iab.org; Fri, 05 Jan 2007 21:22:44 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31Cj-0003l5-7a for ram@iab.org; Fri, 05 Jan 2007 21:22:44 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBF00GF0D9QLO@firewall.mci.com> for ram@iab.org; Sat, 06 Jan 2007 02:22:38 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBF00D78D9QGE@dgismtp06.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 02:22:38 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBF00D3LD9QA0@dgismtp06.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 02:22:38 +0000 (GMT) Date: Sat, 06 Jan 2007 02:22:37 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] In-reply-to: <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Tony Li Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 5 Jan 2007, Tony Li wrote: > > On Jan 5, 2007, at 10:02 AM, Bruce Curtis wrote: > > > Today NAT is a sort of locator rewriting and it doesn't allow > > aggregation. > > NAT permits most excellent aggregation as long as you're willing to > deal with PA addresses. What really becomes cumbersome tho, is when > multihoming is involved. Then, hosts interacting with the hosts > behind the NAT aren't aware of the multiple locators allocated to > their correspondent and havoc ensues. > > So, I'd rather say that NAT does rewrite locators, but in an > uncoordinated way that defeats most of the benefits of multihoming. > As such, it's pretty much useless as a long-term architectural strategy. useless without something that allows the locators switching to not affect the upper layer protocol state? or useless entirely? (perhaps if the upper layer protocol state were unaffected it wouldn't be called NAT?) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 21:52:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31fg-0001yI-G3; Fri, 05 Jan 2007 21:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31ff-0001y9-37 for ram@iab.org; Fri, 05 Jan 2007 21:52:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31fc-0001Rn-Ov for ram@iab.org; Fri, 05 Jan 2007 21:52:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2007 18:52:32 -0800 X-IronPort-AV: i="4.13,155,1167638400"; d="scan'208"; a="98609657:sNHT43878996" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l062qVkV009331; Fri, 5 Jan 2007 18:52:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l062qVZH007463; Fri, 5 Jan 2007 18:52:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 18:52:31 -0800 Received: from [171.71.55.220] ([171.71.55.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 18:52:31 -0800 In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] Date: Fri, 5 Jan 2007 18:52:28 -0800 To: "Chris L. Morrow" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Jan 2007 02:52:31.0167 (UTC) FILETIME=[B5877CF0:01C7313D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1126; t=1168051951; x=1168915951; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20PI=20v=20locator=20rewriting=20[Re=3A=20one=2 0size=20doesn'=20fit=20all] |Sender:=20; bh=+l6lvbS/SbG9eQ1OnhxCrjRu6tCzDG5YrJyd2H9Xidw=; b=fN7KI+hHxiuF5P2dvRsHXyMM8h3qKj8jSSXIMbwqZB7IUoShuPVdnqgbnSKL4VYDsbY6nP/z VIX8ZJLnbuswLstoZ+K8U0V0usOtpNjuQvaTP5CP46GTgNdQUM3Q7UmZ; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> Today NAT is a sort of locator rewriting and it doesn't allow >>> aggregation. >> >> NAT permits most excellent aggregation as long as you're willing to >> deal with PA addresses. What really becomes cumbersome tho, is when >> multihoming is involved. Then, hosts interacting with the hosts >> behind the NAT aren't aware of the multiple locators allocated to >> their correspondent and havoc ensues. >> >> So, I'd rather say that NAT does rewrite locators, but in an >> uncoordinated way that defeats most of the benefits of multihoming. >> As such, it's pretty much useless as a long-term architectural >> strategy. > > useless without something that allows the locators switching to not > affect > the upper layer protocol state? or useless entirely? (perhaps if > the upper > layer protocol state were unaffected it wouldn't be called NAT?) Useless without a distributed database that coordinates locator/ identifier bindings and manages available locators, at which point it looks a heck of a lot like something much more powerful than just NAT. Shim7, anyone? ;-) Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 22:02:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31pE-0006O5-DS; Fri, 05 Jan 2007 22:02:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H31pD-0006Nx-H4 for ram@iab.org; Fri, 05 Jan 2007 22:02:27 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H31pB-0003FA-8f for ram@iab.org; Fri, 05 Jan 2007 22:02:27 -0500 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBF00180F3YX5@firewall.mci.com> for ram@iab.org; Sat, 06 Jan 2007 03:02:23 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBF00ICBF3YDW@dgismtp06.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 03:02:22 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBF00HDGF3Y82@dgismtp06.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 03:02:22 +0000 (GMT) Date: Sat, 06 Jan 2007 03:02:21 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] In-reply-to: <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Tony Li Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 5 Jan 2007, Tony Li wrote: > > >>> Today NAT is a sort of locator rewriting and it doesn't allow > >>> aggregation. > >> > >> NAT permits most excellent aggregation as long as you're willing to > >> deal with PA addresses. What really becomes cumbersome tho, is when > >> multihoming is involved. Then, hosts interacting with the hosts > >> behind the NAT aren't aware of the multiple locators allocated to > >> their correspondent and havoc ensues. > >> > >> So, I'd rather say that NAT does rewrite locators, but in an > >> uncoordinated way that defeats most of the benefits of multihoming. > >> As such, it's pretty much useless as a long-term architectural > >> strategy. > > > > useless without something that allows the locators switching to not > > affect > > the upper layer protocol state? or useless entirely? (perhaps if > > the upper > > layer protocol state were unaffected it wouldn't be called NAT?) > > > Useless without a distributed database that coordinates locator/ > identifier bindings and manages available locators, at which point it > looks a heck of a lot like something much more powerful than just > NAT. Shim7, anyone? ;-) I think I might miss why it's 'useless', i think it'd be quite nice (say for mobile things or even laptops) if you could easily migrate from location to location and maintain connectivity without restarting all the vpn/http/ssh/blah sessions I have to restart everytime my laptop moves. Something that let my locator's change 'at will' (provide some assurance that I'm really me during/after move, sure) would be nice. With that doesn't NAT at my 2 ISP link points (NAT to PA space in each ISP) just look like that sort of mobility? (essentially I move from isp to isp in some form of rapid sucession). I admit that I oversimplified things, but 'useless' it didn't seem. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 05 23:34:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H33Fs-0006OF-G9; Fri, 05 Jan 2007 23:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H33Fs-0006OA-1U for ram@iab.org; Fri, 05 Jan 2007 23:34:04 -0500 Received: from xmail04.myhosting.com ([168.144.250.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H33Fq-0005QR-Ps for ram@iab.org; Fri, 05 Jan 2007 23:34:04 -0500 Received: (qmail 17774 invoked from network); 6 Jan 2007 04:33:56 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with SMTP for ; 6 Jan 2007 04:33:56 -0000 Message-ID: <459F26A9.60306@cisco.com> Date: Fri, 05 Jan 2007 23:33:45 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> In-Reply-To: <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Useless without a distributed database that coordinates > locator/identifier bindings and manages available locators, at which > point it looks a heck of a lot like something much more powerful than > just NAT. Shim7, anyone? ;-) Just call it mobile IP, and be done with it! :-) I'll be the heretic for the day, and say that I really think the main problem with NAT isn't that it's NAT, but rather that is hits us just at the locater/identifier divide. We'd safely hidden the dual nature of IP addresses for years, pretending that DNS records were ID's, and IP addresses locaters, when NAT came along and showed us the reality of the situation. Of course, it also doesn't help that we call Port Address Translators (PATs) Network Address Translators (NATs), when they really aren't the same thing at all. PATs are used to get around address space limitations. Assuming IPv6 solves the address space issue, IPv6 + NAT, disallowing PATs, might not be a bad thing all in all. We should, perhaps, be a little more kind to our NATs. Just thinking out loud.... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnyapER27sUhU9OQRAmzJAKDpXrh5Lgce2Se/GwlmYL57VrHX2gCgoL9Y +tCTW13BmAw1JmlvVVSaIAE= =Q2W8 -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jan 06 00:12:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H33qo-0003zU-L1; Sat, 06 Jan 2007 00:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H33qm-0003z6-TX for ram@iab.org; Sat, 06 Jan 2007 00:12:12 -0500 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H33ql-0000Ed-Lj for ram@iab.org; Sat, 06 Jan 2007 00:12:12 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (alnrmhc14) with SMTP id <20070106051200b1400mj30be>; Sat, 6 Jan 2007 05:12:11 +0000 In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E162D7B-7045-4EE4-BEC5-F1F94D50200A@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] Date: Fri, 5 Jan 2007 21:11:57 -0800 To: Chris L. Morrow X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Useless without a distributed database that coordinates locator/ >> identifier bindings and manages available locators, at which point it >> looks a heck of a lot like something much more powerful than just >> NAT. Shim7, anyone? ;-) > > I think I might miss why it's 'useless', i think it'd be quite nice > (say > for mobile things or even laptops) if you could easily migrate from > location to location and maintain connectivity without restarting > all the > vpn/http/ssh/blah sessions I have to restart everytime my laptop > moves. > Something that let my locator's change 'at will' (provide some > assurance > that I'm really me during/after move, sure) would be nice. With that > doesn't NAT at my 2 ISP link points (NAT to PA space in each ISP) just > look like that sort of mobility? (essentially I move from isp to > isp in > some form of rapid sucession). > > I admit that I oversimplified things, but 'useless' it didn't seem. Chris, Please first understand that we're talking about 'useless' for solving the multihoming problem and implementing a true loc/id split. NAT is wonderful for helping to preserve address space. Horrible in that it violates a clean e2e architecture. That said, even if you exist behind a NAT where there's non-trivial topology and you have to roam and get a new DHCP address for your laptop, the NAT box is going to have NO idea that it's the same laptop and your TCP sessions will necessarily close. Regards, Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jan 06 01:48:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35Kp-0004Qw-Sd; Sat, 06 Jan 2007 01:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H35Ko-0004Qn-Mn for ram@iab.org; Sat, 06 Jan 2007 01:47:18 -0500 Received: from omzesmtp01.mci.com ([199.249.17.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H35Kl-0007tN-D0 for ram@iab.org; Sat, 06 Jan 2007 01:47:18 -0500 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBF00AEXPI6T6@firewall.mci.com> for ram@iab.org; Sat, 06 Jan 2007 06:46:54 +0000 (GMT) Received: from dgismtp02.mcilink.com ([127.0.0.1]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBF00J5PPI5NB@dgismtp02.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 06:46:54 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBF00H9FPI5M5@dgismtp02.mcilink.com> for ram@iab.org; Sat, 06 Jan 2007 06:46:53 +0000 (GMT) Date: Sat, 06 Jan 2007 06:46:53 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] In-reply-to: <2E162D7B-7045-4EE4-BEC5-F1F94D50200A@tony.li> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Tony Li Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> <2E162D7B-7045-4EE4-BEC5-F1F94D50200A@tony.li> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Fri, 5 Jan 2007, Tony Li wrote: > > That said, even if you exist behind a NAT where there's non-trivial > topology and you have to roam and get a new DHCP address for your > laptop, the NAT box is going to have NO idea that it's the same > laptop and your TCP sessions will necessarily close. > today it does because it needs to maintain state and because the upper layer protocol(s) also track the locator/id as a single entity, yes :( It seemed to me that GSE/8+8 gave an opportunity to get away from that set of problems. (locator re-writing) I think in the context of the larger network there is a place for both PI and locator re-write. I'm not sure that locator re-write should be done 'anywhere' but at provider/customer edge it seems simpler to accomplish. There will always be sites with enough complexity/money/reasons to want/need PI space I think that has to be accepted to some extent. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jan 06 08:09:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3BHI-0007nc-3i; Sat, 06 Jan 2007 08:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3BHH-0007nS-CG for ram@iab.org; Sat, 06 Jan 2007 08:08:03 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3BHF-0006Lr-On for ram@iab.org; Sat, 06 Jan 2007 08:08:03 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5DCA11223F9; Sat, 6 Jan 2007 14:07:58 +0100 (CET) Received: from [163.117.203.253] (unknown [163.117.203.253]) by smtp01.uc3m.es (Postfix) with ESMTP id 0003C119F61; Sat, 6 Jan 2007 14:07:54 +0100 (CET) In-Reply-To: References: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> <459E6113.9060404@zurich.ibm.com> <1797C0B2-4F23-4D84-8E65-202C35DBF401@ndsu.edu> <51A3A763-4F87-4881-A3BD-908F518B9964@cisco.com> <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6892efc82c45f4088ca179336dab4e80@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] Date: Sat, 6 Jan 2007 14:07:55 +0100 To: "Chris L. Morrow" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 06/01/2007, a las 4:02, Chris L. Morrow escribi=F3: > > On Fri, 5 Jan 2007, Tony Li wrote: > >> >>>>> Today NAT is a sort of locator rewriting and it doesn't allow >>>>> aggregation. >>>> >>>> NAT permits most excellent aggregation as long as you're willing to >>>> deal with PA addresses. What really becomes cumbersome tho, is = when >>>> multihoming is involved. Then, hosts interacting with the hosts >>>> behind the NAT aren't aware of the multiple locators allocated to >>>> their correspondent and havoc ensues. >>>> >>>> So, I'd rather say that NAT does rewrite locators, but in an >>>> uncoordinated way that defeats most of the benefits of multihoming. >>>> As such, it's pretty much useless as a long-term architectural >>>> strategy. >>> >>> useless without something that allows the locators switching to not >>> affect >>> the upper layer protocol state? or useless entirely? (perhaps if >>> the upper >>> layer protocol state were unaffected it wouldn't be called NAT?) >> >> >> Useless without a distributed database that coordinates locator/ >> identifier bindings and manages available locators, at which point it >> looks a heck of a lot like something much more powerful than just >> NAT. Shim7, anyone? ;-) > > I think I might miss why it's 'useless', i think it'd be quite nice=20 > (say > for mobile things or even laptops) if you could easily migrate from > location to location and maintain connectivity without restarting all=20= > the > vpn/http/ssh/blah sessions I have to restart everytime my laptop = moves. but NAT by itself doesn't give you that, i think, you need an=20 additional protocol > Something that let my locator's change 'at will' (provide some=20 > assurance > that I'm really me during/after move, sure) would be nice. With that > doesn't NAT at my 2 ISP link points (NAT to PA space in each ISP) just > look like that sort of mobility? (essentially I move from isp to isp = in > some form of rapid sucession). right, so in order to preserve you established vpn/http/ssh connections=20= you need a mobility (or a multihoming) protocol and you also need a=20 mechanism to discover the public address that the nat is using from the=20= PA block... > > I admit that I oversimplified things, but 'useless' it didn't seem. > i don't think that NAT are useless, especially in v6 when you can do=20 one to one address mapping, but for me the key feature they provide is=20= address protability avoiding provider lock in. They do not seem to be useful by themselves to preserve established=20 connections through outages in multihomed environments though (even=20 they could provide some more limited fault tolerance, like allowing new=20= communications after an outage) Regards, marcelo > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jan 06 17:26:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Jy5-00083f-2V; Sat, 06 Jan 2007 17:24:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Jy4-00083a-4I for ram@iab.org; Sat, 06 Jan 2007 17:24:48 -0500 Received: from [2a01:d0::6:2] (helo=master.netassist.kiev.ua) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Jxz-0004nA-Gj for ram@iab.org; Sat, 06 Jan 2007 17:24:48 -0500 Received: from [195.214.209.43] (helo=[192.168.253.3]) by master.netassist.kiev.ua with esmtpa (Exim 4.60 and XAMS 0.0.13) id 1H3Jtp-0008P6-Ce for ram@iab.org; Sun, 07 Jan 2007 00:20:25 +0200 Message-ID: <45A02197.5060802@netassist.kiev.ua> Date: Sun, 07 Jan 2007 00:24:23 +0200 From: Max Tulyev User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Destination Locator selection References: <21E6139C-6114-4854-86F9-3618C1A7B3EB@cisco.com> <6C57359C-D7DB-4F88-BF4B-8FA4E82C0D56@virtualized.org> <9EE7B0F9-18AF-40BD-A514-CB7C663DB7AC@cisco.com> <73C711A3-F3D9-4E4D-B739-FFFC4692A893@virtualized.org> <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> In-Reply-To: <0D638088-59A8-4F14-B9B8-E97DD345D4EB@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Roland Dobbins пишет: > I don't think it's in anyone's best interests to tie IP networking to > any particular naming system, for all the reasons already listed, for > reasons of futureproofing, etc. I believe it is in fact a Very Bad Idea. Mine proposal is not to tie IP networking to DNS, but it shows a way for back-up and traffic engineering FOR SOME SERVICES (not addresses!) without getting AS/PI working just now. Owners of www.[verystablesite].com wish their site to be reachable if at least one of their N channels alive, and let customers connect imap.[verystablesite].com, and mailers send mail to mail.[verystablesite].com, and etc. Load ballancing can be done same way. This is most common task for multihoming. It can be solved without wasting world route table, also cheaper way for a user, without any BGP router. And this task depends on DNS system by default. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jan 06 18:30:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Kxu-0003Px-4P; Sat, 06 Jan 2007 18:28:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Kxs-0003PT-5c for ram@iab.org; Sat, 06 Jan 2007 18:28:40 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Kxn-000601-JJ for ram@iab.org; Sat, 06 Jan 2007 18:28:40 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H3Kxl-00087I-Sa for ram@iab.org; Sat, 06 Jan 2007 15:28:34 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Jan 2007 00:28:21 +0100 To: "Bound, Jim" ,"Max Tulyev" , Roland Dobbins , From: JFC Morfin Subject: RE: [RAM] End-user multihoming idea In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FD62F@tayexc14.americas .cpqcorp.net> References: <459AEA23.1020807@netassist.kiev.ua> <816DD9299957E547B5D758D7F977D6DC011FD62F@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060349014==" Errors-To: ram-bounces@iab.org Message-Id: --===============1060349014== Content-Type: multipart/alternative; boundary="----MTuycftzmapuxnrztsxztuajibugwxbxym" ------MTuycftzmapuxnrztsxztuajibugwxbxym Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7C207E05 Dear Max, Jim, and Roland, I support Max and Jim, but Roland's too. The DNSS proposition I introduced last month was actually a DDDS, permitting to use the DNS existing infrastructure in order to resolve a dynamically computed route rather than an address. The pros: 1) the DNS front-end exists but nother is bound to the DNS, any other DDDS is OK 2) the mechanism is "super SHIM6" like: it actually consider a route rather than a simple multihoming 3) the well proven TTL system permits to cache a route and not to call on any system once the necessary first call has been carried out. In case of access failure the only thing to do is to erase the cache. 4) different DNSS servers can provide different routes for different relational spaces, or compute different routes based upon users' constraints. At this stage this does not covers the semantic of a route description, nor the supervision function computing the route, nor the node/node links status description dissemination system to fed the supervisors' databases. jfc At 05:15 03/01/2007, Bound, Jim wrote: >Folks, I think this is getting to detailed for now. But if we go here I >will argue do not use DNS. But I won't do that now but just pointing it >out for the future how to engineering the solution architecture. > >/jim > > > -----Original Message----- > > From: Max Tulyev [mailto:maxtul@netassist.kiev.ua] > > Sent: Tuesday, January 02, 2007 6:26 PM > > To: ram@iab.org > > Subject: [RAM] End-user multihoming idea > > > > Hi All, > > > > I think it is a good idea to use DNS names as a kind of > > "route identifiers" for end-users. The only you need is two > > (or more) connections to different ISPs and specially crafted > > DNS server that generates non-cacheable (TTL=1) replies using > > extra data (i.e. source address of querier, channels load > > statistics, is the particular channel in use or broken now, etc). > > > > It will be good enough for stable access to the site and > > services (www.foo.com, mail.foo.com, ...) with back-ups and > > load ballancing - the only thing most people expect from multihoming. > > > > Yes, it doesn't help for hardcoded IP services, and > > established connections will be lost (but probably restores > > with new IP) when one of channels went down, but most of > > users will experience no problems at all. > > > > -- > > WBR, > > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram ------MTuycftzmapuxnrztsxztuajibugwxbxym Content-Type: text/html Dear Max, Jim, and Roland,
I support Max and Jim, but Roland's too. The DNSS proposition I
introduced last month was actually a DDDS, permitting to use the DNS
existing infrastructure in order to resolve a dynamically computed
route rather than an address. The pros:

1) the DNS front-end exists but nother is bound to the DNS, any other
DDDS is OK
2) the mechanism is "super SHIM6" like: it actually consider a route
rather than a simple multihoming
3) the well proven TTL system permits to cache a route and not to
call on any system once the necessary first call has been carried
out. In case of access failure the only thing to do is to erase the cache.
4) different DNSS servers can provide different routes for different
relational spaces, or compute different routes based upon users' constraints.

At this stage this does not covers the semantic of a route
description, nor the supervision function computing the route, nor
the node/node links status description dissemination system to fed
the supervisors' databases.
jfc


At 05:15 03/01/2007, Bound, Jim wrote:

>Folks, I think this is getting to detailed for now.  But if we go here I
>will argue do not use DNS. But I won't do that now but just pointing it
>out for the future how to engineering the solution architecture.
>
>/jim
>
> > -----Original Message-----
> > From: Max Tulyev [mailto:maxtul@netassist.kiev.ua]
> > Sent: Tuesday, January 02, 2007 6:26 PM
> > To: ram@iab.org
> > Subject: [RAM] End-user multihoming idea
> >
> > Hi All,
> >
> > I think it is a good idea to use DNS names as a kind of
> > "route identifiers" for end-users. The only you need is two
> > (or more) connections to different ISPs and specially crafted
> > DNS server that generates non-cacheable (TTL=1) replies using
> > extra data (i.e. source address of querier, channels load
> > statistics, is the particular channel in use or broken now, etc).
> >
> > It will be good enough for stable access to the site and
> > services (www.foo.com, mail.foo.com, ...) with back-ups and
> > load ballancing - the only thing most people expect from multihoming.
> >
> > Yes, it doesn't help for hardcoded IP services, and
> > established connections will be lost (but probably restores
> > with new IP) when one of channels went down, but most of
> > users will experience no problems at all.
> >
> > --
> > WBR,
> > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
> >
> > _______________________________________________
> > RAM mailing list
> > RAM@iab.org
> > https://www1.ietf.org/mailman/listinfo/ram
> >
>
>_______________________________________________
>RAM mailing list
>RAM@iab.org
>https://www1.ietf.org/mailman/listinfo/ram

------MTuycftzmapuxnrztsxztuajibugwxbxym-- --===============1060349014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1060349014==-- From ram-bounces@iab.org Sat Jan 06 19:14:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3LgI-0001Rr-0N; Sat, 06 Jan 2007 19:14:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3LgH-0001Rm-Gw for ram@iab.org; Sat, 06 Jan 2007 19:14:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3LgG-0005XV-74 for ram@iab.org; Sat, 06 Jan 2007 19:14:33 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 06 Jan 2007 16:14:27 -0800 X-IronPort-AV: i="4.13,157,1167638400"; d="scan'208"; a="98805539:sNHT53769708" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l070ER07032314; Sat, 6 Jan 2007 16:14:27 -0800 Received: from [10.25.7.116] (rdobbins-vpn-4.cisco.com [10.25.7.116]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l070EMlb000804; Sat, 6 Jan 2007 16:14:22 -0800 (PST) In-Reply-To: <5g725m$10mhr8@sj-inbound-a.cisco.com> References: <459AEA23.1020807@netassist.kiev.ua> <816DD9299957E547B5D758D7F977D6DC011FD62F@tayexc14.americas.cpqcorp.net> <5g725m$10mhr8@sj-inbound-a.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] End-user multihoming idea Date: Sat, 6 Jan 2007 16:14:14 -0800 To: JFC Morfin X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=391; t=1168128867; x=1168992867; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20End-user=20multihoming=20idea |Sender:=20; bh=G92nGExuCcfRoeLJSnDUd0fxqDr+Puzv5FPe6/WmESo=; b=OibNeV01DHVgYmyGQ438fWm8sa4reskHD2zZbN/1JiGENEH1ZyLZtSHh89IyzW/utEI0UQ8r FXrQEvBZvQ6UBT1CjbGc4QUTne5b2bVN25rMwxB0mWhRSu0gD7bJUEEw; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org, "Bound, Jim" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 6, 2007, at 3:28 PM, JFC Morfin wrote: > The DNSS proposition I > introduced last month was actually a DDDS, I'll take a look at this, thanks! ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jan 07 12:14:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3baC-00016K-3L; Sun, 07 Jan 2007 12:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3baA-000143-NU for ram@iab.org; Sun, 07 Jan 2007 12:13:18 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ba8-0003Jd-Kn for ram@iab.org; Sun, 07 Jan 2007 12:13:18 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H3ba5-0001k8-3U for ram@iab.org; Sun, 07 Jan 2007 09:13:13 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 07 Jan 2007 18:13:02 +0100 To: "Bound, Jim" ,"Roland Dobbins" , From: JFC Morfin Subject: Re: [RAM] Discovery In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FD63A@tayexc14.americas .cpqcorp.net> References: <3D4F8E9A-973B-4AC5-A608-B2985A51A7DF@cisco.com> <816DD9299957E547B5D758D7F977D6DC011FD63A@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010782203==" Errors-To: ram-bounces@iab.org Message-Id: --===============2010782203== Content-Type: multipart/alternative; boundary="----MTnoyriaszutfdxupwrhcqhwehoyeegeom" ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7A4D60C6 Jim, Very interesting remark as permits to ask simply the very basic question: in your mind should we bound to a single net centricity technology and implementation? Thanks. jfc At 05:42 03/01/2007, Bound, Jim wrote: >Just for thinking there is a set of principles used by U.S. DOD and NATO >and others called net centricity. My reference to this work is the >computer science term and not applied with terms like net centric >warfare or net centric ops, but rather a set of pre-conditions to >achieve net centricity from models to implementations. But it is >beginning to permeate out of the classic military environment and the >core principles I extrapolate and test I use for any architecture and >for implementation are does the networking result provide: connectivity, >interoperability, security, discovery, QoS, and end-to-end (meaning two >peers can communicate without middle boxes and packets could be >encrypted so only the current IP header is in the clear). The point of >discovery is quite important as that is how the network learns of >parameters and information required. And does need some thought while >developing an architecture. If any of these pre-conditions are missing >above (and some add others as a note) net centricity can be negatively >impacted, including discovery. What the answer is for our work here for >discovery is entirely premature to discuss (e.g. DNS, LDAP, UDDI, >LDAP+UDDI, SLP, SOAP, etc). > >Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka > >Best, >/jim > > > > -----Original Message----- > > From: Roland Dobbins [mailto:rdobbins@cisco.com] > > Sent: Tuesday, January 02, 2007 11:21 PM > > To: ram@iab.org > > Subject: Re: [RAM] Destination Locator selection > > > > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: > > > > > Putting the architecture discussion hat on only I would not > > entirely > > > agree given how we have been using the term 'namespace', > > but I do see > > > the concern and point. To find compromise I would suggest > > we do need > > > to be concerned about the principle of "discovery" within the new > > > architecture model. > > > > Thanks for the clarification; in this particular case it was > > a semantic issue, but one to which attention must be paid, lest > > (further) confusion ensue. > > > > > > -------------------------------------------------------------- > > --------- > > Roland Dobbins // 408.527.6376 voice > > > > All battles are perpetual. > > > > -- Milton Friedman > > > > > > > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram ------MTnoyriaszutfdxupwrhcqhwehoyeegeom Content-Type: text/html Jim,
Very interesting remark as permits to ask simply the very basic
question: in your mind should we bound to a single net centricity
technology and implementation?
Thanks.
jfc


At 05:42 03/01/2007, Bound, Jim wrote:

>Just for thinking there is a set of principles used by U.S. DOD and NATO
>and others called net centricity.  My reference to this work is the
>computer science term and not applied with terms like net centric
>warfare or net centric ops, but rather a set of pre-conditions to
>achieve net centricity from models to implementations.  But it is
>beginning to permeate out of the classic military environment and the
>core principles I extrapolate and test I use for any architecture and
>for implementation are does the networking result provide: connectivity,
>interoperability, security, discovery, QoS, and end-to-end (meaning two
>peers can communicate without middle boxes and packets could be
>encrypted so only the current IP header is in the clear).  The point of
>discovery is quite important as that is how the network learns of
>parameters and information required.  And does need some thought while
>developing an architecture. If any of these pre-conditions are missing
>above (and some add others as a note) net centricity can be negatively
>impacted, including discovery.  What the answer is for our work here for
>discovery is entirely premature to discuss (e.g. DNS, LDAP, UDDI,
>LDAP+UDDI, SLP, SOAP, etc).
>
>Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka
>
>Best,
>/jim
>
>
> > -----Original Message-----
> > From: Roland Dobbins [mailto:rdobbins@cisco.com]
> > Sent: Tuesday, January 02, 2007 11:21 PM
> > To: ram@iab.org
> > Subject: Re: [RAM] Destination Locator selection
> >
> >
> > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote:
> >
> > > Putting the architecture discussion hat on only I would not
> > entirely
> > > agree given how we have been using the term 'namespace',
> > but I do see
> > > the concern and point.  To find compromise I would suggest
> > we do need
> > > to be concerned about the principle of "discovery" within the new
> > > architecture model.
> >
> > Thanks for the clarification; in this particular case it was
> > a semantic issue, but one to which attention must be paid, lest
> > (further) confusion ensue.
> >
> >
> > --------------------------------------------------------------
> > ---------
> > Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice
> >
> >               All battles are perpetual.
> >
> >                  -- Milton Friedman
> >
> >
> >
> >
> > _______________________________________________
> > RAM mailing list
> > RAM@iab.org
> > https://www1.ietf.org/mailman/listinfo/ram
> >
>
>_______________________________________________
>RAM mailing list
>RAM@iab.org
>https://www1.ietf.org/mailman/listinfo/ram

------MTnoyriaszutfdxupwrhcqhwehoyeegeom-- --===============2010782203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============2010782203==-- From ram-bounces@iab.org Sun Jan 07 18:43:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hfH-0003Ql-An; Sun, 07 Jan 2007 18:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hfG-0003Qd-VX for ram@iab.org; Sun, 07 Jan 2007 18:42:58 -0500 Received: from centrmmtao03.cox.net ([70.168.83.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3hfE-0005FJ-KC for ram@iab.org; Sun, 07 Jan 2007 18:42:58 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070107234253.PKHE13993.centrmmtao03.cox.net@eastrmimpo02.cox.net> for ; Sun, 7 Jan 2007 18:42:53 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 8PhU1W00H0pnMhQ0000000; Sun, 07 Jan 2007 18:41:29 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <30D8C720-5D13-4705-A194-EA567982D960@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 7 Jan 2007 18:42:50 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [RAM] Re: PI v locator rewriting X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier, Tony Li said: > NAT permits most excellent aggregation as long as you're willing to > deal > with PA addresses. What really becomes cumbersome tho, is when > multihoming > is involved. Then, hosts interacting with the hosts behind the NAT > aren't > aware of the multiple locators allocated to their correspondent and > havoc ensues. > > So, I'd rather say that NAT does rewrite locators, but in an > uncoordinated > way that defeats most of the benefits of multihoming. As such, it's > pretty > much useless as a long-term architectural strategy. Tony, Maybe I've misunderstood, but the first paragraph above appears to say that existing/deployed NAT systems are not sufficient BECAUSE they do not *currently* include a way for correspondents to discover all valid Locators associated with a destination node. If that's a correct understanding, ought not the second paragraph be saying instead that: "In order for NAT to provide multi-homing benefits, we need to enhance it with a mechanism to permit correspondent nodes to discover the full set of valid Locators for nodes behind the NAT (or whatever one calls it) that are communicating with the correspondent nodes." So I don't see this as an *architectural* (using JNC's definition) issue so much as an specification/implementation gap. What am I missing here ? Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jan 07 18:47:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hjv-00052P-Nv; Sun, 07 Jan 2007 18:47:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hju-00052K-8b for ram@iab.org; Sun, 07 Jan 2007 18:47:46 -0500 Received: from centrmmtao03.cox.net ([70.168.83.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3hjs-000676-Vq for ram@iab.org; Sun, 07 Jan 2007 18:47:46 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by centrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070107234744.PMYQ13993.centrmmtao03.cox.net@eastrmimpo02.cox.net> for ; Sun, 7 Jan 2007 18:47:44 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 8PmL1W0020pnMhQ0000000; Sun, 07 Jan 2007 18:46:20 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 7 Jan 2007 18:47:42 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [RAM] Re: Should we provide protection against time shifted attacks? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Marcelo, I know of practical "Time Shifted Attacks" for the currently deployed IPv4 Internet. I also know of practical "3rd Party DoS Attacks" for the currently deployed IPv4 Internet. If some RFC really asserts that none exist, then either there was an editing error someplace or someone was confused. Yours, Ran PS: I don't discuss mechanisms for active attacks on any deployed network on any public mailing list -- except by way of citing already published papers by other people. That's been my policy for many years and won't be changing anytime soon. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jan 07 18:52:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hom-0007AX-6T; Sun, 07 Jan 2007 18:52:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3hol-0007AR-3S for ram@iab.org; Sun, 07 Jan 2007 18:52:47 -0500 Received: from eastrmmtao01.cox.net ([68.230.240.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3hoj-00077X-RD for ram@iab.org; Sun, 07 Jan 2007 18:52:47 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070107235245.UBTH20860.eastrmmtao01.cox.net@eastrmimpo02.cox.net> for ; Sun, 7 Jan 2007 18:52:45 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 8PrL1W0030pnMhQ0000000; Sun, 07 Jan 2007 18:51:20 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 7 Jan 2007 18:52:42 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [RAM] Locator/Identifier mapping X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier Tony Li wrote: % Useless without a distributed database that coordinates locator/ identifier % bindings and manages available locators, at which point it looks % a heck of a lot like something much more powerful than just NAT. % % Shim7, anyone? ;-) % The use of "distributed database" in that sentence immediately makes one think of the DNS -- at least as part of a solution. (Mind, I'm notorious for recycling existing technology in preference to inventing something gratuitously new and different. :-) Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jan 07 23:43:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mL1-00052x-HM; Sun, 07 Jan 2007 23:42:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3mL0-00051y-EL for ram@iab.org; Sun, 07 Jan 2007 23:42:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3mKy-00053p-3r for ram@iab.org; Sun, 07 Jan 2007 23:42:22 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2007 20:42:11 -0800 X-IronPort-AV: i="4.13,158,1167638400"; d="scan'208"; a="455689889:sNHT46653340" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l084gBRa016797; Sun, 7 Jan 2007 20:42:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l084g4ZJ015832; Sun, 7 Jan 2007 20:42:07 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 20:42:04 -0800 Received: from [192.168.0.101] ([10.21.116.60]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 20:42:04 -0800 In-Reply-To: <30D8C720-5D13-4705-A194-EA567982D960@extremenetworks.com> References: <30D8C720-5D13-4705-A194-EA567982D960@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: PI v locator rewriting Date: Sun, 7 Jan 2007 20:42:08 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Jan 2007 04:42:04.0463 (UTC) FILETIME=[58585BF0:01C732DF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1555; t=1168231331; x=1169095331; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20PI=20v=20locator=20rewriting |Sender:=20; bh=2T+8APlQyQNS/NkIrznaA76UdPpKzTPTcep5dpRtniQ=; b=R48cC5p8COMy9mPTLGwelBIGFvzpLLn3gJgsz8PvaDoOTJeO/wH3T7y/2SyvM11NOCO4GY22 a1mSbSMhUi1iTj0tFNdXZM4/dns4No/fLLJ70bfTHg7o/JQPZM3HpAVx; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 7, 2007, at 3:42 PM, RJ Atkinson wrote: > Earlier, Tony Li said: >> NAT permits most excellent aggregation as long as you're willing >> to deal >> with PA addresses. What really becomes cumbersome tho, is when >> multihoming >> is involved. Then, hosts interacting with the hosts behind the NAT >> aren't >> aware of the multiple locators allocated to their correspondent and >> havoc ensues. >> >> So, I'd rather say that NAT does rewrite locators, but in an >> uncoordinated >> way that defeats most of the benefits of multihoming. As such, >> it's pretty >> much useless as a long-term architectural strategy. > > Maybe I've misunderstood, but the first paragraph above appears > to say that existing/deployed NAT systems are not sufficient BECAUSE > they do not *currently* include a way for correspondents to discover > all valid Locators associated with a destination node. > > If that's a correct understanding, ought not the second paragraph > be saying instead that: > > "In order for NAT to provide multi-homing benefits, > we need to enhance it with a mechanism to permit > correspondent nodes to discover the full set of valid Locators > for nodes behind the NAT (or whatever one calls it) that are > communicating with the correspondent nodes." > > So I don't see this as an *architectural* (using JNC's definition) > issue so much as an specification/implementation gap. > > What am I missing here ? Yes, you could do that, but then it wouldn't be NAT, would it now? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 01:14:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nld-0000p8-02; Mon, 08 Jan 2007 01:13:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3nlb-0000oe-OJ for ram@iab.org; Mon, 08 Jan 2007 01:13:55 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3nla-00007q-2U for ram@iab.org; Mon, 08 Jan 2007 01:13:55 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DF887213347; Mon, 8 Jan 2007 08:13:45 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 972FE2132F3; Mon, 8 Jan 2007 08:13:45 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? Date: Mon, 8 Jan 2007 08:13:39 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ran, > I know of practical "Time Shifted Attacks" for the currently > deployed IPv4 Internet. This was news to me -- I must be ignorant. Or, to be more precise, I know of one that allows time shifting of minutes or at most hours, depending of deployed configuration parameters, but not of longer. When designing MIPv6, we ended up allowing time shifting of minutes, by default. > I also know of practical "3rd Party DoS Attacks" for the > currently deployed IPv4 Internet. Me too. But even so, do you think we should design new mechanism that we know, at the design time, to embed new ways of launching such attacks? --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 04:47:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r5b-0003XL-K2; Mon, 08 Jan 2007 04:46:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3r5a-0003X2-P0 for ram@iab.org; Mon, 08 Jan 2007 04:46:46 -0500 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3r5Z-0002O7-7i for ram@iab.org; Mon, 08 Jan 2007 04:46:46 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBJN5S03.91J; Mon, 8 Jan 2007 10:46:40 +0100 In-Reply-To: <459E5CDF.8040302@cisco.com> X-Priority: 1 (High) Subject: Re: [RAM] Destination Locator selection To: Russ White X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Mon, 8 Jan 2007 10:46:37 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 08/01/2007 10:45:09 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ, Russ White escribi=F3 el 05/01/2007 15:12:47: > > > - With a mechanism like TIDR we don't overload the identifier. > > We just dynamically add a locator to the identifier. And the > > locator will be provided by your ISP. > > You're using IP addresses for both, so you're overloading the IP addr= ess > space as both locators and identifiers. > Yes, in TIDR we use IP addresses for both BUT not at the same time. As I have shown in the draft, we could dedicate prefix 240.0.0.0/8 for interdomain locators only. This means that these IP addresses cannot be used but to encapsulate traffic that will be tunneled. In other words, from the whole IP address space a subset of addresses is just used as locators, and locators only. You cannot telnet for example to an IP address that is a locator. This is more clearly seen when you think in IPv4 locators to transport IPv6 packets: an IPv6 identifier prefix would be announced with an IPv4 locator in the BGP update. > > I think we have mainly two problems to solve: (1) scalability of > > the global BGP table, (2) BGP churn. > > TIDR "solves" both though virtualization. > > My point is that while this seems attractive, we must remember that w= e > already have L3VPNs, which are the same sort of virtualization at a > different level, and we're getting into heavy virtualization within > enterprise networks, as well. > > The question is, when you start layering virtualizations on top of on= e > another, what sort of mess do you create in terms of being able to > manage and troubleshoot the layers? We've already seen that hierarchi= cal > layers of more than four or five deep can make things difficult to > troubleshoot, etc, so we tend to virtualize beyond that. This type of virtualization layering already works in other scenarios: think on an international parcel service company (IPS Company). When I order a book to a bookshop in Mexico and I request the book to be delivered by the IPS Company, this company puts the book in a big container specifying destination SPAIN. Once the container is received, for example in the Barcelona Airport, they open the container and gather all the packets with destination MADRID. All these parcels are then put in a truck that will transport them to Madrid. Once in Madrid the Post Office, for example, checks the ZIP code of the parcel and proceeds to deliver the book. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 08:12:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3uHd-0003FU-Ju; Mon, 08 Jan 2007 08:11:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3uHc-0003FP-VO for ram@iab.org; Mon, 08 Jan 2007 08:11:24 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3uHb-0006z9-MM for ram@iab.org; Mon, 08 Jan 2007 08:11:24 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H3uHa-0003F8-0O for ram@iab.org; Mon, 08 Jan 2007 05:11:22 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jan 2007 14:11:18 +0100 To: RJ Atkinson ,ram@iab.org From: JFCM Subject: Re: [RAM] Locator/Identifier mapping In-Reply-To: References: MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.5 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0519986543==" Errors-To: ram-bounces@iab.org Message-Id: --===============0519986543== Content-Type: multipart/alternative; boundary="----MThepttcbbcuujpltmivvdcbbfrfogjvii" ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-73A232E7 At 00:52 08/01/2007, RJ Atkinson wrote: >Earlier Tony Li wrote: >% Useless without a distributed database that coordinates locator/ identifier >% bindings and manages available locators, at which point it looks >% a heck of a lot like something much more powerful than just NAT. >% >% Shim7, anyone? ;-) >% > >The use of "distributed database" in that sentence immediately makes one >think of the DNS -- at least as part of a solution. This makes one think of a DDDS? The way I understand DDDS, DNS is one of them. jfc ------MThepttcbbcuujpltmivvdcbbfrfogjvii Content-Type: text/html At 00:52 08/01/2007, RJ Atkinson wrote:

>Earlier Tony Li wrote:
>% Useless without a distributed database that coordinates locator/ identifier
>% bindings and manages available locators, at which point it looks
>% a heck of a lot like something much more powerful than just NAT.
>%
>% Shim7, anyone? ;-)
>%
>
>The use of "distributed database" in that sentence immediately makes one
>think of the DNS -- at least as part of a solution.

This makes one think of a DDDS?
The way I understand DDDS, DNS is one of them.
jfc  

------MThepttcbbcuujpltmivvdcbbfrfogjvii-- --===============0519986543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0519986543==-- From ram-bounces@iab.org Mon Jan 08 10:03:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3w1j-00069o-W7; Mon, 08 Jan 2007 10:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3w1i-00069i-Ej for ram@iab.org; Mon, 08 Jan 2007 10:03:06 -0500 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3w1g-0008Qj-4c for ram@iab.org; Mon, 08 Jan 2007 10:03:06 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBK1SS01.007; Mon, 8 Jan 2007 16:02:52 +0100 In-Reply-To: <20061231155233.DC40E872D4@mercury.lcs.mit.edu> X-Priority: 1 (High) Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Mon, 8 Jan 2007 16:02:49 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 08/01/2007 16:01:20 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel, jnc@mercury.lcs.mit.edu (Noel Chiappa) escribi=F3 el 31/12/2006 16:52:3= 3: > > Look, as far as I can work out, there are basically two classes of solution > to providing widespread multi-homing. > > The first is "let the routing do it". Alas, within the current routin= g > architecture, that amounts to "forcing every router in the entire > default-free zone to carry an advertisement for site X's PI-address",= which > is widely seen (although not universally, q.v. that address registry meeting > where they approved the PI proposal) as non-workable. > Yes, I also think the problem is the current routing architecture. We have several thousands of autonomous systems in the Internet that we treat all in the same way. But 1/6 of them does a crucial work: these are the transit AS-es, which receive packets coming from one AS and send them to anoter AS. Without transit AS-es (and with the current routing paradigm) we would need to form a huge full-mesh of connections between all the AS-es in the Internet. IMHO the problem is not to force every router in the entire DFZ to carry an advertisement for site X's PI-address. The real problem is that it has to use it for routing, i.e. install it in the RIB and download it in the FIB. Using some type of hierarchy, DFZ routers could give up using PI addresses, specifically those of non-transit AS-es. Regards, Juanjo = _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 10:05:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3w3q-0006i1-Kj; Mon, 08 Jan 2007 10:05:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3w3p-0006hr-Gl for ram@iab.org; Mon, 08 Jan 2007 10:05:17 -0500 Received: from eastrmmtao02.cox.net ([68.230.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3w3n-0000y1-MG for ram@iab.org; Mon, 08 Jan 2007 10:05:16 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070108150512.CWDH9317.eastrmmtao02.cox.net@eastrmimpo02.cox.net> for ; Mon, 8 Jan 2007 10:05:12 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 8f3n1W00S0pnMhQ0000000; Mon, 08 Jan 2007 10:03:47 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> References: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? Date: Mon, 8 Jan 2007 10:05:10 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 8 Jan 2007, at 01:13, Pekka Nikander wrote: >> I know of practical "Time Shifted Attacks" for the currently >> deployed IPv4 Internet. > > This was news to me -- I must be ignorant. > > Or, to be more precise, I know of one that allows time shifting of > minutes or at most hours, depending of deployed configuration > parameters, but not of longer. When designing MIPv6, we ended up > allowing time shifting of minutes, by default. Saying "minutes or at most hours" is not fundamentally different from what I've said -- and that is VERY different from "no attacks exist", which is what Marcelo was claiming for the current IPv4 Internet. If we can live with that for MIPv6 (and I think the upper bound for MIPv6 is hours not minutes, by the way), then that same level of risk ought to be completely acceptable for some other approach, change, or enhancement for the Internet. >> I also know of practical "3rd Party DoS Attacks" for the >> currently deployed IPv4 Internet. > > Me too. > > But even so, do you think we should design new mechanism that we > know, at the design time, to embed new ways of launching such attacks? I think that really is the wrong question. More secure than at present is "nice to have" rather than "MUST". Further, my own experience is that any sort of system that has increased security will also become more brittle. There might be exceptions to that principle, but I can't immediately think of any. For example, requiring cryptographic authentication of some message often creates a new (D)DOS vector.[1] The question ought to be is whether some new scheme or enhancement is LESS SECURE than the currently deployed IPv4 Internet or the currently deployed IPv6 Internet. As long as the new scheme is NOT less secure, that ought to be sufficient. Fundamentally, if folks think that the current risks are NOT acceptable, then they ought to be criticising things like MIPv6 on insecurity grounds and ought to be focusing on fixing the current risks in the currently deployed Internet as their priority. Yours, Ran [1] Details of how the attack would work are deliberately omitted. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 10:12:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wAr-0001oO-Ht; Mon, 08 Jan 2007 10:12:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wAq-0001oI-6L for ram@iab.org; Mon, 08 Jan 2007 10:12:32 -0500 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wAo-0003Nb-P9 for ram@iab.org; Mon, 08 Jan 2007 10:12:32 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBK28U01.S08; Mon, 8 Jan 2007 16:12:30 +0100 In-Reply-To: <4B163ABD-86C9-4499-B9EA-0A9DD3B405C2@cisco.com> X-Priority: 1 (High) Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] To: Tony Li X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Mon, 8 Jan 2007 16:12:26 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 08/01/2007 16:10:57 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony, Tony Li escribi=F3 el 06/01/2007 03:52:28: > > >>> Today NAT is a sort of locator rewriting and it doesn't allow > >>> aggregation. > >> > >> NAT permits most excellent aggregation as long as you're willing t= o > >> deal with PA addresses. What really becomes cumbersome tho, is wh= en > >> multihoming is involved. Then, hosts interacting with the hosts > >> behind the NAT aren't aware of the multiple locators allocated to > >> their correspondent and havoc ensues. > >> > >> So, I'd rather say that NAT does rewrite locators, but in an > >> uncoordinated way that defeats most of the benefits of multihoming= . > >> As such, it's pretty much useless as a long-term architectural > >> strategy. > > > > useless without something that allows the locators switching to not= > > affect > > the upper layer protocol state? or useless entirely? (perhaps if > > the upper > > layer protocol state were unaffected it wouldn't be called NAT?) > > > Useless without a distributed database that coordinates locator/ > identifier bindings and manages available locators, at which point it= > looks a heck of a lot like something much more powerful than just > NAT. Shim7, anyone? ;-) > Why don't we use the BGP table to coordinate loc/id bindings?. This way the routing system would not depend on an external mechanism like the DNS. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:03:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wxv-0007Oj-6f; Mon, 08 Jan 2007 11:03:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wxu-0007O2-9Y for ram@iab.org; Mon, 08 Jan 2007 11:03:14 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wxr-0002W3-Pf for ram@iab.org; Mon, 08 Jan 2007 11:03:14 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l08G3Ax0150232 for ; Mon, 8 Jan 2007 16:03:10 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l08G3Avg2330822 for ; Mon, 8 Jan 2007 17:03:10 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l08G39VO021034 for ; Mon, 8 Jan 2007 17:03:09 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l08G38AC021017; Mon, 8 Jan 2007 17:03:09 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA321192; Mon, 8 Jan 2007 17:03:07 +0100 Message-ID: <45A26B38.5070604@zurich.ibm.com> Date: Mon, 08 Jan 2007 17:03:04 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <459D1C54.4000603@zurich.ibm.com> <20070104175355.GH32409@1-4-5.net> <5AA3B042-6737-4B59-9229-6A07B2C44E67@cisco.com> <20070104183653.GA5990@1-4-5.net> <459E688A.1000905@zurich.ibm.com> <887FB5F6-4922-4B5A-89AA-04A685AD1C79@cisco.com> In-Reply-To: <887FB5F6-4922-4B5A-89AA-04A685AD1C79@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-05 22:10, Tony Li wrote: > > On Jan 5, 2007, at 7:02 AM, Brian E Carpenter wrote: > >>>> I'm intrigued by this. To my way of thinking, the churn rate is an >>>> artifact of BGP's design, the actual physical changes in the >>>> topology, and operational input. It doesn't really seem to be >>>> architectural, it's just a side-effect of the control plane >>>> mechanisms that we've chosen. >> >> If that turns out to be true, it's excellent news - we don't >> need to change the architecture, we just need to fix the >> control plane. Seriously. > > > Brian, > > Is there some theory, argument or position that suggests that it's > architectural? If so, pointers please.... Frankly I think there's a lack of analysis, but certainly I have no such pointers. > > That said, I think that "just fixing the control plane" is not nearly as > trivial as you make it sound. I will point out that additional > hierarchy (i.e., abstraction) of routing information would certainly > help the problem, but that capability is already there today (e.g., > proxy aggregation) if folks could only bring themselves to use it... Correct, it isn't trivial, but control plane fixes should at least be possible on a stepwise basis, which strikes me as doable. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:09:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3x3t-0000iF-AB; Mon, 08 Jan 2007 11:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3x3s-0000i9-6I for ram@iab.org; Mon, 08 Jan 2007 11:09:24 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3x3q-0004g5-Ca for ram@iab.org; Mon, 08 Jan 2007 11:09:24 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l08G9Lhi146728 for ; Mon, 8 Jan 2007 16:09:21 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l08G9LCp1863760 for ; Mon, 8 Jan 2007 16:09:21 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l08G9Km4000703 for ; Mon, 8 Jan 2007 16:09:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l08G9Kxw000697; Mon, 8 Jan 2007 16:09:20 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA191534; Mon, 8 Jan 2007 17:09:19 +0100 Message-ID: <45A26CAE.3010607@zurich.ibm.com> Date: Mon, 08 Jan 2007 17:09:18 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? References: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-08 16:05, RJ Atkinson wrote: ... > > The question ought to be is whether some new scheme or > enhancement is LESS SECURE than the currently deployed IPv4 Internet > or the currently deployed IPv6 Internet. As long as the new scheme > is NOT less secure, that ought to be sufficient. Well, it meets the "first, do no harm" principle, but people who believe the Internet infrastructure is unacceptably insecure today may not agree. Also, it seems hard to judge - if a new feature introduces a qualitatively different threat, how can we assert that it is not less secure? Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:20:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xEN-0008Bj-Ev; Mon, 08 Jan 2007 11:20:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xEM-0008Bc-Df for ram@iab.org; Mon, 08 Jan 2007 11:20:14 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3xEK-0000Xp-VW for ram@iab.org; Mon, 08 Jan 2007 11:20:14 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l08GKCMd153766 for ; Mon, 8 Jan 2007 16:20:12 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l08GKCII3174508 for ; Mon, 8 Jan 2007 17:20:12 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l08GKBCn019693 for ; Mon, 8 Jan 2007 17:20:11 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l08GKBmf019686; Mon, 8 Jan 2007 17:20:11 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA315438; Mon, 8 Jan 2007 17:20:10 +0100 Message-ID: <45A26F38.8040902@zurich.ibm.com> Date: Mon, 08 Jan 2007 17:20:08 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: PI v locator rewriting References: <30D8C720-5D13-4705-A194-EA567982D960@extremenetworks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-08 05:42, Tony Li wrote: > > On Jan 7, 2007, at 3:42 PM, RJ Atkinson wrote: > >> Earlier, Tony Li said: >>> NAT permits most excellent aggregation as long as you're willing to deal >>> with PA addresses. What really becomes cumbersome tho, is when >>> multihoming >>> is involved. Then, hosts interacting with the hosts behind the NAT >>> aren't >>> aware of the multiple locators allocated to their correspondent and >>> havoc ensues. >>> >>> So, I'd rather say that NAT does rewrite locators, but in an >>> uncoordinated >>> way that defeats most of the benefits of multihoming. As such, it's >>> pretty >>> much useless as a long-term architectural strategy. >> >> Maybe I've misunderstood, but the first paragraph above appears >> to say that existing/deployed NAT systems are not sufficient BECAUSE >> they do not *currently* include a way for correspondents to discover >> all valid Locators associated with a destination node. >> >> If that's a correct understanding, ought not the second paragraph >> be saying instead that: >> >> "In order for NAT to provide multi-homing benefits, >> we need to enhance it with a mechanism to permit >> correspondent nodes to discover the full set of valid Locators >> for nodes behind the NAT (or whatever one calls it) that are >> communicating with the correspondent nodes." >> >> So I don't see this as an *architectural* (using JNC's definition) >> issue so much as an specification/implementation gap. >> >> What am I missing here ? > > > Yes, you could do that, but then it wouldn't be NAT, would it now? As a matter of fact, if you follow Ran's line of thought, and decide to solve the problem in the host, you get shim6. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:22:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xGA-0000Zm-1R; Mon, 08 Jan 2007 11:22:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xG8-0000Zc-Mm for ram@iab.org; Mon, 08 Jan 2007 11:22:04 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xG6-0007Fr-49 for ram@iab.org; Mon, 08 Jan 2007 11:22:04 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l08GLxXu092366 for ; Mon, 8 Jan 2007 16:21:59 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l08GLxUL3170500 for ; Mon, 8 Jan 2007 17:21:59 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l08GLwpO026311 for ; Mon, 8 Jan 2007 17:21:59 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l08GLwcJ026296; Mon, 8 Jan 2007 17:21:58 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA312626; Mon, 8 Jan 2007 17:21:57 +0100 Message-ID: <45A26FA4.4090308@zurich.ibm.com> Date: Mon, 08 Jan 2007 17:21:56 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JUAN-JOSE.ADAN@giss.seg-social.es Subject: Re: [RAM] PI v locator rewriting [Re: one size doesn' fit all] References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-08 16:12, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > Tony, >=20 > Tony Li escribi=C3=B3 el 06/01/2007 03:52:28: >>>>> Today NAT is a sort of locator rewriting and it doesn't allow >>>>> aggregation. >>>> NAT permits most excellent aggregation as long as you're willing to >>>> deal with PA addresses. What really becomes cumbersome tho, is when= >>>> multihoming is involved. Then, hosts interacting with the hosts >>>> behind the NAT aren't aware of the multiple locators allocated to >>>> their correspondent and havoc ensues. >>>> >>>> So, I'd rather say that NAT does rewrite locators, but in an >>>> uncoordinated way that defeats most of the benefits of multihoming. >>>> As such, it's pretty much useless as a long-term architectural >>>> strategy. >>> useless without something that allows the locators switching to not >>> affect >>> the upper layer protocol state? or useless entirely? (perhaps if >>> the upper >>> layer protocol state were unaffected it wouldn't be called NAT?) >> >> Useless without a distributed database that coordinates locator/ >> identifier bindings and manages available locators, at which point it >> looks a heck of a lot like something much more powerful than just >> NAT. Shim7, anyone? ;-) >> >=20 > Why don't we use the BGP table to coordinate loc/id bindings?. > This way the routing system would not depend on an external > mechanism like the DNS. Could we maybe focus on the (apparent) fact that we need a loc/id mapping service, and figure out what it needs to do? After that, we can consider whether it should be implemented using DNS, BGP, or avian carriers. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:22:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xGT-0000ig-E0; Mon, 08 Jan 2007 11:22:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xGS-0000iG-0V for ram@iab.org; Mon, 08 Jan 2007 11:22:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xGQ-0007IW-Ms for ram@iab.org; Mon, 08 Jan 2007 11:22:23 -0500 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2007 08:22:22 -0800 X-IronPort-AV: i="4.13,159,1167638400"; d="scan'208"; a="99204837:sNHT39434877" Received: from elear-mac.cisco.com ([10.61.80.227]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l08G5HmU032137; Mon, 8 Jan 2007 08:05:18 -0800 Message-ID: <45A26FBB.9030904@cisco.com> Date: Mon, 08 Jan 2007 17:22:19 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b1 (Macintosh/20061206) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Re: PI v locator rewriting References: <30D8C720-5D13-4705-A194-EA567982D960@extremenetworks.com> <45A26F38.8040902@zurich.ibm.com> In-Reply-To: <45A26F38.8040902@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=299; t=1168272319; x=1169136319; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20PI=20v=20locator=20rewriting |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=9lB4pmdKGMTIO2EDSIK/H+F43rE7mq8EMJ4MjeDZ8ho=; b=Wc5CNWOQpMpMVGkce3PhcjmsTuTChppSq23tUu31NFZPpZ8k9AO3zX7oMMlOy+fRdl5cGdY6 CLzRx9V9fxREcubvRPtfOUgBSBbv3bHlKkDo09aiPevWda5HzplyLMRj; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Tony Li , RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: >> >> >> Yes, you could do that, but then it wouldn't be NAT, would it now? > > As a matter of fact, if you follow Ran's line of thought, > and decide to solve the problem in the host, you get shim6. Right. Or something that looks an awful lot like HIP. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 11:50:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xhi-0005Ad-06; Mon, 08 Jan 2007 11:50:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xhh-0005AX-IQ for ram@iab.org; Mon, 08 Jan 2007 11:50:33 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3xhe-0001uF-9x for ram@iab.org; Mon, 08 Jan 2007 11:50:33 -0500 Received: from pmismtp05.wcomnet.com ([166.37.158.165]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JBK00IDF6S4H5@firewall.mci.com> for ram@iab.org; Mon, 08 Jan 2007 16:50:28 +0000 (GMT) Received: from pmismtp05.wcomnet.com ([127.0.0.1]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JBK00LLN6S3LI@pmismtp05.mcilink.com> for ram@iab.org; Mon, 08 Jan 2007 16:50:27 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JBK00LB66S3IY@pmismtp05.mcilink.com> for ram@iab.org; Mon, 08 Jan 2007 16:50:27 +0000 (GMT) Date: Mon, 08 Jan 2007 16:50:27 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: ram@iab.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE References: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, 8 Jan 2007 JUAN-JOSE.ADAN@giss.seg-social.es wrote: > Noel, > > jnc@mercury.lcs.mit.edu (Noel Chiappa) escribi=F3 el 31/12/2006 16:52:33: > > > > Look, as far as I can work out, there are basically two classes of > solution > > to providing widespread multi-homing. > > > > The first is "let the routing do it". Alas, within the current routing > > architecture, that amounts to "forcing every router in the entire > > default-free zone to carry an advertisement for site X's PI-address", > which > > is widely seen (although not universally, q.v. that address registry > meeting > > where they approved the PI proposal) as non-workable. note that the RIR meeting (ARIN) in question there were several loud voices saying: "this is not a good plan", I think that either: 1) people refused to believe it was a problem 2) people didn't articulate that it was a problem properly 3) folks decided that to solve some immediate business problems they'd sacrifice longer term 'security' 4) folks really want to see ipv6 'deployed' and with some of the current stumbling blocks around ipv6 that isn't going to happen without some incentive for enterprises (pi space was seen as one incentive) (from a person at the meeting in question) > > IMHO the problem is not to force every router in the entire DFZ > to carry an advertisement for site X's PI-address. The real > problem is that it has to use it for routing, i.e. install it > in the RIB and download it in the FIB. Using some type of > hierarchy, DFZ routers could give up using PI addresses, > specifically those of non-transit AS-es. This seems to imply that there are only 2 types of AS's, there are in fact mixes of the 2. Not all Transit-AS's are 'just' transit, not all leaf-ASs are just leaves... With the current physical connectivity of the network there exists a need to have much more information about the network as a whole in more places than one realizes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 12:20:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yA8-0002lN-98; Mon, 08 Jan 2007 12:19:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3yA7-0002l8-IQ for ram@iab.org; Mon, 08 Jan 2007 12:19:55 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3x6L-0005US-PJ for ram@iab.org; Mon, 08 Jan 2007 11:11:58 -0500 Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2007 08:11:57 -0800 X-IronPort-AV: i="4.13,159,1167638400"; d="scan'208"; a="99200210:sNHT39485079" Received: from elear-mac.cisco.com ([10.61.80.227]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l08FsqCl031705; Mon, 8 Jan 2007 07:54:53 -0800 Message-ID: <45A26D4B.1070502@cisco.com> Date: Mon, 08 Jan 2007 17:11:55 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b1 (Macintosh/20061206) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? References: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> <45A26CAE.3010607@zurich.ibm.com> In-Reply-To: <45A26CAE.3010607@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=432; t=1168271694; x=1169135694; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20Should=20we=20provide=20protection=20 against=20time=09shifted=09attacks? |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=Pn8CEB0TJc2khM+iwM9kaYJtumf8zfPYqm7xKLxbyzs=; b=QXyiPD0jKMRttO6LO8IedkHAkIcRLKabsnv52t2dYg+3LwrAxF1LBeT2NdKysA0ClRZ4iWrd YgNPWrkrou92QtG5tX0CsTcDIH1ye3y8+OmqpEVeUqJiWvHYxMcgZEss; Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: > Well, it meets the "first, do no harm" principle, but people who > believe the Internet infrastructure is unacceptably insecure today > may not agree. Also, it seems hard to judge - if a new feature > introduces a qualitatively different threat, how can we assert > that it is not less secure? And are "we" the right people to make that decision (for some ISOC-related value of "we")? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 08 22:37:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47mH-0004od-PJ; Mon, 08 Jan 2007 22:35:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47mG-0004oX-EL for ram@iab.org; Mon, 08 Jan 2007 22:35:56 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47mB-0005LN-26 for ram@iab.org; Mon, 08 Jan 2007 22:35:56 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 9B55034079; Mon, 8 Jan 2007 22:35:54 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 22:35:50 -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: [RAM] Discovery Date: Mon, 8 Jan 2007 22:35:49 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0129A190@tayexc14.americas.cpqcorp.net> In-Reply-To: <20070107170718.1152F32F40@mailtrck.hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Discovery Thread-Index: Accyn7GIhWCrySQjRrmCaDex2yCHbwA/v0iw From: "Bound, Jim" To: "JFC Morfin" , "Roland Dobbins" , X-OriginalArrivalTime: 09 Jan 2007 03:35:50.0170 (UTC) FILETIME=[41E51FA0:01C7339F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org JFC,=20 > Jim, > Very interesting remark as permits to ask simply the very basic > question: in your mind should we bound to a single net=20 > centricity technology and implementation? > Thanks. > jfc Net Centricity principles do not require that tight of a bounding. What it does require is that all the principles can co-exist and operate (per the list below and some add others to the list). Thus it is fair to have multiple boundaries of technology solutions, but the core principles should be checked. It can be useful to the development models, architectures, paradigms, and implemented solutions is my view. Does that answer your question enough for now? Thanks /jim >=20 >=20 > At 05:42 03/01/2007, Bound, Jim wrote: >=20 > >Just for thinking there is a set of principles used by U.S. DOD and=20 > >NATO and others called net centricity. My reference to this work is=20 > >the computer science term and not applied with terms like=20 > net centric=20 > >warfare or net centric ops, but rather a set of pre-conditions to=20 > >achieve net centricity from models to implementations. But it is=20 > >beginning to permeate out of the classic military=20 > environment and the=20 > >core principles I extrapolate and test I use for any=20 > architecture and=20 > >for implementation are does the networking result provide:=20 > >connectivity, interoperability, security, discovery, QoS, and=20 > >end-to-end (meaning two peers can communicate without middle=20 > boxes and=20 > >packets could be encrypted so only the current IP header is in the=20 > >clear). The point of discovery is quite important as that=20 > is how the=20 > >network learns of parameters and information required. And=20 > does need=20 > >some thought while developing an architecture. If any of these=20 > >pre-conditions are missing above (and some add others as a note) net=20 > >centricity can be negatively impacted, including discovery. =20 > What the=20 > >answer is for our work here for discovery is entirely premature to=20 > >discuss (e.g. DNS, LDAP, UDDI, > >LDAP+UDDI, SLP, SOAP, etc). > > > >Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka > > > >Best, > >/jim > > > > > > > -----Original Message----- > > > From: Roland Dobbins [mailto:rdobbins@cisco.com] > > > Sent: Tuesday, January 02, 2007 11:21 PM > > > To: ram@iab.org > > > Subject: Re: [RAM] Destination Locator selection > > > > > > > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: > > > > > > > Putting the architecture discussion hat on only I would not > > > entirely > > > > agree given how we have been using the term 'namespace', > > > but I do see > > > > the concern and point. To find compromise I would suggest > > > we do need > > > > to be concerned about the principle of "discovery"=20 > within the new=20 > > > > architecture model. > > > > > > Thanks for the clarification; in this particular case it was a=20 > > > semantic issue, but one to which attention must be paid, lest > > > (further) confusion ensue. > > > > > > > > > -------------------------------------------------------------- > > > --------- > > > Roland Dobbins // 408.527.6376 voice > > > > > > All battles are perpetual. > > > > > > -- Milton Friedman > > > > > > > > > > > > > > > _______________________________________________ > > > RAM mailing list > > > RAM@iab.org > > > https://www1.ietf.org/mailman/listinfo/ram > > > > > > >_______________________________________________ > >RAM mailing list > >RAM@iab.org > >https://www1.ietf.org/mailman/listinfo/ram >=20 > =20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 07:33:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GA7-0001zl-PL; Tue, 09 Jan 2007 07:33:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4GA5-0001zY-RE for ram@iab.org; Tue, 09 Jan 2007 07:33:05 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4GA4-0005rT-7r for ram@iab.org; Tue, 09 Jan 2007 07:33:05 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 492F2CECD4; Tue, 9 Jan 2007 13:33:03 +0100 (CET) Received: from [163.117.203.137] (unknown [163.117.203.137]) by smtp02.uc3m.es (Postfix) with ESMTP id 71EDCCEC87; Tue, 9 Jan 2007 13:32:13 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? Date: Tue, 9 Jan 2007 13:32:40 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Ran, El 08/01/2007, a las 0:47, RJ Atkinson escribi=F3: > Marcelo, > > I know of practical "Time Shifted Attacks" for the currently > deployed IPv4 Internet. > > I also know of practical "3rd Party DoS Attacks" for the > currently deployed IPv4 Internet. > > If some RFC really asserts that none exist, then either > there was an editing error someplace or someone was confused. > interesting... as i mentioned before, the goal of both MIPv6 Route optimization design=20= and shim6 design was to not to introduce new vulnerabilities and in=20 both cases the community has considered that the time shifted attacks=20 were something new that was possible with MIP/shim6 if not properly=20 secured and that the resulting flooding attacks of a non properly=20 secured MIP/shim6 portocol would be much more dangerous than the ones=20 available today. however, it is possible that the assesment of the current situation and=20= current attacks was flawed and there was some current vulnerabilities=20 missing (as you say that such attacks are possible in the current=20 internet) If this is the case, and we agree that the goal in terms of security is=20= to not to introduce new vulnerabilities, then it would be ok to design=20= an ID/loc split approach that doesn't provide protection against this=20 type of attacks. Such solutions would be certainly simpler than the=20 ones resulting when we take in account the aforementioned attacks. SO imho determining the security level desired for the solution and=20 assessing the possible attacks in the current internet is a critical=20 point to design and evaluate different approaches for this. > Yours, > > Ran > > PS: I don't discuss mechanisms for active attacks on any deployed > network on any public mailing list -- except by way of citing > already published papers by other people. That's been my > policy for many years and won't be changing anytime soon. > i can certainly see merit in this attitude, but how do you suggest we=20 move forward, in particular how should be asses the current=20 vulnerabilties of the internet and we reach concensous on this point if=20= we do not discuss it on the ml?.... any suggestion? Regards, marcelo > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 09:23:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HsT-0007a1-2O; Tue, 09 Jan 2007 09:23:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4HsS-0007Xz-21 for ram@iab.org; Tue, 09 Jan 2007 09:23:00 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4HsO-0001zi-KD for ram@iab.org; Tue, 09 Jan 2007 09:22:59 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B2E00557DE; Tue, 9 Jan 2007 15:22:50 +0100 (CET) Received: from [163.117.139.53] (unknown [163.117.139.53]) by smtp03.uc3m.es (Postfix) with ESMTP id 4CA37557C4; Tue, 9 Jan 2007 15:22:50 +0100 (CET) In-Reply-To: References: <505CA249-2DB1-432D-9F20-FB654BC9CEDC@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <87f85e837e704cba4e04b98d585b1b13@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Re: Should we provide protection against time shifted attacks? Date: Tue, 9 Jan 2007 14:48:05 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org El 08/01/2007, a las 16:05, RJ Atkinson escribi=F3: > If we can live with that for MIPv6 (and I think the upper > bound for MIPv6 is hours not minutes, by the way), no, the upper limit for mipv6 is 7 minutes (this is the lifetime of the=20= BCE when it is secured using the RR check) AFAIK i can live with a solution that allows time shifted attacks of=20 minutes.... perhaps a bit more than 7 minutes, but i don't think we=20 should allow something like 10 hours... > then that same > level of risk ought to be completely acceptable for some other > approach, change, or enhancement for the Internet. > agree MIPv6 security level is appropriate >>> I also know of practical "3rd Party DoS Attacks" for the >>> currently deployed IPv4 Internet. >> >> Me too. >> >> But even so, do you think we should design new mechanism that we=20 >> know, at the design time, to embed new ways of launching such=20 >> attacks? > > I think that really is the wrong question. More secure > than at present is "nice to have" rather than "MUST". Further, > my own experience is that any sort of system that has increased > security will also become more brittle. There might be exceptions > to that principle, but I can't immediately think of any. For > example, requiring cryptographic authentication of some message > often creates a new (D)DOS vector.[1] > > The question ought to be is whether some new scheme or > enhancement is LESS SECURE than the currently deployed IPv4 Internet > or the currently deployed IPv6 Internet. As long as the new scheme > is NOT less secure, that ought to be sufficient. > i am ok with this mipv6 security level can be used as the minimum bar Regards, marcelo > Fundamentally, if folks think that the current risks are NOT > acceptable, then they ought to be criticising things like MIPv6 on > insecurity grounds and ought to be focusing on fixing the current > risks in the currently deployed Internet as their priority. > > Yours, > > Ran > > [1] Details of how the attack would work are deliberately omitted. > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 10:07:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IYp-00012L-AL; Tue, 09 Jan 2007 10:06:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IYo-00012G-GF for ram@iab.org; Tue, 09 Jan 2007 10:06:46 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4IYm-0005nq-Kh for ram@iab.org; Tue, 09 Jan 2007 10:06:46 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l09F6fGv157420 for ; Tue, 9 Jan 2007 15:06:41 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l09F6gJd1724492 for ; Tue, 9 Jan 2007 15:06:42 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l09F6f6l025428 for ; Tue, 9 Jan 2007 15:06:41 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l09F6fVj025416 for ; Tue, 9 Jan 2007 15:06:41 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA232696 for ; Tue, 9 Jan 2007 16:06:40 +0100 Message-ID: <45A3AF7F.5000104@zurich.ibm.com> Date: Tue, 09 Jan 2007 16:06:39 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [RAM] Thoughts about context-dependency of id/loc semantics (long) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It is well established that naming, addressing and routing are conceptually separate (or should be!) [IEN19, IEN48, RFC1498] are formative in this regard. For a long time, the view in the the IETF community was that DNS took care of naming, IP took care of addressing, and routing protocols took care of routing. As growth in the Internet accelerated, cracks appeared in this simplistic view [RFC2101, RFC2775]. Emerging issues such as multihoming, the need for sites to change ISPs, mobility, and end to end security have led to increasing perception that the "addressing" concept has two very distinct aspects: - identifying something - locating something It might be thought that "identifying something" is what a name does. But it turns out that 'example.com' (which in the original concept of DNS would have identified a specific interface on a specific computer) is in fact a virtual name that generally identifies a company called 'Example' and typically leads to a server pool (i.e. multiple computers). Here, we are not talking about that. We are talking about identifying network level entities - put simply, they could be individual TCP/IP stacks or they could be conglomerates generally known as "sites". The word "stack" was defined as the entity to be identified by the IRTF Namespace Research Group in an unpublished document (draft-irtf-nsrg-report) thus: " Today, a host may represent multiple entities. This happens when a service provider hosts many web sites on one server. Similarly, a single entity may be represented by multiple hosts. Replicated web servers are just such an example. These entities are "protocol stacks" or simply "stacks", instantiations of the TCP/IP model, be they across one or many hosts. A stack is defined as one participant or the process on one side of an end-to-end communication. That participant may move and may be represented by multiple hosts... Each instance of a stack has a name, a "stack name". At an architectural level the Name Space Research Group debated the value of such names, and their associated costs. Forms of this name are used in numerous places today. SSH uses public/private key pairs to identify end points. An HTTP cookie anonymously identifies one end of a communication, in such a manner that both the connection and the IP address of the other end point may change many times. Stack names are intended to identify mobile nodes, devices behind NATs, and participants in a content delivery or overlay network." To send a packet to a stack, we need its identity and we need to know where that identity is currently located. Today stack identity and stack location are both somehow combined in an IP address (whether it's IPv4 or IPv6 doesn't matter.) If a stack is identified as 10.1.2.3 we expect the routing system to treat this as a stack locator. Similarly, if a site is identified as 10/8, we expect the routing system to treat this as a site locator. But this example is deliberately a broken one - we know that address and that prefix are ambiguous, and have no global value either as identifiers or as locators. Yet within a given network using private addresses, 10.1.2.3 is a perfectly good stack identifier and locator, and 10.1.2/24 is a pefectly good subnet locator. What is going on here is an illustration of a much more general observation: an IP address, or an IP prefix (the high order bits of an address) can be a stack (or site) identifier, a locator, neither, or both simultaneously *depending on context*. To be specific: - inside a NATted site, 10.1.2.3 is a good stack ID and a good stack locator. outside the site, it becomes simply meaningless garbage bits. - if the site's NAT box has public address 192.0.2.1, then the stack identified internally could be identified externally as 192.0.2.1: and its locator would be 192.0.2.1. The mess here is that an IP address is no longer sufficient as a stack identifier, and of course the port number is only borrowed until the NAT decides to take it away. - if a site has a tunnelled connection to another site, it could be (for example) that 10.1.2.3 is a good identifier on both sites (because they have agreed administratively to divide 10/8 between them) but the locator, as far as site B is concerned, is 192.0.2.77 (because that happens to be the tunnel address in the B to A direction). But for anyone else on the Internet, 192.0.2.77 is meaningless. We could give more examples, and give IPv6 examples. But the conclusion is inescapable: whether an IP address is an identifier, a locator, both, or neither depends on context, and not on the syntax or semantics of the address itself. Exactly the same applies to prefixes. The question that this leads to is whether the simple notion of "locator/identifier split" is actually meaningful. Is this context-dependence of the semantics of an IP address an accident due to slow drift in the Internet's architecture, or is it actually a desirable property of the namespace for IP stacks? To answer this, we need to identify the properties required for a stack identifier namespace and those for a stack locator namespace. If the required properties turn out to be orthogonal, a simple split may be possible; if they turn out to be inseparable, a simple split may be impossible, and the context-dependency mentioned above may be inevitable. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 10:49:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JDq-0003o7-Cx; Tue, 09 Jan 2007 10:49:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JDp-0003mG-5n for ram@iab.org; Tue, 09 Jan 2007 10:49:09 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JDe-0002vL-LS for ram@iab.org; Tue, 09 Jan 2007 10:49:09 -0500 Received: from i03m-212-195-38-17.d4.club-internet.fr ([212.195.38.17] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H4JDc-0001b0-Ki for ram@iab.org; Tue, 09 Jan 2007 07:48:57 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Jan 2007 16:33:56 +0100 To: "Bound, Jim" ,"Roland Dobbins" , From: JFCM Subject: RE: [RAM] Discovery In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0129A190@tayexc14.americas .cpqcorp.net> References: <20070107170718.1152F32F40@mailtrck.hp.com> <816DD9299957E547B5D758D7F977D6DC0129A190@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618462403==" Errors-To: ram-bounces@iab.org Message-Id: --===============1618462403== Content-Type: multipart/alternative; boundary="----MTuycftzmapuxnrztsxztuajibugwxbxym" ------MTuycftzmapuxnrztsxztuajibugwxbxym Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2F1E2C5B At 04:35 09/01/2007, Bound, Jim wrote: >JFC, > > Jim, > > Very interesting remark as permits to ask simply the very basic > > question: in your mind should we bound to a single net > > centricity technology and implementation? > > Thanks. > > jfc > >Net Centricity principles do not require that tight of a bounding. What >it does require is that all the principles can co-exist and operate (per >the list below and some add others to the list). Thus it is fair to >have multiple boundaries of technology solutions, but the core >principles should be checked. It can be useful to the development >models, architectures, paradigms, and implemented solutions is my view. > >Does that answer your question enough for now? Dear Jim, thank you for your answer. I try to understand applied net centricity through practical standardisation examples: JTC1/SG32/WG2 and other works on ontologies and metadata propositions. As usual I observe the same "confusion" (or documented lack of/planned work) between the common Internet layer and my interest in the relational spaces layer (the networks of the network of networks). I feel that net centricity is the correct area where to address this confusion which opposes me to most of the IETF. But I feel that we still miss the necessary thinking to fully do that. This is because I think it calls for "multicentricity" aspects which have not been investigated yet (but I may be wrong). Questions are : (1) is there a single net centricity "technology" (may be not the best term to be used but it seems accurate - not in terms equipment and hardware, but in term of metatechnology to document technologies) (2) or the need of a multicentricity open technology permitting a wide variety of interoperable implementations of the net centricity concept. To try to understand that I consider net centricty as the _degree_ of pertinent usefulness in describing a network system (permitting discovery, QoS, interconnectivity, etc.). It therefore permits to measure the tightness of the bounding between a network implementation and its description. - the more the description is usuefull the easier the discovery, interconnectivity, etc. - two networks may have the same lose description and their interconnection not to scale because their more precise descriptions differ. I also observe that the current descriptive "technology" is hierarchy oriented. This means that the documented models have a root or can be associated in bouquet. But forests are not easy to document. Lateral relations are not really considered as such (but I may have not read the proper documents). I feel that these lateral relations are precisely where "addresses" have a great role to play and call for multi orthogonal numbering plans of addresses. This can be true at every level (machine interconnectivty, software binary and semantic interoperability, people interintelligibility). The opposition I met about Multilingualism is a good example of that misunderstanding: a language (as everything) is first an address - where its concepts are documented, or a conditional interlink chains a documentation. Internet net centricity is documented in values and in texts. There is no problem with values, but there is one with texts as they are documented in one given language. However, even if it was documented in every language, I am not sure that a net centricity based upon the sole current internet experience can document every relational space. What if the description of a network systems calls on concepts ignored by the Internet technology. This is a complex issue. I am working on a paper reviewing the practical axis of effort (fixity, virtuality, mobility, intinerary, multicentricty) approached by this mailing list. This is why I am interested by inputs. Thank you. jfc >Thanks >/jim > > > > > > > At 05:42 03/01/2007, Bound, Jim wrote: > > > > >Just for thinking there is a set of principles used by U.S. DOD and > > >NATO and others called net centricity. My reference to this work is > > >the computer science term and not applied with terms like > > net centric > > >warfare or net centric ops, but rather a set of pre-conditions to > > >achieve net centricity from models to implementations. But it is > > >beginning to permeate out of the classic military > > environment and the > > >core principles I extrapolate and test I use for any > > architecture and > > >for implementation are does the networking result provide: > > >connectivity, interoperability, security, discovery, QoS, and > > >end-to-end (meaning two peers can communicate without middle > > boxes and > > >packets could be encrypted so only the current IP header is in the > > >clear). The point of discovery is quite important as that > > is how the > > >network learns of parameters and information required. And > > does need > > >some thought while developing an architecture. If any of these > > >pre-conditions are missing above (and some add others as a note) net > > >centricity can be negatively impacted, including discovery. > > What the > > >answer is for our work here for discovery is entirely premature to > > >discuss (e.g. DNS, LDAP, UDDI, > > >LDAP+UDDI, SLP, SOAP, etc). > > > > > >Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka > > > > > >Best, > > >/jim > > > > > > > > > > -----Original Message----- > > > > From: Roland Dobbins [mailto:rdobbins@cisco.com] > > > > Sent: Tuesday, January 02, 2007 11:21 PM > > > > To: ram@iab.org > > > > Subject: Re: [RAM] Destination Locator selection > > > > > > > > > > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: > > > > > > > > > Putting the architecture discussion hat on only I would not > > > > entirely > > > > > agree given how we have been using the term 'namespace', > > > > but I do see > > > > > the concern and point. To find compromise I would suggest > > > > we do need > > > > > to be concerned about the principle of "discovery" > > within the new > > > > > architecture model. > > > > > > > > Thanks for the clarification; in this particular case it was a > > > > semantic issue, but one to which attention must be paid, lest > > > > (further) confusion ensue. > > > > > > > > > > > > -------------------------------------------------------------- > > > > --------- > > > > Roland Dobbins // 408.527.6376 voice > > > > > > > > All battles are perpetual. > > > > > > > > -- Milton Friedman > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > RAM mailing list > > > > RAM@iab.org > > > > https://www1.ietf.org/mailman/listinfo/ram > > > > > > > > > >_______________________________________________ > > >RAM mailing list > > >RAM@iab.org > > >https://www1.ietf.org/mailman/listinfo/ram > > > > > > ------MTuycftzmapuxnrztsxztuajibugwxbxym Content-Type: text/html At 04:35 09/01/2007, Bound, Jim wrote:

>JFC,
> > Jim,
> > Very interesting remark as permits to ask simply the very basic
> > question: in your mind should we bound to a single net
> > centricity technology and implementation?
> > Thanks.
> > jfc
>
>Net Centricity principles do not require that tight of a bounding. What
>it does require is that all the principles can co-exist and operate (per
>the list below and some add others to the list).  Thus it is fair to
>have multiple boundaries of technology solutions, but the core
>principles should be checked.  It can be useful to the development
>models, architectures, paradigms, and implemented solutions is my view.
>
>Does that answer your question enough for now?

Dear Jim,
thank you for your answer. I try to understand applied net centricity
through practical standardisation examples: JTC1/SG32/WG2 and other
works on ontologies and metadata propositions. As usual I observe the
same "confusion" (or documented lack of/planned work) between the
common Internet layer and my interest in the relational spaces layer
(the networks of the network of networks).

I feel that net centricity is the correct area where to address this
confusion which opposes me to most of the IETF. But I feel that we
still miss the necessary thinking to fully do that. This is because I
think it calls for "multicentricity" aspects which have not been
investigated yet (but I may be wrong). Questions are :
(1) is there a single net centricity "technology" (may be not the
best term to be used but it seems accurate - not in terms equipment
and hardware, but in term of metatechnology to document technologies)
(2) or the need of a multicentricity open technology permitting a
wide variety of interoperable implementations of the net centricity concept.

To try to understand that I consider net centricty as the _degree_ of
pertinent usefulness in describing a network system (permitting
discovery, QoS, interconnectivity, etc.). It therefore permits to
measure the tightness of the bounding between a network
implementation and its description.

- the more the description is usuefull the easier the discovery,
interconnectivity, etc.
- two networks may have the same lose description and their
interconnection not to scale because their more precise descriptions differ.

I also observe that the current descriptive "technology" is hierarchy
oriented. This means that the documented models have a root or can be
associated in bouquet. But forests are not easy to document. Lateral
relations are not really considered as such (but I may have not read
the proper documents). I feel that these lateral relations are
precisely where "addresses" have a great role to play and call for
multi orthogonal numbering plans of addresses. This can be true at
every level (machine interconnectivty, software binary and semantic
interoperability, people interintelligibility).

The opposition I met about Multilingualism is a good example of that
misunderstanding: a language (as everything) is first an address -
where its concepts are documented, or a conditional interlink chains
a documentation. Internet net centricity is documented in values and
in texts. There is no problem with values, but there is one with
texts as they are documented in one given language. However, even if
it was documented in every language, I am not sure that a net
centricity based upon the sole current internet experience can
document every relational space. What if the description of a network
systems calls on concepts ignored by the Internet technology.

This is a complex issue. I am working on a paper reviewing the
practical axis of effort (fixity, virtuality, mobility, intinerary,
multicentricty) approached by this mailing list. This is why I am
interested by inputs.

Thank you.
jfc







>Thanks
>/jim
>
> >
> >
> > At 05:42 03/01/2007, Bound, Jim wrote:
> >
> > >Just for thinking there is a set of principles used by U.S. DOD and
> > >NATO and others called net centricity.  My reference to this work is
> > >the computer science term and not applied with terms like
> > net centric
> > >warfare or net centric ops, but rather a set of pre-conditions to
> > >achieve net centricity from models to implementations.  But it is
> > >beginning to permeate out of the classic military
> > environment and the
> > >core principles I extrapolate and test I use for any
> > architecture and
> > >for implementation are does the networking result provide:
> > >connectivity, interoperability, security, discovery, QoS, and
> > >end-to-end (meaning two peers can communicate without middle
> > boxes and
> > >packets could be encrypted so only the current IP header is in the
> > >clear).  The point of discovery is quite important as that
> > is how the
> > >network learns of parameters and information required.  And
> > does need
> > >some thought while developing an architecture. If any of these
> > >pre-conditions are missing above (and some add others as a note) net
> > >centricity can be negatively impacted, including discovery.
> > What the
> > >answer is for our work here for discovery is entirely premature to
> > >discuss (e.g. DNS, LDAP, UDDI,
> > >LDAP+UDDI, SLP, SOAP, etc).
> > >
> > >Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka
> > >
> > >Best,
> > >/jim
> > >
> > >
> > > > -----Original Message-----
> > > > From: Roland Dobbins [mailto:rdobbins@cisco.com]
> > > > Sent: Tuesday, January 02, 2007 11:21 PM
> > > > To: ram@iab.org
> > > > Subject: Re: [RAM] Destination Locator selection
> > > >
> > > >
> > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote:
> > > >
> > > > > Putting the architecture discussion hat on only I would not
> > > > entirely
> > > > > agree given how we have been using the term 'namespace',
> > > > but I do see
> > > > > the concern and point.  To find compromise I would suggest
> > > > we do need
> > > > > to be concerned about the principle of "discovery"
> > within the new
> > > > > architecture model.
> > > >
> > > > Thanks for the clarification; in this particular case it was a
> > > > semantic issue, but one to which attention must be paid, lest
> > > > (further) confusion ensue.
> > > >
> > > >
> > > > --------------------------------------------------------------
> > > > ---------
> > > > Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice
> > > >
> > > >               All battles are perpetual.
> > > >
> > > >                  -- Milton Friedman
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > RAM mailing list
> > > > RAM@iab.org
> > > > https://www1.ietf.org/mailman/listinfo/ram
> > > >
> > >
> > >_______________________________________________
> > >RAM mailing list
> > >RAM@iab.org
> > >https://www1.ietf.org/mailman/listinfo/ram
> >
> >   <http://i.msgtag.com/anl/ogdEEgutbu/eetv/foty/Ch/pybmCsasq.gif>;
> >

------MTuycftzmapuxnrztsxztuajibugwxbxym-- --===============1618462403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1618462403==-- From ram-bounces@iab.org Tue Jan 09 15:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NhG-0001gi-6q; Tue, 09 Jan 2007 15:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NhE-0001gL-6I for ram@iab.org; Tue, 09 Jan 2007 15:35:48 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Nh8-0000ZN-Og for ram@iab.org; Tue, 09 Jan 2007 15:35:48 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 93D24340BD; Tue, 9 Jan 2007 15:35:45 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 15:35:39 -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: [RAM] Thoughts about context-dependency of id/loc semantics (long) Date: Tue, 9 Jan 2007 15:35:38 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC012DA9E2@tayexc14.americas.cpqcorp.net> In-Reply-To: <45A3AF7F.5000104@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Thoughts about context-dependency of id/loc semantics (long) Thread-Index: Accz/9ZH/ko9maNLSHaw+beiaCljBgALcTcw From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 09 Jan 2007 20:35:39.0888 (UTC) FILETIME=[B9CF1F00:01C7342D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian, excellent analysis. I feel we need to answer your question below before we go much further down the path here.=20 Thank You, /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Tuesday, January 09, 2007 10:07 AM > To: ram@iab.org > Subject: [RAM] Thoughts about context-dependency of id/loc=20 > semantics (long) >=20 > It is well established that naming, addressing and routing=20 > are conceptually separate (or should be!) [IEN19, IEN48,=20 > RFC1498] are formative in this regard. > For a long time, the view in the the IETF community was that=20 > DNS took care of naming, IP took care of addressing, and=20 > routing protocols took care of routing. As growth in the=20 > Internet accelerated, cracks appeared in this simplistic view=20 > [RFC2101, RFC2775]. >=20 > Emerging issues such as multihoming, the need for sites to=20 > change ISPs, mobility, and end to end security have led to=20 > increasing perception that the "addressing" concept has two=20 > very distinct aspects: >=20 > - identifying something > - locating something >=20 > It might be thought that "identifying something" is what a name does. > But it turns out that 'example.com' (which in the original=20 > concept of DNS would have identified a specific interface on=20 > a specific > computer) is in fact a virtual name that generally identifies=20 > a company called 'Example' and typically leads to a server=20 > pool (i.e. multiple computers). Here, we are not talking about that. > We are talking about identifying network level entities - put=20 > simply, they could be individual TCP/IP stacks or they could=20 > be conglomerates generally known as "sites". >=20 > The word "stack" was defined as the entity to be identified=20 > by the IRTF Namespace Research Group in an unpublished document > (draft-irtf-nsrg-report) thus: >=20 > " Today, a host may represent multiple entities. This happens when a > service provider hosts many web sites on one server. Similarly, a > single entity may be represented by multiple hosts. =20 > Replicated web > servers are just such an example. These entities are "protocol > stacks" or simply "stacks", instantiations of the TCP/IP model, be > they across one or many hosts. A stack is defined as one > participant or the process on one side of an end-to-end > communication. That participant may move and may be=20 > represented by > multiple hosts... >=20 > Each instance of a stack has a name, a "stack name". At an > architectural level the Name Space Research Group debated=20 > the value > of such names, and their associated costs. Forms of this name are > used in numerous places today. SSH uses public/private=20 > key pairs to > identify end points. An HTTP cookie anonymously=20 > identifies one end > of a communication, in such a manner that both the=20 > connection and the > IP address of the other end point may change many times. =20 > Stack names > are intended to identify mobile nodes, devices behind NATs, and > participants in a content delivery or overlay network." >=20 > To send a packet to a stack, we need its identity and we need=20 > to know where that identity is currently located. Today stack=20 > identity and stack location are both somehow combined in an=20 > IP address (whether it's > IPv4 or IPv6 doesn't matter.) If a stack is identified as > 10.1.2.3 we expect the routing system to treat this as a=20 > stack locator. > Similarly, if a site is identified as 10/8, we expect the=20 > routing system to treat this as a site locator. But this=20 > example is deliberately a broken one - we know that address=20 > and that prefix are ambiguous, and have no global value=20 > either as identifiers or as locators. Yet within a given=20 > network using private addresses, 10.1.2.3 is a perfectly good=20 > stack identifier and locator, and 10.1.2/24 is a pefectly=20 > good subnet locator. >=20 > What is going on here is an illustration of a much more general > observation: an IP address, or an IP prefix (the high order=20 > bits of an address) can be a stack (or site) identifier, a=20 > locator, neither, or both simultaneously *depending on context*. >=20 > To be specific: >=20 > - inside a NATted site, 10.1.2.3 is a good stack ID and a=20 > good stack locator. > outside the site, it becomes simply meaningless garbage bits. >=20 > - if the site's NAT box has public address 192.0.2.1, then=20 > the stack identified internally could be identified=20 > externally as 192.0.2.1: and its locator=20 > would be 192.0.2.1. > The mess here is that an IP address is no longer sufficient=20 > as a stack identifier, and of course the port number is only=20 > borrowed until the NAT decides to take it away. >=20 > - if a site has a tunnelled connection to another site, it=20 > could be (for example) that 10.1.2.3 is a good identifier on=20 > both sites (because they have agreed administratively to=20 > divide 10/8 between them) but the locator, as far as site B=20 > is concerned, is 192.0.2.77 (because that happens to be the=20 > tunnel address in the B to A direction). But for anyone else=20 > on the Internet, 192.0.2.77 is meaningless. >=20 > We could give more examples, and give IPv6 examples. But the=20 > conclusion is inescapable: whether an IP address is an=20 > identifier, a locator, both, or neither depends on context,=20 > and not on the syntax or semantics of the address itself.=20 > Exactly the same applies to prefixes. >=20 > The question that this leads to is whether the simple notion=20 > of "locator/identifier split" is actually meaningful. Is this=20 > context-dependence of the semantics of an IP address an=20 > accident due to slow drift in the Internet's architecture, or=20 > is it actually a desirable property of the namespace for IP stacks? >=20 > To answer this, we need to identify the properties required=20 > for a stack identifier namespace and those for a stack=20 > locator namespace. If the required properties turn out to be=20 > orthogonal, a simple split may be possible; if they turn out=20 > to be inseparable, a simple split may be impossible, and the=20 > context-dependency mentioned above may be inevitable. >=20 > Brian >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 15:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NzS-0003O7-Sn; Tue, 09 Jan 2007 15:54:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4NzR-0003NP-Iu for ram@iab.org; Tue, 09 Jan 2007 15:54:37 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4NzJ-0004sP-SZ for ram@iab.org; Tue, 09 Jan 2007 15:54:37 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 7DE9A340B7; Tue, 9 Jan 2007 15:54:34 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 15:54: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: [RAM] Discovery Date: Tue, 9 Jan 2007 15:54:26 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC012DAA07@tayexc14.americas.cpqcorp.net> In-Reply-To: <20070109155031.D1F1E32E3D@atarelrim03.atl.hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Discovery Thread-Index: Acc0BawleRRO7cEhQa2MVrTTNtN1dwAKR3FQ From: "Bound, Jim" To: "JFCM" , "Roland Dobbins" , X-OriginalArrivalTime: 09 Jan 2007 20:54:29.0038 (UTC) FILETIME=[5AD5BCE0:01C73430] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org JFC, =20 Going to go offline with you as I think we may be going a bit astray off topic (and we are going to get yelled at soon :--)) (rightly so).. Maybe when we get done we can apply some input to IETF RAM work succintly. My sole point was to identify discovery not in terms we think today but from a broader view just suggesting when we get a model built then is DNS the answer to discover identifiers. The principles of net centricity were my one way of justifying that we do need to work on discovery to Roland within a network. As I just said in an email I think we need to answer as work item Brian's last mail at least that is my input to the mail list. There is not much point in discovery if we don't have what is to be discoverd nailed down in RAM :--). Look forward to further analysis on xxx-net-centricity, and quite a task you have taken on for your paper be glad to share my view with you. I think your result will be quite informative to a few technology players working this space I can think of for sure. =20 NB: If others find this topic interesting send mail to JFC and I to participate in the offline discussion. =20 Thanks, /jim ________________________________ From: JFCM [mailto:jefsey@jefsey.com]=20 Sent: Tuesday, January 09, 2007 10:34 AM To: Bound, Jim; Roland Dobbins; ram@iab.org Subject: RE: [RAM] Discovery=20 =09 =09 At 04:35 09/01/2007, Bound, Jim wrote: =09 >JFC, > > Jim, > > Very interesting remark as permits to ask simply the very basic > > question: in your mind should we bound to a single net > > centricity technology and implementation? > > Thanks. > > jfc > >Net Centricity principles do not require that tight of a bounding. What >it does require is that all the principles can co-exist and operate (per >the list below and some add others to the list). Thus it is fair to >have multiple boundaries of technology solutions, but the core >principles should be checked. It can be useful to the development >models, architectures, paradigms, and implemented solutions is my view. > >Does that answer your question enough for now? =09 Dear Jim, thank you for your answer. I try to understand applied net centricity=20 through practical standardisation examples: JTC1/SG32/WG2 and other=20 works on ontologies and metadata propositions. As usual I observe the=20 same "confusion" (or documented lack of/planned work) between the=20 common Internet layer and my interest in the relational spaces layer=20 (the networks of the network of networks). =09 I feel that net centricity is the correct area where to address this=20 confusion which opposes me to most of the IETF. But I feel that we=20 still miss the necessary thinking to fully do that. This is because I=20 think it calls for "multicentricity" aspects which have not been investigated yet (but I may be wrong). Questions are : (1) is there a single net centricity "technology" (may be not the=20 best term to be used but it seems accurate - not in terms equipment=20 and hardware, but in term of metatechnology to document technologies) (2) or the need of a multicentricity open technology permitting a=20 wide variety of interoperable implementations of the net centricity concept. =09 To try to understand that I consider net centricty as the _degree_ of=20 pertinent usefulness in describing a network system (permitting=20 discovery, QoS, interconnectivity, etc.). It therefore permits to=20 measure the tightness of the bounding between a network=20 implementation and its description. =09 - the more the description is usuefull the easier the discovery, interconnectivity, etc. - two networks may have the same lose description and their=20 interconnection not to scale because their more precise descriptions differ. =09 I also observe that the current descriptive "technology" is hierarchy=20 oriented. This means that the documented models have a root or can be=20 associated in bouquet. But forests are not easy to document. Lateral=20 relations are not really considered as such (but I may have not read=20 the proper documents). I feel that these lateral relations are=20 precisely where "addresses" have a great role to play and call for=20 multi orthogonal numbering plans of addresses. This can be true at=20 every level (machine interconnectivty, software binary and semantic=20 interoperability, people interintelligibility). =09 The opposition I met about Multilingualism is a good example of that=20 misunderstanding: a language (as everything) is first an address -=20 where its concepts are documented, or a conditional interlink chains=20 a documentation. Internet net centricity is documented in values and=20 in texts. There is no problem with values, but there is one with texts as they are documented in one given language. However, even if=20 it was documented in every language, I am not sure that a net=20 centricity based upon the sole current internet experience can=20 document every relational space. What if the description of a network=20 systems calls on concepts ignored by the Internet technology. =09 This is a complex issue. I am working on a paper reviewing the=20 practical axis of effort (fixity, virtuality, mobility, intinerary,=20 multicentricty) approached by this mailing list. This is why I am=20 interested by inputs. =09 Thank you. jfc =09 =09 =09 =09 =09 =09 =09 >Thanks >/jim > > > > > > > At 05:42 03/01/2007, Bound, Jim wrote: > > > > >Just for thinking there is a set of principles used by U.S. DOD and > > >NATO and others called net centricity. My reference to this work is > > >the computer science term and not applied with terms like > > net centric > > >warfare or net centric ops, but rather a set of pre-conditions to > > >achieve net centricity from models to implementations. But it is > > >beginning to permeate out of the classic military > > environment and the > > >core principles I extrapolate and test I use for any > > architecture and > > >for implementation are does the networking result provide: > > >connectivity, interoperability, security, discovery, QoS, and > > >end-to-end (meaning two peers can communicate without middle > > boxes and > > >packets could be encrypted so only the current IP header is in the > > >clear). The point of discovery is quite important as that > > is how the > > >network learns of parameters and information required. And > > does need > > >some thought while developing an architecture. If any of these > > >pre-conditions are missing above (and some add others as a note) net > > >centricity can be negatively impacted, including discovery. > > What the > > >answer is for our work here for discovery is entirely premature to > > >discuss (e.g. DNS, LDAP, UDDI, > > >LDAP+UDDI, SLP, SOAP, etc). > > > > > >Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka > > > > > >Best, > > >/jim > > > > > > > > > > -----Original Message----- > > > > From: Roland Dobbins [mailto:rdobbins@cisco.com] > > > > Sent: Tuesday, January 02, 2007 11:21 PM > > > > To: ram@iab.org > > > > Subject: Re: [RAM] Destination Locator selection > > > > > > > > > > > > On Jan 2, 2007, at 8:17 PM, Bound, Jim wrote: > > > > > > > > > Putting the architecture discussion hat on only I would not > > > > entirely > > > > > agree given how we have been using the term 'namespace', > > > > but I do see > > > > > the concern and point. To find compromise I would suggest > > > > we do need > > > > > to be concerned about the principle of "discovery" > > within the new > > > > > architecture model. > > > > > > > > Thanks for the clarification; in this particular case it was a > > > > semantic issue, but one to which attention must be paid, lest > > > > (further) confusion ensue. > > > > > > > > > > > > -------------------------------------------------------------- > > > > --------- > > > > Roland Dobbins // 408.527.6376 voice > > > > > > > > All battles are perpetual. > > > > > > > > -- Milton Friedman > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > RAM mailing list > > > > RAM@iab.org > > > > https://www1.ietf.org/mailman/listinfo/ram > > > > > > > > > >_______________________________________________ > > >RAM mailing list > > >RAM@iab.org > > >https://www1.ietf.org/mailman/listinfo/ram > > > > ; > > =09 =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 09 20:02:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4RqX-0006Ci-W2; Tue, 09 Jan 2007 20:01:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4RqW-0006CD-OM for ram@iab.org; Tue, 09 Jan 2007 20:01:40 -0500 Received: from web58710.mail.re1.yahoo.com ([66.196.100.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4RqV-0002yL-B1 for ram@iab.org; Tue, 09 Jan 2007 20:01:40 -0500 Received: (qmail 27793 invoked by uid 60001); 10 Jan 2007 01:01:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=n6GKmdjn/Xwe97qk+mlp7+CsYYqzyqpuenpFqXjWPUnAr05spf3ij5ZltXqWrPOMXWqM5uZRlGX7xNsQepnVgTMieY4XrLIzHeOAeqOgCNpmLL/14GxwfiN/MYVSmjHFwgmjR92Nz4okBxJFF6tIplgKTTZ3SOrsH01zPK0T/fg=; X-YMail-OSG: dXo5.o0VM1mU3iyA8JPW8xDGVfZlrHmbHF2s0vHY Received: from [74.111.124.141] by web58710.mail.re1.yahoo.com via HTTP; Tue, 09 Jan 2007 17:01:38 PST Date: Tue, 9 Jan 2007 17:01:38 -0800 (PST) From: Peter Sherbin Subject: RE: [RAM] Thoughts about context-dependency of id/loc semantics (long) To: Brian E Carpenter , ram@iab.org In-Reply-To: <816DD9299957E547B5D758D7F977D6DC012DA9E2@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <44261.27457.qm@web58710.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > an IP address... can be a... identifier, a locator, neither, or both *depending on > context*. A name tells what the thing is. A name is a quality of the thing. A location tells where the thing is. A location is a quality outside of the thing. Hence an IP address can be an identifier, a locator or neither. An IP address can not be both regardless of the context. > The question... is whether the simple notion of "locator/identifier split" is actually meaningful. Such split would be natural. Any attempt to combine both is meaningless. > Is this context-dependence of the semantics of an IP address an accident..., or is > it actually a desirable property of the namespace for IP stacks? IP address semantics matter as long as the unrelated mean serves the purpose. Sound architecture would follow natural relationships. Thanks, Peter > > -----Original Message----- > > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > > Sent: Tuesday, January 09, 2007 10:07 AM > > To: ram@iab.org > > Subject: [RAM] Thoughts about context-dependency of id/loc > > semantics (long) > > > > It is well established that naming, addressing and routing > > are conceptually separate (or should be!) [IEN19, IEN48, > > RFC1498] are formative in this regard. > > For a long time, the view in the the IETF community was that > > DNS took care of naming, IP took care of addressing, and > > routing protocols took care of routing. As growth in the > > Internet accelerated, cracks appeared in this simplistic view > > [RFC2101, RFC2775]. > > > > Emerging issues such as multihoming, the need for sites to > > change ISPs, mobility, and end to end security have led to > > increasing perception that the "addressing" concept has two > > very distinct aspects: > > > > - identifying something > > - locating something > > > > It might be thought that "identifying something" is what a name does. > > But it turns out that 'example.com' (which in the original > > concept of DNS would have identified a specific interface on > > a specific > > computer) is in fact a virtual name that generally identifies > > a company called 'Example' and typically leads to a server > > pool (i.e. multiple computers). Here, we are not talking about that. > > We are talking about identifying network level entities - put > > simply, they could be individual TCP/IP stacks or they could > > be conglomerates generally known as "sites". > > > > The word "stack" was defined as the entity to be identified > > by the IRTF Namespace Research Group in an unpublished document > > (draft-irtf-nsrg-report) thus: > > > > " Today, a host may represent multiple entities. This happens when a > > service provider hosts many web sites on one server. Similarly, a > > single entity may be represented by multiple hosts. > > Replicated web > > servers are just such an example. These entities are "protocol > > stacks" or simply "stacks", instantiations of the TCP/IP model, be > > they across one or many hosts. A stack is defined as one > > participant or the process on one side of an end-to-end > > communication. That participant may move and may be > > represented by > > multiple hosts... > > > > Each instance of a stack has a name, a "stack name". At an > > architectural level the Name Space Research Group debated > > the value > > of such names, and their associated costs. Forms of this name are > > used in numerous places today. SSH uses public/private > > key pairs to > > identify end points. An HTTP cookie anonymously > > identifies one end > > of a communication, in such a manner that both the > > connection and the > > IP address of the other end point may change many times. > > Stack names > > are intended to identify mobile nodes, devices behind NATs, and > > participants in a content delivery or overlay network." > > > > To send a packet to a stack, we need its identity and we need > > to know where that identity is currently located. Today stack > > identity and stack location are both somehow combined in an > > IP address (whether it's > > IPv4 or IPv6 doesn't matter.) If a stack is identified as > > 10.1.2.3 we expect the routing system to treat this as a > > stack locator. > > Similarly, if a site is identified as 10/8, we expect the > > routing system to treat this as a site locator. But this > > example is deliberately a broken one - we know that address > > and that prefix are ambiguous, and have no global value > > either as identifiers or as locators. Yet within a given > > network using private addresses, 10.1.2.3 is a perfectly good > > stack identifier and locator, and 10.1.2/24 is a pefectly > > good subnet locator. > > > > What is going on here is an illustration of a much more general > > observation: an IP address, or an IP prefix (the high order > > bits of an address) can be a stack (or site) identifier, a > > locator, neither, or both simultaneously *depending on context*. > > > > To be specific: > > > > - inside a NATted site, 10.1.2.3 is a good stack ID and a > > good stack locator. > > outside the site, it becomes simply meaningless garbage bits. > > > > - if the site's NAT box has public address 192.0.2.1, then > > the stack identified internally could be identified > > externally as 192.0.2.1: and its locator > > would be 192.0.2.1. > > The mess here is that an IP address is no longer sufficient > > as a stack identifier, and of course the port number is only > > borrowed until the NAT decides to take it away. > > > > - if a site has a tunnelled connection to another site, it > > could be (for example) that 10.1.2.3 is a good identifier on > > both sites (because they have agreed administratively to > > divide 10/8 between them) but the locator, as far as site B > > is concerned, is 192.0.2.77 (because that happens to be the > > tunnel address in the B to A direction). But for anyone else > > on the Internet, 192.0.2.77 is meaningless. > > > > We could give more examples, and give IPv6 examples. But the > > conclusion is inescapable: whether an IP address is an > > identifier, a locator, both, or neither depends on context, > > and not on the syntax or semantics of the address itself. > > Exactly the same applies to prefixes. > > > > The question that this leads to is whether the simple notion > > of "locator/identifier split" is actually meaningful. Is this > > context-dependence of the semantics of an IP address an > > accident due to slow drift in the Internet's architecture, or > > is it actually a desirable property of the namespace for IP stacks? > > > > To answer this, we need to identify the properties required > > for a stack identifier namespace and those for a stack > > locator namespace. If the required properties turn out to be > > orthogonal, a simple split may be possible; if they turn out > > to be inseparable, a simple split may be impossible, and the > > context-dependency mentioned above may be inevitable. > > > > Brian > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 10 10:02:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ex7-0002WD-Ir; Wed, 10 Jan 2007 10:01:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ex7-0002W5-3t for ram@iab.org; Wed, 10 Jan 2007 10:01:21 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4ex3-0004LJ-OU for ram@iab.org; Wed, 10 Jan 2007 10:01:21 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l0AF1Hpt016106 for ; Wed, 10 Jan 2007 07:01:17 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l0AF1HnG016105 for ram@iab.org; Wed, 10 Jan 2007 07:01:17 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 10 Jan 2007 07:01:17 -0800 From: David Meyer To: ram@iab.org Message-ID: <20070110150117.GA16098@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [RAM] test, please ignore X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145268678==" Errors-To: ram-bounces@iab.org --===============0145268678== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline test message --dmm --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFpP+9ORgD1qCZ2KcRAqePAJ0SFkSSZPTuJOBWekmg92kjshUMuACdGp/r mX9sEfak9AHELiOL5Vv2BOg= =FvFN -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- --===============0145268678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0145268678==-- From ram-bounces@iab.org Wed Jan 10 11:25:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gGZ-0002iu-W0; Wed, 10 Jan 2007 11:25:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gGY-0002h1-Sk for ram@iab.org; Wed, 10 Jan 2007 11:25:30 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4gGR-0007ZC-S8 for ram@iab.org; Wed, 10 Jan 2007 11:25:30 -0500 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0AGPDb18151; Wed, 10 Jan 2007 11:25:13 -0500 (EST) 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: [RAM] Thoughts about context-dependency of id/loc semantics (long) Date: Wed, 10 Jan 2007 11:25:04 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40CCE97D2@zrtphxm2.corp.nortel.com> In-Reply-To: <45A3AF7F.5000104@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Thoughts about context-dependency of id/loc semantics (long) Thread-Index: Accz/90RJGYiO3EpR2i7TZPCQ5LSAAA06zqw From: "Don Fedyk" To: "Brian E Carpenter" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Brian Nice Summary Then is "addressing" in addition to=20 -Identifying something -Locating something=20 Also equally required to be - Capable of being symmetrically translated between contexts?=20 The better translation is supported by underlying protocol(s,) the easier it is to make contexts "well formed" and capable of supporting mobility. Regards, Don=20 =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Tuesday, January 09, 2007 10:07 AM > To: ram@iab.org > Subject: [RAM] Thoughts about context-dependency of id/loc=20 > semantics (long) >=20 > It is well established that naming, addressing and routing=20 > are conceptually > separate (or should be!) [IEN19, IEN48, RFC1498] are=20 > formative in this regard. > For a long time, the view in the the IETF community was that=20 > DNS took care > of naming, IP took care of addressing, and routing protocols=20 > took care of > routing. As growth in the Internet accelerated, cracks=20 > appeared in this > simplistic view [RFC2101, RFC2775]. >=20 > Emerging issues such as multihoming, the need for sites to=20 > change ISPs, > mobility, and end to end security have led to increasing=20 > perception that > the "addressing" concept has two very distinct aspects: >=20 > - identifying something > - locating something >=20 > It might be thought that "identifying something" is what a name does. > But it turns out that 'example.com' (which in the original concept > of DNS would have identified a specific interface on a specific > computer) is in fact a virtual name that generally identifies > a company called 'Example' and typically leads to a server pool > (i.e. multiple computers). Here, we are not talking about that. > We are talking about identifying network level entities - > put simply, they could be individual TCP/IP stacks or they > could be conglomerates generally known as "sites". >=20 > The word "stack" was defined as the entity to be identified > by the IRTF Namespace Research Group in an unpublished document > (draft-irtf-nsrg-report) thus: >=20 > " Today, a host may represent multiple entities. This happens when a > service provider hosts many web sites on one server. Similarly, a > single entity may be represented by multiple hosts. =20 > Replicated web > servers are just such an example. These entities are "protocol > stacks" or simply "stacks", instantiations of the TCP/IP model, be > they across one or many hosts. A stack is defined as one > participant or the process on one side of an end-to-end > communication. That participant may move and may be=20 > represented by > multiple hosts... >=20 > Each instance of a stack has a name, a "stack name". At an > architectural level the Name Space Research Group debated=20 > the value > of such names, and their associated costs. Forms of this name are > used in numerous places today. SSH uses public/private=20 > key pairs to > identify end points. An HTTP cookie anonymously=20 > identifies one end > of a communication, in such a manner that both the=20 > connection and the > IP address of the other end point may change many times. =20 > Stack names > are intended to identify mobile nodes, devices behind NATs, and > participants in a content delivery or overlay network." >=20 > To send a packet to a stack, we need its identity and we need to > know where that identity is currently located. Today stack=20 > identity and > stack location are both somehow combined in an IP address=20 > (whether it's > IPv4 or IPv6 doesn't matter.) If a stack is identified as > 10.1.2.3 we expect the routing system to treat this as a=20 > stack locator. > Similarly, if a site is identified as 10/8, we expect the=20 > routing system > to treat this as a site locator. But this example is deliberately > a broken one - we know that address and that prefix are ambiguous, and > have no global value either as identifiers or as locators. Yet within > a given network using private addresses, 10.1.2.3 is a perfectly > good stack identifier and locator, and 10.1.2/24 is a=20 > pefectly good subnet > locator. >=20 > What is going on here is an illustration of a much more general > observation: an IP address, or an IP prefix (the high order bits > of an address) can be a stack (or site) identifier, a locator, > neither, or both simultaneously *depending on context*. >=20 > To be specific: >=20 > - inside a NATted site, 10.1.2.3 is a good stack ID and a=20 > good stack locator. > outside the site, it becomes simply meaningless garbage bits. >=20 > - if the site's NAT box has public address 192.0.2.1, then the stack > identified internally could be identified externally as > 192.0.2.1: and its locator would be 192.0.2.1. > The mess here is that an IP address is no longer sufficient as a > stack identifier, and of course the port number is only borrowed > until the NAT decides to take it away. >=20 > - if a site has a tunnelled connection to another site, it could be > (for example) that 10.1.2.3 is a good identifier on both=20 > sites (because > they have agreed administratively to divide 10/8 between them) but > the locator, as far as site B is concerned, is 192.0.2.77=20 > (because that > happens to be the tunnel address in the B to A direction). But for > anyone else on the Internet, 192.0.2.77 is meaningless. >=20 > We could give more examples, and give IPv6 examples. But the > conclusion is inescapable: whether an IP address is an identifier, > a locator, both, or neither depends on context, and not on the > syntax or semantics of the address itself. Exactly the same applies > to prefixes. >=20 > The question that this leads to is whether the simple notion of > "locator/identifier split" is actually meaningful. Is this > context-dependence of the semantics of an IP address an > accident due to slow drift in the Internet's architecture, > or is it actually a desirable property of the namespace for > IP stacks? >=20 > To answer this, we need to identify the properties required > for a stack identifier namespace and those for a stack locator > namespace. If the required properties turn out to be orthogonal, > a simple split may be possible; if they turn out to be inseparable, > a simple split may be impossible, and the context-dependency > mentioned above may be inevitable. >=20 > Brian >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jan 14 21:05:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HCj-00077D-Mn; Sun, 14 Jan 2007 21:04:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HCi-000778-Hx for ram@ietf.org; Sun, 14 Jan 2007 21:04:08 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6HCe-00065S-9H for ram@ietf.org; Sun, 14 Jan 2007 21:04:08 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H6HCa-00028v-Rk for ram@ietf.org; Sun, 14 Jan 2007 18:04:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jan 2007 01:31:23 +0100 To: ram@ietf.org From: JFCM MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 2.1 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [RAM] draft summary X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0904406230==" Errors-To: ram-bounces@iab.org Message-Id: --===============0904406230== Content-Type: multipart/alternative; boundary="----MTwhuzmxvaddnapauqusofrpyqzgrhcumw" ------MTwhuzmxvaddnapauqusofrpyqzgrhcumw Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-61FD66BB At this stage there is no matter yet for an I_D. But I made a summary of some ideas on the matter we discuss. http://jefsey.com/addressing.pdf I would thank those sending me private comments. jfc ------MTwhuzmxvaddnapauqusofrpyqzgrhcumw Content-Type: text/html At this stage there is no matter yet for an I_D. But I made a summary
of some ideas on the matter we discuss.  http://jefsey.com/addressing.pdf
I would thank those sending me private comments.
jfc

------MTwhuzmxvaddnapauqusofrpyqzgrhcumw-- --===============0904406230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0904406230==-- From ram-bounces@iab.org Mon Jan 15 15:24:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YNW-0007sV-J4; Mon, 15 Jan 2007 15:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YNU-0007mf-QA for ram@iab.org; Mon, 15 Jan 2007 15:24:24 -0500 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6YNT-00059i-CQ for ram@iab.org; Mon, 15 Jan 2007 15:24:24 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1H6YNJ-0000jS-NF; Mon, 15 Jan 2007 20:24:14 +0000 Message-ID: <45ABE315.6070307@dial.pipex.com> Date: Mon, 15 Jan 2007 20:24:53 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RAM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [RAM] Consequences of needing route micro-management (long) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org After my previous post on Traffic engineering and the network model (http://www1.ietf.org/mail-archive/web/ram/current/msg00102.html) I was thinking some more about the near-perfect in-order delivery constraint imposed by the transport layer. I don't know whether TCP was designed that way to take advantage of the fact that the routing protocols delivered a single fully specified end-to-end route or whether this constraint was deliberately laid on routing at the beginning of IP time, but it is currently a constraint on routing and associated mechanisms: we had to take it into account when architecting DiffServ and in the design of ECMP. [Maybe someone who was in at the beginning remembers which was chicken and which was egg, but it no longer really matters.] The result is that routers need to micro-manage the flow of every packet even in the core of the network. They need to be supplied with a fully specified route from source to destination applicable to every packet that goes past. Further packets belonging to the same 'micro-flow' (DiffServ terminology) must take the same complete path at least for a longish time period - between rerouting events. In a meshy network, with multiple paths that are equivalently effective at delivering the packet, this may be very inefficient and require more complex hardware than is desirable. It effectively introduces (more) state into the control plane of the network core contrary to Internet principles. So far this is just a restatement of the analysis in the previous message, except for bringing out that routers appear to require a complete AS path for each prefix to do their business. Aside on Information Explosion ============================== Before going on I should mention that Joel Halpern pointed out to me that path vector protocols are not good at carrying alternative routes. Doing this leads very quickly to an information explosion. One way of viewing what is happening in core routers today is a sort of partly controlled explosion where providers and multihomed sites are seeking to advertise a smallish number of alternative routes in order to try and make efficient use of the meshy network. Consequences ============ I believe that the need for a fully specified end-to-end path has some important consequences that are limiting our options for solutions and are tied in to Brian Carpenter's observations on the possible need for contextual evaluation of id/loc mapping (http://www1.ietf.org/mail-archive/web/ram/current/msg00445.html). One of the identified shortcomings of the existing inter-domain routing system is that information is propagated further than is desirable. Put another way, a requirement identified for a next gen routing system is locality of information dissemination. At the time when I was involved in writing this down (rrg routing requirements draft), this was an abstract requirement but I think it is now clear to me that the need for a very precisely specified path over the whole end-to-end route and known at every point on the path is not just a symptom, but actually the cause of the problem. In essence, we have information leakage about the internal structure of the various parts of the network to all the other parts. This leakage is driven by the pressure of needing to have a fully specified, unique path available everywhere. In turn, the fact that globally comprehensible information is essentially obliged to be propagated over the whole network drives the need for essentially a single addressing realm. This then results in the need for the hierarchical "addressing follows routing or vice versa" structure with a single hierarchy. Of course the real network does not use a single addressing realm, and research work is looking at additional realms: - NATs provide linkage to site realms - DTN (Delay Tolerant Networking) uses (or at least can use) alternative addressing in DTN realms linked by DTN gateways - Potentially the contextual id/loc mapping links to additional realms. The need for a fully specified end-to-end path puts some very heavy constraints on the gateways between these realms and the routes that pass between them. We know that switching a route from one NAT gateway to another is difficult, and I have had personal experience of trying to work out how to link between a DTN realm and the conventional Internet where there is more than one gateway. Maps and the Single Hierarchy ============================= NIMROD introduced maps as a conceptual model for Internet routing. My understanding from when I looked at the original architecture was that maps would only export sufficient detail to allow a packet to reach the edge of a mapped area where the routing would get more precise directions taking it to a nested boundary, and so on. This would inherently reduce the leakage of information. The detailed working out of this strategy, if I read the runes correctly back when I first met NIMROD and now with a good deal of added hindsight, foundered exactly because the need for a fully specified end-to-end route was anathema to the mapping concept. (This is my own opinion and was certainly not written down in the annals). PNNI attempted to implement the mapping concept, but my understanding - again I have never had anybody confirm this to me - is that it only really worked in a single hierarchical domain with a god-like entity sitting at the top to allow a single path to be created. Does multi-path routing help? A hypothesis. =========================================== It has been my belief (and this was not backed up by proof, and still isn't fully) that a number of the problems that the Internet is suffering are caused by the need to use single tree-like hierarchies for fundamental structures, such as addressing. It appears to me now that it would be worth investigating whether relaxing the transport-imposed in-order delivery constraint would allow the Internet to use multi-path routing. By this I mean that a packet may be routed along any reasonably effective path towards its destination without needing to consider what other members of its micro-flow did. In principle this should match much more closely with the needs of multihoming and traffic engineering. It might well allow the decoupling of DiffServ traffic classes from the constituent micro-flows and make QoS easier to deliver (pious hope??) which would be architecturally much sounder than the current way of working. I believe that multi-path routing would also make it possible to properly realize the NIMROD map concept which seems to be an excellent way of keeping routing information as localised as possible. Finally this would, I believe, make it possible to link addressing realms in a much freer way rather than the restrictive topologies we are forced to adopt today. A research task... ================== As Joel pointed out, the current inter-domain routing mechanisms are unlikely to help with multi-path routing because we would trade one form of information explosion for another one. The current research strategies are AFAIK treading the same ground of finding better ways to deliver a fully specified unique path. We know ways of finding multi-paths in the intra-domain environment where the routing protocols are all-informed (they are used for fast reroute mechanisms). I think inter-domain multi-path and its relationship to maps oght to be a fruitful area for future research, and if my beliefs are correct, we can make some tweaks to existing transports to reduce their dependence on in-order delivery (TCP made some limited changes already if remember correctly) so that we are ready to implement. Philosophically, it is also intriguing, because it would take the Internet closer to the true connectionless model whereas the need for fully specified paths is only a half-way house on the march away from connections. Finally, an analogy =================== In the previous message, I opined that attempting to disguise the meshy nature of the Internet infrastructure rather than embracing it was a dangerous strategy. Those of you familiar with the wireless realm will probably be aware that for more or less the whole of radio technology's short lifetime multi-path reception was a bugbear to be suffered and concealed by putting aerials on high points and pumping out more power. Recent developments initially in military communications and cellular phones have stopped fighting the problem and started using multi-path as a way to get more bandwidth from less power and less spectrum. Multiple directional receiving antennas and cunning adaptations of the spread spectrum correlation techniques have allowed receivers to work with low radiated powers in what would previously been considered impossibly hostile environments. This has recently percolated into Wi-Fi (802.11n) and claims to be further increasing the effective range and/or bandwidth of the technology. Clearly the analogy is not exact, but it reinforces the need to embrace the "multi-path opportunity" and hopefully get a boost in the process! Apologies for the long and somewhat discursive posting. Thoughts? /Elwyn Davies _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 07:55:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6npi-0006oB-8q; Tue, 16 Jan 2007 07:54:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6npg-0006o6-DF for ram@iab.org; Tue, 16 Jan 2007 07:54:32 -0500 Received: from montage.altserver.com ([72.34.52.22] helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6npf-00029O-8C for ram@iab.org; Tue, 16 Jan 2007 07:54:32 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=asus) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1H6npb-0002v9-6s for ram@iab.org; Tue, 16 Jan 2007 04:54:28 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jan 2007 13:54:27 +0100 To: Elwyn Davies ,RAM From: JFCM Subject: Re: [RAM] Consequences of needing route micro-management (long) In-Reply-To: <45ABE315.6070307@dial.pipex.com> References: <45ABE315.6070307@dial.pipex.com> MIME-Version: 1.0 X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1376267056==" Errors-To: ram-bounces@iab.org Message-Id: --===============1376267056== Content-Type: multipart/alternative; boundary="----MTyatxgqyubcjwfypzukaapumntyhedzdi" ------MTyatxgqyubcjwfypzukaapumntyhedzdi Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-28A3477F At 21:24 15/01/2007, Elwyn Davies wrote: >The result is that routers need to micro-manage the flow of every >packet even in the core of the network. They need to be supplied >with a fully specified route from source to destination applicable >to every packet that goes past. Further packets belonging to the >same 'micro-flow' (DiffServ terminology) must take the same complete >path at least for a longish time period - between rerouting >events. In a meshy network, with multiple paths that are >equivalently effective at delivering the packet, this may be very >inefficient and require more complex hardware than is desirable. It >effectively introduces (more) state into the control plane of the >network core contrary to Internet principles. > >So far this is just a restatement of the analysis in the previous >message, except for bringing out that routers appear to require a >complete AS path for each prefix to do their business. Dear Elwyn, I subscribe to most of your concerns, often for the same reasons. However, I feel that the real problem is that you consider them still as engineering issues in the "mono-Internet", rather than using them to explore the possibilities of a "multi-Internet" architectural culture. >Aside on Information Explosion >============================== >Before going on I should mention that Joel Halpern pointed out to me >that path vector protocols are not good at carrying alternative routes. This depends on what you call a path and an alternative route. If the path vector implies a set of alternative route possibilities you do not have the problem anymore. > Doing this leads very quickly to an information explosion. One > way of viewing what is happening in core routers today is a sort of > partly controlled explosion where providers and multihomed sites > are seeking to advertise a smallish number of alternative routes in > order to try and make efficient use of the meshy network. subsidiarity is the key (see below). You still think meshed decentralised network here. Let try to think distributed one. >Consequences >============ >I believe that the need for a fully specified end-to-end path has >some important consequences that are limiting our options for >solutions and are tied in to Brian Carpenter's observations on the >possible need for contextual evaluation of id/loc mapping >(http://www1.ietf.org/mail-archive/web/ram/current/msg00445.html). The key issue here IMHO is to avoid redundant constraining information. Meaning that id and loc information must be totally orthogonal and each of them global. If one is relative in any way, they are not orthogonal and will not scale (this does not preclude orthogonal contextualities) >One of the identified shortcomings of the existing inter-domain >routing system is that information is propagated further than is >desirable. Put another way, a requirement identified for a next gen >routing system is locality of information dissemination. At the >time when I was involved in writing this down (rrg routing >requirements draft), this was an abstract requirement but I think it >is now clear to me that the need for a very precisely specified path >over the whole end-to-end route and known at every point on the path >is not just a symptom, but actually the cause of the problem. Sure it is. But it is to be analysed why. Size, computation, usage, maintenance, fialbility, security, uncompleteness? >In essence, we have information leakage about the internal structure >of the various parts of the network to all the other parts. This >leakage is driven by the pressure of needing to have a fully >specified, unique path available everywhere. Not only. It also comes from focusing on nodes rather than on links (see below) >In turn, the fact that globally comprehensible information is >essentially obliged to be propagated over the whole network drives >the need for essentially a single addressing realm. This then >results in the need for the hierarchical "addressing follows routing >or vice versa" structure with a single hierarchy. Which by essence is a centralised approach, hence unable to support a distributed system for very long. >Of course the real network does not use a single addressing realm, >and research work is looking at additional realms: >- NATs provide linkage to site realms >- DTN (Delay Tolerant Networking) uses (or at least can use) >alternative addressing in DTN realms linked by DTN gateways >- Potentially the contextual id/loc mapping links to additional realms. >The need for a fully specified end-to-end path puts some very heavy >constraints on the gateways between these realms and the routes that >pass between them. We know that switching a route from one NAT >gateway to another is difficult, and I have had personal experience >of trying to work out how to link between a DTN realm and the >conventional Internet where there is more than one gateway. Did you list somewhere the analysis of that difficulties? >Maps and the Single Hierarchy >============================= >NIMROD introduced maps as a conceptual model for Internet routing. Probably the reason why we do not use it today. IMHO the important introduction of NIMROD are the clusters. The error was to consider static nodes rather than focussing on "adjencies". In terms of adjencies there is no difference between adjencies to a node or to a cluster. RFC 1992.3.3 says: "Maps": "a map is a graph composed of nodes and adjencies. Propeties of the nodes are contained in attributes associated wih them. Adjencies have no attributes". Intervert "nodes" and "adjencies" in this section and you have your solution. >My understanding from when I looked at the original architecture was >that maps would only export sufficient detail to allow a packet to >reach the edge of a mapped area where the routing would get more >precise directions taking it to a nested boundary, and so on. This >would inherently reduce the leakage of information. The detailed >working out of this strategy, if I read the runes correctly back >when I first met NIMROD and now with a good deal of added hindsight, >foundered exactly because the need for a fully specified end-to-end >route was anathema to the mapping concept. (This is my own opinion >and was certainly not written down in the annals). The node-node end-to-end route can only be fully specified. To not fully specify it you must either consider clusters as nodes (what creates a really heady infromation flow you do not use), or document the end-to-end route in terms of adjencies. Clusters are then free to support these adjencies the way they want, using their internal adjencies the most efficiently. Other problem with node maps are that different visions are quite complex, traffic load cannot be easily considered, there is no datachecking and alternative routes are complex to compute. Adjency maps have not that problems; - I can document different visions of the same area, depending on different types of service or characteristics and report different adjencies (or lack of adjencies) depending on the user criteria. - traffic load can easily be supported in giving a cost to each adjency and increasing that cost depending on the traffic load. - each node reporting on its adjencies, each adjency is independently reported twice - helping checks. - alternative route resolution can be simplified through the formula AC=AB+BC and taking considering the least effective attributes of AB and BC to deduce the possibilities of AC. >PNNI attempted to implement the mapping concept, but my >understanding - again I have never had anybody confirm this to me - >is that it only really worked in a single hierarchical domain with a >god-like entity sitting at the top to allow a single path to be created. > >Does multi-path routing help? A hypothesis. >=========================================== >It has been my belief (and this was not backed up by proof, and >still isn't fully) that a number of the problems that the Internet >is suffering are caused by the need to use single tree-like >hierarchies for fundamental structures, such as addressing. It >appears to me now that it would be worth investigating whether >relaxing the transport-imposed in-order delivery constraint would >allow the Internet to use multi-path routing. No need to support it when it is not available. The cluster concept permits to address this simply and elegantly. Transparently to the external world. >By this I mean that a packet may be routed along any reasonably >effective path towards its destination without needing to consider >what other members of its micro-flow did. You can route packets as datagrams within a cluster if you find it more effective. >In principle this should match much more closely with the needs of >multihoming and traffic engineering. It might well allow the >decoupling of DiffServ traffic classes from the constituent >micro-flows and make QoS easier to deliver (pious hope??) which >would be architecturally much sounder than the current way of working. > >I believe that multi-path routing would also make it possible to >properly realize the NIMROD map concept which seems to be an >excellent way of keeping routing information as localised as possible. > >Finally this would, I believe, make it possible to link addressing >realms in a much freer way rather than the restrictive topologies we >are forced to adopt today. Yes. You also have to consider the set-up and error mechanisms and ISP rotation (route balancing) [missing in the NIMROD list of requirements] >A research task... >================== >As Joel pointed out, the current inter-domain routing mechanisms are >unlikely to help with multi-path routing because we would trade one >form of information explosion for another one. The current research >strategies are AFAIK treading the same ground of finding better ways >to deliver a fully specified unique path. We know ways of finding >multi-paths in the intra-domain environment where the routing >protocols are all-informed (they are used for fast reroute >mechanisms). I think inter-domain multi-path and its relationship >to maps oght to be a fruitful area for future research, and if my >beliefs are correct, we can make some tweaks to existing transports >to reduce their dependence on in-order delivery (TCP made some >limited changes already if remember correctly) so that we are ready >to implement. This can only be helped by orthogonal and global loc/id/extension addressing schemes. Another issue is to be consistent with semantic internet. I will take an image: http.1.1 - it permits to locally extend the adressing with global (using an URN) or relative information and access virtual hosts on Apache. The same, a new addressing/routing scheme should extend routing to applications and meaning (whatever the way meaning is made addressable). jfc ------MTyatxgqyubcjwfypzukaapumntyhedzdi Content-Type: text/html At 21:24 15/01/2007, Elwyn Davies wrote:
>The result is that routers need to micro-manage the flow of every
>packet even in the core of the network.  They need to be supplied
>with a fully specified route from source to destination applicable
>to every packet that goes past.  Further packets belonging to the
>same 'micro-flow' (DiffServ terminology) must take the same complete
>path at least for a longish time period - between rerouting
>events.  In a meshy network, with multiple paths that are
>equivalently effective at delivering the packet, this may be very
>inefficient and require more complex hardware than is desirable.  It
>effectively introduces (more) state into the control plane of the
>network core contrary to Internet principles.
>
>So far this is just a restatement of the analysis in the previous
>message, except for bringing out that routers appear to require a
>complete AS path for each prefix to do their business.

Dear Elwyn,
I subscribe to most of your concerns, often for the same reasons.
However, I feel that the real problem is that you consider them still
as engineering issues in the "mono-Internet", rather than using them
to explore the possibilities of a "multi-Internet" architectural culture.

>Aside on Information Explosion
>==============================
>Before going on I should mention that Joel Halpern pointed out to me
>that path vector protocols are not good at carrying alternative routes.

This depends on what you call a path and an alternative route. If the
path vector implies a set of alternative route possibilities you do
not have the problem anymore.

>  Doing this leads very quickly to an information explosion.  One
> way of viewing what is happening in core routers today is a sort of
> partly controlled explosion where providers and multihomed sites
> are seeking to advertise a smallish number of alternative routes in
> order to try and make efficient use of the meshy network.

subsidiarity is the key (see below). You still think meshed
decentralised network here. Let try to think distributed one.

>Consequences
>============
>I believe that the need for a fully specified end-to-end path has
>some important consequences that are limiting our options for
>solutions and are tied in to Brian Carpenter's observations on the
>possible need for contextual evaluation of id/loc mapping
>(http://www1.ietf.org/mail-archive/web/ram/current/msg00445.html).

The key issue here IMHO is to avoid redundant constraining
information. Meaning that id and loc information must be totally
orthogonal and each of them global. If one is relative in any way,
they are not orthogonal and will not scale (this does not preclude
orthogonal contextualities)

>One of the identified shortcomings of the existing inter-domain
>routing system is that information is propagated further than is
>desirable.  Put another way, a requirement identified for a next gen
>routing system is locality of information dissemination.  At the
>time when I was involved in writing this down (rrg routing
>requirements draft), this was an abstract requirement but I think it
>is now clear to me that the need for a very precisely specified path
>over the whole end-to-end route and known at every point on the path
>is not just a symptom, but actually the cause of the problem.

Sure it is. But it is to be analysed why. Size, computation, usage,
maintenance, fialbility, security, uncompleteness?

>In essence, we have information leakage about the internal structure
>of the various parts of the network to all the other parts.  This
>leakage is driven by the pressure of needing to have a fully
>specified, unique path available everywhere.

Not only. It also comes from focusing on nodes rather than on links (see below)

>In turn, the fact that globally comprehensible information is
>essentially obliged to be propagated over the whole network drives
>the need for essentially a single addressing realm.  This then
>results in the need for the hierarchical "addressing follows routing
>or vice versa" structure with a single hierarchy.

Which by essence is a centralised approach, hence unable to support a
distributed system for very long.

>Of course the real network does not use a single addressing realm,
>and research work is looking at additional realms:
>- NATs provide linkage to site realms
>- DTN (Delay Tolerant Networking) uses (or at least can use)
>alternative addressing in DTN realms linked by DTN gateways
>- Potentially the contextual id/loc mapping links to additional realms.
>The need for a fully specified end-to-end path puts some very heavy
>constraints on the gateways between these realms and the routes that
>pass between them.  We know that switching a route from one NAT
>gateway to another is difficult, and I have had personal experience
>of trying to work out how to link between a DTN realm and the
>conventional Internet where there is more than one gateway.

Did you list somewhere the analysis of that difficulties?

>Maps and the Single Hierarchy
>=============================
>NIMROD introduced maps as a conceptual model for Internet routing.

Probably the reason why we do not use it today. IMHO the important
introduction of NIMROD are the clusters. The error was to consider
static nodes rather than focussing on "adjencies". In terms of
adjencies there is no difference between adjencies to a node or to a
cluster. RFC 1992.3.3  says: "Maps": "a map is a graph composed of
nodes and adjencies. Propeties of the nodes are contained in
attributes associated wih them. Adjencies have no attributes".
Intervert "nodes" and "adjencies" in this section and you have your solution.

>My understanding from when I looked at the original architecture was
>that maps would only export sufficient detail to allow a packet to
>reach the edge of a mapped area where the routing would get more
>precise directions taking it to a nested boundary, and so on.  This
>would inherently reduce the leakage of information.  The detailed
>working out of this strategy, if I read the runes correctly back
>when I first met NIMROD and now with a good deal of added hindsight,
>foundered exactly because the need for a fully specified end-to-end
>route was anathema to the mapping concept. (This is my own opinion
>and was certainly not written down in the annals).

The node-node end-to-end route can only be fully specified. To not
fully specify it you must either consider clusters as nodes (what
creates a really heady infromation flow you do not use), or document
the end-to-end route in terms of adjencies. Clusters are then free to
support these adjencies the way they want, using their internal
adjencies the most efficiently.

Other problem with node maps are that different visions are quite
complex, traffic load cannot be easily considered, there is no
datachecking and alternative routes are complex to compute. Adjency
maps have not that problems;

- I can document different visions of the same area, depending on
different types of service or characteristics and report different
adjencies (or lack of adjencies) depending on the user criteria.
- traffic load can easily be supported in giving a cost to each
adjency and increasing that cost depending on the traffic load.
- each node reporting on its adjencies, each adjency is independently
reported twice - helping checks.
- alternative route resolution can be simplified through the formula
AC=AB+BC and taking considering the least effective attributes of AB
and BC to deduce the possibilities of AC.

>PNNI attempted to implement the mapping concept, but my
>understanding - again I have never had anybody confirm this to me -
>is that it only really worked in a single hierarchical domain with a
>god-like entity sitting at the top to allow a single path to be created.
>
>Does multi-path routing help? A hypothesis.
>===========================================
>It has been my belief (and this was not backed up by proof, and
>still isn't fully) that a number of the problems that the Internet
>is suffering are caused by the need to use single tree-like
>hierarchies for fundamental structures, such as addressing.  It
>appears to me now that it would be worth investigating whether
>relaxing the transport-imposed in-order delivery constraint would
>allow the Internet to use multi-path routing.

No need to support it when it is not available. The cluster concept
permits to address this simply and elegantly. Transparently to the
external world.

>By this I mean that a packet may be routed along any reasonably
>effective path towards its destination without needing to consider
>what other members of its micro-flow did.

You can route packets as datagrams within a cluster if you find it
more effective.

>In principle this should match much more closely with the needs of
>multihoming and traffic engineering.  It might well allow the
>decoupling of DiffServ traffic classes from the constituent
>micro-flows and make QoS easier to deliver (pious hope??) which
>would be architecturally much sounder than the current way of working.
>
>I believe that multi-path routing would also make it possible to
>properly realize the NIMROD map concept which seems to be an
>excellent way of keeping routing information as localised as possible.
>
>Finally this would, I believe, make it possible to link addressing
>realms in a much freer way rather than the restrictive topologies we
>are forced to adopt today.

Yes.
You also have to consider the set-up and error mechanisms and ISP
rotation (route balancing) [missing in the NIMROD list of requirements]

>A research task...
>==================
>As Joel pointed out, the current inter-domain routing mechanisms are
>unlikely to help with multi-path routing because we would trade one
>form of information explosion for another one.  The current research
>strategies are AFAIK treading the same ground of finding better ways
>to deliver a fully specified unique path.  We know ways of finding
>multi-paths in the intra-domain environment where the routing
>protocols are all-informed (they are used for fast reroute
>mechanisms).  I think inter-domain multi-path and its relationship
>to maps oght to be a fruitful area for future research, and if my
>beliefs are correct, we can make some tweaks to existing transports
>to reduce their dependence on in-order delivery (TCP made some
>limited changes already if remember correctly) so that we are ready
>to implement.

This can only be helped by orthogonal and global loc/id/extension
addressing schemes.

Another issue is to be consistent with semantic internet. I will take
an image: http.1.1 - it permits to locally extend the adressing with
global (using an URN) or relative information and access virtual
hosts on Apache. The same, a new addressing/routing scheme should
extend routing to applications and meaning (whatever the way meaning
is made addressable).

jfc





------MTyatxgqyubcjwfypzukaapumntyhedzdi-- --===============1376267056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1376267056==-- From ram-bounces@iab.org Tue Jan 16 13:15:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sp8-0000hy-FK; Tue, 16 Jan 2007 13:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sp6-0000hs-Qe for ram@iab.org; Tue, 16 Jan 2007 13:14:16 -0500 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sp5-00040W-Ag for ram@iab.org; Tue, 16 Jan 2007 13:14:16 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JBZ3ZL01.T4G; Tue, 16 Jan 2007 19:14:09 +0100 In-Reply-To: <45A3AF7F.5000104@zurich.ibm.com> X-Priority: 1 (High) Subject: Re: [RAM] Thoughts about context-dependency of id/loc semantics (long) To: Brian E Carpenter X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Tue, 16 Jan 2007 19:14:05 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 16/01/2007 19:12:41 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian, See my comments below. Brian E Carpenter escribi=F3 el 09/01/2007 16:06:3= 9: > > What is going on here is an illustration of a much more general > observation: an IP address, or an IP prefix (the high order bits > of an address) can be a stack (or site) identifier, a locator, > neither, or both simultaneously *depending on context*. > > To be specific: > > - inside a NATted site, 10.1.2.3 is a good stack ID and a good stack locator. > outside the site, it becomes simply meaningless garbage bits. > > - if the site's NAT box has public address 192.0.2.1, then the stack > identified internally could be identified externally as > 192.0.2.1: and its locator would be 192.0.2.1. > The mess here is that an IP address is no longer sufficient as a > stack identifier, and of course the port number is only borrowed > until the NAT decides to take it away. > > - if a site has a tunnelled connection to another site, it could be > (for example) that 10.1.2.3 is a good identifier on both sites (becau= se > they have agreed administratively to divide 10/8 between them) but > the locator, as far as site B is concerned, is 192.0.2.77 (because th= at > happens to be the tunnel address in the B to A direction). But for > anyone else on the Internet, 192.0.2.77 is meaningless. Your three examples are a consequence of RFC1918. NAT and tunnels could have been deployed even if private addresses didn't exist to hide for example a part of an enterprise network. But it was RFC1918 which introduced a new context of interpretation for IP addresses. And so it did RFC1112 where IP multicast addresses were introduced. This partition of the address space implies new contexts of interpretations. An example of this is an enterprise network where 10/8 is not only meaningful but also a network in which private prefixes and public prefixes can share the same routing table, and both can be identifiers and locators. > We could give more examples, and give IPv6 examples. But the > conclusion is inescapable: whether an IP address is an identifier, > a locator, both, or neither depends on context, and not on the > syntax or semantics of the address itself. Exactly the same applies > to prefixes. Yes, but we can also think on specific prefixes that could be only used as locators for example. > The question that this leads to is whether the simple notion of > "locator/identifier split" is actually meaningful. Yes, and I think the "loc/id split" should not be taken as an absolute but in a relative sense: what it is an identifier (a non-locator more precisely) at a certain level can be perfectly used as a locator at another level. > ................................................ Is this > context-dependence of the semantics of an IP address an > accident due to slow drift in the Internet's architecture, > or is it actually a desirable property of the namespace for > IP stacks? The context-dependence of the semantics of an IP address is not an accident but it is a direct consequence of the two RFCs mentioned above. And their effect on the interdomain routing infrastructure is so big that every single router connecting to the Internet will have to remove for example private prefixes from the BGP updates. Semantics is always context-dependent. > To answer this, we need to identify the properties required > for a stack identifier namespace and those for a stack locator > namespace. If the required properties turn out to be orthogonal, > a simple split may be possible; if they turn out to be inseparable, > a simple split may be impossible, and the context-dependency > mentioned above may be inevitable. There is another way to study this problem: we can start with a solution that is orthogonal in a specific context and then analyze the pros and cons of the solution. Regards, Juanjo = _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 16:18:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vgL-0007fo-GG; Tue, 16 Jan 2007 16:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vgK-0007ff-Df for ram@iab.org; Tue, 16 Jan 2007 16:17:24 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vgI-0007uy-Py for ram@iab.org; Tue, 16 Jan 2007 16:17:24 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070116211719.FDRE28701.eastrmmtao03.cox.net@eastrmimpo01.cox.net> for ; Tue, 16 Jan 2007 16:17:19 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BxFs1W0170pnMhQ0000000; Tue, 16 Jan 2007 16:15:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Tue, 16 Jan 2007 16:17:16 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [RAM] candidate properties of some new name types X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Some candidate properties of names, for consideration. Locators: - A Locator names a single sub-network, not an interface or node (This is similar to a "routing prefix" in current parlance.) - A node may have multiple Locators at the same time (e.g. due to multi-homing of some sort). - A Locator is only used for routing and forwarding packets, except that the last-hop router uses both the Locator and the Identifier to look up the destination link-layer information (e.g. MAC address) in the ARP/ND cache inside the router. Identifiers: - An Identifier names a node ("stack" in IRTF NSRG parlance) and is not tied to a specific interface or location. - A node may have multiple Identifiers concurrently. - A node may use multiple Identifiers concurrently, however a given single transport session must not change Identifier during the lifetime of that transport session. - An Identifier is not necessarily globally unique, but has a very high probability of being globally unique. - An Identifier is unique within the scope of a given Locator that it is used with. - Identifiers, and not Locators, are included in transport-layer session state. Ran NB: This is *different* than SHIM6. In SHIM6, the semantics of an IPv6 address are even more overloaded than before SHIM6. In this concept, Locators have crisp semantics and Identifiers have different crisp semantics -- no overloading of the same namespace for multiple purposes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 16:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wBr-0003AI-5A; Tue, 16 Jan 2007 16:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wBq-0003AD-1z for ram@iab.org; Tue, 16 Jan 2007 16:49:58 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wBm-0004Qy-Ok for ram@iab.org; Tue, 16 Jan 2007 16:49:58 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc13) with SMTP id <2007011621494801300m29j2e>; Tue, 16 Jan 2007 21:49:51 +0000 Message-ID: <091a01c739b7$a92f0d60$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: "RAM" References: <45ABE315.6070307@dial.pipex.com> Subject: Re: [RAM] Consequences of needing route micro-management (long) Date: Tue, 16 Jan 2007 15:45:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Mark Allman X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, Elwyn, Just to follow up on the transport aspects of your thoughtful note (http://www1.ietf.org/mail-archive/web/ram/current/msg00453.html). TCP did not start out caring about out-of-order delivery. As long as you got an ACK in less than Retransmission TimeOut (RTO) time, any order of delivery for either payload packets or ACKs was fine. TCP became sensitive to out-of-order delivery with Fast Retransmit/Fast Recovery - instead of waiting for RTO, we added a hack that said "when we receive N-many ACKs that don't fill in a 'hole' in the sequence number space, it's likely that we lost a packet, so we should retransmit". The problem is that if you reorder packets by more than N-many, the sender will see enough duplicate ACKs to decide that a packet was lost, in less than RTO time - and TCPs Fast-Retransmit the apparently-missing packet, and then Fast-Recover by cutting the congestion window in half ("Fast" is not a misnomer here, it's less drastic than Slow-Starting from CWND=1). N-many is 3 duplicate ACKs (4 ACKs total) in current-standard TCP. Mark Allman and friends have been working on dynamically adjusting N-many (Non-Congestion Robustness, NCR, recently published in http://www.icir.org/mallman/papers/rfc4653.txt), so there's nothing written in granite that we couldn't CHANGE the way TCP works (or SCTP either, for that matter). The idea, roughly, is to come up with a value of N-many that works over a specific path, instead of always using the same value as we do today. If you see new ACKs coming back after 6 duplicate ACKs, you assume that N-many should be increased from 3, for example. So some of the work on "relaxing nearly in-order delivery constraints" has already happened. It may be that routers could stop worrying about reordering microflows for at least TCP/SCTP traffic, at some point in the future. Thanks, Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 17:12:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wXi-0007oo-0h; Tue, 16 Jan 2007 17:12:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wXf-0007mz-TG for ram@iab.org; Tue, 16 Jan 2007 17:12:32 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wXe-0000ah-BG for ram@iab.org; Tue, 16 Jan 2007 17:12:31 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Jan 2007 14:12:30 -0800 X-IronPort-AV: i="4.13,198,1167638400"; d="scan'208"; a="356432185:sNHT47834564" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0GMCTMm010717; Tue, 16 Jan 2007 14:12:29 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0GMCMH2002543; Tue, 16 Jan 2007 14:12:25 -0800 (PST) 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.1830); Tue, 16 Jan 2007 14:12:22 -0800 Received: from [171.71.55.219] ([171.71.55.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 14:12:21 -0800 In-Reply-To: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 14:12:21 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Jan 2007 22:12:21.0746 (UTC) FILETIME=[64E0A520:01C739BB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1965; t=1168985549; x=1169849549; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20; bh=h1FmMpk846J5voo/zostiAizGfXqIzlfQSK67CqswK8=; b=ohPrOkzD5gsMCQBiz7XlZN3ifJR2Rqpr1xFo1X5cDM+Dbw/Yt71buoIsxTW/lpW3H1XaHmQp uhBYStTC5KgOsmaXtEsFvuMFOLI9Mxp9Z1bS0yE4R5o7/GPjIvc6eaVZ; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Locators: > - A Locator names a single sub-network, not an interface or node > (This is similar to a "routing prefix" in current parlance.) Clarification question: What is a sub-network? I'm guessing that you mean an L2 broadcast domain. > - A Locator is only used for routing and forwarding packets, > except that the last-hop router uses both the Locator and > the Identifier to look up the destination link-layer information > (e.g. MAC address) in the ARP/ND cache inside the router. Related clarification: Does the locator specify the sub-network and then the identifier indexes into the link-layer address cache for that sub-network? Your wording seems to imply that the cache necessarily spans sub-networks, which I don't think you actually mean. > Identifiers: > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. > - A node may have multiple Identifiers concurrently. > - A node may use multiple Identifiers concurrently, > however a given single transport session must not change > Identifier during the lifetime of that transport session. > - An Identifier is not necessarily globally unique, but has > a very high probability of being globally unique. > - An Identifier is unique within the scope of a given Locator > that it is used with. > - Identifiers, and not Locators, are included in transport-layer > session state. Is an identifier bound to a particular link layer address? If so, for how long? If an identifier is bound to a node, is it possible to migrate a transport session? Suppose I have a TCP connection and I suspend the process. It now pops up on a different virtual machine on the same physical hardware. Does that work? What about on different hardware? What about within a different locator? Is the destination locator removed by the last hop-router? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 17:28:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wn2-0008TT-KE; Tue, 16 Jan 2007 17:28:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6wn1-0008TL-S2 for ram@iab.org; Tue, 16 Jan 2007 17:28:23 -0500 Received: from eastrmmtao02.cox.net ([68.230.240.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6wmz-0003pW-Vl for ram@iab.org; Tue, 16 Jan 2007 17:28:23 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070116222817.AWU9317.eastrmmtao02.cox.net@eastrmimpo01.cox.net>; Tue, 16 Jan 2007 17:28:17 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BySp1W01F0pnMhQ0000000; Tue, 16 Jan 2007 17:26:50 -0500 In-Reply-To: References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <656453A6-4681-4CCC-A221-C29D3840DB0E@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 17:28:15 -0500 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 17:12, Tony Li wrote: >> Locators: >> - A Locator names a single sub-network, not an interface or node >> (This is similar to a "routing prefix" in current parlance.) > > > Clarification question: What is a sub-network? I'm guessing that > you mean an L2 broadcast domain. Yes. For example, a single Ethernet VLAN. >> - A Locator is only used for routing and forwarding packets, >> except that the last-hop router uses both the Locator and >> the Identifier to look up the destination link-layer information >> (e.g. MAC address) in the ARP/ND cache inside the router. > > > Related clarification: Does the locator specify the sub-network and > then the identifier indexes into the link-layer address cache for > that sub-network? Your wording seems to imply that the cache > necessarily spans sub-networks, which I don't think you actually mean. Locator specifies the sub-network. Identifier indexes into the link-layer cache for that given Locator. Sorry if the wording was confusing. >> Identifiers: >> - An Identifier names a node ("stack" in IRTF NSRG parlance) >> and is not tied to a specific interface or location. >> - A node may have multiple Identifiers concurrently. >> - A node may use multiple Identifiers concurrently, >> however a given single transport session must not change >> Identifier during the lifetime of that transport session. >> - An Identifier is not necessarily globally unique, but has >> a very high probability of being globally unique. >> - An Identifier is unique within the scope of a given Locator >> that it is used with. >> - Identifiers, and not Locators, are included in transport-layer >> session state. > > > Is an identifier bound to a particular link layer address? If so, > for how long? Hmm. I'm not sure I follow the question. A node might have some Identifier (Ix). The node might use Ix with traffic over a wireless Ethernet interface having MAC address A and also with traffic over a wired Ethernet interface having MAC address B -- concurrently. > If an identifier is bound to a node, is it possible to migrate a > transport session? Suppose I have a TCP connection and I suspend > the process. It now pops up on a different virtual machine on the > same physical hardware. Does that work? What about on different > hardware? What about within a different locator? This gets into what one means by "node" or "virtual machine" or "distributed system" or "different hardware". One can imagine a single distributed system built out of 3 different x86 chassis. If there is a common stack for that single distributed system, then the TCP connection might be moved (internally to the distributed system) from chassis 1 to chassis 3. One can imagine a multi-level secure system having several different virtual machines, each with its own "stack", on a single piece of physical hardware. In this case, for OS reasons unrelated to networking, the TCP process is unlikely to migrate from the TS virtual-machine to the U virtual-machine. If the TCP session is on Node X with Identifier Ix, then if that node moves from location Y (Locator Ly) to location Z (Locator Lz), then the TCP session stays up because it is bound to the Identifier only, so the Locator can change without affecting the TCP session's liveness. > Is the destination locator removed by the last hop-router? It does not have to be removed. Normally, one would imagine that the last-hop router would not remove it, simply to conserve ergs. Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 17:43:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x1e-0005rX-B1; Tue, 16 Jan 2007 17:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x1c-0005pF-Pa for ram@iab.org; Tue, 16 Jan 2007 17:43:28 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6x1b-0007oB-Ed for ram@iab.org; Tue, 16 Jan 2007 17:43:28 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 16 Jan 2007 14:43:26 -0800 X-IronPort-AV: i="4.13,198,1167638400"; d="scan'208"; a="356438222:sNHT61967178" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0GMhQvi026100; Tue, 16 Jan 2007 14:43:26 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0GMhQUw004284; Tue, 16 Jan 2007 14:43:26 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 14:43:26 -0800 Received: from [171.71.55.219] ([171.71.55.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 14:43:26 -0800 In-Reply-To: <656453A6-4681-4CCC-A221-C29D3840DB0E@extremenetworks.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <656453A6-4681-4CCC-A221-C29D3840DB0E@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <407DB873-6EF5-4D3D-B242-6695B4B50A38@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 14:43:25 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Jan 2007 22:43:26.0269 (UTC) FILETIME=[BC3846D0:01C739BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2160; t=1168987406; x=1169851406; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20; bh=JFiQ0P5nih2dSwskLhIeswW/5NPRAbgq32l+L7vko5o=; b=EbGS8d478mt7q2+g81A+/B7JqKqY/ochhGYeZEmt9Ten21AyM5IuxKr32HaAdQavjBtH+AK9 srE9WEruRpfy+gbv0Oo2qH/1e/q4tsmzFiAEz5H9uR90D5lk9QsTN6kZ; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Is an identifier bound to a particular link layer address? If so, >> for how long? > > Hmm. I'm not sure I follow the question. > > A node might have some Identifier (Ix). The node might use Ix > with traffic over a wireless Ethernet interface having MAC address A > and also with traffic over a wired Ethernet interface having MAC > address B -- concurrently. > >> If an identifier is bound to a node, is it possible to migrate a >> transport session? Suppose I have a TCP connection and I suspend >> the process. It now pops up on a different virtual machine on the >> same physical hardware. Does that work? What about on different >> hardware? What about within a different locator? > > This gets into what one means by "node" or "virtual machine" or > "distributed system" or "different hardware". > > One can imagine a single distributed system built out of 3 different > x86 chassis. If there is a common stack for that single distributed > system, then the TCP connection might be moved (internally to the > distributed system) from chassis 1 to chassis 3. > > One can imagine a multi-level secure system having several different > virtual machines, each with its own "stack", on a single piece of > physical hardware. In this case, for OS reasons unrelated to > networking, > the TCP process is unlikely to migrate from the TS virtual-machine > to the U virtual-machine. > > If the TCP session is on Node X with Identifier Ix, then if that node > moves from location Y (Locator Ly) to location Z (Locator Lz), then > the TCP session stays up because it is bound to the Identifier only, > so the Locator can change without affecting the TCP session's > liveness. So, if I'm following you, the session is strongly bound to the identifier for the lifetime of the session. The identifier is strongly bound to the node. The node is loosely bound to the hardware address for the duration of the ARP entry. I have no problems with any of this, I just wanted to make sure that we are clear on the architectural limitations that come along with these definitions. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 17:46:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x47-00049n-3b; Tue, 16 Jan 2007 17:46:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6x44-00049W-TN for ram@iab.org; Tue, 16 Jan 2007 17:46:00 -0500 Received: from centrmmtao01.cox.net ([70.168.83.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6x41-000097-CF for ram@iab.org; Tue, 16 Jan 2007 17:46:00 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070116224554.SNNM23868.centrmmtao01.cox.net@eastrmimpo01.cox.net>; Tue, 16 Jan 2007 17:45:54 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BykT1W0120pnMhQ0000000; Tue, 16 Jan 2007 17:44:27 -0500 In-Reply-To: <407DB873-6EF5-4D3D-B242-6695B4B50A38@cisco.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <656453A6-4681-4CCC-A221-C29D3840DB0E@extremenetworks.com> <407DB873-6EF5-4D3D-B242-6695B4B50A38@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40AD0F42-D6E1-4A5F-A91E-58F8425802EC@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 17:45:53 -0500 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 17:43, Tony Li wrote: > So, if I'm following you, the session is strongly bound to the > identifier > for the lifetime of the session. The identifier is strongly bound > to the > node. The node is loosely bound to the hardware address for the > duration > of the ARP entry. Yes. > I have no problems with any of this, I just wanted to make sure > that we are clear on the architectural limitations that come along > with these definitions. Clarity is good. :-) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 17:53:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xAR-0007BW-S5; Tue, 16 Jan 2007 17:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xAQ-00079k-7g for ram@iab.org; Tue, 16 Jan 2007 17:52:34 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xAP-0001IK-12 for ram@iab.org; Tue, 16 Jan 2007 17:52:34 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 966DC872F7; Tue, 16 Jan 2007 17:52:32 -0500 (EST) To: ram@iab.org, rja@extremenetworks.com Subject: Re: [RAM] candidate properties of some new name types Message-Id: <20070116225232.966DC872F7@mercury.lcs.mit.edu> Date: Tue, 16 Jan 2007 17:52:32 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: RJ Atkinson > Locators: > - A Locator names a single sub-network, not an interface or node Ran, I am really unhappy with this, because it means you have to identify the individual interface on that sub-network (aka physical network) from some other field/name/bits, which presents a whole host of potential problems. E.g. if you're on an 801-style network, and you get the interface's 801 address from the identifier, then i) if a host has two interfaces, which have different 801 names, how/where do you get the bits for the 801 name for the second one (without having two identifiers, which kind of defeats the whole point); ii) if you want an identifier which is none of your 801 addresses, how do you get any of the 801 addresses; etc, etc? And of course all of this entangles the identifier name with the location name, a bad idea right there. And on networks which don't use IEEE 801 style addresses, where does the name of the interface in the local network's namespace go/come from? Are you assuming some sort of broadcast/database/etc lookup mechanism that you can use to translate identifiers to local network interface addresses? What do you do on networks that don't support network-wide broadcast? Use a database? Etc, etc, etc. Really, not a good idea. The locator names the interface, and provides in and of itself all the bits that you need to get the packet to it. End of story., > - A Locator is only used for routing and forwarding packets, > except that the last-hop router uses both the Locator and > the Identifier to look up the destination link-layer information > (e.g. MAC address) in the ARP/ND cache inside the router. See previous comments, e.g. about why mixing naming and location function in two names is really not a good idea. > Identifiers: That all sounds OK to me. Noel PS: And why are we discussing this on a routing-specific mailing list, anyway? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 18:30:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xkO-0002tt-7c; Tue, 16 Jan 2007 18:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6xkM-0002sY-0p for ram@iab.org; Tue, 16 Jan 2007 18:29:42 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6xkL-0007fY-NO for ram@iab.org; Tue, 16 Jan 2007 18:29:42 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0GNU0F5043388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jan 2007 00:30:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Wed, 17 Jan 2007 00:29:25 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I just subscribed and I'm still catching up, but I have to interject here... On 16-jan-2007, at 22:17, RJ Atkinson wrote: > - A Locator names a single sub-network, not an interface or node > (This is similar to a "routing prefix" in current parlance.) = incompatible with what we currently have > - A Locator is only used for routing and forwarding packets, > except that the last-hop router uses both the Locator and > the Identifier to look up the destination link-layer information > (e.g. MAC address) in the ARP/ND cache inside the router. = incompatible with what we currently have > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. = incompatible again > - A node may use multiple Identifiers concurrently, > however a given single transport session must not change > Identifier during the lifetime of that transport session. who are we to tell transports what they can and can't do? > - An Identifier is not necessarily globally unique, Ugh! > - An Identifier is unique within the scope of a given Locator > that it is used with. This isn't easy to do and pretty much ends up requiring global uniqueness anyway. > NB: This is *different* than SHIM6. In SHIM6, the semantics of > an IPv6 address are even more overloaded than before SHIM6. > In this concept, Locators have crisp semantics and Identifiers > have different crisp semantics -- no overloading of the same > namespace for multiple purposes. Irrespective of shim6, in my opinion the ability to overload is a feature. Removing that feature just because it doesn't conform to the contemporary notion of architectural cleanliness is a big mistake, especially in the context of this list, which isn't about coming up with new architectures but rather, solve a specific problem. The good thing about the blurry line between locators and identifiers is that one can be up/downgraded to the other when necessary, so we can create room for ourselves to accomplish our goals. For instance, in a "jack up" model, most routing/forwarding decisions will be done based on the new lower-level locators, but near the source, where the locators aren't present yet, and near the destination, where they're already stripped off, routing/forwarding can happen based on the identifiers. A clear separation between the two means that routers must be upgraded to know the difference, and take both into account on the destination link. While this isn't a bad idea in and of itself (surely IPX is now extinct for other reasons) mandating this type of change for the entire internet creates more problems than it solves. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 18:47:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6y0w-0003Ro-KK; Tue, 16 Jan 2007 18:46:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6y0v-0003Q1-Ej for ram@iab.org; Tue, 16 Jan 2007 18:46:49 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6y0t-0001qJ-ES for ram@iab.org; Tue, 16 Jan 2007 18:46:48 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070116234644.LNAP28701.eastrmmtao03.cox.net@eastrmimpo01.cox.net> for ; Tue, 16 Jan 2007 18:46:44 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BzlH1W00W0pnMhQ0000000; Tue, 16 Jan 2007 18:45:17 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 18:46:43 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 18:29, Iljitsch van Beijnum wrote: > Irrespective of shim6, in my opinion the ability to overload > is a feature. Removing that feature just because it doesn't conform > to the contemporary notion of architectural cleanliness is a big > mistake, ... The idea that such semantic overloading is undesirable goes back at least as far as Shoch. Calling that desire for crisp, clear semantics "contemporary" seems curious. As to your other comments, I think the concepts I've proposed could be implemented in a way that is entirely backwards compatible with IPv6/IPv4. Someone assuming that compatibility is impossible is not identical with it actually being impossible. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 19:00:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yDN-0007bi-7T; Tue, 16 Jan 2007 18:59:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yDM-0007bZ-6w for ram@iab.org; Tue, 16 Jan 2007 18:59:40 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6yDJ-0003tP-A1 for ram@iab.org; Tue, 16 Jan 2007 18:59:38 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070116235931.LZYM28701.eastrmmtao03.cox.net@eastrmimpo01.cox.net>; Tue, 16 Jan 2007 18:59:31 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id Bzy41W00E0pnMhQ0000000; Tue, 16 Jan 2007 18:58:04 -0500 In-Reply-To: <20070116225232.966DC872F7@mercury.lcs.mit.edu> References: <20070116225232.966DC872F7@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <314BF8AD-7ACD-44CF-84CE-0F9BB87F2CBF@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 18:59:30 -0500 To: Noel Chiappa X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 17:52, Noel Chiappa wrote: > E.g. if you're on an 801-style network, and you get the interface's > 801 > address from the identifier, then i) if a host has two interfaces, > which have different 801 names, how/where do you get the bits for > the 801 > name for the second one (without having two identifiers, which kind > of defeats the whole point); I think IPv6 ND could almost handle the case you describe right now, without having to resort to separate IDs for each interface. I'm confident that ND could be enhanced (very slightly) to permit that if it can't already do it today. > ii) if you want an identifier which is none of your 801 addresses, > how do you get any of the 801 addresses; etc, etc? IPv6 ND is an example that works fine. In IPv6, the low-order 64 bits might or might not actually be the link-layer address for that interface. IPv6 ND already handles both cases (that it is and that it isn't the link-layer address). > And of course all of this entangles the identifier name with the > location name, a bad idea right there. Well, they aren't entangled that way, if you follow my examples above. > And on networks which don't use IEEE 801 style addresses, > where does the name of the interface in the local network's > namespace go/come from? There are a range of options. For now, I don't want to close any doors. Just to stimulate thinking, HIP derives IDs from hashes of public keys, IPv6 can derive the ID directly from the link address, or ... > Are you assuming some sort of broadcast/database/etc lookup mechanism > that you can use to translate identifiers to local network interface > addresses? What do you do on networks that don't support network- > wide broadcast? Use a database? In IPv4, we have an ARP Cache. In IPv6, we have an ND Cache. With IPv6, the current practice is to use ND on all link types, not just those with a link-scope broadcast/multicast capability. So network::link location resolution really isn't rocket science. > The locator names the interface, and provides in and of itself all > the bits that you need to get the packet to it. That would be an alternative approach, and a somewhat different architecture. It is limiting in various ways, for example with respect to mobility. > See previous comments, e.g. about why mixing naming and location > function in two names is really not a good idea. It isn't mixing them. The Locator names the subnetwork. The Identifier names the node. One merely uses the name of the node when indexing into the ND/ARP cache -- that is not the same thing as tying the node name to its location at all. The node name does not vary as location changes, only the subnetwork name varies, and the subnetwork name always follows the topology. >> Identifiers: > > That all sounds OK to me. Well, it is reassuring to hear that. :-) > PS: And why are we discussing this on a routing-specific mailing > list, anyway? One possible approach to resolving (some, all of) the current operational routing issues (e.g. table size, mobility, multi-homing) would be to migrate to a new naming/addressing/routing architecture. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 19:01:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yEe-0000wU-7m; Tue, 16 Jan 2007 19:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yEc-0000rV-DW for ram@iab.org; Tue, 16 Jan 2007 19:00:58 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6yEc-00041c-2A for ram@iab.org; Tue, 16 Jan 2007 19:00:58 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0H01HQo043845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jan 2007 01:01:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Wed, 17 Jan 2007 01:00:50 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 17-jan-2007, at 0:46, RJ Atkinson wrote: > On 16 Jan 2007, at 18:29, Iljitsch van Beijnum wrote: >> Irrespective of shim6, in my opinion the ability to overload >> is a feature. Removing that feature just because it doesn't conform >> to the contemporary notion of architectural cleanliness is a big >> mistake, ... > The idea that such semantic overloading is undesirable goes back > at least as far as Shoch. Calling that desire for crisp, clear > semantics "contemporary" seems curious. It's the "overloading is bad" thing that I would call contemporary. It has worked quite well for us for the better part of the 25 years that IPv4 has been around. As I said, IPX/CLNP type link handling isn't bad per se, but I'd rather hang on to the existing way of doing things until it's clear that an alternative is essential in solving the problem at hand. > As to your other comments, I think the concepts I've proposed > could be implemented in a way that is entirely backwards compatible > with IPv6/IPv4. Someone assuming that compatibility is impossible > is not identical with it actually being impossible. You may have overestimated some of us by leaving coming up with that part up to the reader. :-) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 19:29:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ygM-0008Vl-QF; Tue, 16 Jan 2007 19:29:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ygL-0008Vc-2O for ram@iab.org; Tue, 16 Jan 2007 19:29:37 -0500 Received: from centrmmtao06.cox.net ([70.168.83.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ygI-0007Ag-P7 for ram@iab.org; Tue, 16 Jan 2007 19:29:37 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao06.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070117002932.FTDW13510.centrmmtao06.cox.net@eastrmimpo01.cox.net>; Tue, 16 Jan 2007 19:29:32 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id C0U41W0150pnMhQ0000000; Tue, 16 Jan 2007 19:28:05 -0500 In-Reply-To: <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 19:29:30 -0500 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 19:00, Iljitsch van Beijnum wrote: > It's the "overloading is bad" thing that I would call contemporary. Shoch and others suggested such overloading was a bad idea MANY years ago. So the thought that semantic overloading is bad simply is not a new one. Whether one agrees with the notion or not, it isn't "contemporary" but instead is long-standing within the Internet community. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 19:36:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ymt-0003Zi-Ju; Tue, 16 Jan 2007 19:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yms-0003Zb-E1 for ram@iab.org; Tue, 16 Jan 2007 19:36:22 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ymr-0000Eg-7U for ram@iab.org; Tue, 16 Jan 2007 19:36:22 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D2B3B872F7; Tue, 16 Jan 2007 19:36:18 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types Message-Id: <20070117003618.D2B3B872F7@mercury.lcs.mit.edu> Date: Tue, 16 Jan 2007 19:36:18 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum >>> Irrespective of shim6, in my opinion the ability to overload is a >>> feature. Removing that feature just because it doesn't conform to the >>> contemporary notion of architectural cleanliness I'm going to second Ran here. "Overloading is bad" is a pretty old idea, dating back at least to the start of my professional career. >> The idea that such semantic overloading is undesirable goes back at >> least as far as Shoch. > It's the "overloading is bad" thing that I would call contemporary. It's hardly new that people have been pointing out that this particular overloading is bad. See, for instance. RFC-1498 - which is itself a reprint of a paper from *1982*. So, exactly how is a *quarter-century* "contemporary"? It's true that only recently have the majority of people finally conceded the point, but a substantial minority have held this position for aeons. See, for example, the Big-Internet discussions from when IPng was being argued about, back in 1994, and you'll see it's pretty closely divided, even back then. > It has worked quite well for us for the better part of the 25 years > that IPv4 has been around. Lots of kludges and/or bad ideas work OK in small systems, and fail to work as well as the the system gets larger. For a lot of things, almost anything would have worked for the first N years of IPv4 - and did, all over the place. Examples are legion. Our crappy original TCP retransmission algorithms worked fine for many years - until they didn't, at which point we were in trouble until Van Jacobsen fixed them. Allocating addresses to end-sites without caring about who their provider was, worked fine until 1990 or so, when we had to change that with CIDR. Etc, etc, etc. This one's day has finally come, is all. Too bad the necessity of fixing it wasn't accepted earlier, when doing so would have been a lot less painful. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 20:04:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zDL-0003a7-B5; Tue, 16 Jan 2007 20:03:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zDJ-0003X2-5J for ram@iab.org; Tue, 16 Jan 2007 20:03:41 -0500 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6zDE-0004wf-GB for ram@iab.org; Tue, 16 Jan 2007 20:03:41 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1H6zD6-0003LH-6H; Wed, 17 Jan 2007 01:03:28 +0000 Message-ID: <45AD7607.1070501@dial.pipex.com> Date: Wed, 17 Jan 2007 01:04:07 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [RAM] Consequences of needing route micro-management (long) References: <45ABE315.6070307@dial.pipex.com> <091a01c739b7$a92f0d60$6701a8c0@china.huawei.com> In-Reply-To: <091a01c739b7$a92f0d60$6701a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Mark Allman , RAM X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks for pointing this out. I hadn't come across this work. This would help the transition for TCP/SCTP assuming it is effective. However, the multipath problem as stated has other issues (cf RFC 2991) - potentially variable MTU, non-deterministic RTT and these would still be a problem for TCP I fear. Actually I suspect the MTU issue is probably not that serious, but the non-deterministic RTT would certainly upset current TCP algorithms. In the meantime, I have been checking up to see what, if anything, is going on in the research community on *inter-domain* multi-path routing. The vast majority of work is either for intra-domain siuataions or ad-hoc radio networks. There are 3 or 4 sightly interesting papers that I can find. Section 5 of http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/bananas-jcn04.pdf has some thoughts on how you might be able to adapt BGP. This paper is referred to in this TUCS report (http://www.tucs.fi/publications/insight.php?id=tLofman05a) which is a very interesting paper. It discusses the RTT issue noted above and suggests some ways to approach a solution. Jen Rexford and Wen Xu have an overlay story (MIRO - http://www.cs.princeton.edu/~jrex/papers/multipath06.pdf) but this is not really what we are looking for. A multipath distance vector algorithm is described in http://www.soe.ucsc.edu/research/ccrg/publications/vutukury.info01.pdf Regards, Elwyn Spencer Dawkins wrote: > Hi, Elwyn, > > Just to follow up on the transport aspects of your thoughtful note > (http://www1.ietf.org/mail-archive/web/ram/current/msg00453.html). > > TCP did not start out caring about out-of-order delivery. As long as > you got an ACK in less than Retransmission TimeOut (RTO) time, any > order of delivery for either payload packets or ACKs was fine. > > TCP became sensitive to out-of-order delivery with Fast > Retransmit/Fast Recovery - instead of waiting for RTO, we added a hack > that said "when we receive N-many ACKs that don't fill in a 'hole' in > the sequence number space, it's likely that we lost a packet, so we > should retransmit". The problem is that if you reorder packets by more > than N-many, the sender will see enough duplicate ACKs to decide that > a packet was lost, in less than RTO time - and TCPs Fast-Retransmit > the apparently-missing packet, and then Fast-Recover by cutting the > congestion window in half ("Fast" is not a misnomer here, it's less > drastic than Slow-Starting from CWND=1). > > N-many is 3 duplicate ACKs (4 ACKs total) in current-standard TCP. > Mark Allman and friends have been working on dynamically adjusting > N-many (Non-Congestion Robustness, NCR, recently published in > http://www.icir.org/mallman/papers/rfc4653.txt), so there's nothing > written in granite that we couldn't CHANGE the way TCP works (or SCTP > either, for that matter). The idea, roughly, is to come up with a > value of N-many that works over a specific path, instead of always > using the same value as we do today. If you see new ACKs coming back > after 6 duplicate ACKs, you assume that N-many should be increased > from 3, for example. > > So some of the work on "relaxing nearly in-order delivery constraints" > has already happened. It may be that routers could stop worrying about > reordering microflows for at least TCP/SCTP traffic, at some point in > the future. > > Thanks, > > Spencer > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 20:40:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zlj-0004zj-Vw; Tue, 16 Jan 2007 20:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zlj-0004zd-8X for ram@iab.org; Tue, 16 Jan 2007 20:39:15 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6zlh-0002ZG-TY for ram@iab.org; Tue, 16 Jan 2007 20:39:15 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Jan 2007 17:39:13 -0800 X-IronPort-AV: i="4.13,198,1167638400"; d="scan'208"; a="759512827:sNHT46619848" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0H1dDJE011681; Tue, 16 Jan 2007 17:39:13 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0H1d6Go005062; Tue, 16 Jan 2007 17:39:07 -0800 (PST) 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.1830); Tue, 16 Jan 2007 17:39:06 -0800 Received: from [171.71.55.219] ([171.71.55.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 17:39:06 -0800 In-Reply-To: <45ABE315.6070307@dial.pipex.com> References: <45ABE315.6070307@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13658D2A-2D24-4315-9646-7C1994231062@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Consequences of needing route micro-management (long) Date: Tue, 16 Jan 2007 17:39:06 -0800 To: Elwyn Davies X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jan 2007 01:39:06.0070 (UTC) FILETIME=[466E4760:01C739D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2709; t=1168997953; x=1169861953; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Consequences=20of=20needing=20route=20micro-m anagement=20(long) |Sender:=20; bh=+Uzw8l9aHRwwAafCtCvqcmR7wq/614weYrjSZSiAx8w=; b=sFQfvOl4fEbtqdAgabfMNWKM/ybrfH0vH//3wXF8ba9P7nXbnu0Yh8kQQnsltg08JrmvUi0R AiRSX9hIK4Scat+eOk4YT+G/E0tyEk0mMUDI/Q1Wltf2bYJY/doJLG/K; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: RAM X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Elwyn, > The result is that routers need to micro-manage the flow of every > packet even in the core of the network. More precisely, the routers attempt to ensure that packets belonging to a single TCP connection always follow a single path. The typical approach to doing this in the face of multiple paths is to hash the source and destination addresses into an index for the path table. > They need to be supplied with a fully specified route from source > to destination applicable to every packet that goes past. Full path information is a result of BGP's loop-prevention algorithm, and is not related to the need for near-perfect ordering. I'll point out that the Internet has been run successfully (for some values of success ;-), on an entirely different distance-vector algorithm without full path information. > In a meshy network, with multiple paths that are equivalently > effective at delivering the packet, this may be very inefficient > and require more complex hardware than is desirable. It > effectively introduces (more) state into the control plane of the > network core contrary to Internet principles. Nit: the hashing process exists in the forwarding/data plane. > One of the identified shortcomings of the existing inter-domain > routing system is that information is propagated further than is > desirable. Put another way, a requirement identified for a next > gen routing system is locality of information dissemination. I don't think that this is a supportable, practical requirement. As we can see from current practice, we know that if there is economic benefit to violating the locality of information dissemination, it will, in fact happen. Now, the obvious alternative is to legislate additional dissemination out of existence, but that then creates a large deployment disincentive. > Does multi-path routing help? A hypothesis. > =========================================== > > It has been my belief (and this was not backed up by proof, and > still isn't fully) that a number of the problems that the Internet > is suffering are caused by the need to use single tree-like > hierarchies for fundamental structures, such as addressing. It > appears to me now that it would be worth investigating whether > relaxing the transport-imposed in-order delivery constraint would > allow the Internet to use multi-path routing. Again, you're assuming facts not in evidence. In-order delivery does not constrain us to single path routing. While there are issues getting to true multi-path routing, TCP is *not* the problem. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 20:49:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zvj-0000Jt-N3; Tue, 16 Jan 2007 20:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zvi-0000Gz-2F for ram@iab.org; Tue, 16 Jan 2007 20:49:34 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6zve-0004qa-Pt for ram@iab.org; Tue, 16 Jan 2007 20:49:34 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2007 02:49:31 +0100 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0H1nS40006516 for ; Wed, 17 Jan 2007 02:49:29 +0100 Received: from [64.104.66.182] (dhcp-64-104-66-182.cisco.com [64.104.66.182]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0H1nQU3014447 for ; Wed, 17 Jan 2007 09:49:27 +0800 (CST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] candidate properties of some new name types Date: Tue, 16 Jan 2007 17:48:52 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1373; t=1168998570; x=1169862570; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20; bh=niiziaetJzTM4UrMNPTt4eBih5hJNEXU0PVTW2Na+cA=; b=wJGptBH/wDhUF2JcA7nV86PbYetM8g4DlxJ5nTWMO/GCMzyVVx1ur6dOaoKSMAr834vBK7/1 bNE/la4CKFWm5V+KksIGChJkHhzVCfbWeZAJcc2mYXadmMl9ZPvEDhw6; Authentication-Results: ams-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 16, 2007, at 4:00 PM, Iljitsch van Beijnum wrote: > It's the "overloading is bad" thing that I would call contemporary. > It has worked quite well for us for the better part of the 25 years > that IPv4 has been around. As I said, IPX/CLNP type link handling > isn't bad per se, but I'd rather hang on to the existing way of > doing things until it's clear that an alternative is essential in > solving the problem at hand. I strongly disagree with this - the 'existing way of doing things' is the result of design deficiencies in TCP/IP (both in IPv4, which is understandable, given its origins and the lack of experience with widely-deployed packet-switched networks at the time it was designed; more unforgivably, in IPv6, by which time folks should've known better) which have caused untold difficulties over the last 25 years, and has resulted in many Rube Goldbergian-types of 'solutions' which don't scale and are an operational nightmare today, on the networks we all use every day. It has also resulted in the set of problems we're specifically trying to solve on this list. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 20:58:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H704J-0005ct-RB; Tue, 16 Jan 2007 20:58:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H704I-0005cn-9u for ram@iab.org; Tue, 16 Jan 2007 20:58:26 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H704H-0006ck-0G for ram@iab.org; Tue, 16 Jan 2007 20:58:26 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0H1wOWT020309 for ; Tue, 16 Jan 2007 20:58:24 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0H1wOdQ401016 for ; Tue, 16 Jan 2007 18:58:24 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0H1wNmM009599 for ; Tue, 16 Jan 2007 18:58:23 -0700 Received: from cichlid (wecm-9-67-69-246.wecm.ibm.com [9.67.69.246]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0H1wNIr009575; Tue, 16 Jan 2007 18:58:23 -0700 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l0H1wL59031713; Tue, 16 Jan 2007 20:58:21 -0500 Message-Id: <200701170158.l0H1wL59031713@cichlid> To: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types In-reply-to: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> Comments: In-reply-to RJ Atkinson message dated "Tue, 16 Jan 2007 16:17:16 -0500." Date: Tue, 16 Jan 2007 20:58:21 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ran, > Some candidate properties of names, for consideration. > Locators: > - A Locator names a single sub-network, not an interface or node > (This is similar to a "routing prefix" in current parlance.) Based on some of the followups, is this really the same thing as "IPv6 link"? That is, at any point that connects to the "sub-network", the router can do some sort of address resolution (ARP/ND) to map the identifier into a link-layer address, and then deliver the packet at the link layer? (This is close, but not quite the same as L2 broadcast domain). Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 16 21:53:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H70uf-0005gF-PF; Tue, 16 Jan 2007 21:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H70ue-0005g5-QI for ram@iab.org; Tue, 16 Jan 2007 21:52:32 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H70ud-0000U0-48 for ram@iab.org; Tue, 16 Jan 2007 21:52:32 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id l0H2q8PR017710; Wed, 17 Jan 2007 13:52:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070117134335.05400a00@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 Jan 2007 13:51:57 +1100 To: Roland Dobbins , ram@iab.org From: Geoff Huston Subject: Re: [RAM] candidate properties of some new name types In-Reply-To: References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >I strongly disagree with this - the 'existing way of doing things' is >the result of design deficiencies in TCP/IP (both in IPv4, which is >understandable, given its origins and the lack of experience with >widely-deployed packet-switched networks at the time it was designed; >more unforgivably, in IPv6, by which time folks should've known >better) which have caused untold difficulties over the last 25 years, >and has resulted in many Rube Goldbergian-types of 'solutions' which >don't scale and are an operational nightmare today, on the networks >we all use every day. It has also resulted in the set of problems >we're specifically trying to solve on this list. Any engineered system makes trade-offs of some form or another. The overloaded semantics of an IP address are not in and of themselves deficient or forgiveable or otherwise - they were and are tradeoffs. The problem that we see now is that the deployed network is placing more emphasis on aspects of address semantics that appear to have a negative effect on routing scaleability. I wouldn't call that "bad", or necessarily "good". The point of this posting, however, is somewhat different. Having identified a shortcoming that does not mean that you have also identified the most appropriate solution space. i.e. while the problem may well be expressed as overloaded address semantics, the solution may not necessarily directly involve disambiguating the various semantic properties of an address. Other forms of approach, such as in various forms of overlays and adding layers of indirection are also feasible here. regards, Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 08:44:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7B4D-0004fH-2y; Wed, 17 Jan 2007 08:43:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7B4C-0004fC-8c for ram@iab.org; Wed, 17 Jan 2007 08:43:04 -0500 Received: from eastrmmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7B49-0000nk-Us for ram@iab.org; Wed, 17 Jan 2007 08:43:04 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070117134259.QSTD4144.eastrmmtao05.cox.net@eastrmimpo01.cox.net> for ; Wed, 17 Jan 2007 08:42:59 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id CDhX1W00J0pnMhQ0000000; Wed, 17 Jan 2007 08:41:31 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <200701170158.l0H1wL59031713@cichlid> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <200701170158.l0H1wL59031713@cichlid> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4D28C5F9-D32B-41C0-B651-70C18058F124@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Wed, 17 Jan 2007 08:42:57 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 16 Jan 2007, at 20:58, Thomas Narten wrote: >> Some candidate properties of names, for consideration. > >> Locators: >> - A Locator names a single sub-network, not an interface or node >> (This is similar to a "routing prefix" in current parlance.) > > Based on some of the followups, is this really the same thing as "IPv6 > link"? That is, at any point that connects to the "sub-network", the > router can do some sort of address resolution (ARP/ND) to map the > identifier into a link-layer address, and then deliver the packet at > the link layer? (This is close, but not quite the same as L2 broadcast > domain). (Thomas educated me a bit off-list about what "IPv6 link" means, from RFC-2460.) If I understand that term correctly, the answer is yes, a "Locator" names an "IPv6 link". This does not imply a link-layer with native broadcast facility. For example, a Frame Relay or ATM subnetwork could qualify, as could a link-layer with a native broadcast facility, such as wired Ethernet or wireless Ethernet or HF radio. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 09:17:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BbY-0004pT-RB; Wed, 17 Jan 2007 09:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BbX-0004pI-Rd for ram@iab.org; Wed, 17 Jan 2007 09:17:31 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BbW-0000Wi-Ad for ram@iab.org; Wed, 17 Jan 2007 09:17:31 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0HEHTwk173584 for ; Wed, 17 Jan 2007 14:17:29 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0HEHSd51814698 for ; Wed, 17 Jan 2007 14:17:28 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0HEHSWc028741 for ; Wed, 17 Jan 2007 14:17:28 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0HEHS27028733; Wed, 17 Jan 2007 14:17:28 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA284136; Wed, 17 Jan 2007 15:17:26 +0100 Message-ID: <45AE2FF5.9030401@zurich.ibm.com> Date: Wed, 17 Jan 2007 15:17:25 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-17 01:29, RJ Atkinson wrote: > > On 16 Jan 2007, at 19:00, Iljitsch van Beijnum wrote: >> It's the "overloading is bad" thing that I would call contemporary. > > Shoch and others suggested such overloading was a bad idea MANY years ago. > So the thought that semantic overloading is bad simply is not a new one. > Whether one agrees with the notion or not, it isn't "contemporary" > but instead is long-standing within the Internet community. I can't claim the seniority of Shoch, but when Yakov, Jon and I wrote RFC 2101, we certainly didn't think we were describing *good* developments. One sentence in that RFC apparently remains true: "The exact nature of these identifiers requires further study." In answer to a comment of Noel's, I think we're discussing this here because achieving clarity on the loc/id question will allow clarity on what is feasible to change in routing. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 15:43:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HcO-00014Q-58; Wed, 17 Jan 2007 15:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HcM-00014H-Pp for ram@iab.org; Wed, 17 Jan 2007 15:42:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HcL-00026s-Hl for ram@iab.org; Wed, 17 Jan 2007 15:42:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jan 2007 15:42:46 -0500 X-IronPort-AV: i="4.13,201,1167627600"; d="scan'208"; a="111905583:sNHT46800840" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0HKgjxn018333; Wed, 17 Jan 2007 15:42:45 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0HKghOA029761; Wed, 17 Jan 2007 15:42:43 -0500 (EST) Message-ID: <45AE8A3D.7090104@cisco.com> Date: Wed, 17 Jan 2007 15:42:37 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Geoff Huston Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> In-Reply-To: <7.0.0.16.2.20070117134335.05400a00@apnic.net> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2000; t=1169066565; x=1169930565; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Geoff=20Huston=20; bh=fo7kE0T2x6UsJRY/w5ma1dT4boBIKBPPySf4cVlwbJo=; b=bkQEpHrA2/cKf92kmPH1Db7XuHfIDc00o8NN15bv3HqM8dcjwrFcMakqQhreLbQLnyhWetzE VqKA64WTyjMIXl561C8IZzLpxHV/JZXWMJBwB5b/eoPy1Szz9g+8wL1G; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I strongly disagree with this - the 'existing way of doing things' is >> the result of design deficiencies in TCP/IP (both in IPv4, which is >> understandable, given its origins and the lack of experience with >> widely-deployed packet-switched networks at the time it was designed; >> more unforgivably, in IPv6, by which time folks should've known >> better) which have caused untold difficulties over the last 25 years, >> and has resulted in many Rube Goldbergian-types of 'solutions' which >> don't scale and are an operational nightmare today, on the networks >> we all use every day. It has also resulted in the set of problems >> we're specifically trying to solve on this list. > > Any engineered system makes trade-offs of some form or another. The > overloaded semantics of an IP address are not in and of themselves > deficient or forgiveable or otherwise - they were and are tradeoffs. I think the problem here might be the folks designing the routing system didn't specifically choose the overloading, and probably wouldn't have if they had the choice. Applications writers made the choice, I think, in reality to overload more heavily on the IP address, over time. Since they don't feel the pain of overloading more heavily (rather than less), it's logical they're going to push more work on routing so they can do less work (which is, to some degree, what heavy overloading provides--less work for applications). Maybe we need to figure out a way to join the pain of overloading with the gain from overloading so people can actually see all the tradeoffs, and make intelligent choices about it (?).... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFroo9ER27sUhU9OQRAtmGAJ0amNm6KfesqL7yMWnNi/sYbQMqYgCgjrRf m+Iu40417ZOg9pg0Le42PGY= =bxtG -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 15:45:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HfL-0002Ju-7H; Wed, 17 Jan 2007 15:45:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HfK-0002Jj-4w for ram@iab.org; Wed, 17 Jan 2007 15:45:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HfI-0002WX-PV for ram@iab.org; Wed, 17 Jan 2007 15:45:50 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2007 12:45:48 -0800 X-IronPort-AV: i="4.13,201,1167638400"; d="scan'208"; a="51027958:sNHT43002494" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0HKjmA1019506; Wed, 17 Jan 2007 15:45:48 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l0HKjmVT014488; Wed, 17 Jan 2007 15:45:48 -0500 (EST) Message-ID: <45AE8AF7.2040202@cisco.com> Date: Wed, 17 Jan 2007 15:45:43 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <200701170158.l0H1wL59031713@cichlid> <4D28C5F9-D32B-41C0-B651-70C18058F124@extremenetworks.com> In-Reply-To: <4D28C5F9-D32B-41C0-B651-70C18058F124@extremenetworks.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1099; t=1169066748; x=1169930748; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20RJ=20Atkinson=20; bh=UcvPU5j6dBngYW1wYnnl+d8UfNWz9EgUnwTR+/RNUA8=; b=BMEBaiiXqMoUvOcWV0ElRs+c82lgxcPiSAuAvtz7ggpig/dyjdUdV+3YZuZHFblf2BqdoB9F xsbJbJZV7pwIWPGAxJZVcNpxgGkDcHD9kUlzjCd03QXMQsIiho1J+y/8; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If I understand that term correctly, the answer is yes, > a "Locator" names an "IPv6 link". This does not imply a > link-layer with native broadcast facility. For example, > a Frame Relay or ATM subnetwork could qualify, as could > a link-layer with a native broadcast facility, such as > wired Ethernet or wireless Ethernet or HF radio. Perhaps the connection between the penultimate hop in the network and the final destination (?).... In all cases, the penultimate device is (or should be) the last device to handle the packet with the destination layer 3 address intact. This might be getting too esoteric, though. Just trying to think of another idea for describing it without "smuggling in" the idea of a broadcast link, etc. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFror3ER27sUhU9OQRAjtQAKC00zBTs5h2f2IJQ5EINNBjuPoPYwCfdE/S dRtDB7ci3PijVhdrCnfLeUo= =jGNz -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 17:29:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JHN-0006qD-T9; Wed, 17 Jan 2007 17:29:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JHM-0006pE-CO for ram@iab.org; Wed, 17 Jan 2007 17:29:12 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JHM-00071M-3q for ram@iab.org; Wed, 17 Jan 2007 17:29:12 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0HMTSOL069548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jan 2007 23:29:29 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45AE8A3D.7090104@cisco.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Wed, 17 Jan 2007 23:29:02 +0100 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 17-jan-2007, at 21:42, Russ White wrote: > Applications writers made the choice, I think, in reality to overload > more heavily on the IP address, over time. Since they don't feel the > pain of overloading more heavily (rather than less), it's logical > they're going to push more work on routing so they can do less work > (which is, to some degree, what heavy overloading provides--less work > for applications). > Maybe we need to figure out a way to join the pain of overloading with > the gain from overloading so people can actually see all the > tradeoffs, > and make intelligent choices about it (?).... Let's do a little thought experiment: what if we get all the application writers to change their applications within, say, the next two years, to completely remove any references to IP addresses and strictly use APIs that handle FQDNs. So we get to do whatever we want below the FQDN. Would that allow us to solve the routing scalability problem? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 17 20:18:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LuW-0005eq-D9; Wed, 17 Jan 2007 20:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LuV-0005eg-0F for ram@iab.org; Wed, 17 Jan 2007 20:17:47 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7LuT-0005XO-N9 for ram@iab.org; Wed, 17 Jan 2007 20:17:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jan 2007 17:17:46 -0800 X-IronPort-AV: i="4.13,201,1167638400"; d="scan'208"; a="51045529:sNHT49342024" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0I1HjjF016829; Wed, 17 Jan 2007 20:17:45 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0I1HiOA002098; Wed, 17 Jan 2007 20:17:44 -0500 (EST) Message-ID: <45AECAB2.3010106@cisco.com> Date: Wed, 17 Jan 2007 20:17:38 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> In-Reply-To: <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3504; t=1169083065; x=1169947065; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=i6KySvXvubJRjnznW+w0eEiU+Piy/uvdCcNZ/t0J/7c=; b=OuylBaCHO3X88kfE0zmkRbLDKd8yHpSLjSpjSgqXZx0CG2UM1EjmJpSpOsRZEd/HNllhbMhi Y3CDbpXFe3H26fsgMS+TH2pYX4TIFaNLxr3wjMBJaBmnsHuyLqRbjk4U; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Applications writers made the choice, I think, in reality to overload >> more heavily on the IP address, over time. Since they don't feel the >> pain of overloading more heavily (rather than less), it's logical >> they're going to push more work on routing so they can do less work >> (which is, to some degree, what heavy overloading provides--less work >> for applications). > >> Maybe we need to figure out a way to join the pain of overloading with >> the gain from overloading so people can actually see all the tradeoffs, >> and make intelligent choices about it (?).... > > Let's do a little thought experiment: what if we get all the application > writers to change their applications within, say, the next two years, to > completely remove any references to IP addresses and strictly use APIs > that handle FQDNs. So we get to do whatever we want below the FQDN. > Would that allow us to solve the routing scalability problem? So, what you're saying is: If solving the locator/ID problem could actually have a positive impact on routing, then we should see that impact on routing today. I think it depends on what you think the problem is. To speculate.... If applications never ever contained an IP address, then the application state could be transferred between two different IP addresses. This is, in essence, what we're discussing here, anyway. Consider shim6. In reality, once you think about it, this is all shim6 does, only rather than making the IP address invisible to the application, it makes all possible IP addresses visible to the application, and introduces signaling/tools to keep a session running when the address changes. You're continuing to overloading the ID and locator in the network, and doing the separation at the host. Today, I would argue, there's no separation even at the host. We can argue about where the intelligence required to switch IP addresses on the fly should be, whether it's in the host, or in the network (IE, whether we do the locator/ID split in the network, at some edge, or on the host), but let's not, for the moment, and just assume that since we've opened the door for such magic to exist, it just does. The primary thing you've done with this is destroy the case for PI space. This could collapse the table by making aggregation effective again--modulo longer prefixes advertised for traffic engineering. Looking back at this chain of logic (or illogic, perhaps), it seems to me to all come down to this: Do you believe traffic engineering is the problem? Then we don't care about locator/ID separation. Do you believe PI space is the problem? Then we care about the locator/ID split. Do you believe both are elements of the problem? Then we care to the degree we think "solving" multihoming will make the routing table stabilize, modulo the degree we think traffic engineering is the problem. I'm not claiming to know the answer, just trying to figure out how we can find common ground, and a good structure to wrap around this stuff. We need a razor to apply occam's rule to, perhaps, so we can start making progress. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFrsqxER27sUhU9OQRAovqAJ493iwv2lckE0VDEmOhwaoI34zA4wCfUMVi bYJ0nx6yeE+G8cyyFOqxBB0= =gYyQ -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 06:52:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VnM-000637-A5; Thu, 18 Jan 2007 06:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VnK-00062x-Vn for ram@iab.org; Thu, 18 Jan 2007 06:51:03 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7VnJ-0004tv-M2 for ram@iab.org; Thu, 18 Jan 2007 06:51:02 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0IBp40k081176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jan 2007 12:51:05 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45AECAB2.3010106@cisco.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Thu, 18 Jan 2007 12:50:38 +0100 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 18-jan-2007, at 2:17, Russ White wrote: >> Let's do a little thought experiment: what if we get all the >> application >> writers to change their applications within, say, the next two >> years, to >> completely remove any references to IP addresses and strictly use >> APIs >> that handle FQDNs. So we get to do whatever we want below the FQDN. >> Would that allow us to solve the routing scalability problem? > So, what you're saying is: If solving the locator/ID problem could > actually have a positive impact on routing, then we should see that > impact on routing today. No, I don't think I said that... As some of you may know I'm more skeptical about the virtues of a locator/identifier split than some/ most. Obviously the fact that applications deal with IP addresses makes renumbering and some other things harder, but I'm far from convinced that NOT having applications deal with locators will magically solve everything. Then again, it may solve enough to get us to a more affordable neighborhood on the growth curve. But that will require some new lookup and security stuff. I'm interested to know what others think about this. > To speculate.... If applications never ever contained an IP address, > then the application state could be transferred between two > different IP > addresses. This is, in essence, what we're discussing here, anyway. Right. > Consider shim6. In reality, once you think about it, this is all shim6 > does, only rather than making the IP address invisible to the > application, it makes all possible IP addresses visible to the > application, ??? > and introduces signaling/tools to keep a session running > when the address changes. You're continuing to overloading the ID and > locator in the network, Right. Note that the shim6 protocols could easily be adapted to work with a full loc/id split, but this makes backward compatibility a nightmare and we'd need some way to map from the identifier to the locator set which means complexity and session startup delays. > The primary thing you've done with this is destroy the case for PI > space. Really? It's not just the applications that love to handle IP addresses, it's also all the firewalls and other access restrictions. I don't think this will be enough to wean enterprises off of PI. > This could collapse the table by making aggregation effective > again--modulo longer prefixes advertised for traffic engineering. This is one thing I missed in the meeting report draft: we should be exploring better ways to do traffic engineering. (And also see if we can increase the average packet size on the network.) > Do you believe traffic engineering is the problem? Then we don't care > about locator/ID separation. > Do you believe PI space is the problem? Then we care about the > locator/ID split. > Do you believe both are elements of the problem? Yes. > Then we care to the > degree we think "solving" multihoming will make the routing table > stabilize, modulo the degree we think traffic engineering is the > problem. I thought we were solving multihoming in multi6/shim6 but apparently it needs some more solving... _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 07:15:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WAR-0003Qa-W7; Thu, 18 Jan 2007 07:14:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WAR-0003QV-FH for ram@iab.org; Thu, 18 Jan 2007 07:14:55 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7WAP-0000Ei-Sp for ram@iab.org; Thu, 18 Jan 2007 07:14:55 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0ICEqCM162378 for ; Thu, 18 Jan 2007 12:14:52 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0ICEqFI3268816 for ; Thu, 18 Jan 2007 13:14:52 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0ICEp1t010925 for ; Thu, 18 Jan 2007 13:14:52 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0ICEpiQ010917; Thu, 18 Jan 2007 13:14:51 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA99666; Thu, 18 Jan 2007 13:14:41 +0100 Message-ID: <45AF64A9.6020901@zurich.ibm.com> Date: Thu, 18 Jan 2007 13:14:33 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> In-Reply-To: <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Consider shim6. In reality, once you think about it, this is all shim6 >> does, only rather than making the IP address invisible to the >> application, it makes all possible IP addresses visible to the >> application, > > ??? Iljitsch means, I think "That is the exact opposite of what shim6 does." This isn't the shim6 list, but I think it's impotrtant to clarify this. shim6 presents exactly one identifier-address to the upper layer protocol, regardless of how many locator-addresses are in use at network level. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 07:18:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WDz-0005qJ-Fi; Thu, 18 Jan 2007 07:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WDy-0005qC-1j for ram@iab.org; Thu, 18 Jan 2007 07:18:34 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7WDw-0000qW-K4 for ram@iab.org; Thu, 18 Jan 2007 07:18:34 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0ICIUOY084068 for ; Thu, 18 Jan 2007 12:18:30 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0ICIUjE3043378 for ; Thu, 18 Jan 2007 13:18:30 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0ICIUnt016563 for ; Thu, 18 Jan 2007 13:18:30 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0ICIU4s016539; Thu, 18 Jan 2007 13:18:30 +0100 Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA154834; Thu, 18 Jan 2007 13:18:29 +0100 Message-ID: <45AF6593.5000100@zurich.ibm.com> Date: Thu, 18 Jan 2007 13:18:27 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> In-Reply-To: <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-17 23:29, Iljitsch van Beijnum wrote: > On 17-jan-2007, at 21:42, Russ White wrote: > >> Applications writers made the choice, I think, in reality to overload >> more heavily on the IP address, over time. Since they don't feel the >> pain of overloading more heavily (rather than less), it's logical >> they're going to push more work on routing so they can do less work >> (which is, to some degree, what heavy overloading provides--less work >> for applications). > >> Maybe we need to figure out a way to join the pain of overloading with >> the gain from overloading so people can actually see all the tradeoffs, >> and make intelligent choices about it (?).... > > Let's do a little thought experiment: what if we get all the application > writers to change their applications within, say, the next two years, to > completely remove any references to IP addresses and strictly use APIs > that handle FQDNs. So we get to do whatever we want below the FQDN. > Would that allow us to solve the routing scalability problem? The problem with that thought experiment is that it fails even in thought. There are lots of client/server scenarios where the FQDN of the client is unknown or non-existent. It's the identifier (sic) presented by the transport layer that is known by the server, and which the server may need to refer to 3rd party servers. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 09:05:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XsK-00014K-BF; Thu, 18 Jan 2007 09:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7XsJ-00014F-OM for ram@iab.org; Thu, 18 Jan 2007 09:04:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7XsI-0001bZ-C2 for ram@iab.org; Thu, 18 Jan 2007 09:04:19 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2007 06:04:18 -0800 X-IronPort-AV: i="4.13,204,1167638400"; d="scan'208"; a="51077197:sNHT51372208" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IE4IQ1000353; Thu, 18 Jan 2007 09:04:18 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l0IE4GVT017859; Thu, 18 Jan 2007 09:04:17 -0500 (EST) Message-ID: <45AF7E59.2070308@cisco.com> Date: Thu, 18 Jan 2007 09:04:09 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> In-Reply-To: <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4646; t=1169129058; x=1169993058; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=Tr7yEvINpydLvhHSpuEeUZEiVG4y/TAzLV8dfz8Dj5o=; b=oIlozh3myQIYLnKfVW3J4Du4k+Xna6K7Q6krec1sJs2gigWltY1hs/uA1FZJvm4QSGe+m5e5 MgW/qftOWfVtA7+YXi/wlXoGK+qsvOLy9eitLu6r1qQVV9hWiEdGrp4T; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Consider shim6. In reality, once you think about it, this is all shim6 >> does, only rather than making the IP address invisible to the >> application, it makes all possible IP addresses visible to the >> application, > > ??? > >> and introduces signaling/tools to keep a session running >> when the address changes. You're continuing to overloading the ID and >> locator in the network, > > Right. Note that the shim6 protocols could easily be adapted to work > with a full loc/id split, but this makes backward compatibility a > nightmare and we'd need some way to map from the identifier to the > locator set which means complexity and session startup delays. Looking at it from a "higher level," IMHO, SHIM6 does exactly what NAT does at the firewall (not PAT, NAT). You have: o More than one IP address per host. In the case of NAT, you have one per exit point. In the case of SHIM6, you have... One per exit point. o If an IP address changes, you must have some way to transfer session state from one host ID (since the IP address is the host ID in this case) to another. NAT doesn't really have this capability, while SHIM6 does this at the host. So, from the network's point of view, these two are doing the same thing, it's just a matter of where you are doing it. Don't look at the technical details--consider the traffic flow at the next hop beyond the set of NATs--can you tell the difference between multiple NATs and SHIM6? No. >> The primary thing you've done with this is destroy the case for PI >> space. > > Really? It's not just the applications that love to handle IP addresses, > it's also all the firewalls and other access restrictions. I don't think > this will be enough to wean enterprises off of PI. Perhaps, perhaps not. Today, most Enterprises use NAT to "solve" this problem--they keep their locators consistent within their networks by rewriting them at the edge of their network. This is specifically what Roland was stating--when you put NAT on the host, you end up having to rework all of your access control, security, etc, within the network to rely on identifiers, rather than locators. This is one part of the problem with overloading the two. The real question, IMHO, comes down to: o Should NAT be done at the host? o Should NAT be done in the network someplace? o Should NAT not be done at all? We're probably going to have NAT with us always, so I don't think the third option is very "real." If we put NAT at the host, then we don't really care about the locator/ID split, because NAT's being done at the host. In essence, we've put the locator/ID split in the host, and we have to figure out a way to do all of our network security and traffic engineering/QoS based on the ID, not the locator. If we put NAT in the network, then we care about the locator/ID split within the network--making both visible in the network, because that enables the tools needed to move state between two ID's among various locators, and the tools to relate the two things, from a security/TE/QoS perspective. I'm not saying one is easier, or more preferred, I'm just trying, again, to see how all these things interact, and bringing things out of the "SHIM6 vs xxxx" world. Abstracting the problem into black boxes, so we can see how this thing works, and how we can (realistically) change it. It could be, though, that I'm the only person in the world that sees the similarity here, and how it interplays with the locator/ID split.... :-) >> Do you believe traffic engineering is the problem? Then we don't care >> about locator/ID separation. > >> Do you believe PI space is the problem? Then we care about the >> locator/ID split. > >> Do you believe both are elements of the problem? > > Yes. > >> Then we care to the >> degree we think "solving" multihoming will make the routing table >> stabilize, modulo the degree we think traffic engineering is the problem. > > I thought we were solving multihoming in multi6/shim6 but apparently it > needs some more solving... I'm not certain SHIM6 has been accepted as the solution.... (?) Beyond this, do we really understand, for certain, how "NAT on the host" interrelates to the network infrastructure? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr35ZER27sUhU9OQRAo6oAKDJRaLxAkFGXmbhVNSbX7CEkDPfEwCdFOEd mbOG80zDEp3WeA5Sdco+vtY= =hafz -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 09:22:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Y9L-00046l-Ri; Thu, 18 Jan 2007 09:21:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Y9K-00046A-Hd for ram@iab.org; Thu, 18 Jan 2007 09:21:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Y9J-0004fo-9R for ram@iab.org; Thu, 18 Jan 2007 09:21:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2007 06:21:53 -0800 X-IronPort-AV: i="4.13,205,1167638400"; d="scan'208"; a="51078477:sNHT45936212" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0IELr2e032335; Thu, 18 Jan 2007 09:21:53 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l0IELqVT021970; Thu, 18 Jan 2007 09:21:52 -0500 (EST) Message-ID: <45AF8279.6000600@cisco.com> Date: Thu, 18 Jan 2007 09:21:45 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> In-Reply-To: <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1860; t=1169130113; x=1169994113; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=RGyAsOZOlPf4keCN4DAvn83kvGxc2aCgXFKPo5dBTFk=; b=kKRx+DsSNIM+hCIV91mJKoilA7qMJQ6FnKuGaEUKkDWqIsrXOyeInbg+mkerzJ8YazfS8Rr/ teeSOxufj//6x7E2qrZkZ6HjipILfLZXboR0wFclzOjq/NWM2m1wpyUh; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The primary thing you've done with this is destroy the case for PI >> space. > > Really? It's not just the applications that love to handle IP addresses, > it's also all the firewalls and other access restrictions. I don't think > this will be enough to wean enterprises off of PI. BTW, I thought I'd also ask about this one.... Perhaps it's different in Europe, but in the US, I don't know of any enterprises running their hosts on PI space. The networks I've touched recently include Disney/ABC, Cabelas, Walmart, Walgreens, Wachovia, WAMU, Citigroup, and a few dozen others, and they're all running on nonroutable address space behind a bunch of NATs. All of these would be PI if it weren't for NATs. So, it seems to me that splitting the location from the ID would have a large impact on the need /desire for PI space. Most of the enterprise folks I know have just a couple of requirements in regards to IP addresses: 1. Don't change them. 2. Give me a lot. 3. Make it so I can reach things outside my network. There's nothing in that list about having a globally routable IP address on a specific host--reachability is the requirement, not routability. Is other folk's experience really completely the opposite of this? Are there a lot of enterprise's out there screaming for PI space who can't get it? It would be interesting to actually look at the statistics for PI space assigned over time, to compare the percentage of space being assigned to enterprises/SP's. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr4J5ER27sUhU9OQRAspGAJ9mrtnqQ1YIYBbW2CraLl3PgjpY2QCfehH+ BN+iomwF4KTQt/NyOBTnp4Q= =E3T4 -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 09:25:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YCt-000579-Nh; Thu, 18 Jan 2007 09:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YCr-00056s-5Y for ram@iab.org; Thu, 18 Jan 2007 09:25:33 -0500 Received: from clifford.inescn.pt ([192.35.246.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YCp-00063O-BO for ram@iab.org; Thu, 18 Jan 2007 09:25:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by clifford.inescn.pt (8.13.8/8.13.8/1) with ESMTP id l0IEPPUj007560; Thu, 18 Jan 2007 14:25:25 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from clifford.inescn.pt ([127.0.0.1]) by localhost (clifford.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ieDqyh42d0+7; Thu, 18 Jan 2007 14:25:05 +0000 (WET) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by clifford.inescn.pt (8.13.8/8.13.8/9) with ESMTP id l0IEOh7X007514; Thu, 18 Jan 2007 14:24:43 GMT Received: from Globo (wlan-keskonrix.inescn.pt [194.117.25.53]) by pong.inescporto.pt (Postfix) with ESMTP id 5FC9015B64B; Thu, 18 Jan 2007 14:24:43 +0000 (WET) From: "Rui Campos" To: "'Brian E Carpenter'" , "'Iljitsch van Beijnum'" Subject: RE: [RAM] candidate properties of some new name types Date: Thu, 18 Jan 2007 14:24:39 -0000 Message-ID: <001001c73b0c$64156ac0$351975c2@Globo> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45AF6593.5000100@zurich.ibm.com> Thread-Index: Acc6+ww+njmSNQU4TE+8RWaoOO06SgACH55g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108850140==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============0108850140== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000C_01C73B0C.62958180" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C73B0C.62958180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, I have been following the discussions in this list and I just would like to comment this FQDN issue. IMHO, even if FQDNs are used as identifiers for hosts things will not work properly, at least without modifying the way FQDN assignment works in the current Internet (probably that's the your idea, I'm not sure). Let's consider a host H that attaches itself to different domains along the time. While H is attached to the same domain (e.g., domain1.com.) its FQDN does not change. Then, H can be uniquely identified by a peer host even if its IP address changes, assuming that the mapping FQDN <-> IP address is handled properly. However, when H moves between different domains the FQDN will change at the same pace. For instance, at instant 1 H gets connected to domain1.com and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and its FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to domain3 and its FQDN becomes "H.domain3.com". Therefore, every session bound to an FQDN will break when the host moves from one domain to the other. On the other hand, how does a peer host will get informed about the current host's FQDN? If we consider multi-homed hosts (i.e., hosts with multiple network interfaces) the problem is even exacerbated. In fact, multi-homed hosts may have an FQDN per network interface. Then, what FQDN will a peer host use to contact a multi-homed host? There is not a single FQDN that uniquely identifies the host regardless of its location and number of network interfaces. BR, Rui Campos -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: quinta-feira, 18 de Janeiro de 2007 12:18 To: Iljitsch van Beijnum Cc: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types On 2007-01-17 23:29, Iljitsch van Beijnum wrote: > On 17-jan-2007, at 21:42, Russ White wrote: > >> Applications writers made the choice, I think, in reality to overload >> more heavily on the IP address, over time. Since they don't feel the >> pain of overloading more heavily (rather than less), it's logical >> they're going to push more work on routing so they can do less work >> (which is, to some degree, what heavy overloading provides--less work >> for applications). > >> Maybe we need to figure out a way to join the pain of overloading with >> the gain from overloading so people can actually see all the tradeoffs, >> and make intelligent choices about it (?).... > > Let's do a little thought experiment: what if we get all the application > writers to change their applications within, say, the next two years, to > completely remove any references to IP addresses and strictly use APIs > that handle FQDNs. So we get to do whatever we want below the FQDN. > Would that allow us to solve the routing scalability problem? The problem with that thought experiment is that it fails even in thought. There are lots of client/server scenarios where the FQDN of the client is unknown or non-existent. It's the identifier (sic) presented by the transport layer that is known by the server, and which the server may need to refer to 3rd party servers. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram ------=_NextPart_000_000C_01C73B0C.62958180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOFTCCBlkw ggRBoAMCAQICASMwDQYJKoZIhvcNAQEFBQAwejELMAkGA1UEBhMCUFQxFDASBgNVBAoTC0lORVND IFBvcnRvMQwwCgYDVQQLEwNVVE0xHzAdBgNVBAMTFklORVNDIFBvcnRvIC0gVVRNIC0gQ0ExJjAk BgkqhkiG9w0BCQEWF2NhbWFuYWdlckBpbmVzY3BvcnRvLnB0MB4XDTA2MDQxMjIwMzQ0M1oXDTA3 MDQxMjIwMzQ0M1owgZcxCzAJBgNVBAYTAlBUMRMwEQYDVQQDEwpSdWkgQ2FtcG9zMTIwMAYDVQQL EylDb21tdW5pY2F0aW9uIE5ldHdvcmtzIGFuZCBTZXJ2aWNlcyBHcm91cDEMMAoGA1UECxMDVVRN MRQwEgYDVQQKEwtJTkVTQyBQb3J0bzEOMAwGA1UEBxMFUG9ydG8xCzAJBgNVBAUTAjM1MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCS2YXjry7ovnvZvKE9cLo7e2r9OMmJQvw+1KrIjVkM/9fr R99M4CKYWaC2rjTowrR8b2qNifN3hSvhPkFi2/9Hop1PNquD/BW+RdagwLDhf3dz9rhoJeWtAXq8 B/8aBU+TQtFcjLXWvZTilZ1KtVSVkLTM22nTd31TeHANmjUHfQIDAQABo4ICTjCCAkowCQYDVR0T BAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAuBglghkgBhvhCAQ0EIRYfVXNlciBDZXJ0aWZpY2F0ZSBv ZiBJTkVTQyBQb3J0bzAdBgNVHQ4EFgQUngwWtz0W91KkxriNNq1H5cszxj4wgawGA1UdIwSBpDCB oYAU8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVT QyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYw JAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMCAGA1UdEQQZ MBeBFXJjYW1wb3NAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0 by5wdDA4BglghkgBhvhCAQQEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNy bC5jcmwwOAYJYIZIAYb4QgEDBCsWKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2Fj cmwuY3JsMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwv Y2FjcmwuY3JsMA0GCSqGSIb3DQEBBQUAA4ICAQCVHY7N2+xLb93mIrUY15stGEDNgGwlijil/QF6 LhYTFlw4plTT+Dw6UUuKTJIsCVj6uc2FVKBJLXOo8v55ZQYCioi0Lx/GWPRHZ27kwim+BkTIR7OH Mb0cU+yYjEhmCshJBtU2VmSsy3bU2EyjHqbUGEhTUSiFNBXLrkEXC3ubSKvGRY7UR6wZZFOT04V3 DhjKm4nlvZ65dp0/PglSGB0Y+gFwp6yRT4tQ3swGPb13iBreUnPMXyA9boeRF6wVNJIZEzQzUpPq /gXNzdMPsbo/5w09NAn0QaiGP0LaCizBQDGB91/LC7LyfpIY4DKWWaw4TGDWU5vweo3KMdhnoBuM tkMC0/9yxHXqfLrf35q7eBv01KhmIj+qfV3NWgtVVJczQxjtv97g9tjOTYMhEYOLInP82i7jUAEu 3bgn2lP23g0xJXgNGJzQ53s8SvAbp6r0vYpOCie/UAz0FV/aH9ffaZf8sHxEkk5x6k6SPp2FfsD9 CpQ8HqiJtjTX2gw3DEIGzDzcaZQ1OZz+5IjbWtmGvKhbT2dwNckKEt16fmnLgnlBxizwtoMKkMe8 4+xvA/B2M/EGhNYcO0qUGe6tMlMEESQqR3/uBmo1leTA6A9aMC6sPFMO1NCesX3MU+PDCT96/yie LGa+EQwYKQxhHFuvK7O/rI+pG8zcqPmD7iFGRzCCB7QwggWcoAMCAQICCQDEsugO8N0ZQjANBgkq hkiG9w0BAQUFADB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsT A1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2Ft YW5hZ2VyQGluZXNjcG9ydG8ucHQwHhcNMDUwNjE5MTQxNDEwWhcNMjUwNjE0MTQxNDEwWjB6MQsw CQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMW SU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9y dG8ucHQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCd0K8k93BTIHVOeXdtuBf9fY7w wyDUsi0z5B4ma5V3w0Pve2Sb4H2NYu4XVrzqMP/DPX3LmPvoaBXsNFvhyoxr0Aa+fpQB5tO7zlVl jdM5mhWo9lvM8v6r6UEoadBoR6gm/Fc/mybZlH8QaACWPTLYwSXdONvd60hR72m5V4m3RHmyWSs6 ruUPDI0BEgU2fBgiykqQM87QGLXkWz5t7L2Ty0PLNb5+dkNGSWA+6eYViqq1qd+vgVq/biRCqt/m xvrjnbOOnTsU2FQlxXzK5n+CFpr4YMlQISXKz2hqlwO+rcK5sW8gQ/UbgqNPuqwejqrsz62ShyXd 6UFP3kDtHLBwV6SrJy1husupYqdDcdLrDHXs1iRq6JdWc6gFusolRicXEglmSYbnazAkuq/lO+xn xUWMN5fXrk9FqwUFBVHKFJ+BsDmqimBKT8IMlXI0xFq7N/7ASpFNH/2jc9zy6ybdJbDO3a7x7mWC 1VIFfZDl+Cly8z/JbF5bc2ZUkIm2GnjM7s12nR7tDwRxeJV4SgYfoB2/oYFzMfSPegHatFrpyQYh wD8BDW4IZMf9eR9iG1foNOeS8kx4K7ecSF/PhOdvxyuS4ZTDaAr4QDNzZhROuQna1tAilYb5hQIY HzR0/L3Zm9x+cXQAMzJeWB5Cuviafz4VDROw7l2AZNbptUQ1BQIDAQABo4ICOzCCAjcwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU8gsrHnNGEQNPNZjAmg14KoqtJsgwgawGA1UdIwSBpDCBoYAU 8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVTQyBQ b3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYwJAYJ KoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMAsGA1UdDwQEAwIB BjAiBgNVHREEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFn ZXJAaW5lc2Nwb3J0by5wdDARBglghkgBhvhCAQEEBAMCAAcwPgYJYIZIAYb4QgENBDEWL0lORVND IFBvcnRvIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IENlcnRpZmljYXRlMDoGA1UdHwQzMDEwL6At oCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2FjcmwuY3JsMDgGCWCGSAGG+EIB BAQrFilodHRwOi8vcmEuaW5lc2Nwb3J0by5wdC9wdWIvY3JsL2NhY3JsLmNybDA4BglghkgBhvhC AQMEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNybC5jcmwwDQYJKoZIhvcN AQEFBQADggIBAGT5Id7wFvMAuow44xm8oDDEgw94+HwFCiTKTNA9Xa5fO7QjKGWQCe+rXi69q2cy TW598Kgs4pdwQ8oHNEGIuCpIUjpBc1YH7M/injXlnBKK7XOw1/pBEu79lPJvMFS5Lf5NlRIEJW2x tBvduSbRNUB3DZ7RWXMthhMu0WoN94O4TRukNNioeK8thy6C0ch45d1LoVsNylY+KpoV0IFi4efS UY1wkJPrEsTDeeUQZGeqG679ycp3H/5N9NSg7cpFTom3k9M0+ICqvdIZYQCg/XczM/PWTC2hnqbZ o1ppSIF0dgFoZ4VpggjPs3d2MvQzVDELRclgp4/082PI3jgtbieBz5BKvSOh7DrEUdGpY4DJ4A6J Gz94BAnpNCjy0qLIrd/+2GyFCakvzl+ggVcx7ZhapkqBrEXuHA311YxtTOHSJeWDvnnbPUXOf3r+ 30m3VtVFKvwJ/i1EW39cDLpSX9Ny04zRaAbczp3I1eZe4Xjgh1atgAxQxS4SmArcCaI4583U4vcE s+skeJQXCuMO9JwrtNR4ZNSiaAnNYZbVlguHeQ+cKjTrjxYn3agkbJoJDFEHw2YRrpBqZcdwS2ZO Ud4ThL7DtkBEcKWzCd0aFNSR67NAwsiBALv1h1MCwr2RRN96ltvtXH9izDL52h8btdbknqAxT9us nUELzIjgG+fPMYIDFTCCAxECAQEwfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9y dG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqG SIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwCQYFKw4DAhoFAKCCAewwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE4MTQyNDM4WjAjBgkqhkiG 9w0BCQQxFgQUM5QiUirTwlEtSwdknDykYa0MvEAwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgY8GCSsGAQQBgjcQBDGBgTB/MHoxCzAJBgNVBAYTAlBUMRQw EgYDVQQKEwtJTkVTQyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAt IFVUTSAtIENBMSYwJAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdAIBIzCBkQYL KoZIhvcNAQkQAgsxgYGgfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAK BgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJ ARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwDQYJKoZIhvcNAQEBBQAEgYBVvqrwux7xlL/V ++foVZTg1uttVmx4hhvq1EhyBq3POKRYwxpUdItR36Jt2OtPbDhuhMa1uTww7wBVTVeML+DcQLtn odbIVldTY1j+JgCiED3ndaBMVNCq/bMC4xJ4WbJmLde7RM1HV+uOulTQa7CJvXbEZ6mcEAeZY4AX zNcnwgAAAAAAAA== ------=_NextPart_000_000C_01C73B0C.62958180-- --===============0108850140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0108850140==-- From ram-bounces@iab.org Thu Jan 18 09:33:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YKC-0003WA-6M; Thu, 18 Jan 2007 09:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YKA-0003SY-Ev for ram@iab.org; Thu, 18 Jan 2007 09:33:06 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YJo-0007PT-04 for ram@iab.org; Thu, 18 Jan 2007 09:33:06 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0IEWhbf191690 for ; Thu, 18 Jan 2007 14:32:43 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0IEWg721691726 for ; Thu, 18 Jan 2007 14:32:42 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0IEWgcg025349 for ; Thu, 18 Jan 2007 14:32:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0IEWgQs025334; Thu, 18 Jan 2007 14:32:42 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA321242; Thu, 18 Jan 2007 15:32:41 +0100 Message-ID: <45AF8508.6060103@zurich.ibm.com> Date: Thu, 18 Jan 2007 15:32:40 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Russ White Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF7E59.2070308@cisco.com> In-Reply-To: <45AF7E59.2070308@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-18 15:04, Russ White wrote: ... > Looking at it from a "higher level," IMHO, SHIM6 does exactly what NAT > does at the firewall (not PAT, NAT). You have: > > o More than one IP address per host. In the case of NAT, you have one > per exit point. In the case of SHIM6, you have... One per exit point. > > o If an IP address changes, you must have some way to transfer session > state from one host ID (since the IP address is the host ID in this > case) to another. NAT doesn't really have this capability, while SHIM6 > does this at the host. > > So, from the network's point of view, these two are doing the same > thing, it's just a matter of where you are doing it. Don't look at the > technical details--consider the traffic flow at the next hop beyond the > set of NATs--can you tell the difference between multiple NATs and > SHIM6? No. I believe they are isomorphic at that point. They are not isomorphic to the upper layer protocol, because it sees the identifier preserved in one case and munged in the other, and that is basically all that is wrong with NAT. Shim6 is reversible NAT. I think from an upper layer PoV, any kind of reversible NAT is basically OK. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 09:43:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YTi-0001Xk-DW; Thu, 18 Jan 2007 09:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YTh-0001Xf-Np for ram@iab.org; Thu, 18 Jan 2007 09:42:57 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YTf-0001Dk-FO for ram@iab.org; Thu, 18 Jan 2007 09:42:57 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 09:42:56 -0500 X-IronPort-AV: i="4.13,205,1167627600"; d="scan'208"; a="111957271:sNHT46357884" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IEgtic012406; Thu, 18 Jan 2007 09:42:55 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0IEgrOA027380; Thu, 18 Jan 2007 09:42:54 -0500 (EST) Message-ID: <45AF8766.3070208@cisco.com> Date: Thu, 18 Jan 2007 09:42:46 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> In-Reply-To: <45AF8508.6060103@zurich.ibm.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1595; t=1169131375; x=1169995375; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=+Ecs8xiGQTpOS+4SxA27SHUDCBNo9ulJbFFcLAZJ+1w=; b=Iic4PV2R5q7HwdwCCkFCGcTOq62Y/Y4LNe8PLKryfDUwi2yjU29ql6RKedFjnketbcOxI93r IOGtF0CdyP7kzRM3MeEN/9Ugs2HpHL2b1yvrwBgLl+YOUEv+SibrThIg; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> So, from the network's point of view, these two are doing the same >> thing, it's just a matter of where you are doing it. Don't look at the >> technical details--consider the traffic flow at the next hop beyond the >> set of NATs--can you tell the difference between multiple NATs and >> SHIM6? No. > > I believe they are isomorphic at that point. They are not isomorphic > to the upper layer protocol, because it sees the identifier preserved > in one case and munged in the other, and that is basically all that > is wrong with NAT. > > Shim6 is reversible NAT. I think from an upper layer PoV, any kind > of reversible NAT is basically OK. Right--so, if you put "magic" in the network to make all NAT reversible, then it's all okay, correct? Isn't this, in the end, the same thing any locator/ID split accomplishes? That's what I was trying to get to.... Iljitsch asked what the impact of having a locator/ID split would be, and my speculative reply is--about the same as NAT, I'm guessing, because they are similar in what they do, when you look at it from the network's point of view. If we look at the impact of NATs today, it's large, so I'd guess a locator/ID split would have a pretty large impact, as well. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr4dmER27sUhU9OQRAmnkAKD+nXvYN9+B499oUphRayn0x8rZ4gCfW+zG rGM6DISgryCzaOIrP5BV7GU= =vOcV -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 10:27:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZAA-0006oT-HC; Thu, 18 Jan 2007 10:26:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZA9-0006oO-SV for ram@iab.org; Thu, 18 Jan 2007 10:26:49 -0500 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7ZA7-0008Rn-I0 for ram@iab.org; Thu, 18 Jan 2007 10:26:49 -0500 Received: (qmail 50201 invoked by uid 60001); 18 Jan 2007 15:26:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=VljXMmBuGuZ5Pr+OBxX8TcG7EspFuxRU8e+hC2EAuxN69pJQJqZ+JpXYopzZ+YHnB0z6onjYwnak1v52QcRTP5DcIwTKmd0H2iutjM4f4ZmhXD8Hlvi0gN7BYfCYwBENTwmOY515PsUmsZSV5HFU0JWXYTSb1Z2asY7j7+KBy9g=; X-YMail-OSG: JbRUtsIVM1lJs4QEVucWIyG3S_BZKA9kO7WhyYKJUVM6LlDqBffQMmgQDO3l5rxrYDzDhgGmfllHrBfFYcu93fuh31YSPx4AZtO.gYis1ZfT5ZTlGm_XgKNeZjREPYufO3Yz895y2t6VscMiijXe90nXqRlres6vG3I7mggBjK3Ik_C7rUEkfAd1r5g- Received: from [207.107.50.100] by web58701.mail.re1.yahoo.com via HTTP; Thu, 18 Jan 2007 07:26:46 PST Date: Thu, 18 Jan 2007 07:26:46 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] candidate properties of some new name types To: RJ Atkinson , ram@iab.org In-Reply-To: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <235856.50153.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. An Identifier names the ultimate communicating entity. At the top it is an application. If an interface itself needs to communicate than it gets an ID (in addition to a locator). Otherwise it has a locator only. Thanks, Peter --- RJ Atkinson wrote: > Some candidate properties of names, for consideration. > > > Locators: > - A Locator names a single sub-network, not an interface or node > (This is similar to a "routing prefix" in current parlance.) > - A node may have multiple Locators at the same time (e.g. due > to multi-homing of some sort). > - A Locator is only used for routing and forwarding packets, > except that the last-hop router uses both the Locator and > the Identifier to look up the destination link-layer information > (e.g. MAC address) in the ARP/ND cache inside the router. > > > Identifiers: > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. > - A node may have multiple Identifiers concurrently. > - A node may use multiple Identifiers concurrently, > however a given single transport session must not change > Identifier during the lifetime of that transport session. > - An Identifier is not necessarily globally unique, but has > a very high probability of being globally unique. > - An Identifier is unique within the scope of a given Locator > that it is used with. > - Identifiers, and not Locators, are included in transport-layer > session state. > > > Ran > > > NB: This is *different* than SHIM6. In SHIM6, the semantics of > an IPv6 address are even more overloaded than before SHIM6. > In this concept, Locators have crisp semantics and Identifiers > have different crisp semantics -- no overloading of the same > namespace for multiple purposes. > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 10:54:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Zb4-00024d-Je; Thu, 18 Jan 2007 10:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Zb3-00024O-4R for ram@iab.org; Thu, 18 Jan 2007 10:54:37 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Zb2-0005gA-P7 for ram@iab.org; Thu, 18 Jan 2007 10:54:37 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0IFrsp8084887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jan 2007 16:53:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45AF8766.3070208@cisco.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> <45AF8766.3070208@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Current IP address: id or loc, was: candidate properties of some new name types Date: Thu, 18 Jan 2007 16:53:28 +0100 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Just in case, the elevator RFC for shim6: sessions (also non-TCP) start normally but after some packets the shim layer between IP and the next layer negotiates extra addresses with the correspondent. Afer a failure source/destination addresses are rewritten at the source so the packet can now flow over a different path and at the receiver they're restored so upper layers and applications are none the wiser. On 18-jan-2007, at 15:42, Russ White wrote: >> Shim6 is reversible NAT. I think from an upper layer PoV, any kind >> of reversible NAT is basically OK. > Right--so, if you put "magic" in the network to make all NAT > reversible, > then it's all okay, correct? Can we please move away from using the term "NAT"? A butcher and a surgeon appear to do the same thing at first too, until it turns out that the surgeon sows everything back together at the end and the butcher doesn't. But yes, any transformation that is later reversed is ok. Adding/ removing locators is also a lot like encapsulating layer 3 packets in layer 2 frames. The crucial difference is that in order to map the layer 3 identifiers to the layer 2 locators there needs to be a lookup service. The ones we currently use (ARP/ND) don't exactly scale to internet-wide dimensions. > Isn't this, in the end, the same thing any locator/ID split > accomplishes? That's what I was trying to get to.... Iljitsch asked > what > the impact of having a locator/ID split would be, and my speculative > reply is--about the same as NAT, I'm guessing, because they are > similar > in what they do, when you look at it from the network's point of view. Well, maybe it looks the same when you treat the IP address as a locator and include an identifier somewhere that isn't mangled by the NAT, for instance, with HTTP/1.1 (although this isn't the best example). This also looks remarkably similar to GSE: the site exit router / NAT box rewrites the source routing goop while the identifier stays intact. But for protocols that need to use the IP address as an identifier, NAT is basically a man in the middle attack. NAT is of course a good way to avoid having to renumber large numbers of clients, but it doesn't solve multihoming or the push for PI because you still want stable addressing for the servers. Also, renumbering clients isn't exactly a hard problem anymore without NAT. So the question is: is the IP address an identifier, in which case NAT is evil and we need to add locators below the IP address (which shim6 does but then confuses things by compressing away the original identifiers), or is the IP address a locator, in which case NAT is inconsequential but we need to get applications and protocols to use "real" identifiers instead of IP addresses? I guess this means that the current locator/identifier overload is indeed a problem. Obviously there are some problems with using FQDNs as we know them today as identifiers for the reasons that Brian and Rui mention, but I don't see that as something fundamental. A more important issue with non-locator identifiers is that there must be some way to assert ownership of an identifier. Today, the routing system lends authority to address ownership claims: I receive the packet, therefore this is my address. This isn't perfect, of course, but it works reasonably well. We have HBA/CGA but those don't work with IPv4 and public key crypto methods but those require one of those pesky PKIs and significantly more computation than what's needed today. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 10:58:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Zeh-0003wL-5P; Thu, 18 Jan 2007 10:58:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Zef-0003wE-Cq for ram@iab.org; Thu, 18 Jan 2007 10:58:21 -0500 Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Zed-0006rT-C2 for ram@iab.org; Thu, 18 Jan 2007 10:58:21 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070118155816.LIMW27968.eastrmmtao04.cox.net@eastrmimpo01.cox.net> for ; Thu, 18 Jan 2007 10:58:16 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id Cfwo1W0060pnMhQ0000000; Thu, 18 Jan 2007 10:56:48 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <8D73B1D1-3956-47FF-A651-5EC74F3EF4EF@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Thu, 18 Jan 2007 10:58:16 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [RAM] Overloaded semantics & networking APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier, Russ White wrote: > Applications writers made the choice, I think, in reality to overload > more heavily on the IP address, over time. Since they don't feel the > pain of overloading more heavily (rather than less), it's logical > they're going to push more work on routing so they can do less work > (which is, to some degree, what heavy overloading provides--less work > for applications). Historically, that theory isn't true. The root issue behind applications using IP addresses is timing. Specifically, the BSD Sockets networking API was developed, released, and in significant use several years before the Domain Name System (DNS) was first published in an RFC. So an API that used more appropriate (in conventional Computer Science terms) abstractions -- and data hiding -- wasn't available. This meant that programmers, and importantly *documentation* on writing networked applications, were all focused on the BSD Sockets API, rather than on a more abstract networking API. When the AT&T UNIX, Transport Layer Interface (TLI) came along, it ended up looking more like Sockets than the kind of API one really would want. Then, when Windows came along, they just modified the Sockets API, for the good reason that programmers were sort-of familiar with a Sockets-like API. (A 2nd missed opportunity to fix things.) Had the timing been reversed, likely there also would have been a more abstracted API that changed the objects present in the API, along these lines: - Domain name, instead of IP address - Service name, instead of transport-protocol/port Even today, we lack an appropriately abstract openly specified networking API for C/C++. Java has some that are very nice, so it would be possible to do one for C/C++. Ran PS: There is an IETF sponsored API that is very slightly more abstract, working well over IPv4 or IPv6, but it isn't really as abstract as we really need. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:04:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZkB-0008Br-A7; Thu, 18 Jan 2007 11:04:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Zk9-0008Bi-3y for ram@iab.org; Thu, 18 Jan 2007 11:04:01 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Zk6-0007bI-L6 for ram@iab.org; Thu, 18 Jan 2007 11:04:01 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0IG3v4s223272 for ; Thu, 18 Jan 2007 16:03:57 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0IG3vol1957962 for ; Thu, 18 Jan 2007 16:03:57 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0IG3vps019761 for ; Thu, 18 Jan 2007 16:03:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0IG3uQ1019748; Thu, 18 Jan 2007 16:03:57 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA186852; Thu, 18 Jan 2007 17:03:55 +0100 Message-ID: <45AF9A6A.4040702@zurich.ibm.com> Date: Thu, 18 Jan 2007 17:03:54 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Russ White Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF8279.6000600@cisco.com> In-Reply-To: <45AF8279.6000600@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ, On 2007-01-18 15:21, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>> The primary thing you've done with this is destroy the case for PI >>> space. >> Really? It's not just the applications that love to handle IP addresses, >> it's also all the firewalls and other access restrictions. I don't think >> this will be enough to wean enterprises off of PI. > > BTW, I thought I'd also ask about this one.... Perhaps it's different in > Europe, but in the US, I don't know of any enterprises running their > hosts on PI space. The networks I've touched recently include > Disney/ABC, Cabelas, Walmart, Walgreens, Wachovia, WAMU, Citigroup, and > a few dozen others, and they're all running on nonroutable address space > behind a bunch of NATs. > > All of these would be PI if it weren't for NATs. So, it seems to me that > splitting the location from the ID would have a large impact on the need > /desire for PI space. > > Most of the enterprise folks I know have just a couple of requirements > in regards to IP addresses: > > 1. Don't change them. > 2. Give me a lot. > 3. Make it so I can reach things outside my network. > > There's nothing in that list about having a globally routable IP address > on a specific host--reachability is the requirement, not routability. > > Is other folk's experience really completely the opposite of this? Are > there a lot of enterprise's out there screaming for PI space who can't > get it? It would be interesting to actually look at the statistics for > PI space assigned over time, to compare the percentage of space being > assigned to enterprises/SP's. > > :-) > > Russ I totally agree, but maybe add 4. Make it work 100% without unexplained session failures (In case it isn't obvious, loss of NAT state leading to session failures is an almost undiagnosable occurrence, which most IT departments seem unaware of.) I don't mean to NAT-bash here, there's been enough of that, but we need to have a goal to ameliorate the systemic issues of NAT. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:06:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZmS-0000AH-3E; Thu, 18 Jan 2007 11:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZmQ-00009z-He for ram@iab.org; Thu, 18 Jan 2007 11:06:22 -0500 Received: from eastrmmtao06.cox.net ([68.230.240.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ZmP-0007uL-7W for ram@iab.org; Thu, 18 Jan 2007 11:06:22 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070118160620.SCKG19510.eastrmmtao06.cox.net@eastrmimpo01.cox.net> for ; Thu, 18 Jan 2007 11:06:20 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id Cg4s1W00D0pnMhQ0000000; Thu, 18 Jan 2007 11:04:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Thu, 18 Jan 2007 11:06:19 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [RAM] server referrals X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier, Brian Carpenter said: % The problem with that thought experiment is that it fails even in % thought. There are lots of client/server scenarios where the FQDN of % the client is unknown or non-existent. It's the identifier (sic) % presented by the transport layer that is known by the server, and which % the server may need to refer to 3rd party servers. I don't think there is a real problem with taking a client's identifier (and potentially locator, depending on what layer one does this and sundry implementation choices) to determine the right FQDN. - One can do a reverse lookup on the identifier to get an FQDN (details omitted for now; this is a thought exercise) - Even people without Internet clues now generally have both forward/reverse domain-names associated with their IP address(es). That FQDN might be of the form c123456.hooville.cox.net, but for referral purposes the form of the FQDN doesn't matter. - One can ask the client what it's FQDN is, and even (if desired) then do a forward lookup on the FQDN to validate the claim (details omitted, but consider IP option or ICMP message) So I think we have on-the-shelf solutions for the issue you outline in the quoted text above. It would separately help if you gave a real-world example of where such referrals to 3rd party servers is commonly done today. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:29:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7a7T-0000Fs-42; Thu, 18 Jan 2007 11:28:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7a7R-0000FC-Af for ram@iab.org; Thu, 18 Jan 2007 11:28:05 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7a7O-0003Fi-QM for ram@iab.org; Thu, 18 Jan 2007 11:28:05 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0IGS2QR153320 for ; Thu, 18 Jan 2007 16:28:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0IGS1Wj1908908 for ; Thu, 18 Jan 2007 16:28:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0IGS1wq006249 for ; Thu, 18 Jan 2007 16:28:01 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0IGS1b8006241; Thu, 18 Jan 2007 16:28:01 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA290764; Thu, 18 Jan 2007 17:27:58 +0100 Message-ID: <45AFA00C.9080000@zurich.ibm.com> Date: Thu, 18 Jan 2007 17:27:56 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] server referrals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I'll leave someone like Ted Hardie to respond on practical cases of referrals. As far as reverse DNS lookup goes, there are certainly lots of hosts that don't have one, and can we really build an architecture that depends on something as baroque as reverse DNS? Brian On 2007-01-18 17:06, RJ Atkinson wrote: > Earlier, Brian Carpenter said: > % The problem with that thought experiment is that it fails even in > % thought. There are lots of client/server scenarios where the FQDN of > % the client is unknown or non-existent. It's the identifier (sic) > % presented by the transport layer that is known by the server, and which > % the server may need to refer to 3rd party servers. > > I don't think there is a real problem with taking a client's > identifier (and potentially locator, depending on what layer > one does this and sundry implementation choices) to determine > the right FQDN. > > - One can do a reverse lookup on the identifier to get an FQDN > (details omitted for now; this is a thought exercise) > - Even people without Internet clues now generally have both > forward/reverse domain-names associated with their IP address(es). > That FQDN might be of the form c123456.hooville.cox.net, > but for referral purposes the form of the FQDN doesn't matter. > - One can ask the client what it's FQDN is, and even (if desired) > then do a forward lookup on the FQDN to validate the claim > (details omitted, but consider IP option or ICMP message) > > So I think we have on-the-shelf solutions for the issue you > outline in the quoted text above. > > It would separately help if you gave a real-world example of > where such referrals to 3rd party servers is commonly done > today. > > Yours, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:32:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aBt-0001Ps-If; Thu, 18 Jan 2007 11:32:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aBs-0001Pi-FA for ram@iab.org; Thu, 18 Jan 2007 11:32:40 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7aBq-0003cv-69 for ram@iab.org; Thu, 18 Jan 2007 11:32:40 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 11:32:38 -0500 X-IronPort-AV: i="4.13,206,1167627600"; d="scan'208"; a="111966790:sNHT47626500" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IGWbnL024268; Thu, 18 Jan 2007 11:32:37 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0IGWbOA024621; Thu, 18 Jan 2007 11:32:37 -0500 (EST) Message-ID: <45AFA11E.7040906@cisco.com> Date: Thu, 18 Jan 2007 11:32:30 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] Current IP address: id or loc, was: candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> <45AF8766.3070208@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2536; t=1169137957; x=1170001957; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Current=20IP=20address=3A=20id=20or=20loc, =20 was=3A=20candidate=20properties=0A=20of=20some=20new=20name=20types |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=Qs2TlNIEHuB+9jEo7PVY5zFCU7f0/L+MC+iaYYeD0hg=; b=UDaNJvP2rmPnu/QpjB6IGnPZYjrynnjY+Pv+QsOKdg4T0C6WMveVGA+PT4Hjn9lFqKn/ptno E8xgqMXm5+RrnkKMV56s7tFUQMaNNJ/dz6z1umoKLJkCYbe3MtLZADL1; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Well, maybe it looks the same when you treat the IP address as a locator > and include an identifier somewhere that isn't mangled by the NAT, for > instance, with HTTP/1.1 (although this isn't the best example). This > also looks remarkably similar to GSE: the site exit router / NAT box > rewrites the source routing goop while the identifier stays intact. > > But for protocols that need to use the IP address as an identifier, NAT > is basically a man in the middle attack. Yes.... > NAT is of course a good way to avoid having to renumber large numbers of > clients, but it doesn't solve multihoming or the push for PI because you > still want stable addressing for the servers. Also, renumbering clients > isn't exactly a hard problem anymore without NAT. - From a host perspective, yes, but now we've dropped the entire security problem out of the discussion, again. It's not hosts that are hard to renumber, it's security and infrastructure that make this hard. > So the question is: is the IP address an identifier, in which case NAT > is evil and we need to add locators below the IP address (which shim6 > does but then confuses things by compressing away the original > identifiers), or is the IP address a locator, in which case NAT is > inconsequential but we need to get applications and protocols to use > "real" identifiers instead of IP addresses? Right.... Today we have the two overloaded both in the network and in the host.... > Obviously there are some problems with using FQDNs as we know them today > as identifiers for the reasons that Brian and Rui mention, but I don't > see that as something fundamental. A more important issue with > non-locator identifiers is that there must be some way to assert > ownership of an identifier. Today, the routing system lends authority to > address ownership claims: I receive the packet, therefore this is my > address. This isn't perfect, of course, but it works reasonably well. We > have HBA/CGA but those don't work with IPv4 and public key crypto > methods but those require one of those pesky PKIs and significantly more > computation than what's needed today. Yes.... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr6EdER27sUhU9OQRAtc+AKC1BmiNBIBeQA5m83CW3dqWRpMUugCcCq6i XUf4eKrqimMdNhXS/cmB+Z4= =xPtK -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:34:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aD7-0001dS-CQ; Thu, 18 Jan 2007 11:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aD6-0001c3-1x for ram@iab.org; Thu, 18 Jan 2007 11:33:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7aD4-0003uE-NW for ram@iab.org; Thu, 18 Jan 2007 11:33:56 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2007 08:33:54 -0800 X-IronPort-AV: i="4.13,206,1167638400"; d="scan'208"; a="51089327:sNHT43512432" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0IGXsdU018248; Thu, 18 Jan 2007 11:33:54 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l0IGXrVT025575; Thu, 18 Jan 2007 11:33:54 -0500 (EST) Message-ID: <45AFA16B.4070408@cisco.com> Date: Thu, 18 Jan 2007 11:33:47 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Overloaded semantics & networking APIs References: <8D73B1D1-3956-47FF-A651-5EC74F3EF4EF@extremenetworks.com> In-Reply-To: <8D73B1D1-3956-47FF-A651-5EC74F3EF4EF@extremenetworks.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1001; t=1169138034; x=1170002034; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Overloaded=20semantics=20&=20networking=20API s |Sender:=20 |To:=20RJ=20Atkinson=20; bh=T3roNOzy3BLltmrlf4yfOKrS2DP9C0ixSnDW0qXPZdc=; b=tM1Ny2zbxT5iKBf7YqIMfflkiyt3FaRB2rlIuqhHrL8k5b9LcQSWRF1Z16OYYVHdTgLyousg CJhWT9WR9+ZkMlMIEmsG520T3qMF4ASNtWoM4c4ThHIz0jIJb3hC6QLO; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Applications writers made the choice, I think, in reality to overload >> more heavily on the IP address, over time. Since they don't feel the >> pain of overloading more heavily (rather than less), it's logical >> they're going to push more work on routing so they can do less work >> (which is, to some degree, what heavy overloading provides--less work >> for applications). > > Historically, that theory isn't true. > The root issue behind applications using IP addresses is timing. Well, I'm not certain it matters.... Either way, we are where we are outside the choice the network/routing folks would have probably chosen, I think. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr6FrER27sUhU9OQRArpOAJ0Zd1lAD0V6MPxisOIP9rtUDP/iBwCfXwbZ DaqUqzuCZcBwKmKg2pD8FDQ= =pM7y -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 11:43:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aM1-0003yo-Sq; Thu, 18 Jan 2007 11:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aM0-0003ya-4T for ram@iab.org; Thu, 18 Jan 2007 11:43:08 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7aLy-0005Pc-Tq for ram@iab.org; Thu, 18 Jan 2007 11:43:08 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 11:43:07 -0500 X-IronPort-AV: i="4.13,206,1167627600"; d="scan'208"; a="111967217:sNHT45521572" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IGh614026652; Thu, 18 Jan 2007 11:43:06 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0IGh5OA026103; Thu, 18 Jan 2007 11:43:06 -0500 (EST) Message-ID: <45AFA392.8010700@cisco.com> Date: Thu, 18 Jan 2007 11:42:58 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF8279.6000600@cisco.com> <45AF9A6A.4040702@zurich.ibm.com> In-Reply-To: <45AF9A6A.4040702@zurich.ibm.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=762; t=1169138586; x=1170002586; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=6l5inLczl3Rpp1BgmEz9vYI0FhHIHslG5H+af1s+WRA=; b=JYg/VRUhRH3dUxJX7IDjPVO1sj+2jJmwWg+qhLhk6R81bq0CEDGY6hyKuQ4iP3Pj7EUM5qwX lX22iZ6Gjxp3g7z6eqnJuYDEBSMdnLXHU7K/VRx0l/FJoWR+kKpTcgy0; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I don't mean to NAT-bash here, there's been enough of that, > but we need to have a goal to ameliorate the systemic issues > of NAT. Completely agree... The problem with a loc/ID split is you have to have magic someplace to make the two interrelate. Whether that magic is in the host (such as SHIM6), or in the network (such as mobile IP, to some degree), is up one of the problems we have to figure out. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFr6OSER27sUhU9OQRAhpdAKDNhn1zEWxO5A90qBWYWPk2miJKigCfSnpt ahmbUKFqbLvjJ2m0V1rkdUU= =qgL6 -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 12:23:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7az0-0007VI-Q3; Thu, 18 Jan 2007 12:23:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ayy-0007V9-US for ram@iab.org; Thu, 18 Jan 2007 12:23:24 -0500 Received: from centrmmtao01.cox.net ([70.168.83.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ayw-0000pq-KZ for ram@iab.org; Thu, 18 Jan 2007 12:23:24 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao01.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070118172319.TGQS23868.centrmmtao01.cox.net@eastrmimpo01.cox.net>; Thu, 18 Jan 2007 12:23:19 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id ChMr1W00R0pnMhQ0000000; Thu, 18 Jan 2007 12:21:51 -0500 In-Reply-To: <45AFA00C.9080000@zurich.ibm.com> References: <45AFA00C.9080000@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] server referrals Date: Thu, 18 Jan 2007 12:23:18 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 18 Jan 2007, at 11:27, Brian E Carpenter wrote: > As far as reverse DNS lookup goes, there are certainly > lots of hosts that don't have one, and can we really > build an architecture that depends on something as baroque as > reverse DNS? The current architecture already depends on Reverse DNS working, for LOTS of things, including getting SMTP email delivered. In practice, lots of servers already simply refuse connections from hosts without reverse DNS present. If the main thing that broke for lack of reverse DNS would be server referrals, that would seem fine. After all, the clients that did not work would be in the position to fix the issue that caused the referral to not work as expected. The problem might exist in pockets, but it could be corrected locally and incrementally, so scaling wouldn't be an issue. Most residential ISPs have reverse DNS that works -- globally, because of various pressures unrelated to the topics here (example: security, proving to registries that allocated address space is in use). Even the dialup folks now generally have a working reverse DNS. Neither group did a decade ago, but things are a bit better now, or so I'm told. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 14:19:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cmT-0001UC-It; Thu, 18 Jan 2007 14:18:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cmR-0001Sa-QK for ram@iab.org; Thu, 18 Jan 2007 14:18:35 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7cmQ-0005dU-Qh for ram@iab.org; Thu, 18 Jan 2007 14:18:35 -0500 Received: from HeinerHummel@aol.com by imo-d22.mx.aol.com (mail_out_v38_r7.6.) id r.cc6.887c408 (48624); Thu, 18 Jan 2007 14:18:21 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 18 Jan 2007 14:18:18 EST Subject: Re: [RAM] candidate properties of some new name types To: pesherb@yahoo.com, rja@extremenetworks.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1758994490==" Errors-To: ram-bounces@iab.org --===============1758994490== Content-Type: multipart/alternative; boundary="-----------------------------1169147898" -------------------------------1169147898 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 IMHO: the identifier should name some kind of stack, and the locator as wel= l=20 . But here each part is conceived to be just another IP address.Right ? The= =20 locator is not a combination of AS# + some router's IP address. Right?=20 =20 Heiner =20 =20 In einer eMail vom 18.01.2007 16:27:44 Westeurop=E4ische Normalzeit schreibt= =20 pesherb@yahoo.com: > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. An Identifier names the ultimate communicating entity. At the top it is an application. If an interface itself needs to communicate than it gets an ID= =20 (in addition to a locator). Otherwise it has a locator only. Thanks, Peter=20 --- RJ Atkinson wrote: > Some candidate properties of names, for consideration. >=20 >=20 > Locators: > - A Locator names a single sub-network, not an interface or node > (This is similar to a "routing prefix" in current parlance.) > - A node may have multiple Locators at the same time (e.g. due > to multi-homing of some sort). > - A Locator is only used for routing and forwarding packets, > except that the last-hop router uses both the Locator and > the Identifier to look up the destination link-layer information > (e.g. MAC address) in the ARP/ND cache inside the router. >=20 >=20 > Identifiers: > - An Identifier names a node ("stack" in IRTF NSRG parlance) > and is not tied to a specific interface or location. > - A node may have multiple Identifiers concurrently. > - A node may use multiple Identifiers concurrently, > however a given single transport session must not change > Identifier during the lifetime of that transport session. > - An Identifier is not necessarily globally unique, but has > a very high probability of being globally unique. > - An Identifier is unique within the scope of a given Locator > that it is used with. > - Identifiers, and not Locators, are included in transport-layer > session state. >=20 >=20 > Ran >=20 >=20 > NB: This is *different* than SHIM6. In SHIM6, the semantics of > an IPv6 address are even more overloaded than before SHIM6. > In this concept, Locators have crisp semantics and Identifiers > have different crisp semantics -- no overloading of the same > namespace for multiple purposes. >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > =20 ____________________________________________________________________________= __ ______ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -------------------------------1169147898 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
IMHO: the identifier should name some kind of stack, and the=20 locator as well . But here each part is conceived to be=20 just another IP address.Right ? The locator is not a combination of AS#= +=20 some router's IP address. Right?
 
Heiner
 
 
In einer eMail vom 18.01.2007 16:27:44 Westeurop=E4ische Normalzeit sch= reibt=20 pesherb@yahoo.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>> -=20 An Identifier names a node ("stack" in IRTF NSRG parlance)
> =20   and is not tied to a specific interface or location.

An=20 Identifier names the ultimate communicating entity. At the top it is=20 an
application. If an interface itself needs to communicate than it get= s an=20 ID (in
addition to a locator). Otherwise it has a locator=20 only.

Thanks,
Peter

--- RJ Atkinson=20 <rja@extremenetworks.com> wrote:

> Some candidate properti= es=20 of names, for consideration.
>
>
> Locators:
> -= A=20 Locator names a single sub-network, not an interface or node
> = =20   (This is similar to a "routing prefix" in current parlance.)
>= ; -=20 A node may have multiple Locators at the same time (e.g. due
> = =20   to multi-homing of some sort).
> - A Locator is only used for= =20 routing and forwarding packets,
>    except that the last-= hop=20 router uses both the Locator and
>    the Identifier to lo= ok=20 up the destination link-layer information
>    (e.g. MAC=20 address) in the ARP/ND cache inside the router.
>
>
>=20 Identifiers:
> - An Identifier names a node ("stack" in IRTF NSRG=20 parlance)
>    and is not tied to a specific interface or=20 location.
> - A node may have multiple Identifiers concurrently.
= >=20 - A node may use multiple Identifiers concurrently,
>   =20 however a given single transport session must not change
>  &nb= sp;=20 Identifier during the lifetime of that transport session.
> - An=20 Identifier is not necessarily globally unique, but has
>   = ; a=20 very high probability of being globally unique.
> - An Identifier is= =20 unique within the scope of a given Locator
>    that it is= =20 used with.
> - Identifiers, and not Locators, are included in=20 transport-layer
>    session state.
>
>
&= gt;=20 Ran
>
>
> NB:  This is *different* than SHIM6.&nb= sp;=20 In SHIM6, the semantics of
>       an IPv6 addre= ss=20 are even more overloaded than before SHIM6.
>     &nb= sp;=20 In this concept, Locators have crisp semantics and Identifiers
>&nbs= p;=20      have different crisp semantics -- no overloading of th= e=20 same
>       namespace for multiple=20 purposes.
>
>
>=20 _______________________________________________
> RAM mailing=20 list
> RAM@iab.org
>=20 https://www1.ietf.org/mailman/listinfo/ram
>=20




______________________________________________________= ______________________________
Want=20 to start your own business?
Learn how on Yahoo! Small=20 Business.
http://smallbusiness.yahoo.com/r-index

_______________= ________________________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1169147898-- --===============1758994490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1758994490==-- From ram-bounces@iab.org Thu Jan 18 14:20:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7coe-0002M3-1v; Thu, 18 Jan 2007 14:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7coc-0002Lr-NI for ram@iab.org; Thu, 18 Jan 2007 14:20:50 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7cob-000655-GS for ram@iab.org; Thu, 18 Jan 2007 14:20:50 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id BF2341CC1F; Thu, 18 Jan 2007 14:20:46 -0500 (EST) Date: Thu, 18 Jan 2007 14:20:46 -0500 From: John Leslie To: Brian E Carpenter Subject: Re: [RAM] candidate properties of some new name types Message-ID: <20070118192046.GH16158@verdi> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AF6593.5000100@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AF6593.5000100@zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: > > The problem with that thought experiment is that it fails even in > thought. There are lots of client/server scenarios where the FQDN of > the client is unknown or non-existent. Absolutely! > It's the identifier (sic) presented by the transport layer ^^^^^^^^^^ No. It's the _locator_ presented by the TCP API... It is specifically the locator used by the IP stack to respond to the opening SYN with a SYN ACK to continue opening the TCP connection. Since we've never defined a standard way to pass an _identifier_, this _locator_ is used as a substitute identifier. (It has worked surprisingly well over the years. ;^) > that is known by the server, and which the server may need to refer > to 3rd party servers. Absolutely! If we want to accomplish a locator/identifier split, we will have to standardize a way for the originator of a TCP connection to pass the identifier by which it wishes to be known by the other end. (It wouldn't be hard...) -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 16:45:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7f3z-0008Lr-VN; Thu, 18 Jan 2007 16:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7f3y-0008Lg-Nq for ram@iab.org; Thu, 18 Jan 2007 16:44:50 -0500 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7f3x-0007FN-2u for ram@iab.org; Thu, 18 Jan 2007 16:44:50 -0500 Received: from gihm3.apnic.net (dhcp17.potaroo.net [203.10.60.17]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l0ILiaHR041454; Fri, 19 Jan 2007 08:44:37 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070119083929.01587e48@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 19 Jan 2007 08:44:13 +1100 To: Brian E Carpenter , Russ White From: Geoff Huston Subject: Re: [RAM] candidate properties of some new name types In-Reply-To: <45AF8508.6060103@zurich.ibm.com> References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> <45AECAB2.3010106@cisco.com> <56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com> <45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >I believe they are isomorphic at that point. They are not isomorphic >to the upper layer protocol, because it sees the identifier preserved >in one case and munged in the other, and that is basically all that >is wrong with NAT. > >Shim6 is reversible NAT. I think from an upper layer PoV, any kind >of reversible NAT is basically OK. reversible _deterministic_ NAT. There are two problems in NAT space that make life hard: 1 - the other end gets presented with a different packet header than was sent (i.e. NATs are asymmetric and occluded) 2 - NATs are all different. There is no single NAT behaviour specification The combination of these two factors as what makes life hard for applications. SHIM6 alters this to make the action symmetric and uniform. Of course, tunnelling does the same, as does MPLS and many (if not all other) forms of overlays and indirection. Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 18:13:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gQw-0007zZ-QJ; Thu, 18 Jan 2007 18:12:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gQw-0007zU-B7 for ram@iab.org; Thu, 18 Jan 2007 18:12:38 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7gQu-0003lk-OV for ram@iab.org; Thu, 18 Jan 2007 18:12:38 -0500 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 19 Jan 2007 04:05:07 -0800 X-IronPort-AV: i="4.13,206,1167638400"; d="scan'208"; a="74480025:sNHT62025060" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0INCMNp026505 for ; Fri, 19 Jan 2007 04:42:22 +0530 Received: from [10.31.2.30] (hkidc-vpn-client-234-45.cisco.com [10.75.234.45]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0INCKU3016927 for ; Fri, 19 Jan 2007 07:12:21 +0800 (CST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> References: <45AFA00C.9080000@zurich.ibm.com> <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] server referrals Date: Thu, 18 Jan 2007 15:11:43 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=516; t=1169161942; x=1170025942; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20server=20referrals |Sender:=20; bh=4MFGd7VO63Df8pBrte2oRrPcWRMAhdZapGof0mz3rmc=; b=KRKWQQw7ofdOOBPLCl5xDOAdh76ZrgCNT4kDfbdtAxJQa8xvocvbUEpIYry5Ztm5TWpgmTxq FMOcLB088xG16v7OL6M2NmAjrtxhjBiumkgCR8M98x3+maDbAZox2wk5; Authentication-Results: ind-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 18, 2007, at 9:23 AM, RJ Atkinson wrote: > In practice, lots of servers already simply refuse connections > from hosts without reverse DNS present. This is somewhat true on the global Internet; it is manifestly untrue in private/enterprise networks, unfortunately. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Technology is legislation. -- Karl Schroeder _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 18:55:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7h6I-00064s-O6; Thu, 18 Jan 2007 18:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7h6H-00064n-0r for ram@iab.org; Thu, 18 Jan 2007 18:55:21 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7h6E-0003NK-NG for ram@iab.org; Thu, 18 Jan 2007 18:55:21 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20070118235515.SRPI28701.eastrmmtao03.cox.net@eastrmimpo02.cox.net> for ; Thu, 18 Jan 2007 18:55:15 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id Cntk1W00C0pnMhQ0000000; Thu, 18 Jan 2007 18:53:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <97E7126F-4597-4E99-AFE5-DC0EB0F3CDB3@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Subject: Re: [RAM] candidate properties of some new name types Date: Thu, 18 Jan 2007 18:55:15 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier, Heiner Hummel wrote: > IMHO: the identifier should name some kind of stack, and the locator > as well . But here each part is conceived to be just another IP > address. > Right ? > The locator is not a combination of AS# + some router's IP address. > Right? I am definitely NOT thinking that "each part is just another IP address". My thought is conceptually to deprecate the concept of "address" and instead have distinct locators and identifiers (with different namespaces for each -- so reducing the semantic overloading). The approach where "each part is an IP address" increases, rather than decreases, the semantic overloading. That is also roughly the engineering decision that SHIM6 made. So far, I'm not getting into the details of what might constitute the internal format of a locator. One can imagine a range of very different engineering choices there. For now, O'Dell's term "Routing Goop" certainly is good enough for the locator (keeping the details vague enough to keep our options open). Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 23:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lJX-00041P-O7; Thu, 18 Jan 2007 23:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kvw-0007mE-9N for ram@iab.org; Thu, 18 Jan 2007 23:00:56 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7kvu-0005Wq-Ug for ram@iab.org; Thu, 18 Jan 2007 23:00:56 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l0J40s1Z066088; Thu, 18 Jan 2007 20:00:54 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.164]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l0J40dB64419; Thu, 18 Jan 2007 20:00:53 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070118220946.0459a2d0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 18 Jan 2007 22:51:01 -0500 To: Iljitsch van Beijnum From: Ross Callon Subject: Re: [RAM] candidate properties of some new name types In-Reply-To: <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> References: <45AE8A3D.7090104@cisco.com> <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Thu, 18 Jan 2007 23:25:18 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 11:29 PM 1/17/2007 +0100, Iljitsch van Beijnum wrote: >... >Let's do a little thought experiment: what if we get all the >application writers to change their applications within, say, the >next two years, to completely remove any references to IP addresses >and strictly use APIs that handle FQDNs. So we get to do whatever we >want below the FQDN. Would that allow us to solve the routing >scalability problem? I think that we need to map this solution to the reasons that people in practice today deaggregate IP prefixes or use PI addresses. At a minimum, it seems to me that we would need: - (to deal with multi-homed networks) The ability to map FQDNs to multiple IP addresses, plus the ability of the Network Layer (possibly in the host?) to deal with multiple IP addresses for their own addresses, and also the other end's IP addresses, where some might be temporarily not working at any given time. To me this implies some way to figure out which are working (perhaps ICMP Ping with each address combination?) - (to deal with topology changes) Easy ways for entire companies to change their IP addresses while leaving their FQDNs the same. Questions like how to set route filters come to mind (in companies and in service providers). - Ways to do traffic engineering between ASs without requiring deaggregation of prefixes, or at least with limiting the distance (in some sense) that deaggregated routes would be advertised (there are some BGP mechanisms related to this, but I don't know how widely used tFrom ram-bounces@iab.org Thu Jan 18 23:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lJX-00041P-O7; Thu, 18 Jan 2007 23:25:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kvw-0007mE-9N for ram@iab.org; Thu, 18 Jan 2007 23:00:56 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7kvu-0005Wq-Ug for ram@iab.org; Thu, 18 Jan 2007 23:00:56 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l0J40s1Z066088; Thu, 18 Jan 2007 20:00:54 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.164]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l0J40dB64419; Thu, 18 Jan 2007 20:00:53 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070118220946.0459a2d0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 18 Jan 2007 22:51:01 -0500 To: Iljitsch van Beijnum From: Ross Callon Subject: Re: [RAM] candidate properties of some new name types In-Reply-To: <9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com> References: <45AE8A3D.7090104@cisco.com> <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Thu, 18 Jan 2007 23:25:18 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 11:29 PM 1/17/2007 +0100, Iljitsch van Beijnum wrote: >... >Let's do a little thought experiment: what if we get all the >application writers to change their applications within, say, the >next two years, to completely remove any references to IP addresses >and strictly use APIs that handle FQDNs. So we get to do whatever we >want below the FQDN. Would that allow us to solve the routing >scalability problem? I think that we need to map this solution to the reasons that people in practice today deaggregate IP prefixes or use PI addresses. At a minimum, it seems to me that we would need: - (to deal with multi-homed networks) The ability to map FQDNs to multiple IP addresses, plus the ability of the Network Layer (possibly in the host?) to deal with multiple IP addresses for their own addresses, and also the other end's IP addresses, where some might be temporarily not working at any given time. To me this implies some way to figure out which are working (perhaps ICMP Ping with each address combination?) - (to deal with topology changes) Easy ways for entire companies to change their IP addresses while leaving their FQDNs the same. Questions like how to set route filters come to mind (in companies and in service providers). - Ways to do traffic engineering between ASs without requiring deaggregation of prefixes, or at least with limiting the distance (in some sense) that deaggregated routes would be advertised (there are some BGP mechanisms related to this, but I don't know how widely used they are). This gets into things like the difference between "hot potato routing" (forward the packet to a peer AS as close to the source as possible), versus "cold potato routing" (forward the packet to the same peer AS, but closer to the destination). Engineers from network operators could talk about this sort of thing much better than I could, but I sort of suspect that this might be difficult. I am also suspecting that the damage to the host stacks might be more significant than all of these concerns combined. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 23:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lIx-0003uT-8t; Thu, 18 Jan 2007 23:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7b5G-00043v-Io for ram@iab.org; Thu, 18 Jan 2007 12:29:54 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7b5E-0001gx-A4 for ram@iab.org; Thu, 18 Jan 2007 12:29:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 12:29:52 -0500 X-IronPort-AV: i="4.13,206,1167627600"; d="scan'208"; a="111970818:sNHT46525668" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IHTqBC011621; Thu, 18 Jan 2007 12:29:52 -0500 Received: from [68.49.215.202] (che-vpn-cluster-1-273.cisco.com [10.86.241.18]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0IHTpVT010093; Thu, 18 Jan 2007 12:29:51 -0500 (EST) In-Reply-To: <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> References: <45AFA00C.9080000@zurich.ibm.com> <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [RAM] server referrals Date: Thu, 18 Jan 2007 12:29:49 -0500 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1642; t=1169141392; x=1170005392; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[RAM]=20server=20referrals |Sender:=20 |To:=20RJ=20Atkinson=20; bh=saDW2xyoLeDmnVgO+6rn7Qcghb7Ciqwqs8kjIIy3aYY=; b=aAtFqZie2oYm0586YRq10Vi/GukAywtb0YeDw5Dg3V0itHygwqEA9+QAbhELtkkwYQR498Ge YT5llKiDdf4Sula9TWh2j/EVqKJZuDzmgYOQ0uWTu7JxRttApSnYM8aj; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 18 Jan 2007 23:24:43 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org If we are going in down this path, please ensure that what is necessary is included in the draft about this: draft-ietf-dnsop-reverse-mapping-considerations-01.txt On Jan 18, 2007, at 12:23 PM, RJ Atkinson wrote: > > On 18 Jan 2007, at 11:27, Brian E Carpenter wrote: >> As far as revehey are). This gets into things like the difference between "hot potato routing" (forward the packet to a peer AS as close to the source as possible), versus "cold potato routing" (forward the packet to the same peer AS, but closer to the destination). Engineers from network operators could talk about this sort of thing much better than I could, but I sort of suspect that this might be difficult. I am also suspecting that the damage to the host stacks might be more significant than all of these concerns combined. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 18 23:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7lIx-0003uT-8t; Thu, 18 Jan 2007 23:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7b5G-00043v-Io for ram@iab.org; Thu, 18 Jan 2007 12:29:54 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7b5E-0001gx-A4 for ram@iab.org; Thu, 18 Jan 2007 12:29:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2007 12:29:52 -0500 X-IronPort-AV: i="4.13,206,1167627600"; d="scan'208"; a="111970818:sNHT46525668" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0IHTqBC011621; Thu, 18 Jan 2007 12:29:52 -0500 Received: from [68.49.215.202] (che-vpn-cluster-1-273.cisco.com [10.86.241.18]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0IHTpVT010093; Thu, 18 Jan 2007 12:29:51 -0500 (EST) In-Reply-To: <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> References: <45AFA00C.9080000@zurich.ibm.com> <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [RAM] server referrals Date: Thu, 18 Jan 2007 12:29:49 -0500 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1642; t=1169141392; x=1170005392; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[RAM]=20server=20referrals |Sender:=20 |To:=20RJ=20Atkinson=20; bh=saDW2xyoLeDmnVgO+6rn7Qcghb7Ciqwqs8kjIIy3aYY=; b=aAtFqZie2oYm0586YRq10Vi/GukAywtb0YeDw5Dg3V0itHygwqEA9+QAbhELtkkwYQR498Ge YT5llKiDdf4Sula9TWh2j/EVqKJZuDzmgYOQ0uWTu7JxRttApSnYM8aj; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 18 Jan 2007 23:24:43 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org If we are going in down this path, please ensure that what is necessary is included in the draft about this: draft-ietf-dnsop-reverse-mapping-considerations-01.txt On Jan 18, 2007, at 12:23 PM, RJ Atkinson wrote: > > On 18 Jan 2007, at 11:27, Brian E Carpenter wrote: >> As far as reverse DNS lookup goes, there are certainly >> lots of hosts that don't have one, and can we really >> build an architecture that depends on something as baroque as >> reverse DNS? > > The current architecture already depends on Reverse DNS working, > for LOTS of things, including getting SMTP email delivered. > > In practice, lots of servers already simply refuse connections > from hosts without reverse DNS present. > > If the main thing that broke for lack of reverse DNS > would be server referrals, that would seem fine. After all, > the clients that did not work would be in the position > to fix the issue that caused the referral to not work > as expected. The problem might exist in pockets, but it > could be corrected locally and incrementally, so scaling > wouldn't be an issue. > > Most residential ISPs have reverse DNS that works -- globally, > because of various pressures unrelated to the topics here > (example: security, proving to registries that allocated > address space is in use). Even the dialup folks now generally > have a working reverse DNS. Neither group did a decade ago, > but things are a bit better now, or so I'm told. > > Yours, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram rse DNS lookup goes, there are certainly >> lots of hosts that don't have one, and can we really >> build an architecture that depends on something as baroque as >> reverse DNS? > > The current architecture already depends on Reverse DNS working, > for LOTS of things, including getting SMTP email delivered. > > In practice, lots of servers already simply refuse connections > from hosts without reverse DNS present. > > If the main thing that broke for lack of reverse DNS > would be server referrals, that would seem fine. After all, > the clients that did not work would be in the position > to fix the issue that caused the referral to not work > as expected. The problem might exist in pockets, but it > could be corrected locally and incrementally, so scaling > wouldn't be an issue. > > Most residential ISPs have reverse DNS that works -- globally, > because of various pressures unrelated to the topics here > (example: security, proving to registries that allocated > address space is in use). Even the dialup folks now generally > have a working reverse DNS. Neither group did a decade ago, > but things are a bit better now, or so I'm told. > > Yours, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 04:56:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qSu-0006RA-GV; Fri, 19 Jan 2007 04:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qSt-0006Px-Io for ram@iab.org; Fri, 19 Jan 2007 04:55:19 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7qSr-0000w1-10 for ram@iab.org; Fri, 19 Jan 2007 04:55:19 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0J9tFp4151336 for ; Fri, 19 Jan 2007 09:55:15 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0J9tFGV2838540 for ; Fri, 19 Jan 2007 10:55:15 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0J9tF7l019817 for ; Fri, 19 Jan 2007 10:55:15 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0J9tEPR019812; Fri, 19 Jan 2007 10:55:14 +0100 Received: from [9.4.22.200] (dhcp22-200.zurich.ibm.com [9.4.22.200]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA129290; Fri, 19 Jan 2007 10:55:11 +0100 Message-ID: <45B06D51.3020309@zurich.ibm.com> Date: Fri, 19 Jan 2007 08:03:45 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: John Schnizlein Subject: Re: [RAM] server referrals References: <45AFA00C.9080000@zurich.ibm.com> <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I'm not disputing the reality that synthetic reverse DNS for clients is widely practised and widely checked. But it is a hack. My question is whether we should be considering relying on such a hack for a new routing architecture. Brian On 2007-01-18 18:29, John Schnizlein wrote: > If we are going in down this path, please ensure that what is necessary > is included in the draft about this: > draft-ietf-dnsop-reverse-mapping-considerations-01.txt > > On Jan 18, 2007, at 12:23 PM, RJ Atkinson wrote: >> >> On 18 Jan 2007, at 11:27, Brian E Carpenter wrote: >>> As far as reverse DNS lookup goes, there are certainly >>> lots of hosts that don't have one, and can we really >>> build an architecture that depends on something as baroque as reverse >>> DNS? >> >> The current architecture already depends on Reverse DNS working, >> for LOTS of things, including getting SMTP email delivered. >> >> In practice, lots of servers already simply refuse connections >> from hosts without reverse DNS present. >> >> If the main thing that broke for lack of reverse DNS >> would be server referrals, that would seem fine. After all, >> the clients that did not work would be in the position >> to fix the issue that caused the referral to not work >> as expected. The problem might exist in pockets, but it >> could be corrected locally and incrementally, so scaling >> wouldn't be an issue. >> >> Most residential ISPs have reverse DNS that works -- globally, >> because of various pressures unrelated to the topics here >> (example: security, proving to registries that allocated >> address space is in use). Even the dialup folks now generally >> have a working reverse DNS. Neither group did a decade ago, >> but things are a bit better now, or so I'm told. >> >> Yours, >> >> Ran >> >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 05:06:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qdR-0003Zh-2c; Fri, 19 Jan 2007 05:06:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qdP-0003Zc-8f for ram@iab.org; Fri, 19 Jan 2007 05:06:11 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7qdO-0002A0-07 for ram@iab.org; Fri, 19 Jan 2007 05:06:11 -0500 Received: by ug-out-1314.google.com with SMTP id z36so353783uge for ; Fri, 19 Jan 2007 02:06:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=icB6yuzQa/L2FeP6IQkzcWXxn890PI29wvAK3FEhfqRBulXqk5D7kuyB1+CzasBUfkuenH5R8oOkEXmPK1cvDpncGH3p4urYuMhOaSJqqRe6xiCrKYVqEEbeZZoxa1DDy20HkfVLdhEqmzZ5TY716Tmaekg/RzyMradKRswdOdw= Received: by 10.82.152.16 with SMTP id z16mr471918bud.1169201168949; Fri, 19 Jan 2007 02:06:08 -0800 (PST) Received: by 10.82.111.17 with HTTP; Fri, 19 Jan 2007 02:06:08 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 13:06:08 +0300 From: McTim To: "Brian E Carpenter" Subject: Re: [RAM] server referrals In-Reply-To: <45B06D51.3020309@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45AFA00C.9080000@zurich.ibm.com> <3E6D72F0-DA2C-46C0-9014-725DAA72844A@extremenetworks.com> <45B06D51.3020309@zurich.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: RJ Atkinson , ram@iab.org, John Schnizlein X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 1/19/07, Brian E Carpenter wrote: > I'm not disputing the reality that synthetic reverse DNS for > clients is widely practised and widely checked. But it is a > hack. My question is whether we should be considering relying > on such a hack for a new routing architecture. Certainly not IMHO! -- Cheers, McTim $ whois -h whois.afrinic.net mctim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 06:33:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rzF-0007rM-QE; Fri, 19 Jan 2007 06:32:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rzF-0007qs-07 for ram@iab.org; Fri, 19 Jan 2007 06:32:49 -0500 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7rwf-0004wg-6f for ram@iab.org; Fri, 19 Jan 2007 06:30:10 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JC459X00.J6S; Fri, 19 Jan 2007 12:29:57 +0100 In-Reply-To: <45AF8279.6000600@cisco.com> X-Priority: 1 (High) Subject: Re: [RAM] candidate properties of some new name types To: Russ White X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Fri, 19 Jan 2007 12:29:54 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 19/01/2007 12:28:10 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ White escribi=F3 el 18/01/2007 15:21:45: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> The primary thing you've done with this is destroy the case for PI= > >> space. > > > > Really? It's not just the applications that love to handle IP addresses, > > it's also all the firewalls and other access restrictions. I don't think > > this will be enough to wean enterprises off of PI. > > BTW, I thought I'd also ask about this one.... Perhaps it's different= in > Europe, but in the US, I don't know of any enterprises running their > hosts on PI space. The networks I've touched recently include > Disney/ABC, Cabelas, Walmart, Walgreens, Wachovia, WAMU, Citigroup, a= nd > a few dozen others, and they're all running on nonroutable address sp= ace > behind a bunch of NATs. Yes, but look what I have found in ARIN: - Citigroup (AS25883) CITIGROUP 25883 Citigroup (AS22650) CITIGROUP-KNIGHT-FINANCIAL-AS22650 22650 Citigroup (AS30284) CITIGROUP-BANAMEX 30284 - 30285 Citigroup (AS32111) CITIGROUP-JAPAN 32111 Citigroup (AS32287) SOLANA-CITIPLEX 32287 Citigroup (AS33463) CITIGROUP-GLOBAL-ANYCAST-DNS 33463 Citigroup (AS33464) CITIGROUP-BACKBONE 33464 - Cabela's (AS14527) CABELAS 14527 - WALMART.COM (AS17374) WALMART 17374 - Disney Worldwide Services, Inc. (AS25932) DWSI 25932 Disney Worldwide Services, Inc. (AS29736) DWS-ORL 29736 Disney Worldwide Services, Inc. (AS30311) DWS-LON 30311 Disney Worldwide Services, Inc. (AS40051) DWS-HK 40051 Disney Worldwide Services, Inc. (AS11812) DWS-UTAH 11812 - Walgreens Co (AS13626) WALGREESN 13626 - WACHOVIA CORP (AS4243) NC-FUNB-AS 4243 Wachovia Operational Services Corporation (AS2011) WACHOVIA 2011 > All of these would be PI if it weren't for NATs. So, it seems to me t= hat > splitting the location from the ID would have a large impact on the n= eed > /desire for PI space. I have also queried the ARIN database for network addresses assigned to those companies and the number of lines is too big to include it in this note. They seem to have many PI addressing already. > > Most of the enterprise folks I know have just a couple of requirement= s > in regards to IP addresses: > > 1. Don't change them. > 2. Give me a lot. > 3. Make it so I can reach things outside my network. Therefore, according to the ARIN database there is a 4th need: 4. Give me multihoming. ... what is in line with the results presented by G. Huston at the recent IAB Routing Workshop: "The IPv4 network continues to get denser, with finer levels of advertisement granularity. More interconnections, more specific advertisements" > There's nothing in that list about having a globally routable IP addr= ess > on a specific host--reachability is the requirement, not routability.= I think routability is also a need. This is why they too want multihoming. So IMHO they want NAT+PI at the same time. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 07:43:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7t4z-00084D-KR; Fri, 19 Jan 2007 07:42:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7t4z-00082t-2D for ram@iab.org; Fri, 19 Jan 2007 07:42:49 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7t4t-00086R-IH for ram@iab.org; Fri, 19 Jan 2007 07:42:49 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0JCgxBi003791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jan 2007 13:43:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5.0.0.25.2.20070118220946.0459a2d0@zircon.juniper.net> References: <45AE8A3D.7090104@cisco.com> <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com> <568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com> <9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com> <7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com> <7.0.0.16.2.20070117134335.05400a00@apnic.net> <45AE8A3D.7090104@cisco.com> <5.0.0.25.2.20070118220946.0459a2d0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Fri, 19 Jan 2007 13:42:26 +0100 To: Ross Callon X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19-jan-2007, at 4:51, Ross Callon wrote: >> completely remove any references to IP addresses >> and strictly use APIs that handle FQDNs. So we get to do whatever we >> want below the FQDN. Would that allow us to solve the routing >> scalability problem? > I think that we need to map this solution to the reasons that people > in practice today deaggregate IP prefixes or use PI addresses. At a > minimum, it seems to me that we would need: > - (to deal with multi-homed networks) The ability to map FQDNs to > multiple IP addresses, DNS. > plus the ability of the Network Layer (possibly > in the host?) to deal with multiple IP addresses for their own > addresses, Required in IPv6, also possible in many IPv4 implementations. > and also the other end's IP addresses, where some > might be temporarily not working at any given time. To me this > implies some way to figure out which are working (perhaps ICMP > Ping with each address combination?) We came up with draft-ietf-shim6-failure-detection-07.txt to figure out which combination of source/dest addresses works. > - (to deal with topology changes) Easy ways for entire companies to > change their IP addresses while leaving their FQDNs the same. > Questions like how to set route filters come to mind (in companies > and in service providers). This is doable if you can have overlap between the old and the new addresses. > - Ways to do traffic engineering between ASs without requiring > deaggregation of prefixes, or at least with limiting the distance > (in some sense) that deaggregated routes would be advertised > (there are some BGP mechanisms related to this, but I don't > know how widely used they are). This is one of the things I've been saying for a while now: we need better metrics in BGP, because we have none that work across multiple ASes. But TE doesn't need to be done in BGP. An obvious alternative is using DNS SRV records with different priorities for different addresses. > I am also suspecting that the damage to the host stacks might be > more significant than all of these concerns combined. I'm not too worried about the stack. SCTP works, TCP with multiple addresses has been implemented unless I'm mistaken, and we have a pretty good handle on shim6. The more challenging part is removing the addresses from the applications and the protocols. And host-based solutions aren't all that popular, so we'd need a way for middleboxes to do the address juggling. One way to do this is with a proxy, where the source sets up a lower-layer session towards a proxy and the proxy looks at the identifier and sets up a new session towards the real destination. Another solution is NAT where the identifier is carried in-band so call-backs and referrals are possible. In both cases, additional mechanisms to recover from middlebox failures would be required and using the reverse DNS won't work because the source address isn't the one held by the actual source. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 07:56:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tHS-0008KG-KI; Fri, 19 Jan 2007 07:55:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tHS-0008KB-66 for ram@iab.org; Fri, 19 Jan 2007 07:55:42 -0500 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7tHQ-0002Le-VY for ram@iab.org; Fri, 19 Jan 2007 07:55:42 -0500 Received: from s73602 ([72.190.0.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20070119125536.MDMP5532.mta11.adelphia.net@s73602> for ; Fri, 19 Jan 2007 07:55:36 -0500 Message-ID: <006e01c73bc9$2242fff0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com><568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com><9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com><7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com><7.0.0.16.2.20070117134335.05400a00@apnic.net><45AE8A3D.7090104@cisco.com><9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com><45AECAB2.3010106@cisco.com><56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com><45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> <7.0.0.16.2.20070119083929.01587e48@apnic.net> Subject: Re: [RAM] candidate properties of some new name types Date: Fri, 19 Jan 2007 06:55:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > There are two problems in NAT space that make life hard: > > 1 - the other end gets presented with a different packet header than was > sent (i.e. NATs are asymmetric and occluded) > > 2 - NATs are all different. There is no single NAT behaviour specification Based on discussions in BEHAVE, I believe that Geoff's statement here is both correct and understated. I can't find the quote in BEHAVE meeting minutes, but I remember vividly someone last year saying that they find new broken NAT behavior every time they test a new NAT device, and Cullen and Francois have both talked repeatedly about NAT devices that change behavior over the life of a binding, apparently based on either elapsed time or CPU load on the NAT device. So it seems correct to say that there may not even be a single NAT behavior specification FOR A SPECIFIC NAT DEVICE OVER TIME, and that's what really, really reeks. > The combination of these two factors as what makes life hard for > applications. SHIM6 alters this to make the action symmetric and uniform. > Of course, tunnelling does the same, as does MPLS and many (if not all > other) forms of overlays and indirection. I think this is correct as well. Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 08:33:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7trr-0003BP-KI; Fri, 19 Jan 2007 08:33:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7trq-0003BI-32 for ram@iab.org; Fri, 19 Jan 2007 08:33:18 -0500 Received: from imo-m14.mx.aol.com ([64.12.138.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7tro-0008GK-O2 for ram@iab.org; Fri, 19 Jan 2007 08:33:18 -0500 Received: from HeinerHummel@aol.com by imo-m14.mx.aol.com (mail_out_v38_r7.6.) id j.c3c.cec69c9 (30739); Fri, 19 Jan 2007 08:33:06 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 19 Jan 2007 08:33:02 EST Subject: Re: [RAM] candidate properties of some new name types To: rja@extremenetworks.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0332707374==" Errors-To: ram-bounces@iab.org --===============0332707374== Content-Type: multipart/alternative; boundary="-----------------------------1169213582" -------------------------------1169213582 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 My own arguing question was : The locator is not a combination of AS# + some router's IP address.=20 Right? Answer by Ran: So far, I'm not getting into the details of what might constitute the internal format of a locator. One can imagine a range of very different engineering choices there. For now, O'Dell's term "Routing Goop" certainly is good enough for the locator (keeping the details vague enough to keep our options open). Answer by Peter: Why not. AS# could be a part of IP address within a routing hierarchy. Fine, so I conclude: Better information may be placed/structured/stacked=20 into the locator, which I think is good. =20 Heiner =20 In einer eMail vom 19.01.2007 00:56:10 Westeurop=E4ische Normalzeit schreibt= =20 rja@extremenetworks.com: Earlier, Heiner Hummel wrote: > IMHO: the identifier should name some kind of stack, and the locator > as well . But here each part is conceived to be just another IP =20 > address. > Right ? > The locator is not a combination of AS# + some router's IP address. > Right? I am definitely NOT thinking that "each part is just another IP =20 address". My thought is conceptually to deprecate the concept of "address" and instead have distinct locators and identifiers (with different namespaces for each -- so reducing the semantic overloading). The approach where "each part is an IP address" increases, rather than decreases, the semantic overloading. That is also roughly the engineering decision that SHIM6 made. So far, I'm not getting into the details of what might constitute the internal format of a locator. One can imagine a range of very different engineering choices there. For now, O'Dell's term "Routing Goop" certainly is good enough for the locator (keeping the details vague enough to keep our options open). Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -------------------------------1169213582 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
My own arguing question was :
    The locator is not a combination of AS# +  some= =20 router's IP address. Right?

Answer by Ran:
So far, I'm not getting into the details of what might constitute
th= e=20 internal format of a locator.  One can imagine a range of very
diffe= rent=20 engineering choices there.  For now, O'Dell's term
"Routing Goop"=20 certainly is good enough for the locator (keeping
the details vague enoug= h to=20 keep our options open).

Answer by Peter:
Why not. AS# could be a part of IP address within a routing=20 hierarchy.
 
Fine, so I conclude:  Better information may be=20 placed/structured/stacked into the locator, which I think is good.
 
Heiner
 
In einer eMail vom 19.01.2007 00:56:10 Westeurop=E4ische Normalzeit sch= reibt=20 rja@extremenetworks.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Earlier,=20 Heiner Hummel wrote:
> IMHO: the identifier should name some kind of= =20 stack, and the locator
> as well . But here each part is conceived t= o be=20 just another IP 
> address.
> Right ?
> The locato= r is=20 not a combination of AS# + some router's IP address.
> Right?
I=20 am definitely NOT thinking that "each part is just another IP =20
address".
My thought is conceptually to deprecate the concept of=20 "address" and
instead have distinct locators and identifiers (with=20 different
namespaces for each -- so reducing the semantic=20 overloading).

The approach where "each part is an IP address"=20 increases,
rather than decreases, the semantic overloading.  That=20= is=20 also
roughly the engineering decision that SHIM6 made.

So far, I= 'm=20 not getting into the details of what might constitute
the internal form= at=20 of a locator.  One can imagine a range of very
different engineeri= ng=20 choices there.  For now, O'Dell's term
"Routing Goop" certainly is= =20 good enough for the locator (keeping
the details vague enough to keep o= ur=20 options=20 open).

Ran


_____________________________________________= __
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1169213582-- --===============0332707374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0332707374==-- From ram-bounces@iab.org Fri Jan 19 09:28:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uiI-000848-67; Fri, 19 Jan 2007 09:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7uiH-00080S-2v for ram@iab.org; Fri, 19 Jan 2007 09:27:29 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7uiC-00007O-Qs for ram@iab.org; Fri, 19 Jan 2007 09:27:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2007 06:27:25 -0800 X-IronPort-AV: i="4.13,211,1167638400"; d="scan'208"; a="51152112:sNHT47170008" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0JEROob003305; Fri, 19 Jan 2007 09:27:24 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l0JERNVT005175; Fri, 19 Jan 2007 09:27:24 -0500 (EST) Message-ID: <45B0D543.50907@cisco.com> Date: Fri, 19 Jan 2007 09:27:15 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JUAN-JOSE.ADAN@giss.seg-social.es Subject: Re: [RAM] candidate properties of some new name types References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2582; t=1169216844; x=1170080844; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20JUAN-JOSE.ADAN@giss.seg-social.es; bh=ahAuhSj6tja6tUYlyetX04Fq4Z64gSMaCRwOAaJSyzI=; b=rFosISsvfADgrv2U0OYUJ5ggkBweA/AjePfNPeYd9WjwIAk9opYxakfX2h6uK9OIb9SZd6KJ HDHQuYi6fVn6w1iLGdOnYczKYdP+aj4xywPZhVC4ok+ZcnOPvlvmDDgx; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Yes, but look what I have found in ARIN: > - Citigroup (AS25883) CITIGROUP 25883 > Citigroup (AS22650) CITIGROUP-KNIGHT-FINANCIAL-AS22650 22650 > Citigroup (AS30284) CITIGROUP-BANAMEX 30284 - 30285 > Citigroup (AS32111) CITIGROUP-JAPAN 32111 > Citigroup (AS32287) SOLANA-CITIPLEX 32287 > Citigroup (AS33463) CITIGROUP-GLOBAL-ANYCAST-DNS 33463 > Citigroup (AS33464) CITIGROUP-BACKBONE 33464 > - Cabela's (AS14527) CABELAS 14527 > - WALMART.COM (AS17374) WALMART 17374 > - Disney Worldwide Services, Inc. (AS25932) DWSI 25932 > Disney Worldwide Services, Inc. (AS29736) DWS-ORL 29736 > Disney Worldwide Services, Inc. (AS30311) DWS-LON 30311 > Disney Worldwide Services, Inc. (AS40051) DWS-HK 40051 > Disney Worldwide Services, Inc. (AS11812) DWS-UTAH 11812 > - Walgreens Co (AS13626) WALGREESN 13626 > - WACHOVIA CORP (AS4243) NC-FUNB-AS 4243 > Wachovia Operational Services Corporation (AS2011) WACHOVIA 2011 Of course. Do you know if they use them for actually addressing hosts, or for facing out to the Internet addresses at their NAT boxes? I actually happen to know the answer to this question, but I'll let you guess. :-) Second question--did they get those addresses before, or after, they started installing NAT boxes at their edges? In other words, when they were allocated those addresses, were they actually using them to number hosts, and has their policy changed since that time? Don't assume a PI address assigned means the company is using that space in the way you think. > Therefore, according to the ARIN database there is a 4th need: > 4. Give me multihoming. > I think routability is also a need. This is why they > too want multihoming. So IMHO they want NAT+PI at > the same time. IMHO, if you gave them reversable NAT, you would kill off even much of what you're seeing here in the table. Again, this comes from actual discussions with the folks who run these networks, and many others, not just examining the tables.... In fact, I'll make it a point to ask this specific question next week, in a couple of meetings I have with some folks, and then get back to the list with the answers. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsNVDER27sUhU9OQRAqrNAKD+/0a9IHn6kiSaS4YCi1BfZWoqmgCg/WDu SL622BqeGYSM9tkMsK7hwiQ= =itfU -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 09:33:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7unr-0001p5-8s; Fri, 19 Jan 2007 09:33:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7unp-0001lr-VR for ram@iab.org; Fri, 19 Jan 2007 09:33:13 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7unn-0000nf-Mh for ram@iab.org; Fri, 19 Jan 2007 09:33:13 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2007 06:33:12 -0800 X-IronPort-AV: i="4.13,211,1167638400"; d="scan'208"; a="51152579:sNHT47608308" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0JEXBEA005567; Fri, 19 Jan 2007 09:33:11 -0500 Received: from [127.0.0.1] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l0JEXAOA017772; Fri, 19 Jan 2007 09:33:11 -0500 (EST) Message-ID: <45B0D69F.8000708@cisco.com> Date: Fri, 19 Jan 2007 09:33:03 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [RAM] candidate properties of some new name types References: <81F7C0B3-13A6-4A86-A248-AA4D94BACE67@extremenetworks.com><568BC65C-4EEB-48F0-AAE4-4F4CE192C8FF@muada.com><9B072578-D3BA-41BE-AF12-0A9FCFCEAB37@extremenetworks.com><7CD7292F-B4F7-4263-84B9-A733F65ECAB8@muada.com><7.0.0.16.2.20070117134335.05400a00@apnic.net><45AE8A3D.7090104@cisco.com><9A6C23C9-C108-4705-9409-69E13C5B244F@muada.com><45AECAB2.3010106@cisco.com><56D6B7F0-E1E7-4FA8-AD25-4F97EC815896@muada.com><45AF7E59.2070308@cisco.com> <45AF8508.6060103@zurich.ibm.com> <7.0.0.16.2.20070119083929.01587e48@apnic.net> <006e01c73bc9$2242fff0$6501a8c0@china.huawei.com> In-Reply-To: <006e01c73bc9$2242fff0$6501a8c0@china.huawei.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2584; t=1169217191; x=1170081191; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20candidate=20properties=20of=20some=20new=20na me=20types |Sender:=20 |To:=20Spencer=20Dawkins=20; bh=jS5OjF1cCt6Nubrzq4SpZWZq0Z9rTcD/EF/XA9p9sdo=; b=NYDlxh8zP88X417elhT59s2UAus5oCqD/d0n07ZJDNxVXM+jAuh06Rg2GgSB5Eq/a6RjtHT8 8L58n2yJZ1Z0yOmZhg1lX3lQD6N/Wzi5e5S57Ug/k9iFMb5eI6L2/c4K; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> There are two problems in NAT space that make life hard: >> >> 1 - the other end gets presented with a different packet header than >> was sent (i.e. NATs are asymmetric and occluded) >> >> 2 - NATs are all different. There is no single NAT behaviour >> specification > > Based on discussions in BEHAVE, I believe that Geoff's statement here is > both correct and understated. I can't find the quote in BEHAVE meeting > minutes, but I remember vividly someone last year saying that they find > new broken NAT behavior every time they test a new NAT device, and > Cullen and Francois have both talked repeatedly about NAT devices that > change behavior over the life of a binding, apparently based on either > elapsed time or CPU load on the NAT device. > > So it seems correct to say that there may not even be a single NAT > behavior specification FOR A SPECIFIC NAT DEVICE OVER TIME, and that's > what really, really reeks. > >> The combination of these two factors as what makes life hard for >> applications. SHIM6 alters this to make the action symmetric and >> uniform. Of course, tunnelling does the same, as does MPLS and many >> (if not all other) forms of overlays and indirection. > > I think this is correct as well. Of course, we're not talking about current NATs--nor PATs, which many people confuse for NATs. I'll venture to guess that most of the behaviors you're seeing are on the PAT side, not the NAT side. Second, the presumption was that if there some "magic" to make NAT's reversable, then, from the network's perspective, NATs are the same as something like SHIM6. As for the host, if the host is dealing with identifiers, rather than locators, then changes in the locator shouldn't make any difference. Like with a router, where changes above the IP header shouldn't matter (I'm not saying they don't, I'm saying that, in theory, they shouldn't), to a host, changes below the transport header shouldn't matter. That's the entire reason behind layering, isn't it? Isn't the base of the problem we're dealing with here, in terms of loc/ID, really a big, fat, layering violation? (Or, it could be that I'm insane, a possibility my children would gladly endorse). :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsNaeER27sUhU9OQRAi3rAJsGYLmKK/PVJucrVTNOnnCpTS1QwACeK4AD GdvNkUDdk9d/2KE7SWN5stU= =7bhz -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 10:35:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vkX-0000ow-8T; Fri, 19 Jan 2007 10:33:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vkW-0000om-7P for ram@iab.org; Fri, 19 Jan 2007 10:33:52 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vkT-0001EM-SP for ram@iab.org; Fri, 19 Jan 2007 10:33:52 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 50DB087327; Fri, 19 Jan 2007 10:33:49 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types Message-Id: <20070119153349.50DB087327@mercury.lcs.mit.edu> Date: Fri, 19 Jan 2007 10:33:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org {Sorry this reply is kind of delayed - other things have intruded!} > From: RJ Atkinson > Date: Tue, 16 Jan 2007 18:59:30 -0500 >> on networks which don't use IEEE 801 style addresses, where does the >> name of the interface in the local network's namespace go/come from? >> Are you assuming some sort of broadcast/database/etc lookup mechanism >> that you can use to translate identifiers to local network interface >> addresses? What do you do on networks that don't support network-wide >> broadcast? Use a database? > .. With IPv6, the current practice is to use ND on all link types, not > just those with a link-scope broadcast/multicast capability. So > network::link location resolution really isn't rocket science. Yes, but it means there's an extra mechanism down there that has to be working correctly before packets can be delivered. From a complexity/robustness viewpoint, that's not good. ARP in IPv4 is, quite literally, a bag on the side. It's a quite good bag (if I may say so myself, having been the co-designer, along with Plummer :-), but still, it was an after-thought - we were suddenly faced with generating a 48-bit local-network interface address, when we only had a maximum of 24-bits to play with. ARP was the obvious fix - and, being a binding layer, was immediately the subject of various hacks because the system (ta-da) didn't have enough binding layers (a behaviour which continues to this day, sigh). >> The locator names the interface, and provides in and of itself all the >> bits that you need to get the packet to it. > That would be an alternative approach, and a somewhat different > architecture. There may well be engineering reasons why your approach is preferable; e.g. some existing mechanism (e.g. IPv6 ND) you want to re-use, or some other engineering reason (e.g. deployment issues). However, I'm currently (still?) looking at this question on a purely architectural level, and trying to see if there are any architectural reasons one might prefer your approach. > It is limiting in various ways, for example with respect to mobility. Oh, balderdash. Your design provides mobility, of two kinds: i) binding a different locator to an identifier, which provides mobility over an unlimited scope - but "full" locators provide this kind of mobility too, and ii) mobility over a limited scope (one named by a particular locator), via changing the mapping in whatever mechanisms maps identifiers to the "rest" of the locator. I fail to see how providing this second, limited, mobility does that much for you - one might claim it's cheaper/faster than the full mobility, but against that one has to set the facts that first, as extra-architectural mechanism, it's more complexity, and potentially problematic (the far end cannot see it happening, even if it cares). More importantly, if one really wants, one can do this kind of mobility with "full" locators too - if you really need a local binding layer, for some engineering reason, the last element(s) in the locator could say "use local mechanisms to map this portion of the locator to the actual locator" (or perhaps "use local mechanisms to map the identifier to the actual locator", which gives exactly your mechanism). >> mixing naming and location function in two names is really not a good >> idea. > It isn't mixing them. The Locator names the subnetwork. The Identifier > names the node. One merely uses the name of the node You're splitting an almost non-existent hair. Your argument seems to be that the interface really does have a full locator (in some abstract sense), it's just that the complete locator is not visible to the far end, the local part is only visible locally. Using your logic, I can sort of show that IPv4 "has" locators and identifiers too: most interfaces have a globally-unique locator too (their IEEE 48-bit addresses), but they are only visible inside the local scope, via ARP. The fact remains that system wide, you don't have a full name for the interface, one has to use the identifier as well - with the result that there are a variety of scenarios (e.g. two interfaces to a single physical network) in which one *cannot* name the interface completely, i.e. the inability to fully name an interface means there are things one can't do. Hence, my conclusion that your scheme mixes identification and location... > The node name does not vary as location changes, only the subnetwork > name varies, and the subnetwork name always follows the topology. As I said, there may be good engineering reasons to accept your scheme, in which the locator does not fully name the interface. However, thinking purely architecturally, I still feel that fully naming the interface in the locator is architecturally superior - simpler, and more robust. Before we move on to the engineering practicalities, are there any good architectural reasons to prefer "partial" locators? I haven't given it a lot of thought, I must admit (I've more been looking at what's bad about the idea), so perhaps I'll come up with some if I ponder it. Although the generic point I raised (in an architecture with "full" locators, one can always drop the last element(s), if one wants the behaviour of "partial" locators, but one cannot add the last element(s) if one is working in a "partial" architecture") would seem to indicate can be no possible architectural reason to prefer "partial" locators... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 14:10:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7z78-000573-8f; Fri, 19 Jan 2007 14:09:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7z6y-0004uu-Hu for ram@iab.org; Fri, 19 Jan 2007 14:09:17 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7z4P-0004fM-5L for ram@iab.org; Fri, 19 Jan 2007 14:06:38 -0500 Received: from pc6 (1Cust127.tnt29.lnd3.gbr.da.uu.net [62.188.120.127]) by blaster.systems.pipex.net (Postfix) with SMTP id 64CBCE0002F3; Fri, 19 Jan 2007 19:06:29 +0000 (GMT) Message-ID: <032401c73bf4$68d1fe00$0601a8c0@pc6> From: "tom.petch" To: "Russ White" , References: <45B0D543.50907@cisco.com> Subject: [RAM] PI and NAT was candidate properties of some new name types Date: Fri, 19 Jan 2007 15:32:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ I know of one large international enterprise that used NAT exclusively, added up all the PI addresses that they had been allocated around the world by various registries, found it was way in excess of their requirements, and ... gave them back to the LIRs? no way, they got rid of NAT. Tom Petch ----- Original Message ----- From: "Russ White" To: Cc: Sent: Friday, January 19, 2007 3:27 PM Subject: Re: [RAM] candidate properties of some new name types > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Yes, but look what I have found in ARIN: > > - Citigroup (AS25883) CITIGROUP 25883 > > Citigroup (AS22650) CITIGROUP-KNIGHT-FINANCIAL-AS22650 22650 > > Citigroup (AS30284) CITIGROUP-BANAMEX 30284 - 30285 > > Citigroup (AS32111) CITIGROUP-JAPAN 32111 > > Citigroup (AS32287) SOLANA-CITIPLEX 32287 > > Citigroup (AS33463) CITIGROUP-GLOBAL-ANYCAST-DNS 33463 > > Citigroup (AS33464) CITIGROUP-BACKBONE 33464 > > - Cabela's (AS14527) CABELAS 14527 > > - WALMART.COM (AS17374) WALMART 17374 > > - Disney Worldwide Services, Inc. (AS25932) DWSI 25932 > > Disney Worldwide Services, Inc. (AS29736) DWS-ORL 29736 > > Disney Worldwide Services, Inc. (AS30311) DWS-LON 30311 > > Disney Worldwide Services, Inc. (AS40051) DWS-HK 40051 > > Disney Worldwide Services, Inc. (AS11812) DWS-UTAH 11812 > > - Walgreens Co (AS13626) WALGREESN 13626 > > - WACHOVIA CORP (AS4243) NC-FUNB-AS 4243 > > Wachovia Operational Services Corporation (AS2011) WACHOVIA 2011 > > Of course. Do you know if they use them for actually addressing hosts, > or for facing out to the Internet addresses at their NAT boxes? I > actually happen to know the answer to this question, but I'll let you > guess. :-) > > Second question--did they get those addresses before, or after, they > started installing NAT boxes at their edges? In other words, when they > were allocated those addresses, were they actually using them to number > hosts, and has their policy changed since that time? > > Don't assume a PI address assigned means the company is using that space > in the way you think. > > > Therefore, according to the ARIN database there is a 4th need: > > 4. Give me multihoming. > > > I think routability is also a need. This is why they > > too want multihoming. So IMHO they want NAT+PI at > > the same time. > > IMHO, if you gave them reversable NAT, you would kill off even much of > what you're seeing here in the table. Again, this comes from actual > discussions with the folks who run these networks, and many others, not > just examining the tables.... In fact, I'll make it a point to ask this > specific question next week, in a couple of meetings I have with some > folks, and then get back to the list with the answers. > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 17:00:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81l1-0003k3-NW; Fri, 19 Jan 2007 16:58:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H81kz-0003i5-Si for ram@iab.org; Fri, 19 Jan 2007 16:58:45 -0500 Received: from web58709.mail.re1.yahoo.com ([66.196.100.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H81ky-0006e4-FL for ram@iab.org; Fri, 19 Jan 2007 16:58:45 -0500 Received: (qmail 35557 invoked by uid 60001); 19 Jan 2007 21:58:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TyaLfdmotTq0v+CT+pPy4LOBEDArV6wWZl1K9NQuoO7PATU6GphjcPNueQ5ieLIjamzGLNGsIAFlVQUskd2ai22RF2AFAvrp7J7ZURuEZk+nVL6gNGt98TsdfjgJcTR+GNjqNC7NZTYxUK2WQgqvzYwbKPb2rpAX65bYMImDLD0=; X-YMail-OSG: S.FoQAAVM1n_TrQh.Gs6ybg114dYtuOKUrscboWh Received: from [207.107.50.100] by web58709.mail.re1.yahoo.com via HTTP; Fri, 19 Jan 2007 13:58:43 PST Date: Fri, 19 Jan 2007 13:58:43 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] candidate properties of some new name types To: RJ Atkinson , ram@iab.org In-Reply-To: <97E7126F-4597-4E99-AFE5-DC0EB0F3CDB3@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <643087.34694.qm@web58709.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > O'Dell's term "Routing Goop" His drafts (8+8, GSE) have expired. Could anyone point to or share these documents? Thank you, Peter --- RJ Atkinson wrote: > Earlier, Heiner Hummel wrote: > > IMHO: the identifier should name some kind of stack, and the locator > > as well . But here each part is conceived to be just another IP > > address. > > Right ? > > The locator is not a combination of AS# + some router's IP address. > > Right? > > I am definitely NOT thinking that "each part is just another IP > address". > My thought is conceptually to deprecate the concept of "address" and > instead have distinct locators and identifiers (with different > namespaces for each -- so reducing the semantic overloading). > > The approach where "each part is an IP address" increases, > rather than decreases, the semantic overloading. That is also > roughly the engineering decision that SHIM6 made. > > So far, I'm not getting into the details of what might constitute > the internal format of a locator. One can imagine a range of very > different engineering choices there. For now, O'Dell's term > "Routing Goop" certainly is good enough for the locator (keeping > the details vague enough to keep our options open). > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 17:17:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H822K-00036n-NI; Fri, 19 Jan 2007 17:16:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H822I-00036f-Tf for ram@iab.org; Fri, 19 Jan 2007 17:16:38 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H822I-0003KO-LY for ram@iab.org; Fri, 19 Jan 2007 17:16:38 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0JMGwpp011859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jan 2007 23:16:59 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <643087.34694.qm@web58709.mail.re1.yahoo.com> References: <643087.34694.qm@web58709.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] candidate properties of some new name types Date: Fri, 19 Jan 2007 23:16:33 +0100 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19-jan-2007, at 22:58, Peter Sherbin wrote: >> O'Dell's term "Routing Goop" > His drafts (8+8, GSE) have expired. And then some. :-) Those should really be published as historic RFCs or something... > Could anyone point to or share these documents? Have a look at draft-iab-raws-report-00.txt, it contains many good pointers, including one to the GSE draft. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jan 19 17:29:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82DZ-0000cH-Qt; Fri, 19 Jan 2007 17:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82DY-0000c7-Lq for ram@iab.org; Fri, 19 Jan 2007 17:28:16 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H82DU-00063m-9I for ram@iab.org; Fri, 19 Jan 2007 17:28:16 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l0JMS6be013066; Fri, 19 Jan 2007 14:28:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l0JMS2Sp013065; Fri, 19 Jan 2007 14:28:02 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 19 Jan 2007 14:28:02 -0800 From: David Meyer To: Peter Sherbin Subject: Re: [RAM] candidate properties of some new name types Message-ID: <20070119222802.GA13014@1-4-5.net> References: <97E7126F-4597-4E99-AFE5-DC0EB0F3CDB3@extremenetworks.com> <643087.34694.qm@web58709.mail.re1.yahoo.com> Mime-Version: 1.0 In-Reply-To: <643087.34694.qm@web58709.mail.re1.yahoo.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: ea4ac80f790299f943f0a53be7e1a21a Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1050411129==" Errors-To: ram-bounces@iab.org --===============1050411129== 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 Fri, Jan 19, 2007 at 01:58:43PM -0800, Peter Sherbin wrote: > > O'Dell's term "Routing Goop" >=20 > His drafts (8+8, GSE) have expired. Could anyone point to or share these = documents? Check out http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.= txt --dmm --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFsUXyORgD1qCZ2KcRAtkBAJ9DKqa8ecF+hbRvB6NNLRqZq7JU+gCdHNcu Tp0Be687YvHt2hWVD6R26BE= =mpYS -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============1050411129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1050411129==-- From ram-bounces@iab.org Sat Jan 20 11:56:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8JUG-0000Pw-Hg; Sat, 20 Jan 2007 11:54:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8JUE-0000Pr-Um for ram@iab.org; Sat, 20 Jan 2007 11:54:38 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8JUD-0002ms-Lm for ram@iab.org; Sat, 20 Jan 2007 11:54:38 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6102886; Sat, 20 Jan 2007 11:54:35 -0500 In-Reply-To: <032401c73bf4$68d1fe00$0601a8c0@pc6> References: <45B0D543.50907@cisco.com> <032401c73bf4$68d1fe00$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] PI and NAT was candidate properties of some new name types Date: Sat, 20 Jan 2007 11:54:27 -0500 To: "tom.petch" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ram@iab.org, JUAN-JOSE.ADAN@giss.seg-social.es X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 19, 2007, at 9:32 AM, tom.petch wrote: > Russ > > I know of one large international enterprise that used NAT > exclusively, added up > all the PI addresses that they had been allocated around the world > by various > registries, found it was way in excess of their requirements, and ... > > > gave them back to the LIRs? no way, they got rid of NAT. I would regard this as a good thing, given the prevalence of the "NAT provides security" meme. Regards Marshall > > Tom Petch > > > ----- Original Message ----- > From: "Russ White" > To: > Cc: > Sent: Friday, January 19, 2007 3:27 PM > Subject: Re: [RAM] candidate properties of some new name types > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>> Yes, but look what I have found in ARIN: >>> - Citigroup (AS25883) CITIGROUP 25883 >>> Citigroup (AS22650) CITIGROUP-KNIGHT-FINANCIAL-AS22650 22650 >>> Citigroup (AS30284) CITIGROUP-BANAMEX 30284 - 30285 >>> Citigroup (AS32111) CITIGROUP-JAPAN 32111 >>> Citigroup (AS32287) SOLANA-CITIPLEX 32287 >>> Citigroup (AS33463) CITIGROUP-GLOBAL-ANYCAST-DNS 33463 >>> Citigroup (AS33464) CITIGROUP-BACKBONE 33464 >>> - Cabela's (AS14527) CABELAS 14527 >>> - WALMART.COM (AS17374) WALMART 17374 >>> - Disney Worldwide Services, Inc. (AS25932) DWSI 25932 >>> Disney Worldwide Services, Inc. (AS29736) DWS-ORL 29736 >>> Disney Worldwide Services, Inc. (AS30311) DWS-LON 30311 >>> Disney Worldwide Services, Inc. (AS40051) DWS-HK 40051 >>> Disney Worldwide Services, Inc. (AS11812) DWS-UTAH 11812 >>> - Walgreens Co (AS13626) WALGREESN 13626 >>> - WACHOVIA CORP (AS4243) NC-FUNB-AS 4243 >>> Wachovia Operational Services Corporation (AS2011) WACHOVIA >>> 2011 >> >> Of course. Do you know if they use them for actually addressing >> hosts, >> or for facing out to the Internet addresses at their NAT boxes? I >> actually happen to know the answer to this question, but I'll let you >> guess. :-) >> >> Second question--did they get those addresses before, or after, they >> started installing NAT boxes at their edges? In other words, when >> they >> were allocated those addresses, were they actually using them to >> number >> hosts, and has their policy changed since that time? >> >> Don't assume a PI address assigned means the company is using that >> space >> in the way you think. >> >>> Therefore, according to the ARIN database there is a 4th need: >>> 4. Give me multihoming. >> >>> I think routability is also a need. This is why they >>> too want multihoming. So IMHO they want NAT+PI at >>> the same time. >> >> IMHO, if you gave them reversable NAT, you would kill off even >> much of >> what you're seeing here in the table. Again, this comes from actual >> discussions with the folks who run these networks, and many >> others, not >> just examining the tables.... In fact, I'll make it a point to ask >> this >> specific question next week, in a couple of meetings I have with some >> folks, and then get back to the list with the answers. >> >> :-) >> >> Russ >> >> - -- >> riw@cisco.com CCIE <>< Grace Alone > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 22 03:15:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uKZ-0004Q0-9Y; Mon, 22 Jan 2007 03:15:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8uKX-0004Pv-NG for ram@iab.org; Mon, 22 Jan 2007 03:15:05 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8uKT-0006LS-7k for ram@iab.org; Mon, 22 Jan 2007 03:15:05 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0M8EuDM077560 for ; Mon, 22 Jan 2007 08:14:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0M8EuHx1409264 for ; Mon, 22 Jan 2007 08:14:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0M8EtmB031065 for ; Mon, 22 Jan 2007 08:14:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0M8EttO031046; Mon, 22 Jan 2007 08:14:55 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA344070; Mon, 22 Jan 2007 09:14:52 +0100 Message-ID: <45B4727D.9000801@zurich.ibm.com> Date: Mon, 22 Jan 2007 09:14:53 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] candidate properties of some new name types References: <97E7126F-4597-4E99-AFE5-DC0EB0F3CDB3@extremenetworks.com> <643087.34694.qm@web58709.mail.re1.yahoo.com> <20070119222802.GA13014@1-4-5.net> In-Reply-To: <20070119222802.GA13014@1-4-5.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-19 23:28, David Meyer wrote: > On Fri, Jan 19, 2007 at 01:58:43PM -0800, Peter Sherbin wrote: >>> O'Dell's term "Routing Goop" >> His drafts (8+8, GSE) have expired. Could anyone point to or share these documents? > > Check out http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt And bookmark http://tools.ietf.org/id/, which can find a lot of stuff for you. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 22 13:29:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93uP-0001Rj-G9; Mon, 22 Jan 2007 13:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93uN-0001QZ-VV for ram@iab.org; Mon, 22 Jan 2007 13:28:43 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93uM-0007Un-Nn for ram@iab.org; Mon, 22 Jan 2007 13:28:43 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0MISfN9020184 for ; Mon, 22 Jan 2007 13:28:41 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0MISfiJ186218 for ; Mon, 22 Jan 2007 13:28:41 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0MISfBf028532 for ; Mon, 22 Jan 2007 13:28:41 -0500 Received: from cichlid (wecm-9-67-89-110.wecm.ibm.com [9.67.89.110]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0MISelx028513; Mon, 22 Jan 2007 13:28:41 -0500 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l0MIQ890030696; Mon, 22 Jan 2007 13:26:14 -0500 Message-Id: <200701221826.l0MIQ890030696@cichlid> To: RJ Atkinson Subject: Re: [RAM] server referrals In-reply-to: References: Comments: In-reply-to RJ Atkinson message dated "Thu, 18 Jan 2007 11:06:19 -0500." Date: Mon, 22 Jan 2007 13:26:07 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org RJ Atkinson writes: > Earlier, Brian Carpenter said: > % The problem with that thought experiment is that it fails even in > % thought. There are lots of client/server scenarios where the FQDN of > % the client is unknown or non-existent. It's the identifier (sic) > % presented by the transport layer that is known by the server, and > which > % the server may need to refer to 3rd party servers. > I don't think there is a real problem with taking a client's > identifier (and potentially locator, depending on what layer > one does this and sundry implementation choices) to determine > the right FQDN. > - One can do a reverse lookup on the identifier to get an FQDN > (details omitted for now; this is a thought exercise) > - Even people without Internet clues now generally have both > forward/reverse domain-names associated with their IP address(es). > That FQDN might be of the form c123456.hooville.cox.net, > but for referral purposes the form of the FQDN doesn't > matter. IMO, this assertion needs to be shown to be true. I suspect its very much not. A few years back, I was dealing with a sysadmin that blocked ssh logins from IP addresses for which there was no reverse DNS mapping. I found that when I was on the road, I often couldn't log in. When talking about this with some folk at (I believe) RIPE, they observed that the reverse tree was becoming less and less usefully populated. I'm pretty sure there is data around about this from folk that walk the tree as part of checking delegations and such. Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 24 01:35:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9bhX-0004qw-Uj; Wed, 24 Jan 2007 01:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9bhW-0004qp-UK for ram@iab.org; Wed, 24 Jan 2007 01:33:42 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9bhT-0007kk-GA for ram@iab.org; Wed, 24 Jan 2007 01:33:42 -0500 Received: from webmail50.lax.untd.com (webmail50.lax.untd.com [10.131.27.190]) by smtpout05.lax.untd.com with SMTP id AABC5P9N3A5DWFEA for (sender ); Tue, 23 Jan 2007 22:32:57 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKw1QUW2zSAMhDCFDG0AmZkA== Received: (from fergdawg@netzero.net) by webmail50.lax.untd.com (jqueuemail) id MCT3YE44; Tue, 23 Jan 2007 22:32:51 PST Received: from [24.23.201.115] by webmail50.lax.untd.com with HTTP: Wed, 24 Jan 2007 06:32:29 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Wed, 24 Jan 2007 06:32:29 GMT To: ram@iab.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070123.223251.19107.2004754@webmail50.lax.untd.com> X-ContentStamp: 12:6:3909972327 X-MAIL-INFO: 1018f528d19595a818dddd1838384821ed3175884875cd353d7cc13d99ad3d4d115c75c535a87c9cdcd905bc59b1e9ec78fce9fcfc2db1792945184848e8b58848ac912971c59c896c0d0de9a51555ec X-UNTD-Peer-Info: 10.131.27.190|webmail50.lax.untd.com|webmail50.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf-announce@ietf.org Subject: [RAM] Re: Routing & Addressing -- activities (BOF) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Brian Carpenter wrote: >As part of the routing and addressing activities, a BOF is planned >during IETF 68, as a plenary activity (day and time to be >announced later). This will be tracked in the BOF wiki at = http://www1.tools.ietf.org/bof/trac/wiki > > >Details so far: > > * ROAP > o ROuting and Addressing Problem BOF > o Joint with Internet Area; will be a plenary session > o Status: preliminary discussions > o Background: RAWS report > o Responsible ADs: Ross Callon, Mark Townsley = > >Ross and Mark will be collecting proposals for the goals >and content of the BOF. > Has there been any updates to report on this? :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFtv1zq1pz9mNUZTMRAkGaAJsFS01lmsQ3Hi3BIKWm/F2ef87vBgCdE6Id Z8Ph5XdHfkDAsIZ5Emg9txU=3D =3D6mlM -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jan 25 16:24:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAC3S-0001RU-B8; Thu, 25 Jan 2007 16:22:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAC3P-0001RL-5V for ram@iab.org; Thu, 25 Jan 2007 16:22:44 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAC3N-0003oW-PO for ram@iab.org; Thu, 25 Jan 2007 16:22:43 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B179A198771; Thu, 25 Jan 2007 23:22:40 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6D74E19876F; Thu, 25 Jan 2007 23:22:40 +0200 (EET) Message-ID: <45B91FA2.8010408@piuha.net> Date: Thu, 25 Jan 2007 23:22:42 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Fergie Subject: Re: [RAM] Re: Routing & Addressing -- activities (BOF) References: <20070123.223251.19107.2004754@webmail50.lax.untd.com> In-Reply-To: <20070123.223251.19107.2004754@webmail50.lax.untd.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Fergie, > Has there been any updates to report on this? :-) We are planning to have a meeting in Prague. Logistics and the agenda are still under discussion. But I believe that we are going to have some time in one of the plenaries, as well as time from the Internet and Routing area meetings. In terms of what discussion makes sense at this point, the following items come to my mind: - An update/discussion on what we've learned about the problems related to routing table size and dynamics of routing updates since San Diego. - Discussion about possible improvements in the routing space. For instance, is there something we could do about the UPDATE dynamics? - Discussion about possible improvements in the addressing space, primarily some form of identifier-locator split designs. This discussion should probably focus on the architectural choices, desired functionality and requirements, application impacts etc rather than the actual solutions. (But parallel work on solution ideas is still very welcome -- and ongoing.) Note that the three topics are somewhat independent, e.g., the improvements can be useful for many reasons, not just the problem mentioned above. Thoughts? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 29 11:48:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZfb-0006uy-MF; Mon, 29 Jan 2007 11:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZfZ-0006rv-Nj for ram@iab.org; Mon, 29 Jan 2007 11:47:49 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZfX-0004pM-2o for ram@iab.org; Mon, 29 Jan 2007 11:47:49 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ACB26198772; Mon, 29 Jan 2007 18:47:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5A6E719876E; Mon, 29 Jan 2007 18:47:43 +0200 (EET) Message-ID: <45BE2530.2050600@piuha.net> Date: Mon, 29 Jan 2007 18:47:44 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: ram@iab.org Subject: [RAM] thoughts on draft-farinacci-lisp-00 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, I read the draft and was quite happy with it in terms of something that is intended to be a base for experiments. A couple of observations and questions, however: > LISP As an old Lisp hacker, I like the name of your proposal :-) Now, if you can also name the addresses as CARs and identifiers as CDRs (or maybe that's CIRs)... > The operator community has requested that the IETF take a practical > approach to solving the scaling problems associated with global > routing state growth. This document offers a simple solution which > is intended for use in a pilot program to gain experience in working > on this problem. > > The authors hope that publishing this specification will allow the > rapid implementation of multiple vendor prototypes and deployment on > a small scale. Doing this will help the community: > > o ... > I very much agree with the approach of testing practical solutions and getting experience on what the hard issues really are. Thank you for writing up your prototyping/experimenting plans; we should have more drafts that take this approach. > load-splitting across its members. Is load-splitting a requirement from a traffic engineering perspective? What is the impact from the point of view of the same TCP session ending up going over multiple paths? Note that most of the end-host multihoming work has punted this question by stating that load-balancing is out of scope. Or is there something that you can do to avoid the problem with TCP, such as requiring that traffic from the same EID source/destination pair can never be split across paths? > 3. In LISP 1, the packet is routed through the Internet as it is > today. In LISP 1.5, the packet is routed on a different topology > which may have EID prefixes distributed and advertised in an > aggregatable fashion. In either case, the packet arrives at the > ETR. I like this, because it means that applications that are unaware that they are dealing with EIDs can leak them to other hosts, and those hosts will still be use the EIDs, because they are routable. However, presumably this means that for LISP 1, there is no change in the size of the routing table needed in the global Internet. Every site has to be able to be reachable with EIDs. (Conversely, in LISP 3 & 4, you would have the application referral problem.) > RLOC unreachability is > detected by the receipt of ICMP Host Unreachable messages. When an > RLOC has been determined unreachable, it is not used for active > traffic; this is the same as if it is listed in a Mapping Reply with > priority 255. I'm a bit uncomfortable with relying solely on ICMP for this function. What happens if something filters it away, will you be able to recover? Also, the failure/reachability part probably needs more work in general. When do you switch back from a situation where the RLOC has been determined as unreachable? > LISP is designed to be very hardware-based forwarding friendly. By > doing tunnel header prepending [RFC1955] and stripping instead of re- > writing addresses, existing hardware can support the forwarding model > with little or no modification. Where modifications are required, > they should be limited to re-programming existing hardware rather > than requiring expensive design changes to hard-coded algorithms in > silicon. > Sounds good. > EID-prefix-to-Locator mappings need to be explicitly configured. Can you expand on what this means? So, for instance, in the first hop router case, what would we have to configure? The EID prefix advertised in the local network -- but wouldn't we have to configure a prefix anyway? Or the mapping between the router's RLOC and this prefix? But even that might be obvious, assuming that the Lisp feature is turned on and that you have one prefix in the local network and one RLOC from higher up... > o Experiment with provider-independent assignment of EIDs Any thoughts on what this would be? Either for the experiment or for a full-blown solution later? That is, what space would be allocating the EIDs from? Would they be syntactically distinguishable from regular addresses? > ICMP EID-to-RLOC Reply messages are authoritative to the same extent > DNS Replies are. LISP is no less secure than DNS and at this time we > do not intend to add any additional security mechanisms to the > proposal. > I am not sure the comparison to DNS is correct. A different comparison would be to look at what attackers in different locations (on path, off path, peers) can do and whether there is something that changes in this proposal. If Request - Reply is defined so that only the Reply has an effect and that suitable Reply contents cannot be guessed by off-path attackers, then I think we have roughly what we already have for Internet security: on-path attackers will be able to cause problems, but there is some weak protection against off-path attackers. This is mostly good enough, I think. But I suspect there are details that the draft did not go into. For instance, wouldn't there be a need for a router to tell its peer that the router's own addresses have changed? How would that be implemented with only Request and Reply? > 2. The default router is configured as an ITR. It prepends a LISP > header to the packet, with one of it's RLOCs as the source IP > address and uses the destination EID from the original packet > header as the destination IP address. How does the ITR know that it can use LISP towards this destination? Is it syntactically obvious from the destination EID, is it configured, or is it dynamically learned? > o Experiment with mobility to determine if both acceptable > convergence and session survivability properties can be scalably > implemented to support both individual device roaming and site > service provider changes. > The draft does not have a lot of other text on mobility. I suspect there are details to be worked out... for instance, would this be able to provide a rendezvous function for simultaneously moving hosts? And it seems to preclude talking to legacy hosts while moving. And here are also some editorial comments while I'm at it: > When a data packet triggers a Reply to be sent, the RLOC associated > with the EID-prefix matched by the EID in the original packet > destination IP address field will be returned. Did you mean "the RLOCs associated ...."? Presumably there must be multiple RLOCs per EID or EID prefix. > [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol > (HIP) Architecture", RFC 4423, May 2006. > Why was this listed as a normative reference? Were you using something from this RFC? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jan 29 11:56:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZnX-0003L8-Kc; Mon, 29 Jan 2007 11:56:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZnW-0003L1-LP for ram@iab.org; Mon, 29 Jan 2007 11:56:02 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZnV-0006JO-Bj for ram@iab.org; Mon, 29 Jan 2007 11:56:02 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0TGttmm001318 for ; Mon, 29 Jan 2007 11:55:55 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0TGttG7471886 for ; Mon, 29 Jan 2007 09:55:55 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0TGttXv023593 for ; Mon, 29 Jan 2007 09:55:55 -0700 Received: from cichlid (wecm-9-67-124-97.wecm.ibm.com [9.67.124.97]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0TGtsGU023527; Mon, 29 Jan 2007 09:55:54 -0700 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l0TGvKWd008798; Mon, 29 Jan 2007 11:57:20 -0500 Message-Id: <200701291657.l0TGvKWd008798@cichlid> To: Jari Arkko Subject: Re: [RAM] Re: Routing & Addressing -- activities (BOF) In-reply-to: <45B91FA2.8010408@piuha.net> References: <20070123.223251.19107.2004754@webmail50.lax.untd.com> <45B91FA2.8010408@piuha.net> Comments: In-reply-to Jari Arkko message dated "Thu, 25 Jan 2007 23:22:42 +0200." Date: Mon, 29 Jan 2007 11:57:20 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > - An update/discussion on what we've learned about the problems > related to routing table size and dynamics of routing updates > since San Diego. I think it is fairly important that we have a shared understanding of the problem (so that any work we do in this area, actually has a positive impact on the problems/concerns that people have). I'd encourage people to have a look at Section 7 of draft-iab-raws-report-00.txt. Does the text adequately capture what people consider to be the key issue(s)? Thomas _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jan 30 18:34:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Sb-0001RP-Lh; Tue, 30 Jan 2007 18:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Sa-0001RG-NA for ram@ietf.org; Tue, 30 Jan 2007 18:32:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2SZ-0006Px-LH for ram@ietf.org; Tue, 30 Jan 2007 18:32:20 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2007 15:32:16 -0800 X-IronPort-AV: i="4.13,259,1167638400"; d="scan'208"; a="384096933:sNHT974844514" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0UNWFIY008013 for ; Tue, 30 Jan 2007 15:32:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0UNWEDk021283 for ; Tue, 30 Jan 2007 15:32:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 15:32:12 -0800 Received: from [10.32.244.218] ([10.32.244.218]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 15:32:11 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@ietf.org From: Fred Baker Date: Tue, 30 Jan 2007 15:32:15 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jan 2007 23:32:11.0982 (UTC) FILETIME=[DDDD26E0:01C744C6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21497; t=1170199935; x=1171063935; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20be=20afraid... |Sender:=20; bh=BRZFNOG6pdbWYT6cgi9qRpDG6y9rtKO7sNg7s39y0AA=; b=uc25bQAJZQYmNfFCc7bK9MGAAWFPc6YtD42t8teHrpmCu78FThyQx6DTPIyXRhWSEOawFAhb 5JVaxwpsHp8ZQ1sx4oX8TcOMxW1C/oG0PDr/XlBOIAgAvh6lBfkIeL4D; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Cc: Subject: [RAM] be afraid... X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Begin forwarded message: > From: "Brett Thorson" > Date: January 30, 2007 7:13:12 AM PST > To: "'NAv6TF'" > Subject: [nav6tf] IP Addressing Thoughts > Reply-To: nav6tf@HandyNerds.com > > I received this e-mail from a gentleman in our government. He was > wondering if we had any thoughts on his IP Addressing methodology. > I'll > be happy to collect answers and post them to our soon to be FAQ. I > have > included his name and e-mail at the bottom (with his permission) so > if you > wanted to CC him in on this discussion, feel free to do so. > > My own comment: I think it is great to see government entities that > aren't > under the OMB mandate to be looking into IPv6. Finally, people who > understand!! > > --Brett > > A little background may help - I work for the Administrative Office > of the > United States Courts, the third branch of the federal government. > We have > a large WAN with more than 600 endpoints that is based on IPv4. > Recognizing that the future will be here before we realize, > planning for > IPv6 has started even though as the third branch, we are not bound > by OMB > mandates, or other executive branch dictates. > > One of the issues we are looking at is how best to use the large > address > space that IPv6 will provide. The addresses used in the current > network > are distributed geographically. This was originally done as the first > iteration of our WAN was a hub-and-spoke architecture. > > One thought that came to mind was to distribute IPv6 addresses > based on > the class of/quality of service required. VOIP would get one range of > addresses, non real-time data another, etc... - sort of like a big > brother > to MPLS. Routers could be connected to different WAN backbone > architectures such as one port to a point-to-point low latency link > for > voice, another port to a frame relay or similar slower less QoS/CoS > aware > protocol for e-mail, etc.. Based on the network address the router > would > place the data packet on the correct WAN network port. Different > length > queues could be set up for each port to keep all traffic flowing > smoothly. > > Has any other organization given any thought to such an addressing > scheme? > Are there any problems that this would cause? > > It just seemed to make more sense from the wide area network > perspective > than MPLS. This scheme may also allow router resources such as CPU > cycles, to be dedicated to particular types of traffic - maybe > there are > different router architectures that would be better with forwarding > voice > packets over UDP others forwarding non-real time data over TCP. > > Steven Eiserman > Office of Information Technology/Infrastructure Management Division > Administrative Office of the U.S. Courts > Steve_Eiserman@ao.uscourts.gov Begin forwarded message: > From: "Davis, Terry L" > Date: January 30, 2007 7:20:38 AM PST > To: , "NAv6TF" > Subject: RE: [nav6tf] IP Addressing Thoughts > > Brett > > I have several charts on the very addressing concept that he is > suggesting. I believe that type of addressing architecture will be > critical to fully developing a QoS that will support needs like voice > and real-time in the coming generation of Internet services. It also > fits very nicely with the way commercial aircraft are designed > already. > > Take care > Terry > >> -----Original Message----- >> From: Brett Thorson [mailto:nav6tf@HandyNerds.com] >> Sent: Tuesday, January 30, 2007 7:13 AM >> To: 'NAv6TF' >> Subject: [nav6tf] IP Addressing Thoughts >> >> I received this e-mail from a gentleman in our government. He was >> wondering if we had any thoughts on his IP Addressing methodology. > I'll >> be happy to collect answers and post them to our soon to be FAQ. I > have >> included his name and e-mail at the bottom (with his permission) >> so if > you >> wanted to CC him in on this discussion, feel free to do so. >> >> My own comment: I think it is great to see government entities that > aren't >> under the OMB mandate to be looking into IPv6. Finally, people who >> understand!! >> >> --Brett >> >> A little background may help - I work for the Administrative >> Office of > the >> United States Courts, the third branch of the federal government. We > have >> a large WAN with more than 600 endpoints that is based on IPv4. >> Recognizing that the future will be here before we realize, planning > for >> IPv6 has started even though as the third branch, we are not bound by > OMB >> mandates, or other executive branch dictates. >> >> One of the issues we are looking at is how best to use the large > address >> space that IPv6 will provide. The addresses used in the current > network >> are distributed geographically. This was originally done as the >> first >> iteration of our WAN was a hub-and-spoke architecture. >> >> One thought that came to mind was to distribute IPv6 addresses based > on >> the class of/quality of service required. VOIP would get one >> range of >> addresses, non real-time data another, etc... - sort of like a big > brother >> to MPLS. Routers could be connected to different WAN backbone >> architectures such as one port to a point-to-point low latency link > for >> voice, another port to a frame relay or similar slower less QoS/CoS > aware >> protocol for e-mail, etc.. Based on the network address the router > would >> place the data packet on the correct WAN network port. Different > length >> queues could be set up for each port to keep all traffic flowing > smoothly. >> >> Has any other organization given any thought to such an addressing > scheme? >> Are there any problems that this would cause? >> >> It just seemed to make more sense from the wide area network > perspective >> than MPLS. This scheme may also allow router resources such as CPU >> cycles, to be dedicated to particular types of traffic - maybe there > are >> different router architectures that would be better with forwarding > voice >> packets over UDP others forwarding non-real time data over TCP. >> >> Steven Eiserman >> Office of Information Technology/Infrastructure Management Division >> Administrative Office of the U.S. Courts >> Steve_Eiserman@ao.uscourts.gov Begin forwarded message: > From: "Dave Green" > Date: January 30, 2007 7:45:10 AM PST > To: nav6tf@HandyNerds.com, "NAv6TF" > Cc: "Stephen Oronte" > Subject: RE: [nav6tf] IP Addressing Thoughts > > This is great - IPv6 lets us think "Out of the IPv4 Box" and > differentiate services in many ways. > > VOIP/SIP should be an E2E service with special handling, special > security, etc... different from routine client-server traffic like > e-mail and web browsing. SIP/VOIP addresses should be advertised > into a naming service (like DNS) and have special handling (IE the > firewall allows incoming) and - they need special QOS handling. If > your SIP/voip address block has a complete separate IP architecture > and different routing to get better QOS and an E2E model, great - > that's easy to do with IPv6 addressing. You could also achieve > multi-level security in that architecture with IPsec and priority > handling with flow labels, we just have to do the development to > make it happen. With the vast address space available, extension > headers, and flow labels in IPv6 you have a tool kit to accomplish > this sort of QOS+security differentiation for VOIP. > > I know that with the technology available today, we can do > simulation aided design and testing and rapidly prototype and > deploy the VOIP net Steven Eiserman is thinking of. We now have > great IP address management (IPAM) tools like IPAL and IPControl > that let us quickly design out different architectures with an IPv6 > address space, then we can do virtual-live simulation with OPNET to > see the QOS difference with live phones before deploying it. The > technology is here to get this sort of return on investment from > utilizing IPv6 to help solve real problems - this is a great > example where tech investment dollars should be invested in IPv6 > applications to improve actual operations. Going from "mandate" to > "mission" is what will get IPv6 in widespread use. > > David Green > VP of Research and Development | Command Information > 13655 Dulles Technology Drive, Herndon, VA 20171 > Office: 703.561.5937 | Mobile: +1-703-899-9663 > Green@Commandinformation.com > > > -----Original Message----- > From: owner-nav6tf@ipv6forum.com [mailto:owner- > nav6tf@ipv6forum.com] On Behalf Of Brett Thorson > Sent: Tuesday, January 30, 2007 10:13 AM > To: 'NAv6TF' > Subject: [nav6tf] IP Addressing Thoughts > > I received this e-mail from a gentleman in our government. He was > wondering if we had any thoughts on his IP Addressing methodology. > I'll > be happy to collect answers and post them to our soon to be FAQ. I > have > included his name and e-mail at the bottom (with his permission) so > if you > wanted to CC him in on this discussion, feel free to do so. > > My own comment: I think it is great to see government entities that > aren't > under the OMB mandate to be looking into IPv6. Finally, people who > understand!! > > --Brett > > A little background may help - I work for the Administrative Office > of the > United States Courts, the third branch of the federal government. > We have > a large WAN with more than 600 endpoints that is based on IPv4. > Recognizing that the future will be here before we realize, > planning for > IPv6 has started even though as the third branch, we are not bound > by OMB > mandates, or other executive branch dictates. > > One of the issues we are looking at is how best to use the large > address > space that IPv6 will provide. The addresses used in the current > network > are distributed geographically. This was originally done as the first > iteration of our WAN was a hub-and-spoke architecture. > > One thought that came to mind was to distribute IPv6 addresses > based on > the class of/quality of service required. VOIP would get one range of > addresses, non real-time data another, etc... - sort of like a big > brother > to MPLS. Routers could be connected to different WAN backbone > architectures such as one port to a point-to-point low latency link > for > voice, another port to a frame relay or similar slower less QoS/CoS > aware > protocol for e-mail, etc.. Based on the network address the router > would > place the data packet on the correct WAN network port. Different > length > queues could be set up for each port to keep all traffic flowing > smoothly. > > Has any other organization given any thought to such an addressing > scheme? > Are there any problems that this would cause? > > It just seemed to make more sense from the wide area network > perspective > than MPLS. This scheme may also allow router resources such as CPU > cycles, to be dedicated to particular types of traffic - maybe > there are > different router architectures that would be better with forwarding > voice > packets over UDP others forwarding non-real time data over TCP. > > Steven Eiserman > Office of Information Technology/Infrastructure Management Division > Administrative Office of the U.S. Courts > Steve_Eiserman@ao.uscourts.gov Begin forwarded message: > From: "Martin, Cynthia" > Date: January 30, 2007 7:45:16 AM PST > To: , "NAv6TF" > Subject: RE: [nav6tf] IP Addressing Thoughts > > Good Morning, > > The IRS and other federal agencies are already testing this as part of > their migration to an MPLS core with an IPv6 overlay. It's a very > good > migration strategy and solves some problems at the end system. > > -----Original Message----- > From: owner-nav6tf@ipv6forum.com [mailto:owner- > nav6tf@ipv6forum.com] On > Behalf Of Brett Thorson > Sent: Tuesday, January 30, 2007 10:13 AM > To: 'NAv6TF' > Subject: [nav6tf] IP Addressing Thoughts > > I received this e-mail from a gentleman in our government. He was > wondering if we had any thoughts on his IP Addressing methodology. > I'll > be happy to collect answers and post them to our soon to be FAQ. I > have > included his name and e-mail at the bottom (with his permission) so if > you > wanted to CC him in on this discussion, feel free to do so. > > My own comment: I think it is great to see government entities that > aren't > under the OMB mandate to be looking into IPv6. Finally, people who > understand!! > > --Brett > > A little background may help - I work for the Administrative Office of > the > United States Courts, the third branch of the federal government. We > have > a large WAN with more than 600 endpoints that is based on IPv4. > Recognizing that the future will be here before we realize, > planning for > IPv6 has started even though as the third branch, we are not bound by > OMB > mandates, or other executive branch dictates. > > One of the issues we are looking at is how best to use the large > address > space that IPv6 will provide. The addresses used in the current > network > are distributed geographically. This was originally done as the first > iteration of our WAN was a hub-and-spoke architecture. > > One thought that came to mind was to distribute IPv6 addresses > based on > the class of/quality of service required. VOIP would get one range of > addresses, non real-time data another, etc... - sort of like a big > brother > to MPLS. Routers could be connected to different WAN backbone > architectures such as one port to a point-to-point low latency link > for > voice, another port to a frame relay or similar slower less QoS/CoS > aware > protocol for e-mail, etc.. Based on the network address the router > would > place the data packet on the correct WAN network port. Different > length > queues could be set up for each port to keep all traffic flowing > smoothly. > > Has any other organization given any thought to such an addressing > scheme? > Are there any problems that this would cause? > > It just seemed to make more sense from the wide area network > perspective > than MPLS. This scheme may also allow router resources such as CPU > cycles, to be dedicated to particular types of traffic - maybe > there are > different router architectures that would be better with forwarding > voice > packets over UDP others forwarding non-real time data over TCP. > > Steven Eiserman > Office of Information Technology/Infrastructure Management Division > Administrative Office of the U.S. Courts > Steve_Eiserman@ao.uscourts.gov Begin forwarded message: > From: "Davis, Terry L" > Date: January 30, 2007 8:41:26 AM PST > To: "Dave Green" , > , "NAv6TF" > Cc: "Stephen Oronte" > Subject: RE: [nav6tf] IP Addressing Thoughts > > Dave > > I've got a whole set of slides along these lines that I have > developed over the last half dozen years; it also works for in home > services. > > On the military side, it gives a theater commander especially a > whole set of options to merge his various services' networks too. > As the slides also point out, the guys on the military side could > also adopt their IFF coding to do part of the network authentication. > > Take care > Terry > >> -----Original Message----- >> From: Dave Green [mailto:green@commandinformation.com] >> Sent: Tuesday, January 30, 2007 7:45 AM >> To: nav6tf@HandyNerds.com; NAv6TF >> Cc: Stephen Oronte >> Subject: RE: [nav6tf] IP Addressing Thoughts >> >> This is great - IPv6 lets us think "Out of the IPv4 Box" and >> differentiate >> services in many ways. >> >> VOIP/SIP should be an E2E service with special handling, special >> security, >> etc... different from routine client-server traffic like e-mail >> and web >> browsing. SIP/VOIP addresses should be advertised into a naming >> service >> (like DNS) and have special handling (IE the firewall allows >> incoming) and >> - they need special QOS handling. If your SIP/voip address block >> has a >> complete separate IP architecture and different routing to get >> better QOS >> and an E2E model, great - that's easy to do with IPv6 addressing. You >> could also achieve multi-level security in that architecture with >> IPsec >> and priority handling with flow labels, we just have to do the >> development >> to make it happen. With the vast address space available, extension >> headers, and flow labels in IPv6 you have a tool kit to accomplish >> this >> sort of QOS+security differentiation for VOIP. >> >> I know that with the technology available today, we can do simulation >> aided design and testing and rapidly prototype and deploy the VOIP >> net >> Steven Eiserman is thinking of. We now have great IP address >> management >> (IPAM) tools like IPAL and IPControl that let us quickly design out >> different architectures with an IPv6 address space, then we can do >> virtual-live simulation with OPNET to see the QOS difference with >> live >> phones before deploying it. The technology is here to get this >> sort of >> return on investment from utilizing IPv6 to help solve real >> problems - >> this is a great example where tech investment dollars should be >> invested >> in IPv6 applications to improve actual operations. Going from >> "mandate" to >> "mission" is what will get IPv6 in widespread use. >> >> David Green >> VP of Research and Development | Command Information >> 13655 Dulles Technology Drive, Herndon, VA 20171 >> Office: 703.561.5937 | Mobile: +1-703-899-9663 >> Green@Commandinformation.com >> >> >> -----Original Message----- >> From: owner-nav6tf@ipv6forum.com [mailto:owner- >> nav6tf@ipv6forum.com] On >> Behalf Of Brett Thorson >> Sent: Tuesday, January 30, 2007 10:13 AM >> To: 'NAv6TF' >> Subject: [nav6tf] IP Addressing Thoughts >> >> I received this e-mail from a gentleman in our government. He was >> wondering if we had any thoughts on his IP Addressing >> methodology. I'll >> be happy to collect answers and post them to our soon to be FAQ. >> I have >> included his name and e-mail at the bottom (with his permission) >> so if you >> wanted to CC him in on this discussion, feel free to do so. >> >> My own comment: I think it is great to see government entities >> that aren't >> under the OMB mandate to be looking into IPv6. Finally, people who >> understand!! >> >> --Brett >> >> A little background may help - I work for the Administrative >> Office of the >> United States Courts, the third branch of the federal government. >> We have >> a large WAN with more than 600 endpoints that is based on IPv4. >> Recognizing that the future will be here before we realize, >> planning for >> IPv6 has started even though as the third branch, we are not bound >> by OMB >> mandates, or other executive branch dictates. >> >> One of the issues we are looking at is how best to use the large >> address >> space that IPv6 will provide. The addresses used in the current >> network >> are distributed geographically. This was originally done as the >> first >> iteration of our WAN was a hub-and-spoke architecture. >> >> One thought that came to mind was to distribute IPv6 addresses >> based on >> the class of/quality of service required. VOIP would get one >> range of >> addresses, non real-time data another, etc... - sort of like a big >> brother >> to MPLS. Routers could be connected to different WAN backbone >> architectures such as one port to a point-to-point low latency >> link for >> voice, another port to a frame relay or similar slower less QoS/ >> CoS aware >> protocol for e-mail, etc.. Based on the network address the >> router would >> place the data packet on the correct WAN network port. Different >> length >> queues could be set up for each port to keep all traffic flowing >> smoothly. >> >> Has any other organization given any thought to such an addressing >> scheme? >> Are there any problems that this would cause? >> >> It just seemed to make more sense from the wide area network >> perspective >> than MPLS. This scheme may also allow router resources such as CPU >> cycles, to be dedicated to particular types of traffic - maybe >> there are >> different router architectures that would be better with >> forwarding voice >> packets over UDP others forwarding non-real time data over TCP. >> >> Steven Eiserman >> Office of Information Technology/Infrastructure Management Division >> Administrative Office of the U.S. Courts >> Steve_Eiserman@ao.uscourts.gov _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 01:45:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9A6-0002MM-BN; Wed, 31 Jan 2007 01:41:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9A5-0002MB-Dq for ram@ietf.org; Wed, 31 Jan 2007 01:41:41 -0500 Received: from jens242.inetcore.com ([202.33.8.242] helo=inc.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC9A3-0003es-Lz for ram@ietf.org; Wed, 31 Jan 2007 01:41:41 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by inc.inetcore.com (Postfix) with ESMTP id 89732D51D46; Wed, 31 Jan 2007 15:41:24 +0900 (JST) In-Reply-To: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> Content-Transfer-Encoding: 7bit From: Ruri Hiromi Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 15:41:22 +0900 To: Fred Baker X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1b82b4ba484bbe86cdae6d5f8b2d2ccb Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hello, Can I ask you to feed me back what is the afraid point? On 2007/01/31, at 8:32, Fred Baker wrote: > > > Begin forwarded message: > >> From: "Brett Thorson" >> Date: January 30, 2007 7:13:12 AM PST >> To: "'NAv6TF'" >> Subject: [nav6tf] IP Addressing Thoughts >> Reply-To: nav6tf@HandyNerds.com >> >> I received this e-mail from a gentleman in our government. He was >> wondering if we had any thoughts on his IP Addressing >> methodology. I'll >> be happy to collect answers and post them to our soon to be FAQ. >> I have >> included his name and e-mail at the bottom (with his permission) >> so if you >> wanted to CC him in on this discussion, feel free to do so. >> >> My own comment: I think it is great to see government entities >> that aren't >> under the OMB mandate to be looking into IPv6. Finally, people who >> understand!! >> >> --Brett >> >> A little background may help - I work for the Administrative >> Office of the >> United States Courts, the third branch of the federal government. >> We have >> a large WAN with more than 600 endpoints that is based on IPv4. >> Recognizing that the future will be here before we realize, >> planning for >> IPv6 has started even though as the third branch, we are not bound >> by OMB >> mandates, or other executive branch dictates. >> >> One of the issues we are looking at is how best to use the large >> address >> space that IPv6 will provide. The addresses used in the current >> network >> are distributed geographically. This was originally done as the >> first >> iteration of our WAN was a hub-and-spoke architecture. >> >> One thought that came to mind was to distribute IPv6 addresses >> based on >> the class of/quality of service required. VOIP would get one >> range of >> addresses, non real-time data another, etc... - sort of like a big >> brother >> to MPLS. Routers could be connected to different WAN backbone >> architectures such as one port to a point-to-point low latency >> link for >> voice, another port to a frame relay or similar slower less QoS/ >> CoS aware >> protocol for e-mail, etc.. Based on the network address the >> router would >> place the data packet on the correct WAN network port. Different >> length >> queues could be set up for each port to keep all traffic flowing >> smoothly. >> >> Has any other organization given any thought to such an addressing >> scheme? >> Are there any problems that this would cause? >> >> It just seemed to make more sense from the wide area network >> perspective >> than MPLS. This scheme may also allow router resources such as CPU >> cycles, to be dedicated to particular types of traffic - maybe >> there are >> different router architectures that would be better with >> forwarding voice >> packets over UDP others forwarding non-real time data over TCP. >> >> Steven Eiserman >> Office of Information Technology/Infrastructure Management Division >> Administrative Office of the U.S. Courts >> Steve_Eiserman@ao.uscourts.gov > Begin forwarded message: > >> From: "Davis, Terry L" >> Date: January 30, 2007 7:20:38 AM PST >> To: , "NAv6TF" >> Subject: RE: [nav6tf] IP Addressing Thoughts >> >> Brett >> >> I have several charts on the very addressing concept that he is >> suggesting. I believe that type of addressing architecture will be >> critical to fully developing a QoS that will support needs like voice >> and real-time in the coming generation of Internet services. It also >> fits very nicely with the way commercial aircraft are designed >> already. >> >> Take care >> Terry >> >>> -----Original Message----- >>> From: Brett Thorson [mailto:nav6tf@HandyNerds.com] >>> Sent: Tuesday, January 30, 2007 7:13 AM >>> To: 'NAv6TF' >>> Subject: [nav6tf] IP Addressing Thoughts >>> >>> I received this e-mail from a gentleman in our government. He was >>> wondering if we had any thoughts on his IP Addressing methodology. >> I'll >>> be happy to collect answers and post them to our soon to be FAQ. I >> have >>> included his name and e-mail at the bottom (with his permission) >>> so if >> you >>> wanted to CC him in on this discussion, feel free to do so. >>> >>> My own comment: I think it is great to see government entities that >> aren't >>> under the OMB mandate to be looking into IPv6. Finally, people who >>> understand!! >>> >>> --Brett >>> >>> A little background may help - I work for the Administrative >>> Office of >> the >>> United States Courts, the third branch of the federal >>> government. We >> have >>> a large WAN with more than 600 endpoints that is based on IPv4. >>> Recognizing that the future will be here before we realize, planning >> for >>> IPv6 has started even though as the third branch, we are not >>> bound by >> OMB >>> mandates, or other executive branch dictates. >>> >>> One of the issues we are looking at is how best to use the large >> address >>> space that IPv6 will provide. The addresses used in the current >> network >>> are distributed geographically. This was originally done as the >>> first >>> iteration of our WAN was a hub-and-spoke architecture. >>> >>> One thought that came to mind was to distribute IPv6 addresses based >> on >>> the class of/quality of service required. VOIP would get one >>> range of >>> addresses, non real-time data another, etc... - sort of like a big >> brother >>> to MPLS. Routers could be connected to different WAN backbone >>> architectures such as one port to a point-to-point low latency link >> for >>> voice, another port to a frame relay or similar slower less QoS/CoS >> aware >>> protocol for e-mail, etc.. Based on the network address the router >> would >>> place the data packet on the correct WAN network port. Different >> length >>> queues could be set up for each port to keep all traffic flowing >> smoothly. >>> >>> Has any other organization given any thought to such an addressing >> scheme? >>> Are there any problems that this would cause? >>> >>> It just seemed to make more sense from the wide area network >> perspective >>> than MPLS. This scheme may also allow router resources such as CPU >>> cycles, to be dedicated to particular types of traffic - maybe there >> are >>> different router architectures that would be better with forwarding >> voice >>> packets over UDP others forwarding non-real time data over TCP. >>> >>> Steven Eiserman >>> Office of Information Technology/Infrastructure Management Division >>> Administrative Office of the U.S. Courts >>> Steve_Eiserman@ao.uscourts.gov > Begin forwarded message: > >> From: "Dave Green" >> Date: January 30, 2007 7:45:10 AM PST >> To: nav6tf@HandyNerds.com, "NAv6TF" >> Cc: "Stephen Oronte" >> Subject: RE: [nav6tf] IP Addressing Thoughts >> >> This is great - IPv6 lets us think "Out of the IPv4 Box" and >> differentiate services in many ways. >> >> VOIP/SIP should be an E2E service with special handling, special >> security, etc... different from routine client-server traffic like >> e-mail and web browsing. SIP/VOIP addresses should be advertised >> into a naming service (like DNS) and have special handling (IE the >> firewall allows incoming) and - they need special QOS handling. If >> your SIP/voip address block has a complete separate IP >> architecture and different routing to get better QOS and an E2E >> model, great - that's easy to do with IPv6 addressing. You could >> also achieve multi-level security in that architecture with IPsec >> and priority handling with flow labels, we just have to do the >> development to make it happen. With the vast address space >> available, extension headers, and flow labels in IPv6 you have a >> tool kit to accomplish this sort of QOS+security differentiation >> for VOIP. >> >> I know that with the technology available today, we can do >> simulation aided design and testing and rapidly prototype and >> deploy the VOIP net Steven Eiserman is thinking of. We now have >> great IP address management (IPAM) tools like IPAL and IPControl >> that let us quickly design out different architectures with an >> IPv6 address space, then we can do virtual-live simulation with >> OPNET to see the QOS difference with live phones before deploying >> it. The technology is here to get this sort of return on >> investment from utilizing IPv6 to help solve real problems - this >> is a great example where tech investment dollars should be >> invested in IPv6 applications to improve actual operations. Going >> from "mandate" to "mission" is what will get IPv6 in widespread use. >> >> David Green >> VP of Research and Development | Command Information >> 13655 Dulles Technology Drive, Herndon, VA 20171 >> Office: 703.561.5937 | Mobile: +1-703-899-9663 >> Green@Commandinformation.com >> >> >> -----Original Message----- >> From: owner-nav6tf@ipv6forum.com [mailto:owner- >> nav6tf@ipv6forum.com] On Behalf Of Brett Thorson >> Sent: Tuesday, January 30, 2007 10:13 AM >> To: 'NAv6TF' >> Subject: [nav6tf] IP Addressing Thoughts >> >> I received this e-mail from a gentleman in our government. He was >> wondering if we had any thoughts on his IP Addressing >> methodology. I'll >> be happy to collect answers and post them to our soon to be FAQ. >> I have >> included his name and e-mail at the bottom (with his permission) >> so if you >> wanted to CC him in on this discussion, feel free to do so. >> >> My own comment: I think it is great to see government entities >> that aren't >> under the OMB mandate to be looking into IPv6. Finally, people who >> understand!! >> >> --Brett >> >> A little background may help - I work for the Administrative >> Office of the >> United States Courts, the third branch of the federal government. >> We have >> a large WAN with more than 600 endpoints that is based on IPv4. >> Recognizing that the future will be here before we realize, >> planning for >> IPv6 has started even though as the third branch, we are not bound >> by OMB >> mandates, or other executive branch dictates. >> >> One of the issues we are looking at is how best to use the large >> address >> space that IPv6 will provide. The addresses used in the current >> network >> are distributed geographically. This was originally done as the >> first >> iteration of our WAN was a hub-and-spoke architecture. >> >> One thought that came to mind was to distribute IPv6 addresses >> based on >> the class of/quality of service required. VOIP would get one >> range of >> addresses, non real-time data another, etc... - sort of like a big >> brother >> to MPLS. Routers could be connected to different WAN backbone >> architectures such as one port to a point-to-point low latency >> link for >> voice, another port to a frame relay or similar slower less QoS/ >> CoS aware >> protocol for e-mail, etc.. Based on the network address the >> router would >> place the data packet on the correct WAN network port. Different >> length >> queues could be set up for each port to keep all traffic flowing >> smoothly. >> >> Has any other organization given any thought to such an addressing >> scheme? >> Are there any problems that this would cause? >> >> It just seemed to make more sense from the wide area network >> perspective >> than MPLS. This scheme may also allow router resources such as CPU >> cycles, to be dedicated to particular types of traffic - maybe >> there are >> different router architectures that would be better with >> forwarding voice >> packets over UDP others forwarding non-real time data over TCP. >> >> Steven Eiserman >> Office of Information Technology/Infrastructure Management Division >> Administrative Office of the U.S. Courts >> Steve_Eiserman@ao.uscourts.gov > Begin forwarded message: > >> From: "Martin, Cynthia" >> Date: January 30, 2007 7:45:16 AM PST >> To: , "NAv6TF" >> Subject: RE: [nav6tf] IP Addressing Thoughts >> >> Good Morning, >> >> The IRS and other federal agencies are already testing this as >> part of >> their migration to an MPLS core with an IPv6 overlay. It's a very >> good >> migration strategy and solves some problems at the end system. >> >> -----Original Message----- >> From: owner-nav6tf@ipv6forum.com [mailto:owner- >> nav6tf@ipv6forum.com] On >> Behalf Of Brett Thorson >> Sent: Tuesday, January 30, 2007 10:13 AM >> To: 'NAv6TF' >> Subject: [nav6tf] IP Addressing Thoughts >> >> I received this e-mail from a gentleman in our government. He was >> wondering if we had any thoughts on his IP Addressing >> methodology. I'll >> be happy to collect answers and post them to our soon to be FAQ. >> I have >> included his name and e-mail at the bottom (with his permission) >> so if >> you >> wanted to CC him in on this discussion, feel free to do so. >> >> My own comment: I think it is great to see government entities that >> aren't >> under the OMB mandate to be looking into IPv6. Finally, people who >> understand!! >> >> --Brett >> >> A little background may help - I work for the Administrative >> Office of >> the >> United States Courts, the third branch of the federal government. We >> have >> a large WAN with more than 600 endpoints that is based on IPv4. >> Recognizing that the future will be here before we realize, >> planning for >> IPv6 has started even though as the third branch, we are not bound by >> OMB >> mandates, or other executive branch dictates. >> >> One of the issues we are looking at is how best to use the large >> address >> space that IPv6 will provide. The addresses used in the current >> network >> are distributed geographically. This was originally done as the >> first >> iteration of our WAN was a hub-and-spoke architecture. >> >> One thought that came to mind was to distribute IPv6 addresses >> based on >> the class of/quality of service required. VOIP would get one >> range of >> addresses, non real-time data another, etc... - sort of like a big >> brother >> to MPLS. Routers could be connected to different WAN backbone >> architectures such as one port to a point-to-point low latency >> link for >> voice, another port to a frame relay or similar slower less QoS/CoS >> aware >> protocol for e-mail, etc.. Based on the network address the router >> would >> place the data packet on the correct WAN network port. Different >> length >> queues could be set up for each port to keep all traffic flowing >> smoothly. >> >> Has any other organization given any thought to such an addressing >> scheme? >> Are there any problems that this would cause? >> >> It just seemed to make more sense from the wide area network >> perspective >> than MPLS. This scheme may also allow router resources such as CPU >> cycles, to be dedicated to particular types of traffic - maybe >> there are >> different router architectures that would be better with forwarding >> voice >> packets over UDP others forwarding non-real time data over TCP. >> >> Steven Eiserman >> Office of Information Technology/Infrastructure Management Division >> Administrative Office of the U.S. Courts >> Steve_Eiserman@ao.uscourts.gov > Begin forwarded message: > >> From: "Davis, Terry L" >> Date: January 30, 2007 8:41:26 AM PST >> To: "Dave Green" , >> , "NAv6TF" >> Cc: "Stephen Oronte" >> Subject: RE: [nav6tf] IP Addressing Thoughts >> >> Dave >> >> I've got a whole set of slides along these lines that I have >> developed over the last half dozen years; it also works for in >> home services. >> >> On the military side, it gives a theater commander especially a >> whole set of options to merge his various services' networks too. >> As the slides also point out, the guys on the military side could >> also adopt their IFF coding to do part of the network authentication. >> >> Take care >> Terry >> >>> -----Original Message----- >>> From: Dave Green [mailto:green@commandinformation.com] >>> Sent: Tuesday, January 30, 2007 7:45 AM >>> To: nav6tf@HandyNerds.com; NAv6TF >>> Cc: Stephen Oronte >>> Subject: RE: [nav6tf] IP Addressing Thoughts >>> >>> This is great - IPv6 lets us think "Out of the IPv4 Box" and >>> differentiate >>> services in many ways. >>> >>> VOIP/SIP should be an E2E service with special handling, special >>> security, >>> etc... different from routine client-server traffic like e-mail >>> and web >>> browsing. SIP/VOIP addresses should be advertised into a naming >>> service >>> (like DNS) and have special handling (IE the firewall allows >>> incoming) and >>> - they need special QOS handling. If your SIP/voip address block >>> has a >>> complete separate IP architecture and different routing to get >>> better QOS >>> and an E2E model, great - that's easy to do with IPv6 addressing. >>> You >>> could also achieve multi-level security in that architecture with >>> IPsec >>> and priority handling with flow labels, we just have to do the >>> development >>> to make it happen. With the vast address space available, extension >>> headers, and flow labels in IPv6 you have a tool kit to >>> accomplish this >>> sort of QOS+security differentiation for VOIP. >>> >>> I know that with the technology available today, we can do >>> simulation >>> aided design and testing and rapidly prototype and deploy the >>> VOIP net >>> Steven Eiserman is thinking of. We now have great IP address >>> management >>> (IPAM) tools like IPAL and IPControl that let us quickly design out >>> different architectures with an IPv6 address space, then we can do >>> virtual-live simulation with OPNET to see the QOS difference with >>> live >>> phones before deploying it. The technology is here to get this >>> sort of >>> return on investment from utilizing IPv6 to help solve real >>> problems - >>> this is a great example where tech investment dollars should be >>> invested >>> in IPv6 applications to improve actual operations. Going from >>> "mandate" to >>> "mission" is what will get IPv6 in widespread use. >>> >>> David Green >>> VP of Research and Development | Command Information >>> 13655 Dulles Technology Drive, Herndon, VA 20171 >>> Office: 703.561.5937 | Mobile: +1-703-899-9663 >>> Green@Commandinformation.com >>> >>> >>> -----Original Message----- >>> From: owner-nav6tf@ipv6forum.com [mailto:owner- >>> nav6tf@ipv6forum.com] On >>> Behalf Of Brett Thorson >>> Sent: Tuesday, January 30, 2007 10:13 AM >>> To: 'NAv6TF' >>> Subject: [nav6tf] IP Addressing Thoughts >>> >>> I received this e-mail from a gentleman in our government. He was >>> wondering if we had any thoughts on his IP Addressing >>> methodology. I'll >>> be happy to collect answers and post them to our soon to be FAQ. >>> I have >>> included his name and e-mail at the bottom (with his permission) >>> so if you >>> wanted to CC him in on this discussion, feel free to do so. >>> >>> My own comment: I think it is great to see government entities >>> that aren't >>> under the OMB mandate to be looking into IPv6. Finally, people who >>> understand!! >>> >>> --Brett >>> >>> A little background may help - I work for the Administrative >>> Office of the >>> United States Courts, the third branch of the federal >>> government. We have >>> a large WAN with more than 600 endpoints that is based on IPv4. >>> Recognizing that the future will be here before we realize, >>> planning for >>> IPv6 has started even though as the third branch, we are not >>> bound by OMB >>> mandates, or other executive branch dictates. >>> >>> One of the issues we are looking at is how best to use the large >>> address >>> space that IPv6 will provide. The addresses used in the current >>> network >>> are distributed geographically. This was originally done as the >>> first >>> iteration of our WAN was a hub-and-spoke architecture. >>> >>> One thought that came to mind was to distribute IPv6 addresses >>> based on >>> the class of/quality of service required. VOIP would get one >>> range of >>> addresses, non real-time data another, etc... - sort of like a >>> big brother >>> to MPLS. Routers could be connected to different WAN backbone >>> architectures such as one port to a point-to-point low latency >>> link for >>> voice, another port to a frame relay or similar slower less QoS/ >>> CoS aware >>> protocol for e-mail, etc.. Based on the network address the >>> router would >>> place the data packet on the correct WAN network port. Different >>> length >>> queues could be set up for each port to keep all traffic flowing >>> smoothly. >>> >>> Has any other organization given any thought to such an >>> addressing scheme? >>> Are there any problems that this would cause? >>> >>> It just seemed to make more sense from the wide area network >>> perspective >>> than MPLS. This scheme may also allow router resources such as CPU >>> cycles, to be dedicated to particular types of traffic - maybe >>> there are >>> different router architectures that would be better with >>> forwarding voice >>> packets over UDP others forwarding non-real time data over TCP. >>> >>> Steven Eiserman >>> Office of Information Technology/Infrastructure Management Division >>> Administrative Office of the U.S. Courts >>> Steve_Eiserman@ao.uscourts.gov > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram ------------------------------- Ruri Hiromi hiromi@inetcore.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 01:53:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9KG-0008FP-0i; Wed, 31 Jan 2007 01:52:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9KF-0008FJ-2V for ram@ietf.org; Wed, 31 Jan 2007 01:52:11 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC9KD-0005Uj-J5 for ram@ietf.org; Wed, 31 Jan 2007 01:52:11 -0500 Received: from webmail28.lax.untd.com (webmail28.lax.untd.com [10.131.27.168]) by smtpout02.lax.untd.com with SMTP id AABC6ARESAGAT7WS for (sender ); Tue, 30 Jan 2007 22:52:00 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVqT+yy6VZ9Qr/k/CN/LuHVg== Received: (from fergdawg@netzero.net) by webmail28.lax.untd.com (jqueuemail) id MDD5UHTS; Tue, 30 Jan 2007 22:51:59 PST Received: from [24.23.201.115] by webmail28.lax.untd.com with HTTP: Wed, 31 Jan 2007 06:51:28 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Wed, 31 Jan 2007 06:51:28 GMT To: hiromi@inetcore.com Subject: Re: [RAM] be afraid... X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070130.225159.10883.2067448@webmail28.lax.untd.com> X-ContentStamp: 9:4:2622958597 X-MAIL-INFO: 37f41db454d11dd1d130f4dd55c464e4e45059a0e465f15570752da99931311d74c994b4 X-UNTD-Peer-Info: 10.131.27.168|webmail28.lax.untd.com|webmail28.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Ruri Hiromi wrote: >Hello, > >Can I ask you to feed me back what is the afraid point? > [lots of background context elided] Speaking only for myself, I find it kind of scary that this scheme (using v6 addressing as a QoS scheme) is being considered simply because it is IPv6 (and because there are more addresses to shot our collective selves in the head with). I know a little bit about QoS schemes, and the fact that this exact same scheme can be done in IPv4 is just a little bit scary. Figuratively speaking. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFFwDxiq1pz9mNUZTMRAmYyAKDQCc4qVaalRY3lFB/XQO0rbp1SsQCg24rI +gCGMgZhpIqBZ9tx/HyES9Y=3D =3DULpV -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 04:39:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBtN-0006hQ-1r; Wed, 31 Jan 2007 04:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBtL-0006h7-MZ for ram@ietf.org; Wed, 31 Jan 2007 04:36:35 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBtK-0007OJ-8l for ram@ietf.org; Wed, 31 Jan 2007 04:36:35 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0V9XRMo009205; Wed, 31 Jan 2007 11:33:41 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:36:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:36:07 +0200 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: [RAM] be afraid... Date: Wed, 31 Jan 2007 11:36:05 +0200 Message-ID: <326A98184EC61140A2569345DB3614C10455D66B@esebe105.NOE.Nokia.com> In-Reply-To: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] be afraid... Thread-Index: AcdExw1ASgLz9P37REOHl02xYzHtBgAT7yMQ References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> From: To: , X-OriginalArrivalTime: 31 Jan 2007 09:36:07.0515 (UTC) FILETIME=[3BECB2B0:01C7451B] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070131113341-23EA9BB0-485CDD48/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org If one would only receive similar letters from ISPs/operators. But why would they bother? NATs are these T.rexes' new but eventually fruitless way to keep competitors at distance.=20 Meanwhile the evolution is extending the IPv4 address with the 16 bit port number (STUN, STUN relay, TURN, ICE, UPnP IGD, Skype, etc.).=20 /Mikael =20 > >> From: "Brett Thorson" >> >> My own comment: I think it is great to see government entities that=20 >> aren't under the OMB mandate to be looking into IPv6. =20 >Finally, people=20 >> who understand!! >> >> --Brett _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 04:43:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBz2-0008U8-2T; Wed, 31 Jan 2007 04:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBz0-0008TB-NW for ram@iab.org; Wed, 31 Jan 2007 04:42:26 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCByn-0001Vl-MK for ram@iab.org; Wed, 31 Jan 2007 04:42:14 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 336DA212F42 for ; Wed, 31 Jan 2007 11:42:10 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EF302212C84 for ; Wed, 31 Jan 2007 11:42:09 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <943F3EBA-FD4A-405C-BCD6-355F02150B03@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: Pekka Nikander Date: Wed, 31 Jan 2007 11:42:08 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [RAM] A new draft about architectural vs. implementation choices X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On January 2 I wrote as follows: > ... in those solutions that are based on rewriting identifiers to > locators and vice versa, there are two "architectural" dimensions: > > 1. Where the rewriting is done logically: "above" transport, > somewhere within transport and/or host part of IP, or "below" the > host part of IP, i.e., as a part of the "routing" system. > > 2. Where the rewriting is done physically: in an application, at > the host (in a library, stack, or close to the device driver), or > in the network > > Those two dimensions are pretty independent, though not absolutely > orthogonal. ... > > I'm writing a draft outlining how to do that... The first, still quite incomplete (and therefore still brief!) version of the promised draft is now available in the repositories: http://www.ietf.org/internet-drafts/draft-nikander-ram-generix- proxying-00.txt (Sorry for the typo on in the name, but I'm not going to fix it during the lifetime of the draft...) --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 05:12:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCQF-00050r-8A; Wed, 31 Jan 2007 05:10:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCQD-00050m-NL for ram@ietf.org; Wed, 31 Jan 2007 05:10:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCQC-0002hy-K9 for ram@ietf.org; Wed, 31 Jan 2007 05:10:33 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2007 02:10:32 -0800 X-IronPort-AV: i="4.13,261,1167638400"; d="scan'208"; a="107315782:sNHT74191032" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0VAAVan023145; Wed, 31 Jan 2007 02:10:31 -0800 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 l0VAARUw029501; Wed, 31 Jan 2007 02:10:27 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 02:10:26 -0800 Received: from [10.32.244.218] ([10.32.244.218]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 02:10:26 -0800 In-Reply-To: <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62D20529-0CBA-4A4B-B809-3740C6440C44@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 02:10:31 -0800 To: Ruri Hiromi X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 10:10:26.0139 (UTC) FILETIME=[06F5CAB0:01C74520] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23204; t=1170238231; x=1171102231; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[RAM]=20be=20afraid... |Sender:=20; bh=wkXW/AAssEhOmxOhYrQi4+vZU6kltQMeEh8CbshCzXE=; b=M1cO/7ZVZsvxlT9ceFoV38kG4zF4k0/89OJb28kRXBt37t3VV+uwNcAuPbHMAfl1Dx17/Nf9 BOrTdsowvkrq2WHINwGjsLfi9wAFTe1k+3KybscZrqJW+a2ySPti6hKc; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ce0328cdf9c90e4680655d09dccace5 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Remind me: how does address aggregation work in this? On Jan 30, 2007, at 10:41 PM, Ruri Hiromi wrote: > Hello, > > Can I ask you to feed me back what is the afraid point? > > On 2007/01/31, at 8:32, Fred Baker wrote: > >> >> >> Begin forwarded message: >> >>> From: "Brett Thorson" >>> Date: January 30, 2007 7:13:12 AM PST >>> To: "'NAv6TF'" >>> Subject: [nav6tf] IP Addressing Thoughts >>> Reply-To: nav6tf@HandyNerds.com >>> >>> I received this e-mail from a gentleman in our government. He was >>> wondering if we had any thoughts on his IP Addressing >>> methodology. I'll >>> be happy to collect answers and post them to our soon to be FAQ. >>> I have >>> included his name and e-mail at the bottom (with his permission) >>> so if you >>> wanted to CC him in on this discussion, feel free to do so. >>> >>> My own comment: I think it is great to see government entities >>> that aren't >>> under the OMB mandate to be looking into IPv6. Finally, people who >>> understand!! >>> >>> --Brett >>> >>> A little background may help - I work for the Administrative >>> Office of the >>> United States Courts, the third branch of the federal >>> government. We have >>> a large WAN with more than 600 endpoints that is based on IPv4. >>> Recognizing that the future will be here before we realize, >>> planning for >>> IPv6 has started even though as the third branch, we are not >>> bound by OMB >>> mandates, or other executive branch dictates. >>> >>> One of the issues we are looking at is how best to use the large >>> address >>> space that IPv6 will provide. The addresses used in the current >>> network >>> are distributed geographically. This was originally done as the >>> first >>> iteration of our WAN was a hub-and-spoke architecture. >>> >>> One thought that came to mind was to distribute IPv6 addresses >>> based on >>> the class of/quality of service required. VOIP would get one >>> range of >>> addresses, non real-time data another, etc... - sort of like a >>> big brother >>> to MPLS. Routers could be connected to different WAN backbone >>> architectures such as one port to a point-to-point low latency >>> link for >>> voice, another port to a frame relay or similar slower less QoS/ >>> CoS aware >>> protocol for e-mail, etc.. Based on the network address the >>> router would >>> place the data packet on the correct WAN network port. Different >>> length >>> queues could be set up for each port to keep all traffic flowing >>> smoothly. >>> >>> Has any other organization given any thought to such an >>> addressing scheme? >>> Are there any problems that this would cause? >>> >>> It just seemed to make more sense from the wide area network >>> perspective >>> than MPLS. This scheme may also allow router resources such as CPU >>> cycles, to be dedicated to particular types of traffic - maybe >>> there are >>> different router architectures that would be better with >>> forwarding voice >>> packets over UDP others forwarding non-real time data over TCP. >>> >>> Steven Eiserman >>> Office of Information Technology/Infrastructure Management Division >>> Administrative Office of the U.S. Courts >>> Steve_Eiserman@ao.uscourts.gov >> Begin forwarded message: >> >>> From: "Davis, Terry L" >>> Date: January 30, 2007 7:20:38 AM PST >>> To: , "NAv6TF" >>> Subject: RE: [nav6tf] IP Addressing Thoughts >>> >>> Brett >>> >>> I have several charts on the very addressing concept that he is >>> suggesting. I believe that type of addressing architecture will be >>> critical to fully developing a QoS that will support needs like >>> voice >>> and real-time in the coming generation of Internet services. It >>> also >>> fits very nicely with the way commercial aircraft are designed >>> already. >>> >>> Take care >>> Terry >>> >>>> -----Original Message----- >>>> From: Brett Thorson [mailto:nav6tf@HandyNerds.com] >>>> Sent: Tuesday, January 30, 2007 7:13 AM >>>> To: 'NAv6TF' >>>> Subject: [nav6tf] IP Addressing Thoughts >>>> >>>> I received this e-mail from a gentleman in our government. He was >>>> wondering if we had any thoughts on his IP Addressing methodology. >>> I'll >>>> be happy to collect answers and post them to our soon to be FAQ. I >>> have >>>> included his name and e-mail at the bottom (with his permission) >>>> so if >>> you >>>> wanted to CC him in on this discussion, feel free to do so. >>>> >>>> My own comment: I think it is great to see government entities that >>> aren't >>>> under the OMB mandate to be looking into IPv6. Finally, people who >>>> understand!! >>>> >>>> --Brett >>>> >>>> A little background may help - I work for the Administrative >>>> Office of >>> the >>>> United States Courts, the third branch of the federal >>>> government. We >>> have >>>> a large WAN with more than 600 endpoints that is based on IPv4. >>>> Recognizing that the future will be here before we realize, >>>> planning >>> for >>>> IPv6 has started even though as the third branch, we are not >>>> bound by >>> OMB >>>> mandates, or other executive branch dictates. >>>> >>>> One of the issues we are looking at is how best to use the large >>> address >>>> space that IPv6 will provide. The addresses used in the current >>> network >>>> are distributed geographically. This was originally done as the >>>> first >>>> iteration of our WAN was a hub-and-spoke architecture. >>>> >>>> One thought that came to mind was to distribute IPv6 addresses >>>> based >>> on >>>> the class of/quality of service required. VOIP would get one >>>> range of >>>> addresses, non real-time data another, etc... - sort of like a big >>> brother >>>> to MPLS. Routers could be connected to different WAN backbone >>>> architectures such as one port to a point-to-point low latency link >>> for >>>> voice, another port to a frame relay or similar slower less QoS/CoS >>> aware >>>> protocol for e-mail, etc.. Based on the network address the router >>> would >>>> place the data packet on the correct WAN network port. Different >>> length >>>> queues could be set up for each port to keep all traffic flowing >>> smoothly. >>>> >>>> Has any other organization given any thought to such an addressing >>> scheme? >>>> Are there any problems that this would cause? >>>> >>>> It just seemed to make more sense from the wide area network >>> perspective >>>> than MPLS. This scheme may also allow router resources such as CPU >>>> cycles, to be dedicated to particular types of traffic - maybe >>>> there >>> are >>>> different router architectures that would be better with forwarding >>> voice >>>> packets over UDP others forwarding non-real time data over TCP. >>>> >>>> Steven Eiserman >>>> Office of Information Technology/Infrastructure Management Division >>>> Administrative Office of the U.S. Courts >>>> Steve_Eiserman@ao.uscourts.gov >> Begin forwarded message: >> >>> From: "Dave Green" >>> Date: January 30, 2007 7:45:10 AM PST >>> To: nav6tf@HandyNerds.com, "NAv6TF" >>> Cc: "Stephen Oronte" >>> Subject: RE: [nav6tf] IP Addressing Thoughts >>> >>> This is great - IPv6 lets us think "Out of the IPv4 Box" and >>> differentiate services in many ways. >>> >>> VOIP/SIP should be an E2E service with special handling, special >>> security, etc... different from routine client-server traffic >>> like e-mail and web browsing. SIP/VOIP addresses should be >>> advertised into a naming service (like DNS) and have special >>> handling (IE the firewall allows incoming) and - they need >>> special QOS handling. If your SIP/voip address block has a >>> complete separate IP architecture and different routing to get >>> better QOS and an E2E model, great - that's easy to do with IPv6 >>> addressing. You could also achieve multi-level security in that >>> architecture with IPsec and priority handling with flow labels, >>> we just have to do the development to make it happen. With the >>> vast address space available, extension headers, and flow labels >>> in IPv6 you have a tool kit to accomplish this sort of QOS >>> +security differentiation for VOIP. >>> >>> I know that with the technology available today, we can do >>> simulation aided design and testing and rapidly prototype and >>> deploy the VOIP net Steven Eiserman is thinking of. We now have >>> great IP address management (IPAM) tools like IPAL and IPControl >>> that let us quickly design out different architectures with an >>> IPv6 address space, then we can do virtual-live simulation with >>> OPNET to see the QOS difference with live phones before deploying >>> it. The technology is here to get this sort of return on >>> investment from utilizing IPv6 to help solve real problems - this >>> is a great example where tech investment dollars should be >>> invested in IPv6 applications to improve actual operations. Going >>> from "mandate" to "mission" is what will get IPv6 in widespread use. >>> >>> David Green >>> VP of Research and Development | Command Information >>> 13655 Dulles Technology Drive, Herndon, VA 20171 >>> Office: 703.561.5937 | Mobile: +1-703-899-9663 >>> Green@Commandinformation.com >>> >>> >>> -----Original Message----- >>> From: owner-nav6tf@ipv6forum.com [mailto:owner- >>> nav6tf@ipv6forum.com] On Behalf Of Brett Thorson >>> Sent: Tuesday, January 30, 2007 10:13 AM >>> To: 'NAv6TF' >>> Subject: [nav6tf] IP Addressing Thoughts >>> >>> I received this e-mail from a gentleman in our government. He was >>> wondering if we had any thoughts on his IP Addressing >>> methodology. I'll >>> be happy to collect answers and post them to our soon to be FAQ. >>> I have >>> included his name and e-mail at the bottom (with his permission) >>> so if you >>> wanted to CC him in on this discussion, feel free to do so. >>> >>> My own comment: I think it is great to see government entities >>> that aren't >>> under the OMB mandate to be looking into IPv6. Finally, people who >>> understand!! >>> >>> --Brett >>> >>> A little background may help - I work for the Administrative >>> Office of the >>> United States Courts, the third branch of the federal >>> government. We have >>> a large WAN with more than 600 endpoints that is based on IPv4. >>> Recognizing that the future will be here before we realize, >>> planning for >>> IPv6 has started even though as the third branch, we are not >>> bound by OMB >>> mandates, or other executive branch dictates. >>> >>> One of the issues we are looking at is how best to use the large >>> address >>> space that IPv6 will provide. The addresses used in the current >>> network >>> are distributed geographically. This was originally done as the >>> first >>> iteration of our WAN was a hub-and-spoke architecture. >>> >>> One thought that came to mind was to distribute IPv6 addresses >>> based on >>> the class of/quality of service required. VOIP would get one >>> range of >>> addresses, non real-time data another, etc... - sort of like a >>> big brother >>> to MPLS. Routers could be connected to different WAN backbone >>> architectures such as one port to a point-to-point low latency >>> link for >>> voice, another port to a frame relay or similar slower less QoS/ >>> CoS aware >>> protocol for e-mail, etc.. Based on the network address the >>> router would >>> place the data packet on the correct WAN network port. Different >>> length >>> queues could be set up for each port to keep all traffic flowing >>> smoothly. >>> >>> Has any other organization given any thought to such an >>> addressing scheme? >>> Are there any problems that this would cause? >>> >>> It just seemed to make more sense from the wide area network >>> perspective >>> than MPLS. This scheme may also allow router resources such as CPU >>> cycles, to be dedicated to particular types of traffic - maybe >>> there are >>> different router architectures that would be better with >>> forwarding voice >>> packets over UDP others forwarding non-real time data over TCP. >>> >>> Steven Eiserman >>> Office of Information Technology/Infrastructure Management Division >>> Administrative Office of the U.S. Courts >>> Steve_Eiserman@ao.uscourts.gov >> Begin forwarded message: >> >>> From: "Martin, Cynthia" >>> Date: January 30, 2007 7:45:16 AM PST >>> To: , "NAv6TF" >>> Subject: RE: [nav6tf] IP Addressing Thoughts >>> >>> Good Morning, >>> >>> The IRS and other federal agencies are already testing this as >>> part of >>> their migration to an MPLS core with an IPv6 overlay. It's a >>> very good >>> migration strategy and solves some problems at the end system. >>> >>> -----Original Message----- >>> From: owner-nav6tf@ipv6forum.com [mailto:owner- >>> nav6tf@ipv6forum.com] On >>> Behalf Of Brett Thorson >>> Sent: Tuesday, January 30, 2007 10:13 AM >>> To: 'NAv6TF' >>> Subject: [nav6tf] IP Addressing Thoughts >>> >>> I received this e-mail from a gentleman in our government. He was >>> wondering if we had any thoughts on his IP Addressing >>> methodology. I'll >>> be happy to collect answers and post them to our soon to be FAQ. >>> I have >>> included his name and e-mail at the bottom (with his permission) >>> so if >>> you >>> wanted to CC him in on this discussion, feel free to do so. >>> >>> My own comment: I think it is great to see government entities that >>> aren't >>> under the OMB mandate to be looking into IPv6. Finally, people who >>> understand!! >>> >>> --Brett >>> >>> A little background may help - I work for the Administrative >>> Office of >>> the >>> United States Courts, the third branch of the federal >>> government. We >>> have >>> a large WAN with more than 600 endpoints that is based on IPv4. >>> Recognizing that the future will be here before we realize, >>> planning for >>> IPv6 has started even though as the third branch, we are not >>> bound by >>> OMB >>> mandates, or other executive branch dictates. >>> >>> One of the issues we are looking at is how best to use the large >>> address >>> space that IPv6 will provide. The addresses used in the current >>> network >>> are distributed geographically. This was originally done as the >>> first >>> iteration of our WAN was a hub-and-spoke architecture. >>> >>> One thought that came to mind was to distribute IPv6 addresses >>> based on >>> the class of/quality of service required. VOIP would get one >>> range of >>> addresses, non real-time data another, etc... - sort of like a big >>> brother >>> to MPLS. Routers could be connected to different WAN backbone >>> architectures such as one port to a point-to-point low latency >>> link for >>> voice, another port to a frame relay or similar slower less QoS/CoS >>> aware >>> protocol for e-mail, etc.. Based on the network address the router >>> would >>> place the data packet on the correct WAN network port. Different >>> length >>> queues could be set up for each port to keep all traffic flowing >>> smoothly. >>> >>> Has any other organization given any thought to such an addressing >>> scheme? >>> Are there any problems that this would cause? >>> >>> It just seemed to make more sense from the wide area network >>> perspective >>> than MPLS. This scheme may also allow router resources such as CPU >>> cycles, to be dedicated to particular types of traffic - maybe >>> there are >>> different router architectures that would be better with forwarding >>> voice >>> packets over UDP others forwarding non-real time data over TCP. >>> >>> Steven Eiserman >>> Office of Information Technology/Infrastructure Management Division >>> Administrative Office of the U.S. Courts >>> Steve_Eiserman@ao.uscourts.gov >> Begin forwarded message: >> >>> From: "Davis, Terry L" >>> Date: January 30, 2007 8:41:26 AM PST >>> To: "Dave Green" , >>> , "NAv6TF" >>> Cc: "Stephen Oronte" >>> Subject: RE: [nav6tf] IP Addressing Thoughts >>> >>> Dave >>> >>> I've got a whole set of slides along these lines that I have >>> developed over the last half dozen years; it also works for in >>> home services. >>> >>> On the military side, it gives a theater commander especially a >>> whole set of options to merge his various services' networks >>> too. As the slides also point out, the guys on the military side >>> could also adopt their IFF coding to do part of the network >>> authentication. >>> >>> Take care >>> Terry >>> >>>> -----Original Message----- >>>> From: Dave Green [mailto:green@commandinformation.com] >>>> Sent: Tuesday, January 30, 2007 7:45 AM >>>> To: nav6tf@HandyNerds.com; NAv6TF >>>> Cc: Stephen Oronte >>>> Subject: RE: [nav6tf] IP Addressing Thoughts >>>> >>>> This is great - IPv6 lets us think "Out of the IPv4 Box" and >>>> differentiate >>>> services in many ways. >>>> >>>> VOIP/SIP should be an E2E service with special handling, special >>>> security, >>>> etc... different from routine client-server traffic like e-mail >>>> and web >>>> browsing. SIP/VOIP addresses should be advertised into a naming >>>> service >>>> (like DNS) and have special handling (IE the firewall allows >>>> incoming) and >>>> - they need special QOS handling. If your SIP/voip address block >>>> has a >>>> complete separate IP architecture and different routing to get >>>> better QOS >>>> and an E2E model, great - that's easy to do with IPv6 >>>> addressing. You >>>> could also achieve multi-level security in that architecture >>>> with IPsec >>>> and priority handling with flow labels, we just have to do the >>>> development >>>> to make it happen. With the vast address space available, extension >>>> headers, and flow labels in IPv6 you have a tool kit to >>>> accomplish this >>>> sort of QOS+security differentiation for VOIP. >>>> >>>> I know that with the technology available today, we can do >>>> simulation >>>> aided design and testing and rapidly prototype and deploy the >>>> VOIP net >>>> Steven Eiserman is thinking of. We now have great IP address >>>> management >>>> (IPAM) tools like IPAL and IPControl that let us quickly design out >>>> different architectures with an IPv6 address space, then we can do >>>> virtual-live simulation with OPNET to see the QOS difference >>>> with live >>>> phones before deploying it. The technology is here to get this >>>> sort of >>>> return on investment from utilizing IPv6 to help solve real >>>> problems - >>>> this is a great example where tech investment dollars should be >>>> invested >>>> in IPv6 applications to improve actual operations. Going from >>>> "mandate" to >>>> "mission" is what will get IPv6 in widespread use. >>>> >>>> David Green >>>> VP of Research and Development | Command Information >>>> 13655 Dulles Technology Drive, Herndon, VA 20171 >>>> Office: 703.561.5937 | Mobile: +1-703-899-9663 >>>> Green@Commandinformation.com >>>> >>>> >>>> -----Original Message----- >>>> From: owner-nav6tf@ipv6forum.com [mailto:owner- >>>> nav6tf@ipv6forum.com] On >>>> Behalf Of Brett Thorson >>>> Sent: Tuesday, January 30, 2007 10:13 AM >>>> To: 'NAv6TF' >>>> Subject: [nav6tf] IP Addressing Thoughts >>>> >>>> I received this e-mail from a gentleman in our government. He was >>>> wondering if we had any thoughts on his IP Addressing >>>> methodology. I'll >>>> be happy to collect answers and post them to our soon to be >>>> FAQ. I have >>>> included his name and e-mail at the bottom (with his permission) >>>> so if you >>>> wanted to CC him in on this discussion, feel free to do so. >>>> >>>> My own comment: I think it is great to see government entities >>>> that aren't >>>> under the OMB mandate to be looking into IPv6. Finally, people who >>>> understand!! >>>> >>>> --Brett >>>> >>>> A little background may help - I work for the Administrative >>>> Office of the >>>> United States Courts, the third branch of the federal >>>> government. We have >>>> a large WAN with more than 600 endpoints that is based on IPv4. >>>> Recognizing that the future will be here before we realize, >>>> planning for >>>> IPv6 has started even though as the third branch, we are not >>>> bound by OMB >>>> mandates, or other executive branch dictates. >>>> >>>> One of the issues we are looking at is how best to use the large >>>> address >>>> space that IPv6 will provide. The addresses used in the current >>>> network >>>> are distributed geographically. This was originally done as the >>>> first >>>> iteration of our WAN was a hub-and-spoke architecture. >>>> >>>> One thought that came to mind was to distribute IPv6 addresses >>>> based on >>>> the class of/quality of service required. VOIP would get one >>>> range of >>>> addresses, non real-time data another, etc... - sort of like a >>>> big brother >>>> to MPLS. Routers could be connected to different WAN backbone >>>> architectures such as one port to a point-to-point low latency >>>> link for >>>> voice, another port to a frame relay or similar slower less QoS/ >>>> CoS aware >>>> protocol for e-mail, etc.. Based on the network address the >>>> router would >>>> place the data packet on the correct WAN network port. Different >>>> length >>>> queues could be set up for each port to keep all traffic flowing >>>> smoothly. >>>> >>>> Has any other organization given any thought to such an >>>> addressing scheme? >>>> Are there any problems that this would cause? >>>> >>>> It just seemed to make more sense from the wide area network >>>> perspective >>>> than MPLS. This scheme may also allow router resources such as CPU >>>> cycles, to be dedicated to particular types of traffic - maybe >>>> there are >>>> different router architectures that would be better with >>>> forwarding voice >>>> packets over UDP others forwarding non-real time data over TCP. >>>> >>>> Steven Eiserman >>>> Office of Information Technology/Infrastructure Management Division >>>> Administrative Office of the U.S. Courts >>>> Steve_Eiserman@ao.uscourts.gov >> >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram > > ------------------------------- > Ruri Hiromi > hiromi@inetcore.com > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 05:41:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCqt-0000Bl-2T; Wed, 31 Jan 2007 05:38:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCqs-0000Bg-Lt for ram@ietf.org; Wed, 31 Jan 2007 05:38:06 -0500 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCqr-0006Nt-14 for ram@ietf.org; Wed, 31 Jan 2007 05:38:06 -0500 Received: from vaioz1.apnic.net (geoff.telstra.net [203.50.0.18]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l0VAbqWW073697; Wed, 31 Jan 2007 21:37:54 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070131212912.04262750@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 31 Jan 2007 21:37:49 +1100 To: Fred Baker , Ruri Hiromi From: Geoff Huston Subject: Re: [RAM] be afraid... In-Reply-To: <62D20529-0CBA-4A4B-B809-3740C6440C44@cisco.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <62D20529-0CBA-4A4B-B809-3740C6440C44@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 09:10 PM 31/01/2007, Fred Baker wrote: >Remind me: how does address aggregation work in this? Precisely! If you are thinking about linking a QoS response to some pre-determined set of values somewhere in the packet header then we've already had a whole heap of fun with the old TOS field, and then a subsequent foray into dynamic filter sets with Intserv followed by the exploration of a redefined TOS field with Diffserv. We've thought from time to time about forms of QoS-distinguished routing. Each of these approaches have had their issues when attempting to think about deployment issues in spaces of the dimension and shape of the public Internet. With this wealth of experience I would've thought that by now we've learned a little bit about driving specialized network responses over the years and one of those lessons is that the address field in the packet header is probably a pretty poor starting point to use to place service response signalling information. Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 05:58:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCD9T-00013x-0q; Wed, 31 Jan 2007 05:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCD9R-00013p-VF for ram@ietf.org; Wed, 31 Jan 2007 05:57:17 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCD9Q-000334-Hl for ram@ietf.org; Wed, 31 Jan 2007 05:57:17 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VAvFmx154430 for ; Wed, 31 Jan 2007 10:57:15 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VAvFkG1257622 for ; Wed, 31 Jan 2007 11:57:15 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VAvEss011974 for ; Wed, 31 Jan 2007 11:57:15 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VAvCE6011956; Wed, 31 Jan 2007 11:57:13 +0100 Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA305094; Wed, 31 Jan 2007 11:57:12 +0100 Message-ID: <45C07607.9040501@zurich.ibm.com> Date: Wed, 31 Jan 2007 11:57:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Ruri Hiromi Subject: Re: [RAM] be afraid... References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> In-Reply-To: <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-31 07:41, Ruri Hiromi wrote: > Hello, > > Can I ask you to feed me back what is the afraid point? Just to repeat what I wrote to another list on this proposal: ...it makes no sense in a world where VoIP, video, and traditional services are mixed on the same subnets and the same devices, which may be mobile anyway. When I use my IP phone it has its own IP address; when I fire up my softphone, it takes over the same SIP and PSTN identity using a different IP address, sometimes on the same wire and sometimes on another continent. Trying to resolve the associated QoS challenges by playing with IP addresses isn't just a layer violation and extra semantic overloading of addresses: more important, it simply won't work. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 09:12:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGAx-0005JG-2J; Wed, 31 Jan 2007 09:11:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGAq-0005Iw-Qi for ram@ietf.org; Wed, 31 Jan 2007 09:10:56 -0500 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCGAp-000667-B7 for ram@ietf.org; Wed, 31 Jan 2007 09:10:56 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0VEAtpS058750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jan 2007 15:10:56 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45C07607.9040501@zurich.ibm.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 15:10:38 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 31-jan-2007, at 11:57, Brian E Carpenter wrote: > more important, it simply won't work. So when has that ever stopped anyone? Obviously the problems are real, but I can see some value in an approach like this. For instance, for VoIP it's important to give VoIP traffic a higher priority than some other types of traffic. For outgoing traffic this is easy to do by looking at port numbers or diffserv code points, but for incoming traffic that's much harder: essentially, you need to tell an ISP how to deal with different kinds of traffic in a great amount of detail. On the other hand, if different kinds of traffic are directed towards different addresses, it's extremely easy to have them flow into different funnels using standard routing protocols. Maybe others have a better view of this, but it's completely unclear to me how real time traffic over the internet is going to play out in the future. I.e., at some point the last TDM equipment will be hauled off to the scrap heap and we'll all be doing phone calls over IP. Note that this is a completely different situation from what we have today, I wouldn't exactly call current phone calls over IP "voice over IP" but rather "last mile over IP" because when calling between different service providers, there's always (> 99%) still a TDM exchange in the middle. Anyway, at this point, it's necessary for phone company A to have VoIP packets find their way across a big IP network towards phone company B. How is this going to work? I don't think phone companies will like the idea of using publicly routable IP addresses that are subject to DoS attacks and so on. On the other hand, with several thousand phone companies world wide, building a private network doesn't really work all that well. Classic case of the irresistible force vs the immovable object. I don't see a clear best way to do this, which probably means that many people will do it in many different ways and it will take a long time for all of this to work itself out. What was so bad about TDM that it needed replacement again? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 09:19:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGIH-00007Y-MB; Wed, 31 Jan 2007 09:18:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGIF-00007O-Fv for ram@ietf.org; Wed, 31 Jan 2007 09:18:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGIE-0004KH-7C for ram@ietf.org; Wed, 31 Jan 2007 09:18:35 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2007 15:18:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0VEIXq3021382; Wed, 31 Jan 2007 15:18:33 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp188.cisco.com [10.61.64.188]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VEIQC8008771; Wed, 31 Jan 2007 15:18:26 +0100 (MET) Message-ID: <45C0A532.8050106@cisco.com> Date: Wed, 31 Jan 2007 15:18:26 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Fred Baker Subject: Re: [RAM] be afraid... References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <62D20529-0CBA-4A4B-B809-3740C6440C44@cisco.com> In-Reply-To: <62D20529-0CBA-4A4B-B809-3740C6440C44@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=157; t=1170253113; x=1171117113; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20be=20afraid... |Sender:=20; bh=p1s+ixeQtxosH4ouabWmpUiYAVsRS6CG2QIyIprE3rs=; b=Y1cl8JYnesJ2wIKkcFRlrmc0SI2E826THYeyroCx/YuNbH66oUcrNr6Eazi0cy1Xg0R1AlHr xGWbQMVbJ9jYL790KZq5degxHnVu0dO3YyGP1QNAfRAHS8/vG+9EAYQs; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Fred Baker wrote: > Remind me: how does address aggregation work in this? > Within the IGP an Nx hit. Reminds me a whole lot of OSPF with TOS. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 09:59:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGtx-0002bY-PH; Wed, 31 Jan 2007 09:57:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGtv-0002Zq-IS for ram@ietf.org; Wed, 31 Jan 2007 09:57:31 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGtu-0008UL-4W for ram@ietf.org; Wed, 31 Jan 2007 09:57:31 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0VEvTgV124752 for ; Wed, 31 Jan 2007 14:57:29 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VEvSaO1331426 for ; Wed, 31 Jan 2007 14:57:28 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VEvSnh021686 for ; Wed, 31 Jan 2007 14:57:28 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VEvRC2021676; Wed, 31 Jan 2007 14:57:27 GMT Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA367144; Wed, 31 Jan 2007 15:57:27 +0100 Message-ID: <45C0AE56.5080906@zurich.ibm.com> Date: Wed, 31 Jan 2007 15:57:26 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] be afraid... References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I don't get your issue with incoming traffic. Diffserv (or flow label, or IntServ, or NSIS) are all designed to work all along the path. Why will there be phone companies, once SIP goes peer to peer? Things are going to be very different a few years from now. Any semantics we try to impose on addresses today will very likely just look quaint ten years from now. Brian On 2007-01-31 15:10, Iljitsch van Beijnum wrote: > On 31-jan-2007, at 11:57, Brian E Carpenter wrote: > >> more important, it simply won't work. > > So when has that ever stopped anyone? > > Obviously the problems are real, but I can see some value in an approach > like this. For instance, for VoIP it's important to give VoIP traffic a > higher priority than some other types of traffic. For outgoing traffic > this is easy to do by looking at port numbers or diffserv code points, > but for incoming traffic that's much harder: essentially, you need to > tell an ISP how to deal with different kinds of traffic in a great > amount of detail. On the other hand, if different kinds of traffic are > directed towards different addresses, it's extremely easy to have them > flow into different funnels using standard routing protocols. > > Maybe others have a better view of this, but it's completely unclear to > me how real time traffic over the internet is going to play out in the > future. I.e., at some point the last TDM equipment will be hauled off to > the scrap heap and we'll all be doing phone calls over IP. Note that > this is a completely different situation from what we have today, I > wouldn't exactly call current phone calls over IP "voice over IP" but > rather "last mile over IP" because when calling between different > service providers, there's always (> 99%) still a TDM exchange in the > middle. > > Anyway, at this point, it's necessary for phone company A to have VoIP > packets find their way across a big IP network towards phone company B. > How is this going to work? I don't think phone companies will like the > idea of using publicly routable IP addresses that are subject to DoS > attacks and so on. On the other hand, with several thousand phone > companies world wide, building a private network doesn't really work all > that well. Classic case of the irresistible force vs the immovable object. > > I don't see a clear best way to do this, which probably means that many > people will do it in many different ways and it will take a long time > for all of this to work itself out. > > What was so bad about TDM that it needed replacement again? > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 10:34:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHS6-0005kG-AK; Wed, 31 Jan 2007 10:32:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHS5-0005jH-BX for ram@iab.org; Wed, 31 Jan 2007 10:32:49 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHS3-0002Ny-1X for ram@iab.org; Wed, 31 Jan 2007 10:32:49 -0500 Received: from [10.18.2.10] (unknown [10.18.2.10]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 238A57941 for ; Wed, 31 Jan 2007 07:32:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Wed, 31 Jan 2007 10:32:40 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [RAM] Re: server referrals X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Earlier Thomas Narten wrote: > IMO, this assertion needs to be shown to be true. > I suspect its very much not. Well, if one is looking to prove assertions, let us please start with proving the unsubstantiated assertion that server referrals necessarily are broken by moving to an ID/Locator split. I've asked for a concrete example of a case where server referrals would be broken. So far, not one single concrete example has appeared on this list and there's been ample time. Now on that point, let me observe that anything that works today with an "address" can trivially work going forward with an I/L architecture, since an "address" is merely the combination of an "identifier and a locator". To give a trivial example from O'Dell, and this is MERELY one example, the same 128 bits would get passed around for existing IPv6 or I/L split IPv6. In fact, SHIM6 would have challenges in this area if anything did, because an application only knows the "IPv6 address misused as Identifier" value and does not knwo the "IPv6 address used as locator" value. So the application (or even the transport-layer) would not know the "locator" value to pass to the other end in the referral. Despite this issue, SHIM6 seems to have some IETF support and "server referrals" don't seem to be a barrier to SHIM6 standardisation. > A few years back, I was dealing with a sysadmin that blocked ssh > logins from IP addresses for which there was no reverse DNS mapping. I > found that when I was on the road, I often couldn't log in. When > talking about this with some folk at (I believe) RIPE, they observed > that the reverse tree was becoming less and less usefully > populated. I'm pretty sure there is data around about this from folk > that walk the tree as part of checking delegations and such Clearly your experience and mine vary. It is useful to understand that there are a range of data points. Certainly for the (US, JP, and EU) places where I can check existence of reverse DNS, it is there in all cases. It is generally of the form I described before, in the ISP's chunk of DNS, rather than having PTR records being in some end-user's domain -- no surprise since my example was with residential broadband ISPs rather than with a commercial service. For commercial services, my employer has had no problems getting suitable forward and reverse DNS entries -- even for globally routable IP addresses that belong to our sundry uplinks. (Internally, by policy, we always use private addressing and NAT, which actually works fine for our uses, as near as I can tell.) Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 12:27:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJDZ-00070t-Py; Wed, 31 Jan 2007 12:25:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJCm-0006QL-GU for ram@ietf.org; Wed, 31 Jan 2007 12:25:08 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJ87-0004TJ-C9 for ram@ietf.org; Wed, 31 Jan 2007 12:20:28 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l0VHKHMT062261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jan 2007 18:20:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45C0AE56.5080906@zurich.ibm.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <45C0AE56.5080906@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B77C2DB-55B9-409B-B59C-FC8891695AC1@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 18:20:01 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 31-jan-2007, at 15:57, Brian E Carpenter wrote: > I don't get your issue with incoming traffic. Diffserv > (or flow label, or IntServ, or NSIS) are all designed > to work all along the path. Sure. But if you were to call me over the net at iljitsch@muada.com (which works, by the way, when I remember to run my SIP client, but nobody ever phones me at my email address so I tend to forget) then I'm in control of the diffserv bits on the packets from me to you (I'm using diffserv because all the other stuff that I'm familiar with has an even lower chance of working) so I can mark the VoIP packets and make sure they're treated better than bulk stuff when they hit my connection to the internet, which is presumably a bottleneck as my internal network is much faster not to mention all the ISP networks along the way. So my exit router does its smart queuing and life is good. But when I stop talking and you say something, packets flow in the other direction. The bottleneck is the same, but for incoming packets, it's the ISP's router (or worse, layer 2 device, remember that most DSL and cable runs over ATM) that has to do the smart queuing. Suppose they use a simple diffserv setup where there is one code point that gets preferential treatment. This would work reasonably well for outgoing traffic, because there I (my applications, OS ro router) set the code point, but for incoming traffic there is no way to make sure only VoIP packets have the high priority code point. An attacker would very likely use packets with all possible code points, for instance. > Why will there be phone companies, once SIP goes peer to peer? Very likely, if we define "phone company" as "corporation that guards access to a large scale communication network and imposes arbitrary restrictions and high fees". What we see today is the US model where basically, you have a choice (if you're lucky) between cable and DSL for broadband, and a different model here in the Netherlands where you can get DSL from many people but they all go over the same monopoly telco wires. Note though that with fiber to the home you probably won't have any choice after the fiber is installed, because internet, phone and TV service will all run over that same fiber. The organization in control of the access network is in the best position to deliver high quality VoIP because they can give their own VoIP and other real time services higher priority on the access network while competitors must work at the "normal" priority and compete with bulk traffic. There are also some long distance backhauling advantages but those probably don't mean much for voice. The ability to keep these services separate from regular internet traffic is also important security-wise. This is where different addresses for different services can help. In enterprise networks we're probably going to see that too: it's probably cheaper in the long run to have a dedicated VoIP wireless network rather than have one big wireless network but suffer from the problems we tend to see during IETF meeting plenaries. > Things are going to be very different a few years from now. > Any semantics we try to impose on addresses today will > very likely just look quaint ten years from now. A good reason to keep them as semantic-free as possible. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 16:46:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNFf-00057q-4j; Wed, 31 Jan 2007 16:44:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNFd-00057i-83 for ram@ietf.org; Wed, 31 Jan 2007 16:44:21 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNFb-0000ns-Ri for ram@ietf.org; Wed, 31 Jan 2007 16:44:21 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HCNFX-0006ym-M2; Wed, 31 Jan 2007 22:44:18 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6F9E7B6B3; Wed, 31 Jan 2007 22:44:15 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HCNFX-0005zb-54; Wed, 31 Jan 2007 22:44:15 +0100 Message-ID: <45C10DAD.2030409@tm.uka.de> Date: Wed, 31 Jan 2007 22:44:13 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070103 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] be afraid... References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <45C0AE56.5080906@zurich.ibm.com> <3B77C2DB-55B9-409B-B59C-FC8891695AC1@muada.com> In-Reply-To: <3B77C2DB-55B9-409B-B59C-FC8891695AC1@muada.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, Iljitsch van Beijnum wrote: > On 31-jan-2007, at 15:57, Brian E Carpenter wrote: > >> I don't get your issue with incoming traffic. Diffserv >> (or flow label, or IntServ, or NSIS) are all designed >> to work all along the path. > > preferential treatment. This would work reasonably well for outgoing > traffic, because there I (my applications, OS ro router) set the code > point, but for incoming traffic there is no way to make sure only VoIP > packets have the high priority code point. An attacker would very likely > use packets with all possible code points, for instance. Two comments: 1) An essential point in the DiffServ architecture is the first-hop router that either should set the DSCP or should not accept any DiffServ packet markings unless that flow was admitted (by a corresponding policy). So boundary routers must strictly protect DiffServ regions from non-admitted traffic, otherwise guarantees are at risk... 2) QoS Signaling: Protocols for signaling the network in order to provide the necessary differentiation for (some of) your incoming flows are currently standardized in the NSIS WG. Optimally this would go to the other end and start there (e2e signaling and QoS), but signaling your provider in order to turn on DiffServ at the last hop router may be a start...however, you need support from the network and the applications for QoS signaling... Regards, Roland _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 17:10:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNdD-0003mx-0K; Wed, 31 Jan 2007 17:08:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNdC-0003mr-Ae for ram@ietf.org; Wed, 31 Jan 2007 17:08:42 -0500 Received: from audl953.usa.alcatel.com ([143.209.238.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNd7-0007nj-Mf for ram@ietf.org; Wed, 31 Jan 2007 17:08:42 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id l0VM8bb4023288; Wed, 31 Jan 2007 16:08:37 -0600 Received: from [128.251.10.114] ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Jan 2007 16:08:36 -0600 In-Reply-To: References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65E1D3E6-1DED-4240-85F3-27F32F6904C6@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 14:08:32 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Jan 2007 22:08:37.0073 (UTC) FILETIME=[5B288410:01C74584] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Resent now that I updated my subscribed email address to match the from. On Jan 31, 2007, at 6:10 AM, Iljitsch van Beijnum wrote: > On 31-jan-2007, at 11:57, Brian E Carpenter wrote: > > >> more important, it simply won't work. >> > > So when has that ever stopped anyone? > > Obviously the problems are real, but I can see some value in an > approach like this. For instance, for VoIP it's important to give > VoIP traffic a higher priority than some other types of traffic. > This point is often made, but without too much consideration as to where prioritization is useful. Priority schemes are useful ONLY when there is contention for resources on the line. A network is usually designed to handle peak loads without congesting (mother's day load in the US voice networks), after all a carrier does not want to turn away business if they don't have to do so. In addition, this metric has been expanded to include "peak load under worst-case single failure." And with the advent of IP, this can be done without needing to double the bandwidth with a SONET/SDH working and protect path. Admittedly, not all networks are designed to this standard for a variety of reasons (too expensive, resources not available, etc.) If a network has the resources available, there is no need for a marking or prioritization scheme. In the most usual state the network will have resources available in most places. Any QoS scheme needs to be designed with an eye toward being lightweight to address the very real case that it will not be necessary most of the time. This point may be obvious, but it is often overlooked. > For outgoing traffic this is easy to do by looking at port numbers > or diffserv code points, but for incoming traffic that's much > harder: essentially, you need to tell an ISP how to deal with > different kinds of traffic in a great amount of detail. On the > other hand, if different kinds of traffic are directed towards > different addresses, it's extremely easy to have them flow into > different funnels using standard routing protocols. > The issue here is not a technical one, it is an issue of trust. Does your operator trust you to mark your VoIP packets correctly, and in a way meaningful to that operator? If your operator is like those I have experience with, then the answer is no. Any markings that are received from a foreign network are either 1) quashed or 2) rewritten to something locally meaningful. The incoming marking (p-bit, diffserv, mpls exp) is only one handle on which the QoS remarking might be done (others are things like port number or virtual circuit). Along these bilateral lines, if we reexamine the VoIP example between two interlocutors A and B: From A to B: A "marking 1" --> DSLAM ---> PE(Y), remarked into "VoIP/EF class", billing counter optionally incremented/ ---> P(Y) --> PE(Y) to provider X with marking "W", meaning "VoIP" based on their bi-lateral contract/ ---> peering link to X ---> PE(X), remarks "W" into "Z", meaning "VoIP" in their QoS scheme ---> P(X)/ ---> PE(X) (optionally incrementing billing counter) ---> DSLAM ---> B's local router, which remarks/ "Z" back into "marking 1" From B to A: The same thing happens in reverse. There is no problem with the reverse path for the markings, because the markings are done network- by-network into locally significant values. These examples assume that the DSLAM is set to understand and respect "marking 1" as having some meaning. This also assumes that there are no Media Gateways, SIP Proxies or other application-specific devices in the data or signaling path. This wouldn't change the QoS model, but the drawing would change. How this is handled is an administrative trust and contractual issue between the two networks involved. As protocol designers, we must make sure that this sort of thing is supported in a flexible manner to operators can do with it as best meets their needs. > Maybe others have a better view of this, but it's completely > unclear to me how real time traffic over the internet is going to > play out in the future. I.e., at some point the last TDM equipment > will be hauled off to the scrap heap and we'll all be doing phone > calls over IP. Note that this is a completely different situation > from what we have today, I wouldn't exactly call current phone > calls over IP "voice over IP" but rather "last mile over IP" > because when calling between different service providers, there's > always (> 99%) still a TDM exchange in the middle. > There will be a network of bilateral peering arrangements between networks that say "If I send you marking A that means "Video", please treat it as you treat "Video" on your network." And there may be billing arrangements between the networks for different contracts of carriage, depending on the economics. The need for differentiated services will be low if the risk of application degradation due to congestion is low. The more resilient bandwidth we have everywhere the less valuable treating bits differently becomes. QoS will exist as an insurance policy against failure and for high-bandwidth applications (streaming sports events in HDTV, for example). > Anyway, at this point, it's necessary for phone company A to have > VoIP packets find their way across a big IP network towards phone > company B. How is this going to work? I don't think phone companies > will like the idea of using publicly routable IP addresses that are > subject to DoS attacks and so on. On the other hand, with several > thousand phone companies world wide, building a private network > doesn't really work all that well. Classic case of the irresistible > force vs the immovable object. > If an operator want to separate traffic based on application that can be done with VPNs today there is no need for IPv6 to do this. Separation is done on a per-network basis, with a gateway function between network to remap QoS, or NAT, if required. Andrew > I don't see a clear best way to do this, which probably means that > many people will do it in many different ways and it will take a > long time for all of this to work itself out. > > What was so bad about TDM that it needed replacement again? > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 17:51:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOFy-0001Wa-0M; Wed, 31 Jan 2007 17:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOFx-0001WV-6G for ram@ietf.org; Wed, 31 Jan 2007 17:48:45 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCOFu-0001xZ-QR for ram@ietf.org; Wed, 31 Jan 2007 17:48:45 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HCOFp-0001Rw-SM; Wed, 31 Jan 2007 23:48:41 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7C03BB6FC; Wed, 31 Jan 2007 23:48:37 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HCOFp-00062R-6M; Wed, 31 Jan 2007 23:48:37 +0100 Message-ID: <45C11CC4.1050503@tm.uka.de> Date: Wed, 31 Jan 2007 23:48:36 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070103 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Andrew Lange Subject: Re: [RAM] be afraid... References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <65E1D3E6-1DED-4240-85F3-27F32F6904C6@alcatel.com> In-Reply-To: <65E1D3E6-1DED-4240-85F3-27F32F6904C6@alcatel.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Andrew, [comments inline] Andrew Lange wrote: > prioritization is useful. Priority schemes are useful ONLY when there > is contention for resources on the line. A network is usually designed > to handle peak loads without congesting (mother's day load in the US > voice networks), after all a carrier does not want to turn away business > if they don't have to do so. In addition, this metric has been expanded > to include "peak load under worst-case single failure." And with the > advent of IP, this can be done without needing to double the bandwidth > with a SONET/SDH working and protect path. Admittedly, not all networks > are designed to this standard for a variety of reasons (too expensive, > resources not available, etc.) If a network has the resources available, > there is no need for a marking or prioritization scheme. In the most > usual state the network will have resources available in most places. > Any QoS scheme needs to be designed with an eye toward being lightweight > to address the very real case that it will not be necessary most of the > time. This point may be obvious, but it is often overlooked. Sure, QoS mechanisms are only required when there is resource shortage. However, "overprovisioned" networks don't provide enough protection against DDoS (here: flooding attacks). So I know at least one provider that introduced prioritized VoIP traffic in order to protect it against congestion caused from "normal" traffic, e.g. caused during DDoS flooding attacks (congestion may be caused in the direction towards access networks, i.e. when descending the bandwidth hierarchy). This makes sense to me... >> For outgoing traffic this is easy to do by looking at port numbers or >> diffserv code points, but for incoming traffic that's much harder: >> essentially, you need to tell an ISP how to deal with different kinds >> of traffic in a great amount of detail. On the other hand, if >> different kinds of traffic are directed towards different addresses, >> it's extremely easy to have them flow into different funnels using >> standard routing protocols. >> > > The issue here is not a technical one, it is an issue of trust. Does > your operator trust you to mark your VoIP packets correctly, and in a > way meaningful to that operator? If your operator is like those I have Yep. > experience with, then the answer is no. Any markings that are received > from a foreign network are either 1) quashed or 2) rewritten to > something locally meaningful. The incoming marking (p-bit, diffserv, > mpls exp) is only one handle on which the QoS remarking might be done > (others are things like port number or virtual circuit). Correct. Regards, Roland _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 18:14:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOdD-0007C2-Jf; Wed, 31 Jan 2007 18:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOdC-00078i-TO for ram@ietf.org; Wed, 31 Jan 2007 18:12:46 -0500 Received: from audl751.usa.alcatel.com ([143.209.238.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCOdB-0007om-HH for ram@ietf.org; Wed, 31 Jan 2007 18:12:46 -0500 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id l0VNCjK0012543; Wed, 31 Jan 2007 17:12:45 -0600 Received: from [128.251.10.114] ([172.22.216.4]) by usdalsbhs02.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 31 Jan 2007 17:12:44 -0600 In-Reply-To: <45C11CC4.1050503@tm.uka.de> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <65E1D3E6-1DED-4240-85F3-27F32F6904C6@alcatel.com> <45C11CC4.1050503@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [RAM] be afraid... Date: Wed, 31 Jan 2007 15:12:30 -0800 To: Roland Bless X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Jan 2007 23:12:44.0914 (UTC) FILETIME=[50A67520:01C7458D] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Roland, One reply is inline. On Jan 31, 2007, at 2:48 PM, Roland Bless wrote: > Hi Andrew, > > [comments inline] > > Andrew Lange wrote: >> prioritization is useful. Priority schemes are useful ONLY when >> there >> is contention for resources on the line. A network is usually >> designed >> to handle peak loads without congesting (mother's day load in the US >> voice networks), after all a carrier does not want to turn away >> business >> if they don't have to do so. In addition, this metric has been >> expanded >> to include "peak load under worst-case single failure." And with the >> advent of IP, this can be done without needing to double the >> bandwidth >> with a SONET/SDH working and protect path. Admittedly, not all >> networks >> are designed to this standard for a variety of reasons (too >> expensive, >> resources not available, etc.) If a network has the resources >> available, >> there is no need for a marking or prioritization scheme. In the most >> usual state the network will have resources available in most places. >> Any QoS scheme needs to be designed with an eye toward being >> lightweight >> to address the very real case that it will not be necessary most >> of the >> time. This point may be obvious, but it is often overlooked. > > Sure, QoS mechanisms are only required when there is resource > shortage. However, "overprovisioned" networks don't provide > enough protection against DDoS (here: flooding attacks). > So I know at least one provider that introduced prioritized > VoIP traffic in order to protect it against congestion > caused from "normal" traffic, e.g. caused during DDoS flooding > attacks (congestion may be caused in the direction > towards access networks, i.e. when descending the bandwidth > hierarchy). This makes sense to me... Yes, absolutely. The typical congestion point is going to be in the access network, and most likely in the "2nd" mile between the DSALM/ CMTS and the upstream network. This if often where the most oversubscription takes place. If this gets congested then needing a mechanism to help more sensitive applications' traffic get through makes a lot of sense. But this point is not going to be congested all day (one would hope ;-), and the rest of the communications path would likely be fine. This reinforces my point about needing a lightweight, flexible mechanism to address transient and localized congestion. Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jan 31 20:35:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCQox-0004Rc-6b; Wed, 31 Jan 2007 20:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCQov-0004RR-Em for ram@iab.org; Wed, 31 Jan 2007 20:33:01 -0500 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCQor-0008E3-PP for ram@iab.org; Wed, 31 Jan 2007 20:33:01 -0500 Received: from vaioz1.apnic.net (geoff.telstra.net [203.50.0.18]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l111WdMG058369; Thu, 1 Feb 2007 12:32:42 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070201122559.0432a240@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Feb 2007 12:32:39 +1100 To: RJ Atkinson , ram@iab.org From: Geoff Huston Subject: Re: [RAM] Re: server referrals In-Reply-To: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> References: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >In fact, SHIM6 would have challenges in this area if anything did, >because an application only knows the "IPv6 address misused as >Identifier" value and does not knwo the "IPv6 address used as locator" >value. So the application (or even the transport-layer) would >not know the "locator" value to pass to the other end in the referral. >Despite this issue, SHIM6 seems to have some IETF support and >"server referrals" don't seem to be a barrier to SHIM6 standardisation. I'm reluctant to get into a digression into the details of the shim6 approach, but the characterization above is not exactly correct in that the shim6 referral token is the initial locator, which is(*) a valid locator, and in this model the referral mechanism is no different to the way things happen today. (*) my description is also not quite correct here, and there are failure cases for the referral token that could only be resolved back into a candidate locator set by a backward and then a forward DNS query pair, but unless folk want me to dive further into details I'll leave the description at this (terse) approximation. Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram