From ram-bounces@iab.org Fri Dec 01 12:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBoP-0007as-Fm; Fri, 01 Dec 2006 12:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpshp-000369-QH for ram@iab.org; Thu, 30 Nov 2006 15:40:29 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpshn-0001Ou-Ec for ram@iab.org; Thu, 30 Nov 2006 15:40:29 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2006 12:40:27 -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 kAUKeQwi029240; Thu, 30 Nov 2006 12:40:26 -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 kAUKeQOX029445; Thu, 30 Nov 2006 12:40:26 -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); Thu, 30 Nov 2006 12:40:25 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 12:40:24 -0800 In-Reply-To: References: <3ea4c66f94dde2ab5de84ae14ba0294d@it.uc3m.es> 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: Fred Baker Date: Thu, 30 Nov 2006 12:40:23 -0800 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Nov 2006 20:40:24.0865 (UTC) FILETIME=[C3252910:01C714BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2267; t=1164919226; x=1165783226; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Routing=20and=20Addressing=20discussion=20in=20v6ops |Sender:=20; bh=hRui05nOn/pG0QfhjnMXrUxfIOT1j079quEQJME+mbY=; b=AfzXjI+XSv6okcpGnVUTdBJkcg77sqVTQJif5O30oCGBlheSZAG9bNv1f32KdIP7M8FUV4mw EtwTKHKiONIrSpOBNVTpCAgzal96nJLhceYKq31NSFw1BicSFyqO9Kr3; Authentication-Results: sj-dkim-7; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Fri, 01 Dec 2006 12:04:32 -0500 Cc: marla_azinger@czn.com Subject: [RAM] Routing and Addressing discussion in v6ops X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 has suggested that much of this discussion belongs on the ram list. See https://www1.ietf.org/mailman/listinfo/ram and please join it if you feel it is appropriate for you to do so. Where IPv6 Operations has a useful role here, I think, is to bring out internet drafts and perhaps RFCs that inform that discussion. That may include reposting existing internet drafts, and may include new ones. The key thing, though, is that the question is not "what are the multihoming requirements for the entire Internet", but "what are the end-to-end addressing and routing requirements for" what I will call (for lack of better terminology, not become I like it all that well) "Transit ISPs, Access ISPs, large edge networks, mid-sized edge networks, and SOHO and residential networks?" Multihoming is part of that, but inter-ISP traffic engineering is also part, and there may be other parts. If two groups of people find that they have differing requirement sets, the solution is not to force them to come to some unrecognizable consensus, but to have them describe the part of the Internet they are describing requirements for and then accurately cull out those requirements. The classic example of such a divide that I mentioned in another note is the idea that some ISPs want PA addressing as a market lock, and some edge networks detest PA addressing because it is one. One useful note along those lines might be a well researched set of expectations of the Internet, including each of its various ecological zones, in ten, twenty, and fifty years. Consider a call for submissions to have been placed. Note, by the way, that I don't automatically assume that all individual submissions are intended or need to become working group documents, or that all internet drafts are intended or should become RFCs. You will note that I quite happily post internet drafts to pose a discussion and happily let them die if the discussion completes and they are no longer needed. This isn't a race to get written up in the record books. But useful contributions to those discussions will be welcomed, and if the WG is of the opinion that they should be archived I'm all for it. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 01 14:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDly-0005ql-Nq; Fri, 01 Dec 2006 14:10:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDlw-0005oA-OQ for ram@iab.org; Fri, 01 Dec 2006 14:10:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDlu-00056i-2S for ram@iab.org; Fri, 01 Dec 2006 14:10:08 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 11:10:05 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1JA5Ts009464; Fri, 1 Dec 2006 11:10:05 -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 kB1JA2j6004590; Fri, 1 Dec 2006 11:10:04 -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, 1 Dec 2006 11:10:02 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:10:00 -0800 In-Reply-To: <6db4e68e82fd2c581cb3833d714cd64d@it.uc3m.es> References: <3ea4c66f94dde2ab5de84ae14ba0294d@it.uc3m.es> <6db4e68e82fd2c581cb3833d714cd64d@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <721B9E8B-7F78-4547-9252-649E5AF0B8E1@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 1 Dec 2006 11:09:54 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Dec 2006 19:10:00.0919 (UTC) FILETIME=[4CA26E70:01C7157C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9276; t=1165000205; x=1165864205; c=relaxed/simple; s=sjdkim1002; 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=20about=20draft-baker-v6ops-l3-multihoming-analysis-00 |Sender:=20; bh=EewjmeGtOdMtwS5UhwVj0Vh7CogrThdi3l6uap9AFfg=; b=XRpoV2mfis0ZvFr3dWfzjuAIEBAy0ZSQ48yppsScMoUENdH8e0lTf7/YBtanzfceJL3yb8cd 6UDXGkD0TFdzJ8vNS78hO8EcQUSIaHuJ0pkMGsViWeOzmo+M3jqrNCfK; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: v6ops@ops.ietf.org, marla_azinger@czn.com, ram@iab.org Subject: [RAM] Re: about draft-baker-v6ops-l3-multihoming-analysis-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 Moving this from v6ops to ram, and for this email copying both lists. On Dec 1, 2006, at 8:56 AM, marcelo bagnulo braun wrote: > actually, my question was more precisely, if a multiple PA prefixes > approach is suitable for a multihomed soho network? from reading > the paragraph below, i understand that you think that it might, is > this correct? > >> shim6 says it is, and would have each ISP provide its own prefix. >> GSE says it is, but leaves the hosts effectively ignorant of the >> prefixes assigned (within the enterprise network, the routers only >> look at the subnet number, and the hosts only look at the host >> identifier, and the border routers rewrite the part used by the >> ISPs). A variation on GSE would have the border router ICMP back >> to the host indicating that it should be using a certain "routing >> goop", and have the host resend using that. Metro and PI would >> simply have a single prefix on the edge network in the first >> place. If the distance and complexity questions are those of a >> typical home (see slides 3 and 4 of ftp://ftpeng.cisco.com/fred/ >> v6ops/Fred_network_paths.pdf for what I think a typical home looks >> like; the slide needs some updating now and in the coming years >> will have various large datarate home appliances added to it, but >> I suspect it's close) I can't imagine any of those having real >> operational problems. The big issue with multiple prefixes that I >> see are related to the hiccups around network changes. In the paragraph, I report what various proposals think, not so much what I think. shim6 has some real issues related to RFC 3582, IMHO, as discussed in the draft. That said, it technically works (or at least can work), which is my first criterion. As to whether users will find it acceptable, I don't know, but I can tell you that some are saying fairly loudly that they don't. They aren't SOHO customers, though; the ones I am hearing are coming at it from a medium-to-large enterprise or an ISP perspective. GSE is not published as an RFC because its author, Mike O'Dell, considers it half-baked. That said, it resolves a number of issues with the multi-addressing model that shim6 has to work a lot harder to solve, and has less issues related to RFC 3582. It requires a fundamental change to the way we view the IPv6 address, which has some issues, as I commented on yesterday and others have commented on in the past. I can tell you that in many respects it reflects the Xerox Network Systems Internet Transport architecture, aka Novell Netware at the Network layer, and not only works but works well. I don't see any reason it would be unacceptable in a SOHO environment. Let me hasten to say that I have a number of issues with Novell Netware, but they are at the transport layer and above. The XNS architecture (including a TCP-like transport, and UDP-like transport, a simple routing protocol, a separate network layer and an ICMP-like response protocol, and the Courier RPC application) was pretty well thought through, and my observation of the Internet is that every day we seem to become a little more like it. IDP/IPX's limitations, such as the hop count and the flat network number, were fine in 1980 and we know how to overcome now. The GSE variant I mention was first proposed, IIRC, a year or more ago by someone else. GSE supposes that what it calls the "routing goop" (the most significant 48 bits of the address) are completely fungible, and can be overwritten by the border routers at will. But the originator of a datagram does indeed set them to something. This proposal, instead of saying "when you see this the wrong routing goop in a source address outbound, overwrite it" or (RFC 3704) "route it to the right egress", says "when you see the wrong routing goop in a source address outbound, send an ICMP back indicating the routing goop that the originator should be using and drop the packet". The originator resends the datagram accordingly. That works technically as well, and perhaps does less violence to the address, but at the cost of an RTT. An RTT on a LAN (SOHO) isn't much; an RTT in a multi- continent corporate network might be a problem. PI is what we have now for ISPs and a few large companies; PA is what we have now for everyone else. PA works if you are not multihomed; the issues that arise in multihoming are why we are doing shim6. As I note in the draft, both have serious scaling problems if applied to the SOHO environment and (PA) the prefix assigned to the SOHO is advertised through multiple providers. Would they be acceptable to SOHO networks? If they have one address, I don't think they care what happens outside any more than the ISPs care if they get overloaded with multi-addressing. I keep Metro on the table because, while it is a change to the business model, it allows the SOHO to have something akin to a portable PI prefix and the advantages that come with that, but in a far more scalable network architecture for the businesses in the so- called default-free zone. It implies some form of value exchange among ISPs, which I tend to think is unavoidable in the long term. In the final analysis, I think that the companies that instigated the Net Neutrality debate were in fact asking for some form of settlement procedure, both with those who think they already pay for service and shouldn't have to directly pay companies they view as monopolists, and the companies that are saying that over-the-top services should be paying them for transport. Without going into a long dissertation about volume charging, if one buys that the business is *going* to change (has been changing, perhaps in some respects is already changed) in that direction, changing it in a way that makes metro play is not all that hard. Since it looks like PI addressing to the SOHO (and as observed, the SOHO doesn't care what goes on elsewhere), I don't see any reason that the SOHO wouldn't be willing to do it. What I think about the acceptability to SOHOs: In each case, the question of viability in the SOHO environment is pretty straightforward. If it has to be manually configured by an expert, it is a non-starter, and if it is simply a fact of life the SOHO doesn't care. For any of these to be deployable at all, CPE routers like Linksys, Windows, Linux, MacOSX, and so all have to do them "out of the box", and the SOHO is going to deploy whatever comes out of the box. The folks that are going to care about the details of what is implemented are the medium and larger companies and the ISPs, who having larger networks are going to have to understand the implications of the choices. > i also think that having means to centrally enforce TE policies > (which is not in the goals document is also a very valid requirement) In that sentence, the word "central" kind of glows and vibrates. Elaborate? >>> Are we considering a multihoming solution for ISPs or for end sites? >> >> I think the discussion has to take into account both ISPs and >> their customers, which might very well mean that it needs to be >> divided into separate discussions. For example, I have been told >> by some ISPs that they want PA addressing because it gives them a >> market lock, and by some of their customers that they don't want >> PA addressing because it gives ISPs a market lock. That kind of >> divide is a place where a single consensus is simply not going to >> form. > > agree, who should we listen to? Both. Yes, that's hard. In the end, though, the solution we come up with needs to enable ISPs to run their businesses according to rules they are comfortable with and edge networks to be able to run theirs in ways they are comfortable with. Giving them a solution that meets only one set of requirements guarantees that the other will be unhappy and will continue to agitate for something different. > well, i think we could start by dividing the types of multihoming > scenarios as you did in your draft (maybe include other scenarios > as well) and try to identify the requirements for these scenarios. > We can start with the list of goals described in the rfc3582 and we > can add other requirements that you and Marla have identified > talking to the operational community, makes sense? If you're offering to post a draft with some thoughts, that sounds like a reasonable place to start. > the obvious candidate would be centrally managed ULAs (i know they > don't existe, but seems the easiest way to get unique identifiers) We have centrally-managed ULAs now. You get them from IANA through the registries. They are called "global addresses". > big sites, have more requirements of functionality but less > scalability requirements. PI should be ok for them > > small sites, completely different game. Probably less > functionality, easier to manage, easier to renumber but much more > scalability is required. Yes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 02 11:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqXPq-0007Gw-4d; Sat, 02 Dec 2006 11:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqXPp-0007Ew-DA for ram@iab.org; Sat, 02 Dec 2006 11:08:37 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqXPi-0006X7-6T for ram@iab.org; Sat, 02 Dec 2006 11:08:37 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id C23DF34098 for ; Sat, 2 Dec 2006 11:08:29 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Dec 2006 11:08: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 Date: Sat, 2 Dec 2006 11:08:28 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038FCD@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Test Thread-Index: AccWLBq6+518AJ4fRxuY61jaYz2CNQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 02 Dec 2006 16:08:29.0348 (UTC) FILETIME=[1B2A5640:01C7162C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [RAM] Test X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 12:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMjc-0007lc-Af; Thu, 07 Dec 2006 12:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsMHn-0002t8-VS for ram@ietf.org; Thu, 07 Dec 2006 11:39:51 -0500 Received: from vacation.karoshi.com ([198.32.6.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsMHO-0006Qq-Cn for ram@ietf.org; Thu, 07 Dec 2006 11:39:50 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id kB7GbuSK018567; Thu, 7 Dec 2006 16:37:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id kB7Gbt41018566; Thu, 7 Dec 2006 16:37:55 GMT Date: Thu, 7 Dec 2006 16:37:55 +0000 From: bmanning@karoshi.com To: Fred Baker Message-ID: <20061207163755.GA18551@vacation.karoshi.com.> References: <20061207035509.34371.qmail@web58711.mail.re1.yahoo.com> <37B5CD2B-3028-4C2A-83ED-89E60C2AB377@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37B5CD2B-3028-4C2A-83ED-89E60C2AB377@cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 1.3 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Thu, 07 Dec 2006 12:08:35 -0500 Cc: v6ops@ops.ietf.org, marla_azinger@czn.com, ram@ietf.org Subject: [RAM] Re: draft-baker-v6ops-13-multihoming-analysis-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 so... are we bringing back RFC 1897? On Thu, Dec 07, 2006 at 08:33:37AM -0500, Fred Baker wrote: > concatenating the ASN into the IP address would certainly be one way > of providing a scalable routing locator. Check the archives, and you > will find that at one time (perhaps a decade back) I suggested that > as a quick method for the initial assignment of addresses - simply > give every current AS a prefix numerically related to its AS number. > I don't believe that to be required for scalability, however, which > is why I don't bring it up in the document. What I do see as required > is the ability to limit the number of prefixes advertised to a number > comparable to the number of assigned AS numbers, and constrain those > to people who actually need an AS number from a BGP perspective. > > We have been asked to move this conversation to ram@iab.org aka > ram@ietf.org. > > On Dec 6, 2006, at 10:55 PM, Peter Sherbin wrote: > > >Fred, > > > >More comments > >p.3 says "Fortune 500" while p. 20 has "Fortune 1000". > >p.18 above the diagram "the links from B<->A and B<->A were > >shorter", why two B<->A? > >p.19 near the top "issues... relate to human stupidity". How about > >"human error"? > >p.27 section 5. "From the author's perspective" when the draft has > >two authors. > > > >This is a good summary of what is going on plus projections. But > >overall it feels > >that the current architecture constrains the market and it does not > >scale. The draft > >illustrates the need for flexible PI addressing with the model such > >as "a service > >domain. That domain could as easily be the customers of a > >cooperative as the > >citizens of a government". Any given tax authority is a good proxy > >for such > >cooperative and it could assume a mechanical function of the > >distribution and > >management of PI. > > > >Providers would get through RIR an independent set of > >geographically rigid > >aggregation points, eg. ASN. A new protocol could be needed to > >combine PI+ASN for > >scalable routing(?) > > > >Thanks, > > > >Peter > > > > > > > >______________________________________________________________________ > >______________ > >Yahoo! Music Unlimited > >Access over 1 million songs. > >http://music.yahoo.com/unlimited _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 13:12:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNir-0003uC-Vk; Thu, 07 Dec 2006 13:11:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNiq-0003tu-LH for ram@ietf.org; Thu, 07 Dec 2006 13:11:52 -0500 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GsNiM-0003v6-3p for ram@ietf.org; Thu, 07 Dec 2006 13:11:52 -0500 Received: (qmail 24671 invoked by uid 60001); 7 Dec 2006 18:11:21 -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=Ts1oHc/qPzwUvbmHBujAiAM1CTTDO+BNs2qA+BYBlTt8fXZxMoyg5iw2GqW8AGhoKJSZ/5semR0TWfxHrm9un8UFShAW2iOoGPMtaM0AZ0jix1ci+eS34nBRzLeNZYchCwf7S/BZ2ssFN9QDrSazuGfJ2gy+bC+0jZ5rb4JwXMY=; X-YMail-OSG: nbFt68QVM1n4P7ndjMJL1qpr3HxoRK27_fWPlkOBuwXYhqG_L_daK4xMbTILIKXNx0EmcN0Zhxc3DtgVlu.bcYagwNIKNUEPxEC2VndxoO7Kh5EeZTC6IrZvKHCmYO5UODGnjwuB74GkoU3FpN.9w7BbDgltYsBwm43gtpORNzbhoTy0Qb3gQGQpDT0- Received: from [207.107.50.100] by web58708.mail.re1.yahoo.com via HTTP; Thu, 07 Dec 2006 10:11:21 PST Date: Thu, 7 Dec 2006 10:11:21 -0800 (PST) From: Peter Sherbin To: bmanning@karoshi.com, Fred Baker In-Reply-To: <20061207163755.GA18551@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <684061.24495.qm@web58708.mail.re1.yahoo.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: v6ops@ops.ietf.org, marla_azinger@czn.com, ram@ietf.org Subject: [RAM] Re: draft-baker-v6ops-13-multihoming-analysis-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 > so... are we bringing back RFC 1897? Would it work to apply RFC 1897 as: - ASN has 16 bits and there is a room for a larger ASN if needed - EU would still get 128-bit IPv6 address with the leading 32 bits set to zero (to be replaced with ASN at the network connection point) - IPv4 is built in meaning that EU can keep their current IPv4 and put them right into IPv6 easing the transition - /32 provides big enough space to any EU --- bmanning@karoshi.com wrote: > > so... are we bringing back RFC 1897? > > > On Thu, Dec 07, 2006 at 08:33:37AM -0500, Fred Baker wrote: > > concatenating the ASN into the IP address would certainly be one way > > of providing a scalable routing locator. Check the archives, and you > > will find that at one time (perhaps a decade back) I suggested that > > as a quick method for the initial assignment of addresses - simply > > give every current AS a prefix numerically related to its AS number. > > I don't believe that to be required for scalability, however, which > > is why I don't bring it up in the document. What I do see as required > > is the ability to limit the number of prefixes advertised to a number > > comparable to the number of assigned AS numbers, and constrain those > > to people who actually need an AS number from a BGP perspective. > > > > We have been asked to move this conversation to ram@iab.org aka > > ram@ietf.org. > > > > On Dec 6, 2006, at 10:55 PM, Peter Sherbin wrote: > > > > >Fred, > > > > > >More comments > > >p.3 says "Fortune 500" while p. 20 has "Fortune 1000". > > >p.18 above the diagram "the links from B<->A and B<->A were > > >shorter", why two B<->A? > > >p.19 near the top "issues... relate to human stupidity". How about > > >"human error"? > > >p.27 section 5. "From the author's perspective" when the draft has > > >two authors. > > > > > >This is a good summary of what is going on plus projections. But > > >overall it feels > > >that the current architecture constrains the market and it does not > > >scale. The draft > > >illustrates the need for flexible PI addressing with the model such > > >as "a service > > >domain. That domain could as easily be the customers of a > > >cooperative as the > > >citizens of a government". Any given tax authority is a good proxy > > >for such > > >cooperative and it could assume a mechanical function of the > > >distribution and > > >management of PI. > > > > > >Providers would get through RIR an independent set of > > >geographically rigid > > >aggregation points, eg. ASN. A new protocol could be needed to > > >combine PI+ASN for > > >scalable routing(?) > > > > > >Thanks, > > > > > >Peter > > > > > > > > > > > >______________________________________________________________________ > > >______________ > > >Yahoo! Music Unlimited > > >Access over 1 million songs. > > >http://music.yahoo.com/unlimited > ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 14:06:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOZn-0006lw-VD; Thu, 07 Dec 2006 14:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOZm-0006ip-1v; Thu, 07 Dec 2006 14:06:34 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOZi-0004Ly-Lw; Thu, 07 Dec 2006 14:06:34 -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 kB7J6UrT014067; Thu, 7 Dec 2006 11:06:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kB7J6Obu014066; Thu, 7 Dec 2006 11:06:24 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 7 Dec 2006 11:06:24 -0800 From: David Meyer To: architecture-discuss@ietf.org, routingworkshop@lists.i1b.org, ram@iab.org, v6ops@ops.ietf.org Message-ID: <20061207190624.GA13988@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: 97adf591118a232206bdb5a27b217034 Cc: iab@ietf.org, iesg@ietf.org Subject: [RAM] mailing lists and follow-ons to the IAB Routing & Addressing workshop X-BeenThere: ram@iab.org X-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="===============1112124260==" Errors-To: ram-bounces@iab.org --===============1112124260== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, There's been a lot of discussion of what the follow-on's to the workshop might be on various lists. What I'm hoping we can do is consolidate that discussion on ram@iab.org. The I* will be using ram@iab.org for discussion going forward, so please subscribe if you are interested.=20 =09 thnx, --dmm --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFeGYwORgD1qCZ2KcRAoBTAKCRbBrD57uKgHbXGVdJ4eDoVlmrCQCghm45 LARkLGQgj1378XWa9l8QFCo= =SI+m -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- --===============1112124260== 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 --===============1112124260==-- From ram-bounces@iab.org Thu Dec 07 15:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPZv-0000fU-7U; Thu, 07 Dec 2006 15:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPZt-0000cZ-Qa for ram@iab.org; Thu, 07 Dec 2006 15:10:45 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsPYs-0004fD-7h for ram@iab.org; Thu, 07 Dec 2006 15:09:43 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A0BDF872C0; Thu, 7 Dec 2006 15:09:41 -0500 (EST) To: architecture-discuss@ietf.org, ram@iab.org, routingworkshop@lists.i1b.org, v6ops@ops.ietf.org Message-Id: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Date: Thu, 7 Dec 2006 15:09:41 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: iab@ietf.org, iesg@ietf.org, jnc@mercury.lcs.mit.edu Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 > discussion of what the follow-on's to the workshop might be on various > lists. What I'm hoping we can do is consolidate that discussion on > ram@iab.org. I would take a slightly different view, and think there is (non-overlapping) role for both (and I hope the various I* bodies won't take offense at me for differing a bit with this plan; I really do have everyone's best interests at heart here.) First, this is a big problem, and there are a number of different technical areas; with a single forum, it might get kind of Babel-like. Second, and more important I think, I find that in any wide-ranging discussion like this, the routing stuff (which is usually the hardest problem) gets the short end of the stick. (I have my opinions on why that happens, but I'll leave them be for now.) And, I hope I don't need to point out, it was coming problems with the routing which have led to this. IMNSHO, it's really unacceptable to work on this problem and not give a key role to consideration of how the routing is going to work. And to make sure the routing is going to work, we have to dive into the muck and tackle the routing technical issues in some detail, to make sure it all really works. So we have to drive pretty quickly to considering the technical details of how the routing is going to work, I think. And that's something the people who seem to have energy available to discuss things have been fairly loathe to do, despite some not-so-subtle prods from me. So I think keeping the RAM list focused on just the routing stuff is really pretty critical; it's clear that that's a really substantial discussion. Discussion of other related topics there (e.g. separation of location and identity) would just distract from that, and that's where A-D list would be useful. I feel that discussion of such issues as end-end naming, whether we have to use the "jack-up" model (in which end-hosts remain totally unmodified), etc, etc, really ought to be kept on A-D, to keep RAM clear for these routing issues. To keep this from getting too long, I'll send out a separate message in a couple of hours (just on RAM) giving a little more detail on the points I think RAM needs to work on, and how I think it can best make progress on them. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 16:06:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQRD-0004Ej-RS; Thu, 07 Dec 2006 16:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQRC-0004EH-4h; Thu, 07 Dec 2006 16:05:50 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsQRA-0005Hm-Se; Thu, 07 Dec 2006 16:05:50 -0500 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id 9.c79.743b8b4 (41809); Thu, 7 Dec 2006 16:05:38 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 7 Dec 2006 16:05:35 EST Subject: Re: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addr... To: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org, ram@iab.org, routingworkshop@lists.i1b.org, v6ops@ops.ietf.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: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: iab@ietf.org, iesg@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: , Content-Type: multipart/mixed; boundary="===============0052539270==" Errors-To: ram-bounces@iab.org --===============0052539270== Content-Type: multipart/alternative; boundary="-----------------------------1165525535" -------------------------------1165525535 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Noel wrote: IMNSHO, it's really unacceptable to work on this problem and not give a key role to consideration of how the routing is going to work. And to make sure the routing is going to work, we have to dive into the muck and tackle the routing technical issues in some detail, to make sure it all really works. So we have to drive pretty quickly to considering the technical details of how the routing is going to work, I think. And that's something the people who seem to have energy available to discuss things have been fairly loathe to do, despite some not-so-subtle prods from me. I totally agree. How can addressing be discussed without envisioning a routing scheme that fits for the future ?!! Maybe in preparation for such a discussion we should discuss how bad current IETF-routing is. I am sure other technologies (robotics, navigation systems,..) have surpassed internet routing by far. The IETF is still dependent on such a primitive TTL-mechanism which hasn't been improved substantially by getting a new name in IPv6. With RPF-checks you can not defeat the DoS attacks, but you can prevent multipath routing and realtime traffic control. With BGP...(stop, I might be told without BGP this email wouldn't make its way out). Heiner -------------------------------1165525535 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Noel wrote:
IMNSHO, it's really unacceptable to work on this pro= blem=20 and not give a key
role to consideration of how the routing is going to w= ork.=20 And to make sure
the routing is going to work, we have to dive into the m= uck=20 and tackle the
routing technical issues in some detail, to make sure it a= ll=20 really works. So
we have to drive pretty quickly to considering the techn= ical=20 details of how
the routing is going to work, I think. And that's somethin= g=20 the people who
seem to have energy available to discuss things have been=20 fairly loathe to do,
despite some not-so-subtle prods from me.
 
I totally agree. How can addressing be discussed without envisioni= ng=20 a  routing scheme that fits for the future ?!! 
Maybe in preparation for such a  discussion we should discuss= how=20 bad current IETF-routing is. I am sure other technologies (robotics, navigat= ion=20 systems,..) have surpassed internet routing by far. The IETF is still depend= ent=20 on such a primitive TTL-mechanism which hasn't been improved substantially&n= bsp;=20 by getting a new name in IPv6.
With RPF-checks you can not defeat the DoS attacks, but you=20 can prevent multipath
routing and realtime traffic control.  With BGP...(stop, I might b= e=20 told without BGP this email wouldn't make its way out). 
 
Heiner
 
 
 
 
 
 
 
 

 
 -------------------------------1165525535-- --===============0052539270== 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 --===============0052539270==-- From ram-bounces@iab.org Thu Dec 07 16:13:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQYI-0007T7-Bm; Thu, 07 Dec 2006 16:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQYG-0007Rz-Ty; Thu, 07 Dec 2006 16:13:08 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsQYF-0006Mr-GT; Thu, 07 Dec 2006 16:13:08 -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 kB7LD6BM018392; Thu, 7 Dec 2006 13:13:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kB7LD6V2018391; Thu, 7 Dec 2006 13:13:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 7 Dec 2006 13:13:06 -0800 From: David Meyer To: Noel Chiappa Message-ID: <20061207211306.GA18311@1-4-5.net> References: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061207200941.A0BDF872C0@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: f66b12316365a3fe519e75911daf28a8 Cc: iab@ietf.org, architecture-discuss@ietf.org, routingworkshop@lists.i1b.org, iesg@ietf.org, ram@iab.org, v6ops@ops.ietf.org Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop X-BeenThere: ram@iab.org X-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="===============1990235713==" Errors-To: ram-bounces@iab.org --===============1990235713== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 07, 2006 at 03:09:41PM -0500, Noel Chiappa wrote: > > From: David Meyer >=20 > > discussion of what the follow-on's to the workshop might be on vari= ous > > lists. What I'm hoping we can do is consolidate that discussion on > > ram@iab.org. >=20 > I would take a slightly different view, and think there is (non-overlappi= ng) > role for both (and I hope the various I* bodies won't take offense at me = for > differing a bit with this plan; I really do have everyone's best interest= s at > heart here.) >=20 >=20 > First, this is a big problem, and there are a number of different technic= al > areas; with a single forum, it might get kind of Babel-like. Second, and = more > important I think, I find that in any wide-ranging discussion like this, = the > routing stuff (which is usually the hardest problem) gets the short end of > the stick. (I have my opinions on why that happens, but I'll leave them be > for now.) And, I hope I don't need to point out, it was coming problems w= ith > the routing which have led to this. >=20 > IMNSHO, it's really unacceptable to work on this problem and not give a k= ey > role to consideration of how the routing is going to work. And to make su= re > the routing is going to work, we have to dive into the muck and tackle the > routing technical issues in some detail, to make sure it all really works= . So > we have to drive pretty quickly to considering the technical details of h= ow > the routing is going to work, I think. And that's something the people who > seem to have energy available to discuss things have been fairly loathe t= o do, > despite some not-so-subtle prods from me. >=20 >=20 > So I think keeping the RAM list focused on just the routing stuff is real= ly > pretty critical; it's clear that that's a really substantial discussion. > Discussion of other related topics there (e.g. separation of location and > identity) would just distract from that, and that's where A-D list would = be > useful. >=20 > I feel that discussion of such issues as end-end naming, whether we have = to > use the "jack-up" model (in which end-hosts remain totally unmodified), e= tc, > etc, really ought to be kept on A-D, to keep RAM clear for these routing > issues. >=20 > To keep this from getting too long, I'll send out a separate message in a > couple of hours (just on RAM) giving a little more detail on the points I > think RAM needs to work on, and how I think it can best make progress on = them. Thanks Noel. No disagreement on my part. --dmm =09 =09 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFeIPiORgD1qCZ2KcRAlzmAJ9HwQyvyxeC/c5oAz+iYVoT+a4kcgCfeIZu Lv1b9m1siumv0fZcK1msiQ4= =sRIW -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- --===============1990235713== 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 --===============1990235713==-- From ram-bounces@iab.org Thu Dec 07 18:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSpZ-0000jL-52; Thu, 07 Dec 2006 18:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSpY-0000j8-EG for ram@iab.org; Thu, 07 Dec 2006 18:39:08 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSpW-0004z5-2N for ram@iab.org; Thu, 07 Dec 2006 18:39:08 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B04C4AC73; Thu, 7 Dec 2006 18:39:02 -0500 (EST) Date: Thu, 7 Dec 2006 18:39:02 -0500 From: John Leslie To: Noel Chiappa Subject: Re: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop Message-ID: <20061207233902.GA67571@verdi> References: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: architecture-discuss@ietf.org, 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 Chiappa wrote: >> From: David Meyer > >> discussion of what the follow-on's to the workshop might be on various >> lists. What I'm hoping we can do is consolidate that discussion on >> ram@iab.org. It _will prove difficult to keep general architecture separate from routing table growth. I agree with David that keeping a complete (enough) record of the discussion on the RAM list is a reasonable request. This will probably result in a fair amount of cross-posting. :^( > I would take a slightly different view, and think there is > (non-overlapping) role for both (and I hope the various I* bodies won't > take offense at me for differing a bit with this plan; I really do have > everyone's best interests at heart here.) It's important to consider the stated purpose of the RAM list: ] ] This list serves as a technical discussion forum for all members of the ] IETF community that are interested in continued discussion of the ] analysis of and potential solutions to the continued growth in the size ] and dynamics of the Internet's default free zone routing table. We need, IMHO, to respect that. > First, this is a big problem, and there are a number of different > technical areas; with a single forum, it might get kind of Babel-like. A very definite risk! > Second, and more important I think, I find that in any wide-ranging > discussion like this, the routing stuff (which is usually the hardest > problem) gets the short end of the stick. (I have my opinions on why > that happens, but I'll leave them be for now.) And, I hope I don't > need to point out, it was coming problems with the routing which have > led to this. I don't mind stating my opinion why: too few folks understand routing, while too many insist on talking about it. > IMNSHO, it's really unacceptable to work on this problem and not give > a key role to consideration of how the routing is going to work. Agreed. > And to make sure the routing is going to work, we have to dive into > the muck and tackle the routing technical issues in some detail, > to make sure it all really works. Agreed. This is perhaps _too_ hard on a fully open list... > So we have to drive pretty quickly to considering the technical details > of how the routing is going to work, I think. And that's something the > people who seem to have energy available to discuss things have been > fairly loathe to do, despite some not-so-subtle prods from me. As any rational expert should be, IMHO, until s/he is assured of protection from "feature creep". > So I think keeping the RAM list focused on just the routing stuff is > really pretty critical; it's clear that that's a really substantial > discussion. I agree that discussing routing details is currently more appropriate for RAM than [arch-d]. I am even willing to (try to) help Noel discuss it there. But I don't think it a good idea to try to limit that list to routing discussion. > Discussion of other related topics there (e.g. separation of location > and identity) would just distract from that, and that's where A-D list > would be useful. IMHO, _some_ separation of location from identity will be necessary in order to make routing scale acceptably. It seems unwise to call such discussion out-of-scope. > I feel that discussion of such issues as end-end naming, whether we > have to use the "jack-up" model (in which end-hosts remain totally > unmodified), etc, etc, really ought to be kept on A-D, to keep RAM > clear for these routing issues. End-to-end naming probably belongs on [arch-d]. "Jack-up" is likely necessary for short-term fixes. It too should be in-scope for discussion on RAM. > To keep this from getting too long, I'll send out a separate message > in a couple of hours (just on RAM) giving a little more detail on the > points I think RAM needs to work on, and how I think it can best make > progress on them. Sounds like a good idea to start discussion! -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 22:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWXN-00027c-Rd; Thu, 07 Dec 2006 22:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWXL-00027X-Td for ram@ietf.org; Thu, 07 Dec 2006 22:36:35 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWXK-0002eI-LN for ram@ietf.org; Thu, 07 Dec 2006 22:36:35 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 07 Dec 2006 19:36:34 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB83aYWD019491; Thu, 7 Dec 2006 19:36:34 -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 kB83aNW6016724; Thu, 7 Dec 2006 19:36:23 -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); Thu, 7 Dec 2006 19:36:23 -0800 Received: from [172.17.129.50] ([10.21.82.188]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 19:36:22 -0800 In-Reply-To: <20061207163755.GA18551@vacation.karoshi.com.> References: <20061207035509.34371.qmail@web58711.mail.re1.yahoo.com> <37B5CD2B-3028-4C2A-83ED-89E60C2AB377@cisco.com> <20061207163755.GA18551@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <66BAD21C-399B-44A4-922D-512803050937@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 7 Dec 2006 22:36:18 -0500 To: bmanning@karoshi.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Dec 2006 03:36:22.0907 (UTC) FILETIME=[083064B0:01C71A7A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=158; t=1165548994; x=1166412994; c=relaxed/simple; s=sjdkim2002; 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=20draft-baker-v6ops-13-multihoming-analysis-00 |Sender:=20; bh=wktuwNnZrFau7OoPXNNbqBfPpCydO3b7avFvBStQCJc=; b=fixoeF6YVKC7EReHHD1kD7MaXhIlv+d7ijYZPGEZLSOiMh7d3YmVuCHMfoAKd9gimH7qhcKi lmFYmBz5aRex5Gde2LO7MtlH6rus+m3jyu8JZN+OR/hMCg4MA3dUIWJW; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: v6ops@ops.ietf.org, marla_azinger@czn.com, ram@ietf.org Subject: [RAM] Re: draft-baker-v6ops-13-multihoming-analysis-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 On Dec 7, 2006, at 11:37 AM, bmanning@karoshi.com wrote: > so... are we bringing back RFC 1897? I'm not recommending that. Sounds like Peter might. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 07 23:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWwK-0003W8-9f; Thu, 07 Dec 2006 23:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWwJ-0003W3-F9 for ram@iab.org; Thu, 07 Dec 2006 23:02:23 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWwE-0007uM-4r for ram@iab.org; Thu, 07 Dec 2006 23:02:23 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 7DE2C34097; Thu, 7 Dec 2006 23:02:22 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 23:02:14 -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] Re: [arch-d] mailing lists and follow-ons to the IAB Routing &Addressing workshop Date: Thu, 7 Dec 2006 23:02:12 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C9@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing &Addressing workshop Thread-Index: AccaO9hNojdXo/YWTUe0K17wnMkqqwAQZRyw From: "Bound, Jim" To: "Noel Chiappa" , , , , X-OriginalArrivalTime: 08 Dec 2006 04:02:14.0411 (UTC) FILETIME=[A4F51DB0:01C71A7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: iab@ietf.org, iesg@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 think Noel makes good sense here but suggest one caveat. When and if identifiers and naming appears as imperative to any architecture we have to take time to delve into them not just put them on hold and that will take us away from just routing a bit but only for routing not transport and I fear if we don't do that we may not see bug in the routing architecture of future analysis and development in RAM. /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, December 07, 2006 3:10 PM > To: architecture-discuss@ietf.org; ram@iab.org;=20 > routingworkshop@lists.i1b.org; v6ops@ops.ietf.org > Cc: iab@ietf.org; iesg@ietf.org; jnc@mercury.lcs.mit.edu > Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to=20 > the IAB Routing &Addressing workshop >=20 > > From: David Meyer >=20 > > discussion of what the follow-on's to the workshop=20 > might be on various > > lists. What I'm hoping we can do is consolidate that=20 > discussion on > > ram@iab.org. >=20 > I would take a slightly different view, and think there is=20 > (non-overlapping) role for both (and I hope the various I*=20 > bodies won't take offense at me for differing a bit with this=20 > plan; I really do have everyone's best interests at heart here.) >=20 >=20 > First, this is a big problem, and there are a number of=20 > different technical areas; with a single forum, it might get=20 > kind of Babel-like. Second, and more important I think, I=20 > find that in any wide-ranging discussion like this, the=20 > routing stuff (which is usually the hardest problem) gets the=20 > short end of the stick. (I have my opinions on why that=20 > happens, but I'll leave them be for now.) And, I hope I don't=20 > need to point out, it was coming problems with the routing=20 > which have led to this. >=20 > IMNSHO, it's really unacceptable to work on this problem and=20 > not give a key role to consideration of how the routing is=20 > going to work. And to make sure the routing is going to work,=20 > we have to dive into the muck and tackle the routing=20 > technical issues in some detail, to make sure it all really=20 > works. So we have to drive pretty quickly to considering the=20 > technical details of how the routing is going to work, I=20 > think. And that's something the people who seem to have=20 > energy available to discuss things have been fairly loathe to=20 > do, despite some not-so-subtle prods from me. >=20 >=20 > So I think keeping the RAM list focused on just the routing=20 > stuff is really pretty critical; it's clear that that's a=20 > really substantial discussion. > Discussion of other related topics there (e.g. separation of=20 > location and > identity) would just distract from that, and that's where A-D=20 > list would be useful. >=20 > I feel that discussion of such issues as end-end naming,=20 > whether we have to use the "jack-up" model (in which=20 > end-hosts remain totally unmodified), etc, etc, really ought=20 > to be kept on A-D, to keep RAM clear for these routing issues. >=20 > To keep this from getting too long, I'll send out a separate=20 > message in a couple of hours (just on RAM) giving a little=20 > more detail on the points I think RAM needs to work on, and=20 > how I think it can best make progress on them. >=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 Fri Dec 08 11:42:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsin4-0006ZO-OX; Fri, 08 Dec 2006 11:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsin2-0006ZA-Ud for ram@iab.org; Fri, 08 Dec 2006 11:41:36 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsin0-0007qg-MD for ram@iab.org; Fri, 08 Dec 2006 11:41:36 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4A6C986ADB; Fri, 8 Dec 2006 11:41:34 -0500 (EST) To: ram@iab.org Message-Id: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> Date: Fri, 8 Dec 2006 11:41:34 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: jnc@mercury.lcs.mit.edu Subject: [RAM] Critical routing questions, and how to proceed X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 keep this from getting too long, I'll send out a separate message in > a couple of hours (just on RAM) giving a little more detail on the > points I think RAM needs to work on OK, so here's the promised message. First come a few things on which I think agreement has been reached, and then I get to ones which are still open. When I look at what the problem seems to be (according to the various presentations), it seems to be growth in the size of the routing table (with dynamics of routing table entries coming in second). The two main drivers of growth seem to be i) multi-homing, and ii) general entropy and lack of aggregation. Is this correct? The multi-homing clearly has to be handled by use of multiple routing-names, and identity/location separation. Is that generally agreed on? Whether that separation happens through widescale deployment of mechanisms above the basic internetworking layer (e.g. SHIM6 or HIP), or through what I've been calling the "jack-up" model (inserting a new internetworking layer underneath the existing one, and turning existing IPvN addresses into things that are mostly identity-names), remains to be seen. (Although that's a critical question to decide, I don't think it has a lot of impact on the routing questions; although it is true that jack-up assumes a new routing-name namespace, which answers question 1 below with a "yes", and forces us to immediately move to question 2.) So here are a number of further open questions that come to mind. - 1. Assuming that growth through multi-homing is controlled, is general entropy in the routing tables so bad that we need to somehow move to a routing-name namespace which has more hierarchy, and in which less entropy is allowed (i.e. it's more purely connectivity-based)? In other words, even if we could deploy HIP/SHIM6/whatever, is the entropy in the IPvN namespace going to be so big that in the not-too-distant future we will no longer be able to do path computations using names from the space? Bluntly: do we have to deploy a new namespace for routing-names? - I will leave aside less-critical questions like i) the syntax of that new namespace (i.e. do we recycle an existing syntax), ii) what routing algorithms we use to compute paths in that new namespace, etc, for the moment, and get to the one that's really troubling me: - 2. If we do have a new namespace for routing-names, then how does the interoperability work? (This is some of what I was pondering with those diagrams I drew.) I think we more or less have to inject old routing-names in the new routing plane, but do we then wind up going from the frying pan to the fire, where we have even *more* destinations to track? My suggestion is that someone (you, David?), organize a small telecon to try and come up with a coherent, organized "list of discussion points" to be covered on RAM, and that someone (you, again?) then tries to guide the list through those points in a organized and productive way, rather than simply letting the e-conversation ramble off in a totally unguided way. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 13:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsktM-0000pT-1p; Fri, 08 Dec 2006 13:56:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsktK-0000pO-Kg for ram@iab.org; Fri, 08 Dec 2006 13:56:14 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsktJ-0000bZ-4n for ram@iab.org; Fri, 08 Dec 2006 13:56:14 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F24201112E1; Fri, 8 Dec 2006 19:56:11 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id A8FA61112D1; Fri, 8 Dec 2006 19:56:07 +0100 (CET) In-Reply-To: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3b00a37e6819a02307db83063d1199f6@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Critical routing questions, and how to proceed Date: Fri, 8 Dec 2006 19:56:09 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) 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 El 08/12/2006, a las 17:41, Noel Chiappa escribi=F3: > > - 1. Assuming that growth through multi-homing is controlled, is=20 > general > entropy in the routing tables so bad that we need to somehow move to a > routing-name namespace which has more hierarchy, and in which less=20 > entropy is > allowed (i.e. it's more purely connectivity-based)? In other words,=20 > even if > we could deploy HIP/SHIM6/whatever, is the entropy in the IPvN=20 > namespace > going to be so big that in the not-too-distant future we will no=20 > longer be > able to do path computations using names from the space? maybe a related question would be: how many of the bgp routing entries=20= today are due to multihomed sites and how many are due to more=20 specifics being announced for TE reasons? i think there are some=20 reports out there with this info... anyone has a pointer? Thanks, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 14:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl1w-0004Vq-Vy; Fri, 08 Dec 2006 14:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl1v-0004UJ-Ji for ram@iab.org; Fri, 08 Dec 2006 14:05:07 -0500 Received: from smtp.armas.fi ([81.16.64.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsl1p-0001Rr-0U for ram@iab.org; Fri, 08 Dec 2006 14:05:07 -0500 Received: from [127.0.0.1] (jarno-at-home1.jl.finnetcom.net [212.149.74.245]) by smtp.armas.fi (Postfix) with SMTP id 3B427AB0449; Fri, 8 Dec 2006 21:04:32 +0200 (EET) Message-ID: <4579B73F.4050105@ainaip.net> Date: Fri, 08 Dec 2006 21:04:31 +0200 From: =?ISO-8859-1?Q?Jarno_L=E4hteenm=E4ki?= Organization: AinaCom Oy User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [RAM] Critical routing questions, and how to proceed References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <3b00a37e6819a02307db83063d1199f6@it.uc3m.es> In-Reply-To: <3b00a37e6819a02307db83063d1199f6@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1 X-smtp.armas.fi-MailScanner-Information: Please contact the ISP for more information X-smtp.armas.fi-MailScanner: Found to be clean X-smtp.armas.fi-MailScanner-From: jarlah@ainaip.net Content-Transfer-Encoding: quoted-printable 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 For IPv4 see: http://www.cidr-report.org/ For IPv6 see: http://www.cidr-report.org/v6/ Regards, --> Jarno L=E4hteenm=E4ki marcelo bagnulo braun wrote: > maybe a related question would be: how many of the bgp routing entries > today are due to multihomed sites and how many are due to more > specifics being announced for TE reasons? i think there are some > reports out there with this info... anyone has a pointer? > > Thanks, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 15:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmN8-0004K3-Ob; Fri, 08 Dec 2006 15:31:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmN6-0004Jp-MG for ram@iab.org; Fri, 08 Dec 2006 15:31:04 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsmN3-0006Hg-DJ for ram@iab.org; Fri, 08 Dec 2006 15:31:04 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id DCC804AC6E; Fri, 8 Dec 2006 15:30:53 -0500 (EST) Date: Fri, 8 Dec 2006 15:30:53 -0500 From: John Leslie To: Noel Chiappa Message-ID: <20061208203052.GB67571@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org Subject: [RAM] Critical routing problems X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Commenting on just this one issue: Noel Chiappa wrote: > > When I look at what the problem seems to be (according to the various > presentations), it seems to be growth in the size of the routing table > (with dynamics of routing table entries coming in second). This list exists because folks complained about the growth of the routing tables. I agree this growth needs to be moderated; but if the issue were _only_ the memory to hold routing tables, I'd tell the folks to stop whining and hire people with experience in central-processor design. There are a _lot_ of tricks used there to effectively manage large memory requirements. I do not believe that is the only issue, however. Route churn is a problem which cannot be fixed with that bag of tricks; and the route churn problem depends on the table size. As mobility (inevitably) becomes more common, the need for real- time changes in forwarding paths to end-users will increase the demand for real-time changes in routes chosen. This is the pressure I believe we most seriously have to moderate. (Before you ask: No attempts to outlaw such changes can be successful, IMHO.) Bottom line: I agree we need to reduce the pressure leading to increases in the size of routing tables at the "backbone". -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 15:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmXG-000099-Mp; Fri, 08 Dec 2006 15:41:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmXF-00008w-7L for ram@iab.org; Fri, 08 Dec 2006 15:41:33 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GsmXB-0008A0-1i for ram@iab.org; Fri, 08 Dec 2006 15:41:33 -0500 Received: from webmail06.lax.untd.com (webmail06.lax.untd.com [10.131.27.146]) by smtpout07.lax.untd.com with SMTP id AABCZVVREAWT5RQ2 for (sender ); Fri, 8 Dec 2006 12:41:08 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKaYuNJOtENoCEOAwaET1nzw== Received: (from fergdawg@netzero.net) by webmail06.lax.untd.com (jqueuemail) id L84KSYDR; Fri, 08 Dec 2006 12:40:37 PST Received: from [168.61.0.42] by webmail06.lax.untd.com with HTTP: Fri, 8 Dec 2006 20:40:13 GMT X-Originating-IP: [168.61.0.42] Mime-Version: 1.0 From: "Fergie" Date: Fri, 8 Dec 2006 20:40:13 GMT To: john@jlc.net Subject: Re: [RAM] Critical routing problems X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061208.124037.2704.1639766@webmail06.lax.untd.com> X-ContentStamp: 18:9:3647235602 X-MAIL-INFO: 331d9965b454995454c41df4414029202049e4e020d059410061758d242d2d9911f93165 X-UNTD-Peer-Info: 10.131.27.146|webmail06.lax.untd.com|webmail06.lax.untd.com|fergdawg@netzero.net 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: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- John Leslie wrote: >Commenting on just this one issue: > >Noel Chiappa wrote: >> = >> When I look at what the problem seems to be (according to the various= >> presentations), it seems to be growth in the size of the routing tabl= e >> (with dynamics of routing table entries coming in second). > >This list exists because folks complained about the growth of the >routing tables. > >I agree this growth needs to be moderated; but if the issue were >_only_ the memory to hold routing tables, I'd tell the folks to stop >whining and hire people with experience in central-processor design. >There are a _lot_ of tricks used there to effectively manage large >memory requirements. > >I do not believe that is the only issue, however. Route churn is >a problem which cannot be fixed with that bag of tricks; and the >route churn problem depends on the table size. > >As mobility (inevitably) becomes more common, the need for real- >time changes in forwarding paths to end-users will increase the >demand for real-time changes in routes chosen. This is the pressure >I believe we most seriously have to moderate. (Before you ask: No >attempts to outlaw such changes can be successful, IMHO.) > >Bottom line: I agree we need to reduce the pressure leading to >increases in the size of routing tables at the "backbone". > These are _exactly_ the issues which the major backbone operators have been asking us to consider -- for several years now. It's a shame that it has taken this long to get the attention of the IAB/IETF. :-) $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFec2gq1pz9mNUZTMRAkCPAKDDdThOxP9IBwfkolkYHBNV4nHRtwCgpgVH +eYnoznPse5OfYFV7Pr0fYY=3D =3DtGj6 -----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 Fri Dec 08 15:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmfH-00036x-Vc; Fri, 08 Dec 2006 15:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmfG-00036s-Pq for ram@iab.org; Fri, 08 Dec 2006 15:49:50 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsmfF-0000Ol-Hk for ram@iab.org; Fri, 08 Dec 2006 15:49:50 -0500 Received: from s73602 (futurewei.com?[65.104.224.99]) by comcast.net (rwcrmhc13) with SMTP id <20061208204944m1300afbi4e>; Fri, 8 Dec 2006 20:49:44 +0000 Message-ID: <12b601c71b09$f75c5eb0$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> Subject: Re: [RAM] Critical routing problems Date: Fri, 8 Dec 2006 14:46:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 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 Hi, John, > As mobility (inevitably) becomes more common, the need for real- > time changes in forwarding paths to end-users will increase the > demand for real-time changes in routes chosen. This is the pressure > I believe we most seriously have to moderate. (Before you ask: No > attempts to outlaw such changes can be successful, IMHO.) > > Bottom line: I agree we need to reduce the pressure leading to > increases in the size of routing tables at the "backbone". ??? I don't attend Mobile IP working group meetings these days, but the whole point of Mobile IP WAS to let you send IP traffic to someone who's not in the "right place", based on IP address and routing tables, by using tunneling encapsulation to present routers with outer IP addresses that ARE topologically correct. I don't understand how increased use of tunneling would show up as route churn. One of us is confused. Could you say more about this? Thanks, Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 16:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmuM-0000XM-UW; Fri, 08 Dec 2006 16:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmuM-0000XB-5z for ram@iab.org; Fri, 08 Dec 2006 16:05:26 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsmuB-0003Na-8F for ram@iab.org; Fri, 08 Dec 2006 16:05:26 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 08 Dec 2006 13:04:14 -0800 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 kB8L4DiW007327; Fri, 8 Dec 2006 13:04:13 -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 kB8L4Cin020073; Fri, 8 Dec 2006 13:04:13 -0800 (PST) Received: from [10.100.0.100] ([10.61.80.188]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id kB8Kn0Cd011608; Fri, 8 Dec 2006 12:49:01 -0800 Message-ID: <4579D349.604@cisco.com> Date: Fri, 08 Dec 2006 21:04:09 +0000 From: Eliot Lear User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: John Leslie References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> In-Reply-To: <20061208203052.GB67571@verdi> 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=1984; t=1165611853; x=1166475853; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20What=20is=20the=20required=20reading=20for=20this=20problem=2 0space? |Sender:=20; bh=BljEaASvGsapEvotjvOkZKxtZ+5DQhf+g6DaWcZU+9Y=; b=oB0mhCMq/wp7WA3DiLRoEuvdZ6W71jYYOtXVCadBO9bwy7VQrKxLWGPIzOTeLy++BkQWiX4s f5yM/bhHQUoGBNBfaghn3duA3Zw/tPPJLSB4xw5681Izw+iUrYEpDQIV; DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1984; t=1165610942; x=1166474942; 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:=20What=20is=20the=20required=20reading=20for=20this=20problem=2 0space? |Sender:=20 |To:=20John=20Leslie=20; bh=BljEaASvGsapEvotjvOkZKxtZ+5DQhf+g6DaWcZU+9Y=; b=Vw3tT9yVEg34+S/m6TbOBxLw34P+OHED0Kngwbfyqm0cW2wLfgbcJENB233RDGrcGimt2xO7 M6STrTFmp3YHEYrz3PZoFJcRQ8avmYm3eCEPaBfN8Xe8JiKbGyVirQ/3; Authentication-Results: sj-dkim-3; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Noel Chiappa , ram@iab.org Subject: [RAM] What is the required reading for this problem space? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org John Leslie wrote: > As mobility (inevitably) becomes more common, the need for real- > time changes in forwarding paths to end-users will increase the > demand for real-time changes in routes chosen. This is the pressure > I believe we most seriously have to moderate. (Before you ask: No > attempts to outlaw such changes can be successful, IMHO.) > I agree with Spencer on this one. With the exception of Connexion I know of no other applications of BGP for mobility, and it certainly does seem to be fitting the square peg in the round hole, when MIP and MIPv6 exist. Therefore, let us assume for the moment that we have two classes of use cases: * Multihoming * Traffic Engineering One useful pointer would be a paper that analyzes the churn in the routing system and attempts to determine how much of that churn is useful at different points in the network. In other words, are we hiding information sufficiently well to attain the stated goals for the two cases above? I work has been done on this in the past, but I can't find the pointer. Another way of putting this: before we march forward on architectural changes, are we sure we fully understand what is causing the pain points? What are the exacerbating circumstances? If we say, for instance, that the core routing table is O(256k) and growing at a rate of 30% per year, if we were to reduce that growth rate to 5% per year, would we have solved a problem? In short, if we are to take Vince's and Dave's presentations to heart, the problem is NOT that we will hit a wall, but rather that we ARE hitting a knee. How far back to we have to pull to get into the middle of the pack (c.f, Rogers Adoption curve)? If we pull back to whatever that rate is within the core, are we going to get hit from other sides, like say carrying customer IGP information within BGP for 2547 VPNs? In short, what is the required reading here? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 16:17:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsn5w-0005r3-Hh; Fri, 08 Dec 2006 16:17:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsn5v-0005qt-Ow for ram@iab.org; Fri, 08 Dec 2006 16:17:23 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsn5t-0006Ce-Ry for ram@iab.org; Fri, 08 Dec 2006 16:17:23 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 338694ACA4; Fri, 8 Dec 2006 16:17:22 -0500 (EST) Date: Fri, 8 Dec 2006 16:17:22 -0500 From: John Leslie To: Noel Chiappa Subject: Re: [RAM] Critical routing questions, and how to proceed Message-ID: <20061208211722.GC67571@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i 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 Noel Chiappa wrote: > > The multi-homing clearly has to be handled by use of multiple routing-names, > and identity/location separation. Is that generally agreed on? I think we agree; but I worry whether we all mean the same thing by those words. What I think that means is that there needs to be a routing and forwarding structure which can deliver packets to the same node via paths which differ in the last hop (or more); and that there needs to be some function which allows the sender (or its agent) to determine the locators (routing-names) of those alternate paths. (I'm expecting to get flamed for that -- but it's really pointless to settle on nice-sounding words if we can't agree what they mean.) > Whether that separation happens through widescale deployment of mechanisms > above the basic internetworking layer (e.g. SHIM6 or HIP), or through what > I've been calling the "jack-up" model (inserting a new internetworking > layer underneath the existing one, and turning existing IPvN addresses > into things that are mostly identity-names), remains to be seen. Those are not the only possibilities -- even in the short-term. It's quite reasonable to design around interface boxes, and have their translation function be gradually integrated into operating systems. We should be careful how we introduce changes intended as short-term fixes. Most of the folks that will need to adopt them don't want to listen to lectures on architecture. Indeed, we'll probably need most folks to think of them as "improved NAT boxes" or "improved office routers". ;^) > (Although that's a critical question to decide, I don't think it has > a lot of impact on the routing questions; although it is true that > jack-up assumes a new routing-name namespace, which answers question 1 > below with a "yes", and forces us to immediately move to question 2.) We _definitely_ don't want to be selling this as a "new routing-name namespace"! > So here are a number of further open questions that come to mind. > > - 1. Assuming that growth through multi-homing is controlled, is general > entropy in the routing tables so bad that we need to somehow move > to a routing-name namespace which has more hierarchy, and in which > less entropy is allowed (i.e. it's more purely connectivity-based)? IMHO, this need is fairly immediate -- I expect problems within five years if we don't, and five years is about as fast as we can hope to deploy it. > In other words, even if we could deploy HIP/SHIM6/whatever, is the entropy > in the IPvN namespace going to be so big that in the not-too-distant > future we will no longer be able to do path computations using names from > the space? Bluntly: do we have to deploy a new namespace for routing-names? Actually, that's a different question. IPv6 comes with very strong hierarchy if we just can slow down the pressure to end-run it. HIP and/or SHIM6 _could_ help slow that pressure; but neither can hope for universal deployment fast enough. (Perhaps they could become part of the bag-o-tricks in those "improved office routers"?) > - I will leave aside less-critical questions like i) the syntax of that > new namespace (i.e. do we recycle an existing syntax), ii) what routing > algorithms we use to compute paths in that new namespace, etc, for the > moment, and get to the one that's really troubling me: Agreed. > - 2. If we do have a new namespace for routing-names, then how does the > interoperability work? (This is some of what I was pondering with > those diagrams I drew.) I think we more or less have to inject old > routing-names in the new routing plane, but do we then wind up > going from the frying pan to the fire, where we have even *more* > destinations to track? Good question! Ideally, the interoperability works seamlessly: "old routers" in the forwarding path don't have to change anything, getting their forwarding tables for the "new namespace" the same way they get "old namespace" routes. IMHO, if we get sufficient deployment, aggressive flap-damping can reduce the routing-table size faster than we need to add "new" routes. > > My suggestion is that someone (you, David?), organize a small telecon > to try and come up with a coherent, organized "list of discussion points" > to be covered on RAM, and that someone (you, again?) then tries to guide > the list through those points in a organized and productive way, rather > than simply letting the e-conversation ramble off in a totally unguided > way. Noel is asking a lot here -- perhaps too much. For the time being, I suggest that Noel simply posts the "discussion points he thinks would be helpful, and anyone who disagrees explain to Noel in private email what's wrong with them. -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 16:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnZE-00065I-Pz; Fri, 08 Dec 2006 16:47:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnZC-00062I-Lg for ram@iab.org; Fri, 08 Dec 2006 16:47:38 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsnZB-0003Du-ET for ram@iab.org; Fri, 08 Dec 2006 16:47:38 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C7E64AC76; Fri, 8 Dec 2006 16:47:35 -0500 (EST) Date: Fri, 8 Dec 2006 16:47:34 -0500 From: John Leslie To: Spencer Dawkins Subject: Re: [RAM] Critical routing problems Message-ID: <20061208214734.GA74502@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> <12b601c71b09$f75c5eb0$6701a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12b601c71b09$f75c5eb0$6701a8c0@china.huawei.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Spencer Dawkins wrote: > >> As mobility (inevitably) becomes more common, the need for real- >> time changes in forwarding paths to end-users will increase the >> demand for real-time changes in routes chosen. This is the pressure >> I believe we most seriously have to moderate. (Before you ask: No >> attempts to outlaw such changes can be successful, IMHO.) > > I don't attend Mobile IP working group meetings these days, but the > whole point of Mobile IP WAS to let you send IP traffic to someone > who's not in the "right place", based on IP address and routing > tables, by using tunneling encapsulation to present routers with > outer IP addresses that ARE topologically correct. I don't understand > how increased use of tunneling would show up as route churn. > > One of us is confused. Could you say more about this? Well, I'm sure _I'm_ confused. ;^) Tunneling has a number of problems (which I won't go into). But it doesn't _by_itself_ increase route churn. Consider air travel. It's common for folks to travel to different continents. Their mobile device _should_ get an IP address on the continent they've traveled to. Their dispatch point is likely still on the continent they came from. They're pretty sure to want to exchange packets with hosts on the continent they're on. Tunneling no longer seems so attractive... All the "solutions" that come to mind raise questions of security and privacy. I foresee pointy-haired bosses insisting "just fix the routing!!!". Some folks just don't appreciate the subtle beauty of our work... -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 17:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsnnl-0004Ej-U1; Fri, 08 Dec 2006 17:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsnnk-0004EW-H5 for ram@iab.org; Fri, 08 Dec 2006 17:02:40 -0500 Received: from smtp160.iad.emailsrvr.com ([207.97.245.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsnnj-0005OC-82 for ram@iab.org; Fri, 08 Dec 2006 17:02:40 -0500 Received: from [192.168.0.2] (c-67-188-42-109.hsd1.ca.comcast.net [67.188.42.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dow.street@linquest.com) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id D5B3F641C7B; Fri, 8 Dec 2006 17:02:36 -0500 (EST) In-Reply-To: <20061208214734.GA74502@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> <12b601c71b09$f75c5eb0$6701a8c0@china.huawei.com> <20061208214734.GA74502@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17FE637D-97F6-4837-B23F-22205428753A@linquest.com> Content-Transfer-Encoding: 7bit From: Dow Street Subject: Re: [RAM] Critical routing problems Date: Fri, 8 Dec 2006 14:02:34 -0800 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: OK 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 I agree with John (I think). We should not artificially scope the "Internet" for which we're designing a new routing system to the current set of wireline links managed by commercial ISPs. Instead, try to imagine a network with several orders of magnitude more devices, many of them mobile (meaning wireless links and ad-hoc topology). Pieces of the "infrastructure" may be mobile as well, and connectivity back to a central "core" is not guaranteed. For example, two cars on the highway with an IP capable link should be able to exchange data even if neither can access the core. If you include this whole scope of connectivity scenarios then the "fixed waypoint" model of MIP or NEMO breaks down quickly and you have to solve it in routing. In other words, support for mobility/nomadic behavior should be a fundamental consideration in the architecture, not an add-on feature. It is fine if we come to the consensus that the full scope of fixed ISP core, MANET, ad-hoc community WIFI, personal networks, etc. cannot be accommodated in a single architecture. But, that decision should be due to limitations of technology, not limitations of imagination. R, Dow On Dec 8, 2006, at 1:47 PM, John Leslie wrote: > Spencer Dawkins wrote: >> >>> As mobility (inevitably) becomes more common, the need for real- >>> time changes in forwarding paths to end-users will increase the >>> demand for real-time changes in routes chosen. This is the pressure >>> I believe we most seriously have to moderate. (Before you ask: No >>> attempts to outlaw such changes can be successful, IMHO.) >> >> I don't attend Mobile IP working group meetings these days, but the >> whole point of Mobile IP WAS to let you send IP traffic to someone >> who's not in the "right place", based on IP address and routing >> tables, by using tunneling encapsulation to present routers with >> outer IP addresses that ARE topologically correct. I don't understand >> how increased use of tunneling would show up as route churn. >> >> One of us is confused. Could you say more about this? > > Well, I'm sure _I'm_ confused. ;^) > > Tunneling has a number of problems (which I won't go into). But it > doesn't _by_itself_ increase route churn. > > Consider air travel. It's common for folks to travel to different > continents. Their mobile device _should_ get an IP address on the > continent they've traveled to. Their dispatch point is likely still > on the continent they came from. They're pretty sure to want to > exchange > packets with hosts on the continent they're on. Tunneling no longer > seems so attractive... > > All the "solutions" that come to mind raise questions of security > and privacy. I foresee pointy-haired bosses insisting "just fix the > routing!!!". > > Some folks just don't appreciate the subtle beauty of our work... > > -- > John Leslie > > _______________________________________________ > 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 Dec 08 17:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnqX-0005dr-Vj; Fri, 08 Dec 2006 17:05:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnqX-0005dm-C4 for ram@iab.org; Fri, 08 Dec 2006 17:05:33 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsnqV-0005z5-Rv for ram@iab.org; Fri, 08 Dec 2006 17:05:33 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 4BAD74AC9C; Fri, 8 Dec 2006 17:05:32 -0500 (EST) Date: Fri, 8 Dec 2006 17:05:32 -0500 From: John Leslie To: Eliot Lear Message-ID: <20061208220532.GB74502@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> <4579D349.604@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4579D349.604@cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ram@iab.org Subject: [RAM] Re: What is the required reading for this problem space? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Eliot Lear wrote: > John Leslie wrote: > >> As mobility (inevitably) becomes more common, the need for real- >> time changes in forwarding paths to end-users will increase the >> demand for real-time changes in routes chosen. This is the pressure >> I believe we most seriously have to moderate. (Before you ask: No >> attempts to outlaw such changes can be successful, IMHO.) > > I agree with Spencer on this one. With the exception of Connexion I > know of no other applications of BGP for mobility, and it certainly does > seem to be fitting the square peg in the round hole, when MIP and MIPv6 > exist. Agreed... But from where I sit I see an awful lot of square pegs... > Therefore, let us assume for the moment that we have two classes of use > cases: > > * Multihoming > * Traffic Engineering Multihoming _should_ become more common. At the least, we must expect it to rise as the number of businesses connected rises. Traffic Engineering should be pretty independent of anything we do. The things I can think of to improve traffic engineering without adding routes are out of scope for this list. (Hmm... I may have to eat those words, but not now...) > One useful pointer would be a paper that analyzes the churn in the > routing system and attempts to determine how much of that churn is > useful at different points in the network. Agreed. Alas, I'm not aware of such a paper. > In other words, are we hiding information sufficiently well to attain > the stated goals for the two cases above? I seriously doubt it (but I'd be happy to read actual studies). > Another way of putting this: before we march forward on architectural > changes, are we sure we fully understand what is causing the pain points? No, of course not! > What are the exacerbating circumstances? If we say, for instance, that > the core routing table is O(256k) and growing at a rate of 30% per year, > if we were to reduce that growth rate to 5% per year, would we have > solved a problem? Good questions! > How far back to we have to pull to get into the middle of the pack > (c.f, Rogers Adoption curve)? If we pull back to whatever that rate > is within the core, are we going to get hit from other sides, like > say carrying customer IGP information within BGP for 2547 VPNs? I like to believe there's a way to reduce demand for increasing routes, rather than just increasing costs. I definitely would expect to get hit from other sides if we try to solve this by increasing costs. -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 08 21:28:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsruz-0007Qz-Ky; Fri, 08 Dec 2006 21:26:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsruy-0007PK-9K for ram@iab.org; Fri, 08 Dec 2006 21:26:24 -0500 Received: from rommie.caida.org ([192.172.226.78] helo=caida.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsruv-0003Ja-UO for ram@iab.org; Fri, 08 Dec 2006 21:26:24 -0500 Received: from lapa (user-10cmft4.cable.mindspring.com [64.203.63.164]) by caida.org (Postfix) with ESMTP id D82BCB9A2; Fri, 8 Dec 2006 18:26:14 -0800 (PST) From: "Dmitri Krioukov" To: "'John Leslie'" , "'Noel Chiappa'" Subject: RE: [RAM] Critical routing problems Date: Fri, 8 Dec 2006 18:26:08 -0800 Message-ID: <011e01c71b39$62b67900$1f01a8c0@lapa> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20061208203052.GB67571@verdi> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 agree with this one, of course: if it was only the routing table size, i.e., no churn caused by dynamics, then the first slide of http://www.caida.org/publications/presentations/2006/dima_ietf67_scalability_routing/ says :) -- There exist routing algorithms such that even if all of 2^128 IPv6 'nodes' are completely de- aggregated (i.e., all IPv6 addresses are used as flat IDs), the 'DFZ' routing tables still contain less than 128^2 ~ 16,000 entries (~1000 entries for IPv4) -- dima. http://www.caida.org/~dima/ > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Friday, December 08, 2006 12:31 PM > To: Noel Chiappa > Cc: ram@iab.org > Subject: [RAM] Critical routing problems > > > Commenting on just this one issue: > > Noel Chiappa wrote: > > > > When I look at what the problem seems to be (according to > the various > > presentations), it seems to be growth in the size of the > routing table > > (with dynamics of routing table entries coming in second). > > This list exists because folks complained about the growth of the > routing tables. > > I agree this growth needs to be moderated; but if the issue were > _only_ the memory to hold routing tables, I'd tell the folks to stop > whining and hire people with experience in central-processor design. > There are a _lot_ of tricks used there to effectively manage large > memory requirements. > > I do not believe that is the only issue, however. Route churn is > a problem which cannot be fixed with that bag of tricks; and the > route churn problem depends on the table size. > > As mobility (inevitably) becomes more common, the need for real- > time changes in forwarding paths to end-users will increase the > demand for real-time changes in routes chosen. This is the pressure > I believe we most seriously have to moderate. (Before you ask: No > attempts to outlaw such changes can be successful, IMHO.) > > Bottom line: I agree we need to reduce the pressure leading to > increases in the size of routing tables at the "backbone". > > -- > John Leslie > > _______________________________________________ > 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 Dec 08 23:41:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gstzv-0006sV-CX; Fri, 08 Dec 2006 23:39:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gstzu-0006sL-7P for ram@iab.org; Fri, 08 Dec 2006 23:39:38 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gstzs-0003x8-1D for ram@iab.org; Fri, 08 Dec 2006 23:39:38 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc15) with SMTP id <20061209043931015006v7ppe>; Sat, 9 Dec 2006 04:39:31 +0000 In-Reply-To: <20061208203052.GB67571@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208203052.GB67571@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EB3784E-D2DF-4D01-B65D-D107E6D508A5@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Critical routing problems Date: Fri, 8 Dec 2006 20:39:46 -0800 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 > I agree this growth needs to be moderated; but if the issue were > _only_ the memory to hold routing tables, I'd tell the folks to stop > whining and hire people with experience in central-processor design. > There are a _lot_ of tricks used there to effectively manage large > memory requirements. Ummm.... been there and done exactly that. I've got bad, bad news for you. They think we're in trouble too. They've looked at this and think it's a serious issue. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 09 05:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszLH-00069k-KK; Sat, 09 Dec 2006 05:22:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GszLG-00069c-Jp for ram@iab.org; Sat, 09 Dec 2006 05:22:02 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GszLD-0008ER-Sh for ram@iab.org; Sat, 09 Dec 2006 05:22:02 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C501D213126; Sat, 9 Dec 2006 12:21:50 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 39E57213119; Sat, 9 Dec 2006 12:21:50 +0200 (EET) In-Reply-To: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> References: <20061208164134.4A6C986ADB@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: Pekka Nikander Subject: Re: [RAM] Critical routing questions, and how to proceed Date: Sat, 9 Dec 2006 12:21:48 +0200 To: Noel Chiappa , John Leslie X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Chiappa wrote: > When I look at what the problem seems to be ..., it seems to be > growth in the size of the routing table (with dynamics of routing > table entries coming in second). The two main drivers of growth > seem to be i) multi-homing, and ii) general entropy and lack of > aggregation. Is this correct? I've been told that traffic engineering is another major factor. However, I have to admit not understanding what people mean with it. (A good reference would help.) > The multi-homing clearly has to be handled by use of multiple > routing-names, and identity/location separation. Is that generally > agreed on? I agree, but my reasons may be different than yours; see the end of this message. John Leslie interpreted Noel's statement as follows: > What I think that means is that there needs to be a routing and > forwarding structure which can deliver packets to the same node via > paths which differ...; and that there needs to be some function > which allows the sender (or its agent) to determine the locators > (routing-names) of those alternate paths. I agree with this description. To me, the notion of *primarily* doing the mapping at the sender but allowing the mapping to be delegated to an agent is an important one; see below. Noel continued: > Whether that separation happens through widescale deployment of > mechanisms above the basic internetworking layer ..., or through > what I've been calling the "jack-up" model ..., remains to be seen. These seem to be the basic architectural choices, given the practical constraints. However, one particular problem here is that people seem to see here more architectural choices that there are. For example, the one that John Leslie proposed ... > It's quite reasonable to design around interface boxes, and have > their translation function be gradually integrated into operating > systems. ... is in my opinion just a perhaps-good transition path. Hence, from the 30000 feet high architectural perspective, having such "interface boxes" does not architecturally differ from the primary id/ loc separation approach (akin-to HIP/SHIM6/whatever). It just represents a particular intermediate deployment technique towards a full id/loc separation. [A thorny issue in any such proxy scheme is security, i.e., delegation. With public keys it is easy to solve; without public keys the problem seems harder to solve.] [I agree with John Leslie's comments on who to market such the change.] > So here are a number of further open questions that come to mind. I don't have any informed opinion on your two questions; I'm here to learn in those respects. I do agree that organising this discussion is needed, as opposed to the more freely ranging discussion at arch-d. Personally, I'd even be ready to accept strict moderation, if needed. --- What follows is a piece of architectural argumentation why I think that multi-homing is best handled by using multiple routing-names, as opposed to e.g. using compact routing. This may be a slight digression on this list and belong more to arch-d; I'll try to be very brief. If a longer argumentation is needed, perhaps we should take that to arch-d? As yet another starting point, I find the findings in compact routing very interesting (see e.g. Dima's presentation). Based on them (e.g. the BC algorithm with stretch of 1.01 for Internet ASes), the bad news is on slide 20 of Dima's presentation: > The algorithms are essentially static > > - Topology pre-processing (pre-computation) costs are not considered > > - Distributed implementations are possible, but the bounds for the > number of messages they need to generate in order to process a > topology change are not considered This leads to me _believe_ that perhaps _time_ is a more fundamental problem here than space. That is, apparently we could compress the routing tables quite small, given the current network structures, but we cannot do that fast enough. In other words, if we had a static network, we would not need multiple-routing names to handle multi- homing. In still other words, due to constraints on the real-life dynamics of the network vs. computational requirements of today's space-efficient representations and algorithms, it seems plausible that using multiple routing-names is a reasonable piece of a solution. BTW, the same argument applies even more to mobility; there the time scales are typically even smaller than with typical multi-homing and I don't see any reasonable way of handling those time scales with routing at the global level. But that's another discussion that IMHO does not belong to this list but more to arch-d. I'd just remind people, as recently discussed at arch-d, that Mobile IP and NEMO like anchor-based solutions are more hacks mandated by the lack of proper name spaces in the architecture rather than good architectural solutions. Finally, as I stated in arch-d, I believe that there are about half a dozen architectural issues in the current situation where a proper identifier / locator separation would help. Multi-homing and mobility are only two of those. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 09 06:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0dT-0005GT-B0; Sat, 09 Dec 2006 06:44:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0dR-00059l-BR for ram@iab.org; Sat, 09 Dec 2006 06:44:53 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt0dM-0002bg-2J for ram@iab.org; Sat, 09 Dec 2006 06:44:53 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id B98DA3400C; Sat, 9 Dec 2006 06:44:47 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 06:44:47 -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] Critical routing problems Date: Sat, 9 Dec 2006 06:44:46 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A0F@tayexc14.americas.cpqcorp.net> In-Reply-To: <12b601c71b09$f75c5eb0$6701a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Critical routing problems Thread-Index: AccbCnX771JKJ5Q3QGGebyk3M1PGuwAfKM3A From: "Bound, Jim" To: "Spencer Dawkins" , X-OriginalArrivalTime: 09 Dec 2006 11:44:47.0550 (UTC) FILETIME=[6D87CDE0:01C71B87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Point to Note is several Mobile IP optimizations avoid tunnels completely. I believe tunnels will not be required for mobility when it becomes so pervasive it will impact the operators.=20 I do believe it exacerbates routing churn because it will require operators to carry potentially more routes that are from different prefix addresses thus has an aggregation affect. /jim > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Friday, December 08, 2006 3:47 PM > To: ram@iab.org > Subject: Re: [RAM] Critical routing problems >=20 > Hi, John, >=20 > > As mobility (inevitably) becomes more common, the need for real-=20 > > time changes in forwarding paths to end-users will increase=20 > the demand=20 > > for real-time changes in routes chosen. This is the=20 > pressure I believe=20 > > we most seriously have to moderate. (Before you ask: No attempts to=20 > > outlaw such changes can be successful, IMHO.) > > > > Bottom line: I agree we need to reduce the pressure leading to=20 > > increases in the size of routing tables at the "backbone". >=20 > ??? >=20 > I don't attend Mobile IP working group meetings these days,=20 > but the whole point of Mobile IP WAS to let you send IP=20 > traffic to someone who's not in the "right place", based on=20 > IP address and routing tables, by using tunneling=20 > encapsulation to present routers with outer IP addresses that=20 > ARE topologically correct. I don't understand how increased=20 > use of tunneling would show up as route churn. >=20 > One of us is confused. Could you say more about this? >=20 > Thanks, >=20 > Spencer=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 Sat Dec 09 17:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAUG-0000Lt-2K; Sat, 09 Dec 2006 17:16:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAUE-0000La-Li; Sat, 09 Dec 2006 17:16:02 -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 1GtAUD-0008Hm-5U; Sat, 09 Dec 2006 17:16:02 -0500 Received: from 199.13.wireless.icannsaopaulo.br (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kB9M9LSv005182; Sat, 9 Dec 2006 14:09:29 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by 199.13.wireless.icannsaopaulo.br (PGP Universal service); Sat, 09 Dec 2006 20:15:51 -0200 X-PGP-Universal: processed; by 199.13.wireless.icannsaopaulo.br on Sat, 09 Dec 2006 20:15:51 -0200 In-Reply-To: <121fd274017de9e61550cf58bb93856e@it.uc3m.es> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> From: David Conrad Date: Sat, 9 Dec 2006 20:15:39 -0200 To: marcelo bagnulo braun 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: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ram@iab.org Subject: [RAM] Re: [arch-d] Major practical decision X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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've redirected this to ram@iab.org, bcc'ing arch-d since this is talking more about an implementation model than a theoretical model. I've gathered the feeling is that discussion about what Noel calls the "jack up" approach such as this should occur on ram instead of arch-d.] Marcelo, Just to be clear, my focus has been to try to come up with a model that would minimize the number of changes that would need to be made to deployed systems as I believe this significantly improves the chances that stuff will actually get deployed. While I would love to see a clean-sheet architecture, I'll admit to being a bit too cynical to believe it would ever get deployed. On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: > i am not sure i understand what you have in mind, but the peer that > is communicating with host within the multihomed site will need to > know the identifier and all the locators, so it can encapsulate > with all the different locators, right? No. The source "host" would only need to know about the identifier of the destination "host" (discoverable via DNS as normal). The multiple locators would be bound to the identifier later. I think it is actually fairly important that the "host" _not_ know about locators as the alternative is a layering violation that ends up causing a lot of problems in the end. In the model I've argued for, the mapping from identifier to locator would occur at the "edge" (where the "edge" could be anywhere from the source device to the first hop router to the ISP/end site boundary). At this mapping device/"edge" router, the packet would be encapsulated with the destination address being one of the set of locators associated with the identifier. At the destination mapping device/"edge" router, the packet would be de-encapsulated and forwarded on to the destination identifier. > If this is the case, the peer (or some box near the peer) needs to > support whatever protocol are used to securely exchange the > identifier and locator set. Yes, in the sense that the mapping needs to be propagated somehow, either some push mechanism (e.g., a flooding protocol or as a BGP attribute or whatever) or a pull mechanism (e.g., something like the DNS). If you use the DNS, you could have something like: ; dest identifier RR dst locator pref 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... b000::0002 200 ... c000::0003 300 ... which could be secured with DNSSEC (assuming it ever gets deployed). > This box needs to be deployed, hence, we need support outside the > multihomed site, right? I think I see what you're saying. So, there are 4 cases: 1) unmapped source, unmapped destination: this is what we have now. 2) mapped source, mapped destination: this would be the goal. 3) mapped source, unmapped destination: if the destination is reachable via the "legacy" routing system, this would work if the mapping service is able to determine that the destination is not mapped and fall back to case 1. For this to work, the source identifier would have to be routable, perhaps sub-optimally, in the "legacy" routing system. 4) unmapped source, mapped destination: since the source knows nothing about mapping, the only way the destination would be reachable is if the destination identifier is routable, perhaps sub- optimally, in the "legacy" routing system. Given this, as a transition mechanism, the existing "addresses" (which I'm defining to be the merged identifier/locator blob of bits we have in the source and destination fields of IP packets now) would be treated as identifiers if they are mapped and locators if they aren't. The mapping device/"edge" router would make the determination on the fly based on whether the mapping succeeded or failed. So, yes, there would need to be some support outside the multi-homed site to take advantage of the multi-homing (etc.), but things will still work, perhaps sub-optimally, without it. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 10 04:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtL3G-0001Zr-Av; Sun, 10 Dec 2006 04:32:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtL3F-0001Zm-GF for ram@iab.org; Sun, 10 Dec 2006 04:32:53 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtL3D-0004zE-VK for ram@iab.org; Sun, 10 Dec 2006 04:32:53 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1648C213129; Sun, 10 Dec 2006 11:32:51 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B27AA21311D; Sun, 10 Dec 2006 11:32:50 +0200 (EET) In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <190FAA49-041B-45CA-9FA3-373739620EBE@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: [arch-d] Major practical decision Date: Sun, 10 Dec 2006 11:32:49 +0200 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP 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: , Errors-To: ram-bounces@iab.org > So, there are 4 cases: > > 1) unmapped source, unmapped destination: this is what we have now. > > 2) mapped source, mapped destination: this would be the goal. > > 3) mapped source, unmapped destination: if the destination is > reachable via the "legacy" routing system, this would work if the > mapping service is able to determine that the destination is not > mapped and fall back to case 1. For this to work, the source > identifier would have to be routable, perhaps sub-optimally, in the > "legacy" routing system. > > 4) unmapped source, mapped destination: since the source knows > nothing about mapping, the only way the destination would be > reachable is if the destination identifier is routable, perhaps sub- > optimally, in the "legacy" routing system. This seems to be essentially what I tried to state in one of my messages at arch-d but couldn't say as nicely. I fully agree that we will need transition mechanisms for #3/#4. The details of such transition mechanisms should be designed with economics very much in mind, making sure that those that will benefit are also those that will cover the costs, either immediately or through a very direct and simple value chain. > Given this, as a transition mechanism, the existing > "addresses" (which I'm defining to be the merged identifier/locator > blob of bits we have in the source and destination fields of IP > packets now) would be treated as identifiers if they are mapped and > locators if they aren't. The mapping device/"edge" router would > make the determination on the fly based on whether the mapping > succeeded or failed. I mostly agree. One difference that I'd prefer is to consider the "mapped addresses" as _representations_ of or _handles_ for the identifiers, not as the actual identifiers themselves. (Or, alternatively, if we decide to take Noel's jack-up way, the "unmapped addresses" would be handles for the locators.) That is, I'd like to make the new name space genuinely distinct, and embed it to the existing name space only in order to make these kinds of transition mechanisms to work. For example, our proposed ORCHID mechanisms should be considered as a medium-term transition mechanism that allows public keys to be embedded to the IPv6 address space. > So, yes, there would need to be some support outside the multi- > homed site to take advantage of the multi-homing (etc.), but things > will still work, perhaps sub-optimally, without it. I concur. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 10 06:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtMnc-0007vJ-BX; Sun, 10 Dec 2006 06:24:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtMnb-0007vD-E4 for ram@iab.org; Sun, 10 Dec 2006 06:24:51 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtMnY-00042t-O0 for ram@iab.org; Sun, 10 Dec 2006 06:24:51 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 918D01110A5; Sun, 10 Dec 2006 12:24:47 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id D99E611108B; Sun, 10 Dec 2006 12:24:46 +0100 (CET) In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> 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 Date: Sun, 10 Dec 2006 12:24:51 +0100 To: David Conrad X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: ram@iab.org Subject: [RAM] Re: [arch-d] Major practical decision X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 09/12/2006, a las 23:15, David Conrad escribi=F3: > [I've redirected this to ram@iab.org, bcc'ing arch-d since this is=20 > talking more about an implementation model than a theoretical model. =20= > I've gathered the feeling is that discussion about what Noel calls the=20= > "jack up" approach such as this should occur on ram instead of=20 > arch-d.] > > Marcelo, > > Just to be clear, my focus has been to try to come up with a model=20 > that would minimize the number of changes that would need to be made=20= > to deployed systems as I believe this significantly improves the=20 > chances that stuff will actually get deployed. While I would love to=20= > see a clean-sheet architecture, I'll admit to being a bit too cynical=20= > to believe it would ever get deployed. > yes this is valid goal imho > On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: >> i am not sure i understand what you have in mind, but the peer that=20= >> is communicating with host within the multihomed site will need to=20 >> know the identifier and all the locators, so it can encapsulate with=20= >> all the different locators, right? > > No. The source "host" would only need to know about the identifier of=20= > the destination "host" (discoverable via DNS as normal). The multiple=20= > locators would be bound to the identifier later. I think it is=20 > actually fairly important that the "host" _not_ know about locators as=20= > the alternative is a layering violation that ends up causing a lot of=20= > problems in the end. > > In the model I've argued for, the mapping from identifier to locator=20= > would occur at the "edge" (where the "edge" could be anywhere from the=20= > source device to the first hop router to the ISP/end site boundary). i can see that this approach maybe easier to deploy than other=20 approaches that require updating all the routers or updating all the=20 hosts. This is very clear in the case of the multihomed site, where it=20= will install the new box so it can obtain multihoming support wihtout=20 need to update its routers and/or hosts. but otoh, i fail to see the=20 motivation for a single homed site to adopt such a box. I mean,=20 wouldn't be easier in this case to wait for the OS update in the hosts=20= and that the OS has build in the multihoming support? > At this mapping device/"edge" router, the packet would be=20 > encapsulated with the destination address being one of the set of=20 > locators associated with the identifier. At the destination mapping=20= > device/"edge" router, the packet would be de-encapsulated and=20 > forwarded on to the destination identifier. > >> If this is the case, the peer (or some box near the peer) needs to=20 >> support whatever protocol are used to securely exchange the=20 >> identifier and locator set. > > Yes, in the sense that the mapping needs to be propagated somehow,=20 > either some push mechanism (e.g., a flooding protocol or as a BGP=20 > attribute or whatever) or a pull mechanism (e.g., something like the=20= > DNS). If you use the DNS, you could have something like: > > ; dest identifier RR dst locator pref > 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... > b000::0002 200 ... > c000::0003 300 ... > > which could be secured with DNSSEC (assuming it ever gets deployed). imho DNSSec is not required for this. It would be nice to have but not=20= a must... I mean, if we obtain the ID to locators mapping from the=20 insecure DNS we wouldn't be introducing new vulnerabilities to the=20 current internet, since a attacker can simply change the FQDN to IP=20 address DNS reply and perform similar attacks. > >> This box needs to be deployed, hence, we need support outside the=20 >> multihomed site, right? > > I think I see what you're saying. So, there are 4 cases: > > 1) unmapped source, unmapped destination: this is what we have now. > > 2) mapped source, mapped destination: this would be the goal. > > 3) mapped source, unmapped destination: if the destination is=20 > reachable via the "legacy" routing system, this would work if the=20 > mapping service is able to determine that the destination is not=20 > mapped and fall back to case 1. For this to work, the source=20 > identifier would have to be routable, perhaps sub-optimally, in the=20 > "legacy" routing system. > > 4) unmapped source, mapped destination: since the source knows nothing=20= > about mapping, the only way the destination would be reachable is if=20= > the destination identifier is routable, perhaps sub-optimally, in the=20= > "legacy" routing system. > > Given this, as a transition mechanism, the existing "addresses" (which=20= > I'm defining to be the merged identifier/locator blob of bits we have=20= > in the source and destination fields of IP packets now) would be=20 > treated as identifiers if they are mapped and locators if they aren't.=20= > The mapping device/"edge" router would make the determination on the=20= > fly based on whether the mapping succeeded or failed. > > So, yes, there would need to be some support outside the multi-homed=20= > site to take advantage of the multi-homing (etc.), but things will=20 > still work, perhaps sub-optimally, without it. > suboptimaly meaning that it would work without the multihoming=20 benefits, right? Regards, marcelo > Rgds, > -drc > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 10 19:39:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtZA7-0004uc-6Z; Sun, 10 Dec 2006 19:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtZA6-0004uU-Fi for ram@iab.org; Sun, 10 Dec 2006 19:36:54 -0500 Received: from web58704.mail.re1.yahoo.com ([66.196.100.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtZA0-0005ts-2W for ram@iab.org; Sun, 10 Dec 2006 19:36:54 -0500 Received: (qmail 56691 invoked by uid 60001); 11 Dec 2006 00:36:30 -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=hYE31SIb0hafhHcty4rGKgiKJwrtsa/x7SGLT9DWG0GqnL0CuLVmYkcn78+6uXP4nk1dtJJ/QCkH7SclFB3jlPX3mDk9Da8Dai3zLDzdQkQVUJcb1qYRnGim2wOhS5ZG/KoMJlU6RitSFJRQiWCIczdGEJ/j+BhK2MvxzAu8nIQ=; X-YMail-OSG: 0yya5KYVM1nOQUotCbh0KHP2NzFuNqO84f2XoLmt Received: from [74.111.124.141] by web58704.mail.re1.yahoo.com via HTTP; Sun, 10 Dec 2006 16:36:30 PST Date: Sun, 10 Dec 2006 16:36:30 -0800 (PST) From: Peter Sherbin Subject: Re: [RAM] Critical routing questions, and how to proceed To: Noel Chiappa , ram@iab.org In-Reply-To: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <726466.56358.qm@web58704.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Now we are getting somewhere. Thank you Noel for championing this. For routing consider the following (provider's hat on): 1. When providers merge a new network becomes a collection of ASNs. Reaching a single ASN takes years because of re-numbering of end customers. 2. Two providers splitting the assets of the third. One gets a core and another takes the edge. ASN goes with the core. The second provider faces re-numbering of all acquired customers. Both 1. and 2. are current cases worth tens of millions and a lot of people go through a lot of pain trying to resolve them. Hence a provider's requirement to the new routing is to allow free move of PI addressed edge networks between ASs. Thanks, Peter --- Noel Chiappa wrote: > > To keep this from getting too long, I'll send out a separate message in > > a couple of hours (just on RAM) giving a little more detail on the > > points I think RAM needs to work on > > OK, so here's the promised message. First come a few things on which I think > agreement has been reached, and then I get to ones which are still open. > > > When I look at what the problem seems to be (according to the various > presentations), it seems to be growth in the size of the routing table (with > dynamics of routing table entries coming in second). The two main drivers of > growth seem to be i) multi-homing, and ii) general entropy and lack of > aggregation. Is this correct? > > The multi-homing clearly has to be handled by use of multiple routing-names, > and identity/location separation. Is that generally agreed on? > > Whether that separation happens through widescale deployment of mechanisms > above the basic internetworking layer (e.g. SHIM6 or HIP), or through what > I've been calling the "jack-up" model (inserting a new internetworking layer > underneath the existing one, and turning existing IPvN addresses into things > that are mostly identity-names), remains to be seen. (Although that's a > critical question to decide, I don't think it has a lot of impact on the > routing questions; although it is true that jack-up assumes a new > routing-name namespace, which answers question 1 below with a "yes", and > forces us to immediately move to question 2.) > > > So here are a number of further open questions that come to mind. > > - 1. Assuming that growth through multi-homing is controlled, is general > entropy in the routing tables so bad that we need to somehow move to a > routing-name namespace which has more hierarchy, and in which less entropy is > allowed (i.e. it's more purely connectivity-based)? In other words, even if > we could deploy HIP/SHIM6/whatever, is the entropy in the IPvN namespace > going to be so big that in the not-too-distant future we will no longer be > able to do path computations using names from the space? Bluntly: do we have > to deploy a new namespace for routing-names? > > - I will leave aside less-critical questions like i) the syntax of that new > namespace (i.e. do we recycle an existing syntax), ii) what routing > algorithms we use to compute paths in that new namespace, etc, for the > moment, and get to the one that's really troubling me: > > - 2. If we do have a new namespace for routing-names, then how does the > interoperability work? (This is some of what I was pondering with those > diagrams I drew.) I think we more or less have to inject old routing-names in > the new routing plane, but do we then wind up going from the frying pan to > the fire, where we have even *more* destinations to track? > > > > My suggestion is that someone (you, David?), organize a small telecon to try > and come up with a coherent, organized "list of discussion points" to be > covered on RAM, and that someone (you, again?) then tries to guide the list > through those points in a organized and productive way, rather than simply > letting the e-conversation ramble off in a totally unguided way. > > 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 Mon Dec 11 09:41:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmJr-00057X-Ci; Mon, 11 Dec 2006 09:39:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmJq-00057S-JS for ram@iab.org; Mon, 11 Dec 2006 09:39:50 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtmJj-0005gE-6N for ram@iab.org; Mon, 11 Dec 2006 09:39:50 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id B49CD34150 for ; Mon, 11 Dec 2006 09:39:42 -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, 11 Dec 2006 09:39:42 -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] Re: [arch-d] Major practical decision Date: Mon, 11 Dec 2006 09:39:41 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2C3E@tayexc14.americas.cpqcorp.net> In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: [arch-d] Major practical decision Thread-Index: Accb3/n/th6yBD6UQqyOR4SWjbSVbABUQ3og From: "Bound, Jim" To: X-OriginalArrivalTime: 11 Dec 2006 14:39:42.0684 (UTC) FILETIME=[31F1A9C0:01C71D32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 to be clear, my focus has been to try to come up with a=20 > model that would minimize the number of changes that would=20 > need to be made to deployed systems as I believe this=20 > significantly improves the chances that stuff will actually=20 > get deployed. While I would love to see a clean-sheet=20 > architecture, I'll admit to being a bit too cynical to=20 > believe it would ever get deployed. >=20 > On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: > > i am not sure i understand what you have in mind, but the=20 > peer that is=20 > > communicating with host within the multihomed site will=20 > need to know=20 > > the identifier and all the locators, so it can encapsulate with all=20 > > the different locators, right? >=20 > No. The source "host" would only need to know about the=20 > identifier of the destination "host" (discoverable via DNS as=20 > normal). The multiple locators would be bound to the=20 > identifier later. I think it is actually fairly important=20 > that the "host" _not_ know about locators as the alternative=20 > is a layering violation that ends up causing a lot of=20 > problems in the end. This is what I have been saying too on the end-to-end part the host transport should not be involved with the locators at all. This would mean some fixes to SHIM6 but minimal. =20 What I do suggest we avoid is routing-name-space lookups when the locators are determined later past the transport and will for now assume some caching model as some have implemented IPsec SA database required for both user and network subsystem space. Thus source address selection would be at the point locators are determined. >=20 > In the model I've argued for, the mapping from identifier to=20 > locator would occur at the "edge" (where the "edge" could be=20 > anywhere from the source device to the first hop router to=20 > the ISP/end site boundary). At this mapping device/"edge"=20 > router, the packet would be encapsulated with the destination=20 > address being one of the set of locators associated with the=20 > identifier. At the destination mapping device/"edge" router,=20 > the packet would be de-encapsulated and forwarded on to the=20 > destination identifier. The above I don't agree with the host node must be involved with sending the packet to a locator (routing-namespace identifier) if the edge wants to "re-map" given our new model architecture that is fine as long as the "destination" address stays in tact. I also would like to see us avoid "tunneling" wherever possible. >=20 > > If this is the case, the peer (or some box near the peer) needs to=20 > > support whatever protocol are used to securely exchange the=20 > identifier=20 > > and locator set. >=20 > Yes, in the sense that the mapping needs to be propagated=20 > somehow, either some push mechanism (e.g., a flooding=20 > protocol or as a BGP attribute or whatever) or a pull=20 > mechanism (e.g., something like the DNS). If you use the DNS,=20 > you could have something like: >=20 > ; dest identifier RR dst locator pref > 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... > b000::0002 200 ... > c000::0003 300 ... >=20 > which could be secured with DNSSEC (assuming it ever gets deployed). I do not want to use DNS. Fine as conceptual model but there are alternatives in the market today and emerging in general for the principle of "discovery" within networks. >=20 > > This box needs to be deployed, hence, we need support outside the=20 > > multihomed site, right? >=20 > I think I see what you're saying. So, there are 4 cases: >=20 > 1) unmapped source, unmapped destination: this is what we have now. >=20 > 2) mapped source, mapped destination: this would be the goal. >=20 > 3) mapped source, unmapped destination: if the destination is=20 > reachable via the "legacy" routing system, this would work if=20 > the mapping service is able to determine that the destination=20 > is not mapped and fall back to case 1. For this to work, the=20 > source identifier would have to be routable, perhaps=20 > sub-optimally, in the "legacy" routing system. Destination must be mapped from the space this is a part of the current architecture that works and far to much to change. >=20 > 4) unmapped source, mapped destination: since the source=20 > knows nothing about mapping, the only way the destination=20 > would be reachable is if the destination identifier is=20 > routable, perhaps sub- optimally, in the "legacy" routing system. >=20 > Given this, as a transition mechanism, the existing=20 > "addresses" (which I'm defining to be the merged=20 > identifier/locator blob of bits we have in the source and=20 > destination fields of IP packets now) would be treated as=20 > identifiers if they are mapped and locators if they aren't.=20 > The mapping device/"edge" router would make the determination=20 > on the fly based on whether the mapping succeeded or failed. >=20 > So, yes, there would need to be some support outside the=20 > multi-homed site to take advantage of the multi-homing=20 > (etc.), but things will still work, perhaps sub-optimally, without it. I think that can be fixed with a new architecture. =20 /jim >=20 > Rgds, > -drc >=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 Mon Dec 11 10:48:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtnNO-0003EF-Ik; Mon, 11 Dec 2006 10:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtnNN-0003EA-Eb for ram@iab.org; Mon, 11 Dec 2006 10:47:33 -0500 Received: from [72.34.52.22] (helo=montage2.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtnNK-0000cx-Nm for ram@iab.org; Mon, 11 Dec 2006 10:47:33 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage2.altserver.com with esmtp (Exim 4.52) id 1GtnN9-0005rN-Lv for ram@iab.org; Mon, 11 Dec 2006 07:47:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Dec 2006 16:45:31 +0100 To: David Conrad , marcelo bagnulo braun From: JFCM In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> 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.1 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: ram@iab.org Subject: [RAM] Re: [arch-d] Major practical decision X-BeenThere: ram@iab.org X-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="===============1390998373==" Errors-To: ram-bounces@iab.org Message-Id: --===============1390998373== Content-Type: multipart/alternative; boundary="----MTefyjdzhbcwoscraixnilxjjmbwtexmdx" ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-495F4706 Dear David, I agree and documented how a global path and a global locator should be supported. Here, I am afraid I disagree on three grounds at least; 1. you do not permit the sender to chose the path what for legal (US law) and economic reasons (two-tiered offers) is a need 2. you impose two different processing at two separated places 3. you increase the intelligence in the dumb network. Dont you fear it might make the proposition attractive enough to users, and possibly create scalability problems? jfc At 23:15 09/12/2006, David Conrad wrote: >[I've redirected this to ram@iab.org, bcc'ing arch-d since this is >talking more about an implementation model than a theoretical model. >I've gathered the feeling is that discussion about what Noel calls >the "jack up" approach such as this should occur on ram instead of >arch-d.] > >Marcelo, > >Just to be clear, my focus has been to try to come up with a model >that would minimize the number of changes that would need to be made >to deployed systems as I believe this significantly improves the >chances that stuff will actually get deployed. While I would love to >see a clean-sheet architecture, I'll admit to being a bit too cynical >to believe it would ever get deployed. > >On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: >>i am not sure i understand what you have in mind, but the peer that >>is communicating with host within the multihomed site will need to >>know the identifier and all the locators, so it can encapsulate >>with all the different locators, right? > >No. The source "host" would only need to know about the identifier >of the destination "host" (discoverable via DNS as normal). The >multiple locators would be bound to the identifier later. I think it >is actually fairly important that the "host" _not_ know about >locators as the alternative is a layering violation that ends up >causing a lot of problems in the end. > >In the model I've argued for, the mapping from identifier to locator >would occur at the "edge" (where the "edge" could be anywhere from >the source device to the first hop router to the ISP/end site >boundary). At this mapping device/"edge" router, the packet would be >encapsulated with the destination address being one of the set of >locators associated with the identifier. At the destination mapping >device/"edge" router, the packet would be de-encapsulated and >forwarded on to the destination identifier. > >>If this is the case, the peer (or some box near the peer) needs to >>support whatever protocol are used to securely exchange the >>identifier and locator set. > >Yes, in the sense that the mapping needs to be propagated somehow, >either some push mechanism (e.g., a flooding protocol or as a BGP >attribute or whatever) or a pull mechanism (e.g., something like the >DNS). If you use the DNS, you could have something like: > >; dest identifier RR dst locator pref >1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... > b000::0002 200 ... > c000::0003 300 ... > >which could be secured with DNSSEC (assuming it ever gets deployed). > >>This box needs to be deployed, hence, we need support outside the >>multihomed site, right? > >I think I see what you're saying. So, there are 4 cases: > >1) unmapped source, unmapped destination: this is what we have now. > >2) mapped source, mapped destination: this would be the goal. > >3) mapped source, unmapped destination: if the destination is >reachable via the "legacy" routing system, this would work if the >mapping service is able to determine that the destination is not >mapped and fall back to case 1. For this to work, the source >identifier would have to be routable, perhaps sub-optimally, in the >"legacy" routing system. > >4) unmapped source, mapped destination: since the source knows >nothing about mapping, the only way the destination would be >reachable is if the destination identifier is routable, perhaps sub- >optimally, in the "legacy" routing system. > >Given this, as a transition mechanism, the existing >"addresses" (which I'm defining to be the merged identifier/locator >blob of bits we have in the source and destination fields of IP >packets now) would be treated as identifiers if they are mapped and >locators if they aren't. The mapping device/"edge" router would make >the determination on the fly based on whether the mapping succeeded >or failed. > >So, yes, there would need to be some support outside the multi-homed >site to take advantage of the multi-homing (etc.), but things will >still work, perhaps sub-optimally, without it. > >Rgds, >-drc > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss ------MTefyjdzhbcwoscraixnilxjjmbwtexmdx Content-Type: text/html Dear David,
I agree and documented how a global path and a global locator should
be supported. Here, I am afraid I disagree on three grounds at least;

1. you do not permit the sender to chose the path what for legal (US
law) and economic reasons (two-tiered offers) is a need
2. you impose two different processing at two separated places
3. you increase the intelligence in the dumb network.

Dont you fear it might make the proposition attractive enough to
users, and possibly create scalability problems?
jfc

At 23:15 09/12/2006, David Conrad wrote:

>[I've redirected this to ram@iab.org, bcc'ing arch-d since this is
>talking more about an implementation model than a theoretical model.
>I've gathered the feeling is that discussion about what Noel calls
>the "jack up" approach such as this should occur on ram instead of
>arch-d.]
>
>Marcelo,
>
>Just to be clear, my focus has been to try to come up with a model
>that would minimize the number of changes that would need to be made
>to deployed systems as I believe this significantly improves the
>chances that stuff will actually get deployed.  While I would love to
>see a clean-sheet architecture, I'll admit to being a bit too cynical
>to believe it would ever get deployed.
>
>On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote:
>>i am not sure i understand what you have in mind, but the peer that
>>is communicating with host within the multihomed site will need to
>>know the identifier and all the locators, so it can encapsulate
>>with all the different locators, right?
>
>No.  The source "host" would only need to know about the identifier
>of the destination "host" (discoverable via DNS as normal). The
>multiple locators would be bound to the identifier later.  I think it
>is actually fairly important that the "host" _not_ know about
>locators as the alternative is a layering violation that ends up
>causing a lot of problems in the end.
>
>In the model I've argued for, the mapping from identifier to locator
>would occur at the "edge" (where the "edge" could be anywhere from
>the source device to the first hop router to the ISP/end site
>boundary).  At this mapping device/"edge" router, the packet would be
>encapsulated with the destination address being one of the set of
>locators associated with the identifier.  At the destination mapping
>device/"edge" router, the packet would be de-encapsulated and
>forwarded on to the destination identifier.
>
>>If this is the case, the peer (or some box near the peer) needs to
>>support whatever protocol are used to securely exchange the
>>identifier and locator set.
>
>Yes, in the sense that the mapping needs to be propagated somehow,
>either some push mechanism (e.g., a flooding protocol or as a BGP
>attribute or whatever) or a pull mechanism (e.g., something like the
>DNS). If you use the DNS, you could have something like:
>
>; dest identifier                            RR  dst locator pref
>1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001  100 ...
>                                                  b000::0002  200 ...
>                                                  c000::0003  300 ...
>
>which could be secured with DNSSEC (assuming it ever gets deployed).
>
>>This box needs to be deployed, hence, we need support outside the
>>multihomed site, right?
>
>I think I see what you're saying.  So, there are 4 cases:
>
>1) unmapped source, unmapped destination: this is what we have now.
>
>2) mapped source, mapped destination: this would be the goal.
>
>3) mapped source, unmapped destination: if the destination is
>reachable via the "legacy" routing system, this would work if the
>mapping service is able to determine that the destination is not
>mapped and fall back to case 1.  For this to work, the source
>identifier would have to be routable, perhaps sub-optimally, in the
>"legacy" routing system.
>
>4) unmapped source, mapped destination: since the source knows
>nothing about mapping, the only way the destination would be
>reachable is if the destination identifier is routable, perhaps sub-
>optimally, in the "legacy" routing system.
>
>Given this, as a transition mechanism, the existing
>"addresses" (which I'm defining to be the merged identifier/locator
>blob of bits we have in the source and destination fields of IP
>packets now) would be treated as identifiers if they are mapped and
>locators if they aren't. The mapping device/"edge" router would make
>the determination on the fly based on whether the mapping succeeded
>or failed.
>
>So, yes, there would need to be some support outside the multi-homed
>site to take advantage of the multi-homing (etc.), but things will
>still work, perhaps sub-optimally, without it.
>
>Rgds,
>-drc
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss

------MTefyjdzhbcwoscraixnilxjjmbwtexmdx-- --===============1390998373== 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 --===============1390998373==-- From ram-bounces@iab.org Tue Dec 12 07:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu73k-0003md-3X; Tue, 12 Dec 2006 07:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu73i-0003mT-GE for ram@iab.org; Tue, 12 Dec 2006 07:48:34 -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 1Gu73g-00018Y-TY for ram@iab.org; Tue, 12 Dec 2006 07:48:34 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JA5VKV00.41C; Tue, 12 Dec 2006 13:48:31 +0100 In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> X-Priority: 1 (High) To: David Conrad X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Tue, 12 Dec 2006 13:48:28 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 12/12/2006 13:48:01 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: 2086112c730e13d5955355df27e3074b Cc: ram@iab.org Subject: [RAM] Re: [arch-d] Major practical decision X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 subscribed the RAM mailing list a couple of weeks ago, and I think you may be interested in reading the draft on "Tunneled Interdomain Routing" that I sent to the IETF in October. My proposal is based on the use a new transitive BGP attribute that I have called LOCATOR. You can find the new version of the draft-adan-idr-tidr-01.txt in the following URL: http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg13203.htm= l Regards, Juanjo David Conrad escribi=F3 el 09/12/2006 23:15:39: > [I've redirected this to ram@iab.org, bcc'ing arch-d since this is > talking more about an implementation model than a theoretical model. > I've gathered the feeling is that discussion about what Noel calls > the "jack up" approach such as this should occur on ram instead of > arch-d.] > > Marcelo, > > Just to be clear, my focus has been to try to come up with a model > that would minimize the number of changes that would need to be made > to deployed systems as I believe this significantly improves the > chances that stuff will actually get deployed. While I would love to= > see a clean-sheet architecture, I'll admit to being a bit too cynical= > to believe it would ever get deployed. > > On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: > > i am not sure i understand what you have in mind, but the peer that= > > is communicating with host within the multihomed site will need to > > know the identifier and all the locators, so it can encapsulate > > with all the different locators, right? > > No. The source "host" would only need to know about the identifier > of the destination "host" (discoverable via DNS as normal). The > multiple locators would be bound to the identifier later. I think it= > is actually fairly important that the "host" _not_ know about > locators as the alternative is a layering violation that ends up > causing a lot of problems in the end. > > In the model I've argued for, the mapping from identifier to locator > would occur at the "edge" (where the "edge" could be anywhere from > the source device to the first hop router to the ISP/end site > boundary). At this mapping device/"edge" router, the packet would be= > encapsulated with the destination address being one of the set of > locators associated with the identifier. At the destination mapping > device/"edge" router, the packet would be de-encapsulated and > forwarded on to the destination identifier. > > > If this is the case, the peer (or some box near the peer) needs to > > support whatever protocol are used to securely exchange the > > identifier and locator set. > > Yes, in the sense that the mapping needs to be propagated somehow, > either some push mechanism (e.g., a flooding protocol or as a BGP > attribute or whatever) or a pull mechanism (e.g., something like the > DNS). If you use the DNS, you could have something like: > > ; dest identifier RR dst locator pref > 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... > b000::0002 200 ...= > c000::0003 300 ...= > > which could be secured with DNSSEC (assuming it ever gets deployed). > > > This box needs to be deployed, hence, we need support outside the > > multihomed site, right? > > I think I see what you're saying. So, there are 4 cases: > > 1) unmapped source, unmapped destination: this is what we have now. > > 2) mapped source, mapped destination: this would be the goal. > > 3) mapped source, unmapped destination: if the destination is > reachable via the "legacy" routing system, this would work if the > mapping service is able to determine that the destination is not > mapped and fall back to case 1. For this to work, the source > identifier would have to be routable, perhaps sub-optimally, in the > "legacy" routing system. > > 4) unmapped source, mapped destination: since the source knows > nothing about mapping, the only way the destination would be > reachable is if the destination identifier is routable, perhaps sub- > optimally, in the "legacy" routing system. > > Given this, as a transition mechanism, the existing > "addresses" (which I'm defining to be the merged identifier/locator > blob of bits we have in the source and destination fields of IP > packets now) would be treated as identifiers if they are mapped and > locators if they aren't. The mapping device/"edge" router would make > the determination on the fly based on whether the mapping succeeded > or failed. > > So, yes, there would need to be some support outside the multi-homed > site to take advantage of the multi-homing (etc.), but things will > still work, perhaps sub-optimally, without it. > > Rgds, > -drc > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Dec 12 19:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHZz-00024V-A9; Tue, 12 Dec 2006 19:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHZy-00024Q-Iz for ram@iab.org; Tue, 12 Dec 2006 19:02:34 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuHZx-0000y5-BK for ram@iab.org; Tue, 12 Dec 2006 19:02:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 95B714ACC2; Tue, 12 Dec 2006 19:02:30 -0500 (EST) Date: Tue, 12 Dec 2006 19:02:30 -0500 From: John Leslie To: Pekka Nikander Subject: Re: [RAM] Critical routing questions, and how to proceed Message-ID: <20061213000230.GC60450@verdi> References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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 Pekka Nikander wrote: > Noel Chiappa wrote: > >> When I look at what the problem seems to be ..., it seems to be >> growth in the size of the routing table (with dynamics of routing >> table entries coming in second). The two main drivers of growth >> seem to be i) multi-homing, and ii) general entropy and lack of >> aggregation. Is this correct? > > I've been told that traffic engineering is another major factor. > However, I have to admit not understanding what people mean with it. > (A good reference would help.) http://www.oreilly.com/catalog/bgp/chapter/ch06.html > Noel continued: >> Whether that separation happens through widescale deployment of >> mechanisms above the basic internetworking layer ..., or through >> what I've been calling the "jack-up" model ..., remains to be seen. > > These seem to be the basic architectural choices, given the practical > constraints. > > However, one particular problem here is that people seem to see here > more architectural choices that there are. For example, the one that > John Leslie proposed ... > >> It's quite reasonable to design around interface boxes, and have >> their translation function be gradually integrated into operating >> systems. > > ... is in my opinion just a perhaps-good transition path. I didn't mean it as "different", exactly: rather as an umbrella not limited strictly to one side of the proffered choice. > [A thorny issue in any such proxy scheme is security, i.e., > delegation. With public keys it is easy to solve; without public > keys the problem seems harder to solve.] Clearly that issue is real. Several partial-solutions come to mind. This deserves discussion; but I'm not sure we're ready to discuss it. -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Dec 12 19:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHjY-0005Ch-Ae; Tue, 12 Dec 2006 19:12:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHjX-0005Cb-8q for ram@iab.org; Tue, 12 Dec 2006 19:12:27 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuHjU-0002IL-UH for ram@iab.org; Tue, 12 Dec 2006 19:12:27 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 61AF54AC73; Tue, 12 Dec 2006 19:12:25 -0500 (EST) Date: Tue, 12 Dec 2006 19:12:25 -0500 From: John Leslie To: David Conrad Subject: Re: [RAM] Re: [arch-d] Major practical decision Message-ID: <20061213001225.GD60450@verdi> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 David Conrad wrote: > On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: > >> i am not sure i understand what you have in mind, but the peer that >> is communicating with host within the multihomed site will need to >> know the identifier and all the locators, so it can encapsulate >> with all the different locators, right? > > No. The source "host" would only need to know about the identifier > of the destination "host" (discoverable via DNS as normal). The > multiple locators would be bound to the identifier later. I think it > is actually fairly important that the "host" _not_ know about > locators as the alternative is a layering violation that ends up > causing a lot of problems in the end. I don't follow why this is necessarily a layering violation. -- John Leslie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 13 08:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuTlI-0004Vw-Ne; Wed, 13 Dec 2006 08:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuTlH-0004Uw-UP for ram@iab.org; Wed, 13 Dec 2006 08:03:03 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuTlG-0005MZ-El for ram@iab.org; Wed, 13 Dec 2006 08:03:03 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7D40B212E36; Wed, 13 Dec 2006 15:03:01 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 460B5212D98; Wed, 13 Dec 2006 15:03:01 +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: <837FAC8F-4DE7-42E1-A1DC-1CA7D64DC617@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: [arch-d] Major practical decision Date: Wed, 13 Dec 2006 15:02:59 +0200 To: JUAN-JOSE.ADAN@giss.seg-social.es X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP 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 > ... I think you may be interested in reading the draft on "Tunneled > Interdomain Routing" that I sent to the IETF in October. My > proposal is based on the use a new transitive BGP attribute that I > have called LOCATOR. > > You can find the new version of the draft-adan-idr-tidr-01.txt in > the following URL: > > http://www1.ietf.org/mail-archive/web/i-d-announce/current/ > msg13203.html Interesting, though I have to admit not understanding all the details with one casual reading. If I understand correctly, this is one specific example of the approaches that Noel has called "jack-up". Anyway, a few questions appeared in my mind immediately: 1. How do you think that the proposed AS public keys can be distributed; conversely, what is the underlying trust model? 2. What's your overall vision of the configuration of the system? How does it differ from current configuration practises? 3. What happens if someone starts to inject maliciously "tunneled" packets into the network? I guess I have to read the draft better with better time; at this point I'm just trying to understand if there are any open issues that might mean major problems for any approach like this. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 13 11:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWrF-0007gD-0m; Wed, 13 Dec 2006 11:21:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuWrD-0007g7-Q8 for ram@iab.org; Wed, 13 Dec 2006 11:21:23 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuWrA-00052K-9A for ram@iab.org; Wed, 13 Dec 2006 11:21:23 -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 kBDGLICq195558 for ; Wed, 13 Dec 2006 16:21:18 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 kBDGLINQ2629852 for ; Wed, 13 Dec 2006 17:21:18 +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 kBDGLHjI003516 for ; Wed, 13 Dec 2006 17:21:17 +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 kBDGLHp3003503; Wed, 13 Dec 2006 17:21:17 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA40252; Wed, 13 Dec 2006 17:21:16 +0100 Message-ID: <4580287B.2040208@zurich.ibm.com> Date: Wed, 13 Dec 2006 17:21:15 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John Leslie Subject: Re: [RAM] Critical routing questions, and how to proceed References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu> <20061208211722.GC67571@verdi> In-Reply-To: <20061208211722.GC67571@verdi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Sorry to be a couple ofd days behind the wave... John Leslie wrote: > Noel Chiappa wrote: > >>The multi-homing clearly has to be handled by use of multiple routing-names, >>and identity/location separation. Is that generally agreed on? > > > I think we agree; but I worry whether we all mean the same thing by > those words. > > What I think that means is that there needs to be a routing and > forwarding structure which can deliver packets to the same node via > paths which differ in the last hop (or more); and that there needs > to be some function which allows the sender (or its agent) to > determine the locators (routing-names) of those alternate paths. The problem I'm having with this relatively simple view of id/loc is that I see a lot of practical evidence that the distinction between id and loc is context dependent. I've been trying to write this up in a coherent way and haven't quite succeeded yet, but if it's correct, it implies that same bit string may need to function as an ID during part of a packet's lifetime, and as a locator during another part. Having added that confusion to Noel and John's formulation, I'd also observe that paths may or may not differ in the last hop; the point is that they differ somewhere, and that is easier to engineer if they use different locators. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 14 04:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gun5W-0003b6-1z; Thu, 14 Dec 2006 04:41:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gun5U-0003ay-6e for ram@iab.org; Thu, 14 Dec 2006 04:41:12 -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 1Gun5S-0000Vd-Oo for ram@iab.org; Thu, 14 Dec 2006 04:41:12 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JA9C8E03.H66; Thu, 14 Dec 2006 10:41:02 +0100 In-Reply-To: <837FAC8F-4DE7-42E1-A1DC-1CA7D64DC617@nomadiclab.com> X-Priority: 1 (High) Subject: Re: [RAM] Re: [arch-d] Major practical decision To: Pekka Nikander X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 14 Dec 2006 10:40:57 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 14/12/2006 10:40:19 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: 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 Pekka, Thank you very much for your comments. See my explanations below. Pekka Nikander escribi=F3 el 13/12/2006= 14:02:59: > > Interesting, though I have to admit not understanding all the details= > with one casual reading. > > If I understand correctly, this is one specific example of the > approaches that Noel has called "jack-up". I don't know what "jack-up" means. Can you point me to any resource on this?. > Anyway, a few questions appeared in my mind immediately: > > 1. How do you think that the proposed AS public keys can be > distributed; conversely, what is the underlying trust model? In my opinion Internet Routing Registries should provide for the certificates that ISPs should use. I say ISPs because, as I show in the TIDR draft, leaf AS-s would not need to have public AS numbers. If I am your ISP and you are a leaf AS, I will be responsible to make sure that you are injecting valid prefixes, namely prefixes from your assigned IP address block. And I will include the digital signature within the LOCATOR attribute using the certificate that I received from the IRR. > 2. What's your overall vision of the configuration of the system? > How does it differ from current configuration practises? As I also show in the TIDR draft, in the end, leaf AS-s would not need to have public AS numbers and they would continue to have backup and traffic engineering capabilities. Even more, they could achieve deterministic incoming traffic engineering. See section 7.2. in my draft, "Deterministic Customer Traffic Engineering for Incoming Traffic". > 3. What happens if someone starts to inject maliciously "tunneled" > packets into the network? If an ISP receives TIDR-tunneled packets from a stub network (i.e. a current nontransit leaf AS) the ISP will have to discard them. This can be easily achieved if we assign a specific IP address range per AS (e.g. an 240.x.y.0/8, with (x,y)=3DAS number). See section 7.6. in my draft, "Protection of the Inter-domain Routing Infrastructure". > I guess I have to read the draft better with better time; at this > point I'm just trying to understand if there are any open issues that= > might mean major problems for any approach like this. Yes, please. Any further comments will be appreciated. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 14 04:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GunKU-0002Nm-Sq; Thu, 14 Dec 2006 04:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GunKU-0002Nb-6r for ram@iab.org; Thu, 14 Dec 2006 04:56:42 -0500 Received: from mail.nederland.net ([2001:4038:0:100::15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GunKR-0003H8-LJ for ram@iab.org; Thu, 14 Dec 2006 04:56:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by romeo.computel.nl (Postfix) with ESMTP id 919AF14190; Thu, 14 Dec 2006 10:56:32 +0100 (CET) Received: from mail.nederland.net ([127.0.0.1]) by localhost (romeo.computel.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyTjPitQZzOC; Thu, 14 Dec 2006 10:56:27 +0100 (CET) Received: from balefirehome (rtr.10ww.steffann.nl [83.137.22.2]) by romeo.computel.nl (Postfix) with ESMTP id 4FB831418D; Thu, 14 Dec 2006 10:56:26 +0100 (CET) Message-ID: <001801c71f66$1ee86360$64c8a8c0@balefirehome> From: "Sander Steffann" To: "Pekka Nikander" , References: Subject: Re: [RAM] Re: [arch-d] Major practical decision Date: Thu, 14 Dec 2006 10:56:25 +0100 Organization: Computel Standby BV MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -2.8 (--) 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 Hi, > If an ISP receives TIDR-tunneled packets from a stub network (i.e. > a current nontransit leaf AS) the ISP will have to discard them. > This can be easily achieved if we assign a specific IP address > range per AS (e.g. an 240.x.y.0/8, with (x,y)=AS number). > See section 7.6. in my draft, "Protection of the Inter-domain > Routing Infrastructure". One big problem: Since 32-bit AS numbers are currently being introduced, assuming that an ASN is 16-bits is not possible anymore. - Sander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 14 05:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GunqQ-0007Ed-4R; Thu, 14 Dec 2006 05:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GunqP-0007EY-Df for ram@iab.org; Thu, 14 Dec 2006 05:29:41 -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 1GunqO-0007wi-0B for ram@iab.org; Thu, 14 Dec 2006 05:29:41 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JA9EH603.H6R; Thu, 14 Dec 2006 11:29:30 +0100 X-Priority: 1 (High) In-Reply-To: <001801c71f66$1ee86360$64c8a8c0@balefirehome> Subject: Re: [RAM] Re: [arch-d] Major practical decision To: "Sander Steffann" X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 14 Dec 2006 11:29:26 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 14/12/2006 11:28:47 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: 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 Sander, "Sander Steffann" escribi=F3 el 14/12/2006 10:= 56:25: > Hi, > > > If an ISP receives TIDR-tunneled packets from a stub network (i.e. > > a current nontransit leaf AS) the ISP will have to discard them. > > This can be easily achieved if we assign a specific IP address > > range per AS (e.g. an 240.x.y.0/8, with (x,y)=3DAS number). > > See section 7.6. in my draft, "Protection of the Inter-domain > > Routing Infrastructure". > > One big problem: Since 32-bit AS numbers are currently being introduc= ed, > assuming that an ASN is 16-bits is not possible anymore. Yes, AS numbers can now be 4-byte long. ("The IESG Approved the Expansion of the AS Number Registry" on 27-November-2006). Although what I said in my previous mail was just an "Exempli gratia" we should not forget that multihomed leaf AS-s are far more numerous than transit AS-s. I see some possibilities: 1- We reserve 1-64512 for ISPs. 2- We can use TIDR, because with TIDR non-transit multihomed AS-s will no longer need any public AS number for backup or traffic engineering purposes. 3- We use IPv6 addresses for "locator prefixes" to accomodate 4-byte AS numbers. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 14 05:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCb-0000BZ-2g; Thu, 14 Dec 2006 05:52:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCZ-0000BT-GW for ram@iab.org; Thu, 14 Dec 2006 05:52:35 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoCX-0003AN-Ua for ram@iab.org; Thu, 14 Dec 2006 05:52:35 -0500 Received: from pc6 (1Cust98.tnt106.lnd4.gbr.da.uu.net [213.116.60.98]) by astro.systems.pipex.net (Postfix) with SMTP id C58D2E000187; Thu, 14 Dec 2006 10:52:28 +0000 (GMT) Message-ID: <021d01c71f65$8a578d20$0601a8c0@pc6> From: "tom.petch" To: "Brian E Carpenter" , "John Leslie" References: <20061208164134.4A6C986ADB@mercury.lcs.mit.edu><20061208211722.GC67571@verdi> <4580287B.2040208@zurich.ibm.com> Subject: Re: [RAM] Critical routing questions, and how to proceed Date: Thu, 14 Dec 2006 10:48:07 +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: 4d87d2aa806f79fed918a62e834505ca 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 ----- Original Message ----- From: "Brian E Carpenter" To: "John Leslie" Cc: Sent: Wednesday, December 13, 2006 5:21 PM Subject: Re: [RAM] Critical routing questions, and how to proceed > > Sorry to be a couple ofd days behind the wave... > > John Leslie wrote: > > Noel Chiappa wrote: > > > >>The multi-homing clearly has to be handled by use of multiple routing-names, > >>and identity/location separation. Is that generally agreed on? > > > > I think we agree; but I worry whether we all mean the same thing by > > those words. > > > > What I think that means is that there needs to be a routing and > > forwarding structure which can deliver packets to the same node via > > paths which differ in the last hop (or more); and that there needs > > to be some function which allows the sender (or its agent) to > > determine the locators (routing-names) of those alternate paths. > > > Having added that confusion to Noel and John's formulation, I'd also > observe that paths may or may not differ in the last hop; the point > is that they differ somewhere, and that is easier to engineer > if they use different locators. > > Brian > Using multi-homing to achieve high availability, then I disagree with both formulations. What is needed is a different last mile, on the grounds that that is where most failures occur (at least last time I saw any data). Choosing a different provider/telco is a good start but may not be enough since they can share the last mile and (parts of) the node feeding it. The best solution I saw, some time ago, was one provider coming in through fibre, the other through a radio link. But even without that, I think the focus should be on having a different provider. A suitable addressing architecture is then to have the same 'address within site' with the AS number (or similar) differentiating the providers. Tom Petch > _______________________________________________ > 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 Dec 14 06:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guowf-0003Lk-Lk; Thu, 14 Dec 2006 06:40:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guowe-0003L1-4s for ram@iab.org; Thu, 14 Dec 2006 06:40:12 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guowc-0002ci-VC for ram@iab.org; Thu, 14 Dec 2006 06:40:12 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9DD20872CC; Thu, 14 Dec 2006 06:40:10 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] Re: [arch-d] Major practical decision Message-Id: <20061214114010.9DD20872CC@mercury.lcs.mit.edu> Date: Thu, 14 Dec 2006 06:40:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: JUAN-JOSE.ADAN@giss.seg-social.es >> the approaches that Noel has called "jack-up". > I don't know what "jack-up" means. Can you point me to any resource on > this?. It's a term I starting using over on the Architecture-Discuss list to describe a class of evolutionary schemes for the Internet in which: - A new internetwork layer is inserted beneath the existing IPv4/IPv6 (commonly referred to as "IPvN") layers. - The existing IPvN "addresses" become names which basically just identify communicating entities, and do not say where in the network they are. Examples of "jack-up" in other systems (in which the semantics of existing names are changed, but the syntax is retained for benefit of the applications) include the way in which portable numbers are provided in the telephone system. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 15 04:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9Gz-0005dq-SJ; Fri, 15 Dec 2006 04:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9Gx-0005cm-TF for ram@iab.org; Fri, 15 Dec 2006 04:22:31 -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 1Gv9Gv-00020T-9w for ram@iab.org; Fri, 15 Dec 2006 04:22: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 JAB61302.22A; Fri, 15 Dec 2006 10:22:15 +0100 In-Reply-To: <20061214114010.9DD20872CC@mercury.lcs.mit.edu> X-Priority: 1 (High) Subject: Re: [RAM] Re: [arch-d] Major practical decision 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: Fri, 15 Dec 2006 10:22:11 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 15/12/2006 10:21:26 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: 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 Noel, Thank you for your explanation. I have some comments below. jnc@mercury.lcs.mit.edu (Noel Chiappa) escribi=F3 el 14/12/2006 12:40:1= 0: > > From: JUAN-JOSE.ADAN@giss.seg-social.es > > >> the approaches that Noel has called "jack-up". > > > I don't know what "jack-up" means. Can you point me to any reso= urce on > > this?. > > It's a term I starting using over on the Architecture-Discuss list to= > describe a class of evolutionary schemes for the Internet in which: > > - A new internetwork layer is inserted beneath the existing IPv4/IPv6= > (commonly referred to as "IPvN") layers. > > - The existing IPvN "addresses" become names which basically just identify > communicating entities, and do not say where in the network they are.= > > > Examples of "jack-up" in other systems (in which the semantics of existing > names are changed, but the syntax is retained for benefit of the > applications) include the way in which portable numbers are provided = in the > telephone system. Then I think my proposal on "Tunneled Interdomain Routing" (TIDR) is a not a "jack-up" mechanism for two reasons: 1. There is no NEW internetwork layer beneath the existing IPvN layer. In TIDR we use tunnels, and most of the value-added services are based on tunnels (mobility, VPNs, TE,...). I think there is a need for a richer routing paradigm, and in my opinion the solution is something like TIDR. I think we need the come of age of tunnels within the IP architecture. 2. In TIDR the existing IPvN addresses don't become names wich basically just identify communicating entities. They are just identifiers for INTER-domain routing, BUT once the tunneled packet is detunneled the identifier (i.e. the inner IP address) reappears with the role of locator again. This is what I have called the "Relativity of Identifiers and Locators" in my draft. A normal IP address will become identifier or locator depending on the way we will use it: it will become just a mere identifier wrt inter-domain routing as long as there exists a locator to which we can tunnel its traffic. And similarly, a normal IP address will become a locator whenever it is used as a tunnel destination. Then, the role of an IP address as an identifier or as a locator is relative to the use we decide to do with it. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 15 04:30:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9OH-0007xT-84; Fri, 15 Dec 2006 04:30:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9OG-0007xM-04 for ram@iab.org; Fri, 15 Dec 2006 04:30:04 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv9OD-00038Q-I8 for ram@iab.org; Fri, 15 Dec 2006 04:30:03 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 147B3212F45; Fri, 15 Dec 2006 11:29:58 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D5151212E56; Fri, 15 Dec 2006 11:29:57 +0200 (EET) 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: <37EA1CF7-7949-4598-AA0F-43926A827A1F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: [arch-d] Major practical decision Date: Fri, 15 Dec 2006 11:29:56 +0200 To: JUAN-JOSE.ADAN@giss.seg-social.es X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.1 (/) 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 > In my opinion Internet Routing Registries should provide for > the certificates that ISPs should use. ... > > If an ISP receives TIDR-tunneled packets from a stub network (i.e. > a current nontransit leaf AS) the ISP will have to discard them. These seem to assume that we have a) a working global certification infrastructure run by the RIRs b) that all ISPs are diligent in filtering incoming traffic. AFAIK, neither of these are true today, even after multiple years of attempting to build them. Consequently, I'd like to understand how your proposal would behave if you were not able to assume one of those, or either of those. Personally, I keep it more probable that the RIRs could establish cross-certified certificate infrastructures for their customers than that all ISPs would ever be diligent. Hence, it may be better to start from pondering what happens if there are a few ISPs (say 0.1% of all ISPS) that are not diligent in filtering their TIDR-tunnelled packets, or who may have other motives (such as fraud) so that they themselves occasionally inject maliciously formatted TIDR-tunnelled packets. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 15 05:10:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvA1A-0006cp-NE; Fri, 15 Dec 2006 05:10:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvA18-0006cf-Lh for ram@iab.org; Fri, 15 Dec 2006 05:10:14 -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 1GvA16-0004DB-Qe for ram@iab.org; Fri, 15 Dec 2006 05:10:14 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JAB88Y02.K07; Fri, 15 Dec 2006 11:10:10 +0100 In-Reply-To: <37EA1CF7-7949-4598-AA0F-43926A827A1F@nomadiclab.com> X-Priority: 1 (High) Subject: Re: [RAM] Re: [arch-d] Major practical decision To: Pekka Nikander X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Fri, 15 Dec 2006 11:10:05 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 15/12/2006 11:09:21 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: 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 Pekka, See below. Pekka Nikander escribi=F3 el 15/12/2006= 10:29:56: > > In my opinion Internet Routing Registries should provide for > > the certificates that ISPs should use. ... > > > > If an ISP receives TIDR-tunneled packets from a stub network (i.e. > > a current nontransit leaf AS) the ISP will have to discard them. > > These seem to assume that we have > > a) a working global certification infrastructure run by the RIRs > > b) that all ISPs are diligent in filtering incoming traffic. > > AFAIK, neither of these are true today, even after multiple years of > attempting to build them. > > Consequently, I'd like to understand how your proposal would behave > if you were not able to assume one of those, or either of those. > Personally, I keep it more probable that the RIRs could establish > cross-certified certificate infrastructures for their customers than > that all ISPs would ever be diligent. Hence, it may be better to > start from pondering what happens if there are a few ISPs (say 0.1% > of all ISPS) that are not diligent in filtering their TIDR-tunnelled > packets, or who may have other motives (such as fraud) so that they > themselves occasionally inject maliciously formatted TIDR-tunnelled > packets. = _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 15 10:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF8B-0000lP-WF; Fri, 15 Dec 2006 10:37:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF8B-0000lC-8d; Fri, 15 Dec 2006 10:37:51 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvF89-0004Eu-Sl; Fri, 15 Dec 2006 10:37:51 -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 kBFFbjlK003438; Fri, 15 Dec 2006 07:37:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFFbeM9003435; Fri, 15 Dec 2006 07:37:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 07:37:40 -0800 From: David Meyer To: routingworkshop@lists.i1b.org Message-ID: <20061215153739.GA2627@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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: v6ops@ops.ietf.org, architecture-discuss@ietf.org, ram@iab.org Subject: [RAM] draft-iab-raws-report-00.txt posted to the ID repository X-BeenThere: ram@iab.org X-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="===============0111922707==" Errors-To: ram-bounces@iab.org --===============0111922707== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =09 Folks, First, sorry about the wide distribution and any duplicates you may receive. I just posted draft-iab-raws-report-00.txt posted to the ID repository. Until it gets there, I've put a copy on=20 http://www.1-4-5.net/~dmm/draft-iab-raws-report-00.txt for your light holiday reading :-) Looking forward to your comments and the ongoing discussion.=20 --dmm (for dmm, lixia, and kevin) --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgsFCORgD1qCZ2KcRAmcQAKCLyMeMzNx7ROt11ApvGOGLMpA1MQCfcYHF QcQMW2AAVdlBKJPCPE5EkVE= =GU14 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- --===============0111922707== 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 --===============0111922707==-- From ram-bounces@iab.org Fri Dec 15 11:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFeQ-0005cN-Vh; Fri, 15 Dec 2006 11:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFeP-0005c5-6i for ram@iab.org; Fri, 15 Dec 2006 11:11:09 -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 1GvFeM-0001K2-Pv for ram@iab.org; Fri, 15 Dec 2006 11:11:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2006 08:11:06 -0800 X-IronPort-AV: i="4.12,176,1165219200"; d="scan'208"; a="352159380:sNHT45550688" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBFGB6tD002418; Fri, 15 Dec 2006 08:11:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBFGAqjc023327; Fri, 15 Dec 2006 08:11:01 -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); Fri, 15 Dec 2006 08:10:55 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:10:55 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 15 Dec 2006 10:10:51 -0600 Subject: Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository From: David Ward To: David Meyer , , David Ward Message-ID: Thread-Topic: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Thread-Index: AccgY5b31aKQ0oxWEduJiwAX8sbpFw== In-Reply-To: <20061215153739.GA2627@1-4-5.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 16:10:55.0562 (UTC) FILETIME=[99AF92A0:01C72063] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1169; t=1166199066; x=1167063066; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[RAM]=20draft-iab-raws-report-00.txt=20posted=20to=20 the=20ID=20repository |Sender:=20; bh=aziWbth/aEjYBqLGsbxaVcosUji9SZOnQ9s1rCeqEfU=; b=PZZcMj0N5tpXKmX4/uDjSAXVkcB1P8+ZvyGv5G7zfN25G1lE7zvM054o/omjKCw1j0KR3jl+ er6+sV+fjngWqE3DUwdq9jlajVstnahYHicuw8R0kdV0/zDMu4VpXYm3; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: v6ops@ops.ietf.org, architecture-discuss@ietf.org, 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 - As editor of the document that captures the presentations and discussion during this workshop, how should incorrect statements be handled? Unfortunately, there are some errors in the statements that don't quite reflect reality (once example is in the Routing convergence section 7.3). Since the doc represents what was discussed, it may not be appropriate to correct the statements. Would any corrections or clarifications go into the future problem statement document that you mention? Thanks -DWard On 12/15/06 9:37 AM, "David Meyer" wrote: > > Folks, > > First, sorry about the wide distribution and any > duplicates you may receive. > > I just posted draft-iab-raws-report-00.txt posted to the > ID repository. Until it gets there, I've put a copy on > > http://www.1-4-5.net/~dmm/draft-iab-raws-report-00.txt > > for your light holiday reading :-) > > Looking forward to your comments and the ongoing > discussion. > > --dmm (for dmm, lixia, and kevin) > > _______________________________________________ > 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 Dec 15 11:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFpL-0000z2-7f; Fri, 15 Dec 2006 11:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFpJ-0000yP-Km; Fri, 15 Dec 2006 11:22:25 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvFpF-0002tc-T5; Fri, 15 Dec 2006 11:22: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 kBFGLVjE005349; Fri, 15 Dec 2006 08:21:31 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFGLVbZ005348; Fri, 15 Dec 2006 08:21:31 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 08:21:31 -0800 From: David Meyer To: David Ward Subject: Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Message-ID: <20061215162131.GA5146@1-4-5.net> References: <20061215153739.GA2627@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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, 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="===============1173816072==" Errors-To: ram-bounces@iab.org --===============1173816072== 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 Dave, > As editor of the document that captures the presentations and discuss= ion > during this workshop, how should incorrect statements be handled? > Unfortunately, there are some errors in the statements that don't quite > reflect reality (once example is in the Routing convergence section 7.3). > Since the doc represents what was discussed, it may not be appropriate to > correct the statements. Would any corrections or clarifications go into t= he > future problem statement document that you mention? I understand your problem with 7.3. Clearly, we understand that IGPs can (and do) converge more quickly that BGP does. If I understand your concern, it is with this text (please correct me if I'm wrong): The IGP convergence can also be very slow, which can lead to intolerable performance problems for real time applications such as VoIP. The cause for this slow convergence can be due to multiple factors, including... in that it seems to suggest that IGP convergence is *slower* that BGP convergence (correct)? If so, will text like: While IGPs are designed to and do converge much more qucikly that BGP might, the workshop participants were concerened that the growth of the size of the DFZ RIB, in addition to the various specical purpose routes they must carry can slow IGP convergence. The cause for this slow convergence can be due to multiple factors, including.... or similar address your concern?=20 thnx for the comments, --dmm --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgsuLORgD1qCZ2KcRAuyJAJ41UlVqsAnpanA/u5g2dKnCjW68AgCfVAGj Kqkp2i8oq7oBS2kHCpfLR80= =upIN -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============1173816072== 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 --===============1173816072==-- From ram-bounces@iab.org Fri Dec 15 11:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGAm-00039q-Ah; Fri, 15 Dec 2006 11:44:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGAk-00036U-SK for ram@iab.org; Fri, 15 Dec 2006 11:44:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvGAi-0006fT-BG for ram@iab.org; Fri, 15 Dec 2006 11:44:34 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2006 08:44:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBFGiUPI025452; Fri, 15 Dec 2006 08:44:30 -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 kBFGiQZi027911; Fri, 15 Dec 2006 08:44:26 -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); Fri, 15 Dec 2006 08:44:25 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:44:25 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 15 Dec 2006 10:44:21 -0600 Subject: Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository From: David Ward To: David Meyer , David Ward Message-ID: Thread-Topic: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Thread-Index: AccgaEUFg7PkGoxbEduJiwAX8sbpFw== In-Reply-To: <20061215162131.GA5146@1-4-5.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 16:44:25.0619 (UTC) FILETIME=[47C5EE30:01C72068] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2308; t=1166201070; x=1167065070; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[RAM]=20draft-iab-raws-report-00.txt=20posted=20to=20 the=20ID=20repository |Sender:=20; bh=RnkmmfNq27+3cL+3FXUt/TK90wNKZY9g1N6QFNIEtJw=; b=lBoiWkhxO0PPRB4uDtbhTPNNbLcpQlO2WLxT/hIHT05ZPMeO3KmV4/ebjYLTCjxYvpUVkv5p vkWENMPuoSY7iURXyn03W1ayhbpG8aMw1KylSgpBOMHdpVLuluFCnMRB; Authentication-Results: sj-dkim-5; header.From=dward@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, 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 - It is better but, still not completely correct (given the remainder of the section). The meta-point is that the doc is a statement of what was discussed in the workshop. There are factual errors in the doc in addition to what I cited (I purposefully chose perhaps the least controversial in 7.3). Your answer below implies that you would like the workshop doc to be correct vs leaving it as a statement from the workshop and then having the problem statement fully clarified. I suggest that you proceed forward w/ the problem statement and not potentially revise history. Of course, it is up to authors and group ... 0.02$ -DWard On 12/15/06 10:21 AM, "David Meyer" wrote: > Dave, > >> As editor of the document that captures the presentations and discussion >> during this workshop, how should incorrect statements be handled? >> Unfortunately, there are some errors in the statements that don't quite >> reflect reality (once example is in the Routing convergence section 7.3). >> Since the doc represents what was discussed, it may not be appropriate to >> correct the statements. Would any corrections or clarifications go into the >> future problem statement document that you mention? > > I understand your problem with 7.3. Clearly, we > understand that IGPs can (and do) converge more quickly > that BGP does. If I understand your concern, it is with > this text (please correct me if I'm wrong): > > The IGP convergence can also be very slow, which can > lead to intolerable performance problems for real time > applications such as VoIP. The cause for this slow > convergence can be due to multiple factors, including... > > in that it seems to suggest that IGP convergence is > *slower* that BGP convergence (correct)? If so, will > text like: > > While IGPs are designed to and do converge much more > qucikly that BGP might, the workshop participants were > concerened that the growth of the size of the DFZ RIB, > in addition to the various specical purpose routes > they must carry can slow IGP convergence. The cause > for this slow convergence can be due to multiple > factors, including.... > > or similar address your concern? > > thnx for the comments, > > --dmm > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 15 12:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGSc-0002mR-ER; Fri, 15 Dec 2006 12:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGSb-0002mA-8v; Fri, 15 Dec 2006 12:03:01 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvGSU-0001PV-Rf; Fri, 15 Dec 2006 12:03:01 -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 kBFH2nos006503; Fri, 15 Dec 2006 09:02:49 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFH2f4g006502; Fri, 15 Dec 2006 09:02:41 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 09:02:41 -0800 From: David Meyer To: David Ward Subject: Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Message-ID: <20061215170241.GC6427@1-4-5.net> References: <20061215162131.GA5146@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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, 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="===============1661827239==" Errors-To: ram-bounces@iab.org --===============1661827239== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote: > Dave - >=20 > It is better but, still not completely correct (given the remainder of > the section). The meta-point is that the doc is a statement of what was > discussed in the workshop. There are factual errors in the doc in addition > to what I cited (I purposefully chose perhaps the least controversial in > 7.3). Your answer below implies that you would like the workshop doc to be > correct vs leaving it as a statement from the workshop and then having the > problem statement fully clarified. I suggest that you proceed forward w/ = the > problem statement and not potentially revise history. Of course, it is up= to > authors and group ... Well, what the report is supposed to reflect is what happened at the workshop. So I didn't intend to revise history, but rather clarify what was said. --dmm --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgtUxORgD1qCZ2KcRAihXAJ0fL9/D8h1W0S6xRPveW0RmeeUahACdFizH Gtj6SXrKsHTWeijFCQTPYio= =pQjo -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- --===============1661827239== 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 --===============1661827239==-- From ram-bounces@iab.org Fri Dec 15 13:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvI0T-0007eS-D2; Fri, 15 Dec 2006 13:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvI0S-0007eK-E1; Fri, 15 Dec 2006 13:42:04 -0500 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvI0R-0007R8-34; Fri, 15 Dec 2006 13:42:04 -0500 Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v38_r7.6.) id z.471.355fb5df (40520); Fri, 15 Dec 2006 13:41:42 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <471.355fb5df.32b44663@aol.com> Date: Fri, 15 Dec 2006 13:41:39 EST Subject: Re: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository To: dmm@1-4-5.net, dward@cisco.com 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: 68ba2b07ef271dba6ee42a93832cfa4c Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, 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="===============0201293096==" Errors-To: ram-bounces@iab.org --===============0201293096== Content-Type: multipart/alternative; boundary="-----------------------------1166208099" -------------------------------1166208099 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am glad that this IAB-workshop confirms my saying that there is no future=20= =20 with IPv6 and BGP.Both are children of the 90's. Also: it is not only the ba= d =20 convergency of BGP (which is due to its flat design and which is also the=20 cause for instability(=3Drouting churn) AND non-scalability. Furthermore i= t=20 prevents real-time traffic balancing for good. OSPF could do better, but do= esn't=20 either as long as there is this SPF-dogma ( I accused it four years ago in=20= a=20 longer thread "Rambo-SPF....") where each router behaves as if it were the=20 center of the internet :-( =20 Heiner =20 =20 In einer eMail vom 15.12.2006 18:04:48 Westeurop=E4ische Normalzeit schreibt= =20 dmm@1-4-5.net: On Fri, Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote: > Dave - > =20 > It is better but, still not completely correct (given the remainder o= f > the section). The meta-point is that the doc is a statement of what was > discussed in the workshop. There are factual errors in the doc in additio= n > to what I cited (I purposefully chose perhaps the least controversial in > 7.3). Your answer below implies that you would like the workshop doc to b= e > correct vs leaving it as a statement from the workshop and then having th= e > problem statement fully clarified. I suggest that you proceed forward w/=20 the > problem statement and not potentially revise history. Of course, it is up= =20 to > authors and group ... Well, what the report is supposed to reflect is what happened at the workshop. So I didn't intend to revise history, but rather clarify what was said. --dmm _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1166208099 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I am glad that this IAB-workshop confirms my saying that there is no fu= ture=20 with IPv6 and BGP.Both are children of the 90's. Also: it is not only the ba= d=20 convergency of BGP (which is due to its flat design and which  is=20 also the cause  for instability(=3Drouting churn) AND non-scalabil= ity.=20 Furthermore it prevents real-time traffic balancing for good. OSPF coul= d do=20 better, but doesn't either as long as there is this SPF-dogma ( I accused it= =20 four years ago in a longer thread "Rambo-SPF....") where each router behaves= as=20 if it were the center of the internet :-(
 
Heiner
 
 
In einer eMail vom 15.12.2006 18:04:48 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 Fri,=20 Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote:
> Dave -
>= =20
>     It is better but, still not completely correct= =20 (given the remainder of
> the section). The meta-point is that the d= oc=20 is a statement of what was
> discussed in the workshop. There are=20 factual errors in the doc in addition
> to what I cited (I purposefu= lly=20 chose perhaps the least controversial in
> 7.3). Your answer below=20 implies that you would like the workshop doc to be
> correct vs leav= ing=20 it as a statement from the workshop and then having the
> problem=20 statement fully clarified. I suggest that you proceed forward w/ the
&g= t;=20 problem statement and not potentially revise history. Of course, it is up=20 to
> authors and group ...

    Well, what the repor= t is=20 supposed to reflect is what
    happened at the workshop. So=20= I=20 didn't intend to revise
    history, but rather clarify what=20= was=20 said.

   =20 --dmm

_______________________________________________
Architectu= re-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1166208099-- --===============0201293096== 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 --===============0201293096==-- From ram-bounces@iab.org Sun Dec 17 10:04:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxYn-0003MM-2O; Sun, 17 Dec 2006 10:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxYl-0003KY-7g for ram@iab.org; Sun, 17 Dec 2006 10:04:15 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxYg-0001PP-1S for ram@iab.org; Sun, 17 Dec 2006 10:04:15 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 2C1633402B; Sun, 17 Dec 2006 10:04:26 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 10:04:07 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [RAM] Re: [arch-d] Major practical decision Date: Sun, 17 Dec 2006 10:04:06 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F7D@tayexc14.americas.cpqcorp.net> In-Reply-To: <837FAC8F-4DE7-42E1-A1DC-1CA7D64DC617@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: [arch-d] Major practical decision Thread-Index: AccetxhjlZaX2QV+Rwm6vObjFj0KMgDNUo/g From: "Bound, Jim" To: "Pekka Nikander" , X-OriginalArrivalTime: 17 Dec 2006 15:04:07.0710 (UTC) FILETIME=[99A563E0:01C721EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > 3. What happens if someone starts to inject maliciously "tunneled" =20 > packets into the network? That is what intrusion detection software and architecture is for and why I have essential basic issues with HIP and SHIM6 bothering with this other than due dilliegence to address core network communications security. Ergo don't see the point of CGA at all. /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 17 23:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw9hz-00049q-E6; Sun, 17 Dec 2006 23:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw9hx-00049i-Si for ram@iab.org; Sun, 17 Dec 2006 23:02:33 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw9hr-0002FE-AT for ram@iab.org; Sun, 17 Dec 2006 23:02:33 -0500 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JAG00DHFB64TX@firewall.mci.com> for ram@iab.org; Mon, 18 Dec 2006 04:01:16 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JAG009LOB63W4@dgismtp04.mcilink.com> for ram@iab.org; Mon, 18 Dec 2006 04:01:16 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JAG0098WB63W8@dgismtp04.mcilink.com> for ram@iab.org; Mon, 18 Dec 2006 04:01:15 +0000 (GMT) Date: Mon, 18 Dec 2006 04:01:15 +0000 (GMT) From: "Chris L. Morrow" Subject: RE: [RAM] Re: [arch-d] Major practical decision In-reply-to: <816DD9299957E547B5D758D7F977D6DC01178F7D@tayexc14.americas.cpqcorp.net> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: "Bound, Jim" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <816DD9299957E547B5D758D7F977D6DC01178F7D@tayexc14.americas.cpqcorp.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Pekka Nikander , JUAN-JOSE.ADAN@giss.seg-social.es, 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, 17 Dec 2006, Bound, Jim wrote: > > > 3. What happens if someone starts to inject maliciously "tunneled" > > packets into the network? > > That is what intrusion detection software and architecture is for and in the core no one can see your traffic ( not an IDS atleast) so this traffic would get delivered to the end-site (or end-tunnel destination) before anyone can see it and do 'something' about it. On the other hand, what would you do with it anyway? Stop the tunnel source? which is perhaps also spoofed? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Dec 18 05:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFzt-0004Ji-Oq; Mon, 18 Dec 2006 05:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFzs-0004JT-Fx for ram@iab.org; Mon, 18 Dec 2006 05:45:28 -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 1GwFzq-0000xL-1E for ram@iab.org; Mon, 18 Dec 2006 05:45:28 -0500 Received: from GWSalida2.correo.portal.ss ([10.99.1.190]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JAGTVJ00.130; Mon, 18 Dec 2006 11:45:19 +0100 In-Reply-To: <37EA1CF7-7949-4598-AA0F-43926A827A1F@nomadiclab.com> X-Priority: 1 (High) Subject: Re: [RAM] Re: [arch-d] Major practical decision To: Pekka Nikander X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Mon, 18 Dec 2006 11:44:24 +0100 X-MIMETrack: Serialize by Router on GWSalida2/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 18/12/2006 11:44:08 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: 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 Pekka, See below the comments I didn=B4t send last Friday. Pekka Nikander escribi=F3 el 15/12/2006= 10:29:56: > > In my opinion Internet Routing Registries should provide for > > the certificates that ISPs should use. ... > > > > If an ISP receives TIDR-tunneled packets from a stub network (i.e. > > a current nontransit leaf AS) the ISP will have to discard them. > > These seem to assume that we have > > a) a working global certification infrastructure run by the RIRs > > b) that all ISPs are diligent in filtering incoming traffic. > > AFAIK, neither of these are true today, even after multiple years of > attempting to build them. > > Consequently, I'd like to understand how your proposal would behave > if you were not able to assume one of those, or either of those. > Personally, I keep it more probable that the RIRs could establish > cross-certified certificate infrastructures for their customers than > that all ISPs would ever be diligent. Hence, it may be better to > start from pondering what happens if there are a few ISPs (say 0.1% > of all ISPS) that are not diligent in filtering their TIDR-tunnelled > packets, or who may have other motives (such as fraud) so that they > themselves occasionally inject maliciously formatted TIDR-tunnelled > packets. Yes, some sort of certification infrastructure will be needed. WRT filtering TIDR-tunneled packets let's assume the following: Leaf_AS - ISP1 - ISP2 - Two possible methods for ISP1 to filter TIDR-tunneled packets coming from a Leaf_AS are: (1) discard IP packets sent to any locator prefix the same as we do with traffic sent to 10.0.0.0/8; (2) use uRPF to discard this incoming traffic. - But the point still is: what if ISP1 doesn=B4t filter tunneled traffic coming from Leaf_AS?. With TIDR there is no need for Leaf_AS to use a public AS number: it's a ISP1's task to announce prefixes residing in Leaf_AS with a LOCATOR pointing to ISP1. Therefore ISP1 should never receive transit traffic (i.e. tunneled traffic) from Leaf_AS. In my draft I suggest the use of different layer-2 encapsulations for transit and non-transit traffic, so that the layer-2 encapsulation for transit traffic should only be valid when establishing a BGP session with another transit AS. And this should be enforced in some way. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Dec 18 09:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJcX-0004bw-Rw; Mon, 18 Dec 2006 09:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJcW-0004br-NQ for ram@iab.org; Mon, 18 Dec 2006 09:37:36 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJcR-00080u-Fb for ram@iab.org; Mon, 18 Dec 2006 09:37:36 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CC7A03401A; Mon, 18 Dec 2006 09:37:30 -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, 18 Dec 2006 09:37:30 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [RAM] Re: [arch-d] Major practical decision Date: Mon, 18 Dec 2006 09:37:29 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01179101@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: [arch-d] Major practical decision Thread-Index: AcciWWKwgZmZeJIMRTGJbt68sE6+UgAV89oA From: "Bound, Jim" To: "Chris L. Morrow" X-OriginalArrivalTime: 18 Dec 2006 14:37:30.0410 (UTC) FILETIME=[0BFE80A0:01C722B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Pekka Nikander , JUAN-JOSE.ADAN@giss.seg-social.es, 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 > > > > > 3. What happens if someone starts to inject maliciously "tunneled" > > > packets into the network? > > > > That is what intrusion detection software and architecture=20 > is for and >=20 > in the core no one can see your traffic ( not an IDS atleast)=20 > so this traffic would get delivered to the end-site (or=20 > end-tunnel destination) before anyone can see it and do=20 > 'something' about it. On the other hand, what would you do=20 > with it anyway? Stop the tunnel source? which is perhaps also spoofed? Good question. Even in the core and even if the entire payload is encrypted, meaning a router, switch, et al cannot see anything but the routing-namespace-identifiers (cannot see the transport layer as today tcp/port, etc.) there are means to do Deep Packet Inspection (DPI) at any point in the path to the destination emerging based upon mathematical models and in-band-signaling for blockage (bad term but for now use it) thus DOS at least can be seen for intrusion prevention. The implementation would use DPI on smart-aware-nodes similar to the current IETF NSIS architecture and operational model. This way it does not effect the actual traffic. But more importantly I do not believe we should try to solve many of the security problems or attacks trying to define an architecture for a new model its just to much to ask when the real prevention of most of what SHIM6 is addressing and specifically CGA and HBA can be addressed by intrusion detection/prevention. =20 /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Dec 19 10:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgop-0007Yz-8p; Tue, 19 Dec 2006 10:23:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgon-0007Yg-JZ for ram@iab.org; Tue, 19 Dec 2006 10:23:49 -0500 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwgok-00078Y-V9 for ram@iab.org; Tue, 19 Dec 2006 10:23:49 -0500 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.131296095; Tue, 19 Dec 2006 10:38:05 -0500 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Dec 2006 10:21:32 -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 Date: Tue, 19 Dec 2006 10:21:51 -0500 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01D04234@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: about draft-baker-v6ops-l3-multihoming-analysis-00 Thread-Index: AccjgWcRCPeXWEKqQ5+Z+VVJvKUuJA== From: "Azinger, Marla" To: X-OriginalArrivalTime: 19 Dec 2006 15:21:32.0871 (UTC) FILETIME=[5D6FCD70:01C72381] X-Spam-Score: 1.1 (+) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: Subject: [RAM] RE: about draft-baker-v6ops-l3-multihoming-analysis-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 Fred and Marcelo- In a nut shell. No matter what we do, one size never fits all. As for renumbering, I help run a medium sized transit network and also = provide a large amount of dsl services, and we are undergoing our 2nd = renumbering of the network. It is a pain, but to us, not that big of a = deal. So honestly, I see this debate as a personal perception that can = be on either sides of the coin. So we must consider both. One more subject from this email that I'd like to respond on, I think I = saw a small debate of how multihoming should interact with PA and PI. = Again, I see this as both sides of the coin. There are a good number of = large enterprises and ISP's that want to receive their IP addresses from = their upstream network provider and not get PI addresses. They dont = view this as a lock in by their provider and they dont care about = portability. Yet there are others that only want PI and nothing else. = Since our community is made up of both those that dont want PI and those = that do want PI, I believe we should be working on a solution that = addresses both sides of this coin. Hope this input isnt to late for thought. Sorry about the big delay. Marla -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Wednesday, November 29, 2006 2:00 PM To: marcelo bagnulo braun Cc: Azinger, Marla; v6ops@ops.ietf.org Subject: Re: about draft-baker-v6ops-l3-multihoming-analysis-00 On Nov 22, 2006, at 7:32 AM, marcelo bagnulo braun wrote: > El 21/11/2006, a las 20:59, Fred Baker escribi=F3: >> On Nov 21, 2006, at 10:03 AM, marcelo bagnulo braun wrote: >>> First, i think that the draft makes a good job in identifying =20 >>> that not all multihoming sites are the same... >> >> Thanks for your comments. I think you and I very much agree that =20 >> there are different requirements. For example, I think that a =20 >> Fortune 100 company probably has the same address-independence =20 >> requirements as an ISP has, while a homeowner changing his IP =20 >> address when he moves from house to house seems very reasonable. > > and when you change the isp of your home network? would it be =20 > acceptable to renumber in this case? That's a question; it really depends on what changes when I change =20 ISPs. I'll observe that I have one ISP, and when @Home went south =20 they renumbered my home. It wasn't much of a big deal for me, in part =20 because I run a NAT (like everyone else does, I suppose) for IPv4 =20 traffic and don't have IPv6 service. The one problem that I =20 encountered was that the VPN tunnel I use to go to work required that =20 my company know what IP address I am coming in from and I had to =20 advise them of the new one. The counterpart in an IPv6 world would be =20 (see RFC 4192) that they configure my router (RFC 4076) with the new =20 prefix, allow an interval for my network to make use of it, advise me =20 that they have done so and give me time to adjust DNS and advise my =20 company etc, and then withdraw the old prefix. In a PA situation, I =20 don't see any reason that this would be inappropriate. The question is whether PA is appropriate in a multihomed network. =20 shim6 says it is, and would have each ISP provide its own prefix. GSE =20 says it is, but leaves the hosts effectively ignorant of the prefixes =20 assigned (within the enterprise network, the routers only look at the =20 subnet number, and the hosts only look at the host identifier, and =20 the border routers rewrite the part used by the ISPs). A variation on =20 GSE would have the border router ICMP back to the host indicating =20 that it should be using a certain "routing goop", and have the host =20 resend using that. Metro and PI would simply have a single prefix on =20 the edge network in the first place. If the distance and complexity =20 questions are those of a typical home (see slides 3 and 4 of ftp://=20 ftpeng.cisco.com/fred/v6ops/Fred_network_paths.pdf for what I think a =20 typical home looks like; the slide needs some updating now and in the =20 coming years will have various large datarate home appliances added =20 to it, but I suspect it's close) I can't imagine any of those having =20 real operational problems. The big issue with multiple prefixes that =20 I see are related to the hiccups around network changes. One concern I have with the "/48 is what is assigned to the edge, =20 even the PI multihomed edge" is that one-size-fits-all seems an =20 uneasy solution. My canonical examples are my home and my company, =20 and there is a lot of space in between, but consider my company if =20 you will. Cisco has about 50,000 employees including temps and =20 contractors, and puts a LAN (if it were IPv6, which it is not, it =20 would be a /64) in many of our homes for home offices. Let's take a =20 flier and say it put one in each telecommuting home. That would =20 consume a /48, and it would have to be global in scope, not ULA. We =20 have a lot of labs (a single test rack, used by a single engineer for =20 unit or integration testing, might have a dozen LANs in it), a lot of =20 buildings, and so on. A company the size of Cisco would find uses for =20 another /48 easily just doing that, and for ULAs in test racks. I =20 wouldn't be too surprised to find that we actually wanted to run /48s =20 by continent or theatre. And while, yes, Cisco is #83 on the Fortune =20 100 list, many of the 82 above us on that list dwarf us in size. =20 Consider Exxon Mobil, Ford, or General Electric... http://=20 en.wikipedia.org/wiki/List_of_Fortune_500#1-100. It's not obvious to =20 me that the assumption that a single 16 bit subnet number used =20 throughout the corporate network makes sense; I would think the =20 architecture has to allow for several /48s. In other words, I think =20 we need to be able to use what GSE calls the "routing goop" within =20 the enterprise network, not just in the ISP backbone. That said, I'm hard pressed to describe anything resembling a home in =20 similar terms. In fact, I tend to think that the authorities that =20 assign prefixes have rational arguments for considering assignment of =20 44, 48, 52, 56, 60, and 64 bit prefixes to be service options that =20 might be bundled with other aspects of the service or might be sold =20 separately. > actually i would like to point out that RFC3582 is not a =20 > requirements document but it is a _goals_ document (its title is =20 > "Goals for IPv6 Site-Multihoming Architectures") yes. That said, it is the closest thing we have to a requirements =20 document, and it is what is thrown in my face as having not been met =20 when various solutions are discussed. > I would also like to point out, that "portability" is not listed as =20 > a requirement in RFC3582, so there are absolutelly no =20 > considerations about renumbering/porivder lock in/portability in =20 > the document OK, I pulled that in from another sector. Marla reports that many =20 edge networks in nanog-etc want address portability, and I have heard =20 it from other sources as well. If we can provide a certain level of =20 address portability without screwing up the network, there is value =20 in it, I think. >> What might be helpful (thinking out loud here, not making a =20 >> pronouncement; I wonder what people think) to the community at =20 >> large would be a requirements document or set of documents that =20 >> discusses not "requirements of a multihoming solution" but =20 >> "addressing and routing requirements of an end to end network". It =20 >> would have to discuss traffic engineering, from the perspective of =20 >> saying what requirements were reasonable and solvable and what =20 >> were not. It would have to discuss backbone and access ISPs and =20 >> their business models, > > i think this is very interesting point that you bring here.... > > Are we considering a multihoming solution for ISPs or for end sites? I think the discussion has to take into account both ISPs and their =20 customers, which might very well mean that it needs to be divided =20 into separate discussions. For example, I have been told by some ISPs =20 that they want PA addressing because it gives them a market lock, and =20 by some of their customers that they don't want PA addressing because =20 it gives ISPs a market lock. That kind of divide is a place where a =20 single consensus is simply not going to form. That said, my statement =20 above says "lets go beyond multihoming; what actually are the set(s) =20 of requirements for routing and addressing end to end and in the =20 middle?" > I mean i think it is clear that the requirements for a multihoming =20 > solution for an ISP and for an end site are likely to differ (or at =20 > least it is not obvious to me that they are the same or that the =20 > same solution could support both ISP and end site multihoming) > > imho, different requiremetns sets should be determined including: > - small end sites > - soho end sites > - large sites > - ISPs > > Probably there need to be different types of ISPs but i don't have =20 > enough background for this... I guess I think of ISPs as being broadly divided into transit =20 networks and access networks, although defining those terms crisply =20 is going to be pretty tough. We used to talk about Tier 1 networks as =20 global, Tier 2 networks as regional, and tertiary networks as being =20 local; I tend to think of networks now as providing either =20 interconnection between businesses or residential/SOHO access, and =20 see FTTH as muddying that puddle. > imho it would be interesting to at least try to produce these =20 > documents and see if it is possible to reach concensous on the =20 > requirements for each scenario I agree. It is likely to be input to the RAM discussion that the IESG =20 is in the process of chartering, and may be more appropriately moved =20 there at some point. Is there a part of that you would like to =20 contribute to? >> In the end, there are a small number of solutions that can be =20 >> looked at generally to provide a scalable address management =20 >> architecture. > > scalable in which sense? :-) in the sense I used the term - or more to the point chose to not use =20 the term - in the document referred to in the subject line. Since I =20 couldn't find a crisp definition, I went in the direction of trying =20 to enumerate the number of prefixes that each algorithm resulted in =20 under a consistent set of assumptions that seemed to have some hope =20 of being in the general neighborhood of reality. Larger and less firm =20 numbers (as in "O(10^7)") are less desirable than smaller numbers (as =20 in "O(10^5)") that have obvious derivations. > so multiaddressing does provide scalability for the routing system, =20 > but imposes a new way of doing a bunch of stuff Each of the solutions on the table changes something. Multi-=20 addressing, as you term it, is pretty straightforward if the end =20 systems and routers directly support it, so while it is different it =20 isn't all that scary to me. GSE is similarly straightforward - I =20 implemented roughly the same set of algorithms in an XNS/IPX router =20 in the late 1980's. Metro requires no changes to the ISP or customer =20 premises equipment - it can be deployed today - but requires =20 differences in business relationships. PI is something we are =20 deploying today, and if the approach is to be applied to businesses =20 with ten or more employees (Vince's slides from the IETF meeting) =20 drives the amount of memory in a backbone router into the sky. There =20 is some form of change in every one of these, and part of the =20 discussion needs to be that for the viability of everybody's networks =20 and businesses nobody's cows can be considered sacred. All options =20 are on the table and the trade-offs have to be made with as little =20 emotion as humanly possible. >> GSE depends, for scalability, on rewriting part of the source =20 >> address in a datagram, which helps with a number of the routing =20 >> problems but begs the question of how the transport associates a =20 >> request with a response. For example, if I use networks 1 and 2 =20 >> and you use networks 3 and 4, and I send a message from 1::me to =20 >> 3::you and get a reply from 4::you to 2::me, how do I identify =20 >> that the datagram I received is a reply to the same session? Doing =20 >> so requires the Endpoint ID to truly be globally unique, which is =20 >> a tall order, or it requires some form of dongle at the transport =20 >> layer that addresses the issue. One could imagine the locator/id =20 >> separation resulting in a mandate for the use of IPSEC integrity =20 >> mode to inform the transport's multiplexor. > > i really don't see how this could work... I mean how would you =20 > establish any-to-any IPSec SAs that can prove endpoint ID =20 > ownership? I can see two ways of doing this, crypto ids or a third =20 > trusted party. In any case, you end up with the problem of how to =20 > delegate the capability of rewriting to the routers... and so on. =20 > My point is this can be made to work, but it won't be as simple and =20 > nice as the current proposal I was pointing out a problem the current proposal doesn't solve... =20 How does, for example, an RFC 3041 address gain global uniqueness? If =20 a MAC address is used, how do we ensure global uniqueness for =20 addresses that have the "local" flag set? If the endpoint identifier =20 isn't globally unique, why do I believe that I can treat it as such =20 an identifier without the routing goop that tells me which instance =20 I'm looking at? > what it seems to be an insolvable problem (or at least extremely =20 > hard) is to build a solution that has the scalability required for =20 > a massive adoption (the one required for a small end site =20 > multihoming solution) and provides all the features required by big =20 > sites.... Personally, I don't think that is necessary. The obvious way to solve =20 a fortune-something-company problem is to treat the fortune =20 company as if it were an ISP and give it a PI assignment =20 comparable to an ISP. If that is a /32 and the guy only needs a /52, =20 so be it. We're talking about a few hundred of these globally, and =20 once they have a PI prefix they won't be back for a new prefix for a =20 while. I'd like to see the policies of the RIRs say as much. That =20 said, for SOHO networks and mid-sized companies (do they have =20 different requirements?) that's definitely not the right solution, =20 and we need an approach that works both for them and for the ISPs =20 that serve them. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 20 12:01:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4oV-0001EW-BV; Wed, 20 Dec 2006 12:01:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4oU-0001EM-DK for ram@iab.org; Wed, 20 Dec 2006 12:01:06 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4oP-0003MA-F5 for ram@iab.org; Wed, 20 Dec 2006 12:01: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 kBKH0SJE005793; Wed, 20 Dec 2006 09:00:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBKH0Ou7005792; Wed, 20 Dec 2006 09:00:24 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 20 Dec 2006 09:00:24 -0800 From: David Meyer To: ram@iab.org Message-ID: <20061220170024.GA4735@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: 1.4 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [RAM] moving a discussion from various I* lists to 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="===============1185846236==" Errors-To: ram-bounces@iab.org --===============1185846236== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The context here was that Leslie and I (and others) were discussing the implications of the fact that vendors are telling us that hardware that can hold RIB/FIBs of sizes like 1 x 10^6 entries can be built today, and of sizes like 1 x 10^7 in the 3-5 year time frame (I think the term used was "not scared of 10M entry RIBs" or something like that). We're hearing these kinds of numbers from most vendors now. So I did a calculation based on Geoff's projections (see reference below) in an effort to understand what the "not scared" numbers would mean for RIB/FIB headroom over the next several years. This is what I came up with:=20 Let the "not scared" 3-5 year {R,F}IB size is 1 x 10^7=20 RIB and/or FIB entries. In that case, we have a factor of 40x headroom in the next 3-5 years at constant RIB size. That is,=20 "the not scared" {R,F}IB size/sizeof(todays DFZ RIB) ~ 1 X 10^7/2.5 x 10^5 ~ 40 (and yeah, the DFZ RIB is more like 200K, but this is back of the envelope stuff in any event). So do we expect more than 40x growth in the appearance (in the DFZ RIB) of prefixes designed to enable multihoming (and/or TE) say, in the next 5 years? Geoff predicts (again, ATNAC reference, see below) the growth from 2008 to 2010 to be something like 3.75 x 10^5, so with that number (same calculation), you get something like: 1 x 10^7/3.75 x 10^5 ~ 27 So again that would appear that 27x is quite a bit of headroom (or maybe not), or so it would seem. Of course, this "no problem at 1 x 10^7 RIB/FIB entries" analysis is vastly simplified, since it doesn't consider many important factors, including: - All components of capital cost, including power, all varieties of real estate (ASIC, pin-out, LC, PoP, ...), etc, - The need for multiple copies of the RIB, VPN routes, more specifics, other special purpose routes,=20 - The advent of wildcards such as the widespread deployment of IPv6, mobility and its interaction with the routing system, etc. - It also assumes that the trends that Geoff identified don't qualitatively change. I'll just note here that while RIB/FIB sizes are issues to be concerned about, I am equally concerned (or perhaps more concerned) about the trend toward carrying increasingly fine-grained information in the routing system (Geoff has a bit to say about this as well in reference cited below). This is because carrying this kind of information in the routing system exposes the core to dynamics that might not be too attractive. That is, the network's dynamics are closely related to how big RIBs and FIBs are. BTW, why exactly would you need a RIB of size 10^7? So the concern is that the RIB/FIBs are growing, addition to some organic growth, precisely because we're carrying increasingly fine grained information in the routing system. This in turn exposes the core of the network to "edge burstiness UPDATE stream", and we have a very poor handle on the exact nature of that burstiness. The point is that this is a function, at least in part, of our protocol design and has deep implications for processing resources. =20 In any event, all of that prompted Leslie to ask a few questions. The following is my response to Leslie's questions. I'd be interested in others reflections on all of this. =20 > >>Thanks -- that helps me understand your point to be that > >>the easiest thing to measure (DFZ FIB/RIB projections and > >>ability to accommodate that growth in hardware)=20 > > > > > > Well, we definitely can look at what's out there now (and > > over the past 8-10 years), and try to see the trends. We > > also are hearing that building RIB/FIBs that are sized on > > the order 10M entries is also not an issue. So yes, that > > seems accurate.=20 > > > > > >>is not the measure of the ultimate issues: > >> > >> . still don't know if such hardware is deployable > >> [doesn't strike me as an IETF-able problem] > > > > > > Me either. > > > > > >> . haven't begun to discuss the impact(s) of the > >> forces driving the FIB/RIB growth (progressively > >> finer-grained information held in the DFZ; impact > >> on computation requirements & convergence times) > >> [do strike me as IETF-able problems] > > > > > > Yes, and these do seem like protocol issues (combined > > with RIR policy, but to some extent, those policies are > > driven by what protocols we've built/deployed). > > > > > >> . apart from what's up in the core, there are other > >> things desired in the routing system, maybe. > >> [does strike me as an IETF-able problem] > > > > > > Yes.=20 > > > > > >>And there are no particular studies to measure the above. > > > > > > Regarding the second point, my sense is that while Geoff > > and some others have good work on what is happening *now* > > with RIB and UPDATE growth, we don't know too much about > > the dynamic nature of UPDATEs. BTW, if folks know about > > other work on this topic, I'd appreciate a pointer (or > > pointers) to that work.=20 > > > > thnx, > > > > --dmm > > ----- End forwarded message ----- <author> Huston, G. and G. Armitage </author> <date year=3D3D"2006"/> </front> <seriesInfo name=3D"Huston, G.," value=3D"http://www.potaroo.net/papers/phd/atnac-2006/bgp-atnac2006.pdf"= /> </reference> --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiWwoORgD1qCZ2KcRApH9AJ4xG4mrnm28ffgtJVFonHfYoh92JgCePq3f WwK10bSo/Ai2YF3gbThts2w= =oy+7 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- --===============1185846236== 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 --===============1185846236==-- From ram-bounces@iab.org Wed Dec 20 18:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAlB-0006NH-S4; Wed, 20 Dec 2006 18:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAlA-0006LB-79 for ram@iab.org; Wed, 20 Dec 2006 18:22:04 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAl8-00051e-Rv for ram@iab.org; Wed, 20 Dec 2006 18:22:04 -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 kBKNM1Qk021878; Wed, 20 Dec 2006 15:22:01 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBKNM1Tx021877; Wed, 20 Dec 2006 15:22:01 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 20 Dec 2006 15:22:01 -0800 From: David Meyer <dmm@1-4-5.net> To: Tony Li <tli@cisco.com> Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061220232201.GA21784@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> Mime-Version: 1.0 In-Reply-To: <674D3434-399A-4499-9D99-8FE329B2C221@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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List <ram.iab.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ram> List-Post: <mailto:ram@iab.org> List-Help: <mailto:ram-request@iab.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1447078490==" Errors-To: ram-bounces@iab.org --===============1447078490== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tony, > If the sole point is to build a large RIB, I can get you one that's =20 > extremely large for very, very cheap. It'll hold about 10^11 entries =20 > and it'll cost you about USD $1000. >=20 > It's called a 'disk'. ;-) :-) > More seriously, the point is that performance and cost play a =20 > significant role, and if you do not take those into consideration, =20 > then you'll be missing a significant fraction of the problem. =20 Yes, that was (in part) of the point of my note.=20 > Please recall that BGP convergence time, for example, is > bounded by DRAM access times and that order of magnitude > improvements in size do not help at all in convergence. =20 Yep. > An Internet that does not converge does not do anyone any good. No, it isn't. > I think that whether or not the promised technology is deployable is =20 > VERY much an IETF problem. The E is for engineering after all. No disagreement at all. These numbers were flying around on various I* lists and I wanted to do some trivial math to see what they implied, hence my message. We're not disagreeing.=20 --dmm --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFicWZORgD1qCZ2KcRAuFlAJ48q0dFBSISnHa+PYSabUEbJSBZxgCfdQtY AkpKJUziiFTfmBh6d8H84Po= =0uo+ -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- --===============1447078490== 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 --===============1447078490==-- From ram-bounces@iab.org Wed Dec 20 18:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAki-00065s-MW; Wed, 20 Dec 2006 18:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAeM-00030a-Pm for ram@iab.org; Wed, 20 Dec 2006 18:15:02 -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 1GxAeL-0003cw-61 for ram@iab.org; Wed, 20 Dec 2006 18:15:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Dec 2006 15:15:01 -0800 X-IronPort-AV: i="4.12,193,1165219200"; d="scan'208"; a="353115506:sNHT55919402" 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 kBKNF09j003399; Wed, 20 Dec 2006 15:15:00 -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 kBKNEuZg008736; Wed, 20 Dec 2006 15:14:56 -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); Wed, 20 Dec 2006 15:14:55 -0800 Received: from [171.71.55.60] ([171.71.55.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 15:14:55 -0800 In-Reply-To: <20061220170024.GA4735@1-4-5.net> References: <20061220170024.GA4735@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: <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li <tli@cisco.com> Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Date: Wed, 20 Dec 2006 15:14:48 -0800 To: David Meyer <dmm@1-4-5.net> X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Dec 2006 23:14:55.0795 (UTC) FILETIME=[A94FD030:01C7248C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6827; t=1166656500; x=1167520500; 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<tli@cisco.com> |Subject:=20Re=3A=20[RAM]=20moving=20a=20discussion=20from=20various=20I* =20lists=20to=20ram@iab.org |Sender:=20; bh=yh5smXQvufnjqH9dwsPc+FREb7w28RjSyD/txu4ycw8=; b=V8NdENWvRNLPzNjPJgOo7BAMNQ5BYjE23lq8Ic2zLSxNsNUqkBFZL02wYfx0F9yhBPHKrKGS vZB/RfnAjl2rQgohru+SxlLM8Gqutr0pzWPqUBE/XHG0fnKAMiF5jCyH; 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: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Wed, 20 Dec 2006 18:21:36 -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 <ram.iab.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/ram> List-Post: <mailto:ram@iab.org> List-Help: <mailto:ram-request@iab.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe> Errors-To: ram-bounces@iab.org Dave, If the sole point is to build a large RIB, I can get you one that's extremely large for very, very cheap. It'll hold about 10^11 entries and it'll cost you about USD $1000. It's called a 'disk'. ;-) More seriously, the point is that performance and cost play a significant role, and if you do not take those into consideration, then you'll be missing a significant fraction of the problem. Please recall that BGP convergence time, for example, is bounded by DRAM access times and that order of magnitude improvements in size do not help at all in convergence. An Internet that does not converge does not do anyone any good. I think that whether or not the promised technology is deployable is VERY much an IETF problem. The E is for engineering after all. Tony On Dec 20, 2006, at 9:00 AM, David Meyer wrote: > The context here was that Leslie and I (and others) were > discussing the implications of the fact that vendors are > telling us that hardware that can hold RIB/FIBs of sizes > like 1 x 10^6 entries can be built today, and of sizes > like 1 x 10^7 in the 3-5 year time frame (I think the > term used was "not scared of 10M entry RIBs" or something > like that). We're hearing these kinds of numbers from > most vendors now. > > So I did a calculation based on Geoff's projections (see > reference below) in an effort to understand what the "not > scared" numbers would mean for RIB/FIB headroom over the > next several years. This is what I came up with: > > Let the "not scared" 3-5 year {R,F}IB size is 1 x 10^7 > RIB and/or FIB entries. In that case, we have a factor of > 40x headroom in the next 3-5 years at constant RIB > size. That is, > > "the not scared" {R,F}IB size/sizeof(todays DFZ RIB) > ~ 1 X 10^7/2.5 x 10^5 > ~ 40 > > (and yeah, the DFZ RIB is more like 200K, but this is > back of the envelope stuff in any event). > > So do we expect more than 40x growth in the appearance (in > the DFZ RIB) of prefixes designed to enable multihoming > (and/or TE) say, in the next 5 years? Geoff predicts > (again, ATNAC reference, see below) the growth from 2008 > to 2010 to be something like 3.75 x 10^5, so with that > number (same calculation), you get something like: > > 1 x 10^7/3.75 x 10^5 ~ 27 > > So again that would appear that 27x is quite a bit of > headroom (or maybe not), or so it would seem. > > Of course, this "no problem at 1 x 10^7 RIB/FIB entries" > analysis is vastly simplified, since it doesn't consider > many important factors, including: > > - All components of capital cost, including power, all > varieties of real estate (ASIC, pin-out, LC, PoP, ...), > etc, > > - The need for multiple copies of the RIB, VPN routes, > more specifics, other special purpose routes, > > - The advent of wildcards such as the widespread > deployment of IPv6, mobility and its interaction with > the routing system, etc. > > - It also assumes that the trends that Geoff identified > don't qualitatively change. > > I'll just note here that while RIB/FIB sizes are issues > to be concerned about, I am equally concerned (or perhaps > more concerned) about the trend toward carrying > increasingly fine-grained information in the routing > system (Geoff has a bit to say about this as well in > reference cited below). This is because carrying this > kind of information in the routing system exposes the > core to dynamics that might not be too attractive. That > is, the network's dynamics are closely related to how big > RIBs and FIBs are. BTW, why exactly would you need a RIB > of size 10^7? > > So the concern is that the RIB/FIBs are growing, addition > to some organic growth, precisely because we're carrying > increasingly fine grained information in the routing > system. This in turn exposes the core of the network to > "edge burstiness UPDATE stream", and we have a very poor > handle on the exact nature of that burstiness. The point > is that this is a function, at least in part, of our > protocol design and has deep implications for processing > resources. > > In any event, all of that prompted Leslie to ask a few > questions. The following is my response to Leslie's > questions. I'd be interested in others reflections on all > of this. > >>>> Thanks -- that helps me understand your point to be that >>>> the easiest thing to measure (DFZ FIB/RIB projections and >>>> ability to accommodate that growth in hardware) >>> >>> >>> Well, we definitely can look at what's out there now (and >>> over the past 8-10 years), and try to see the trends. We >>> also are hearing that building RIB/FIBs that are sized on >>> the order 10M entries is also not an issue. So yes, that >>> seems accurate. >>> >>> >>>> is not the measure of the ultimate issues: >>>> >>>> . still don't know if such hardware is deployable >>>> [doesn't strike me as an IETF-able problem] >>> >>> >>> Me either. >>> >>> >>>> . haven't begun to discuss the impact(s) of the >>>> forces driving the FIB/RIB growth (progressively >>>> finer-grained information held in the DFZ; impact >>>> on computation requirements & convergence times) >>>> [do strike me as IETF-able problems] >>> >>> >>> Yes, and these do seem like protocol issues (combined >>> with RIR policy, but to some extent, those policies are >>> driven by what protocols we've built/deployed). >>> >>> >>>> . apart from what's up in the core, there are other >>>> things desired in the routing system, maybe. >>>> [does strike me as an IETF-able problem] >>> >>> >>> Yes. >>> >>> >>>> And there are no particular studies to measure the above. >>> >>> >>> Regarding the second point, my sense is that while Geoff >>> and some others have good work on what is happening *now* >>> with RIB and UPDATE growth, we don't know too much about >>> the dynamic nature of UPDATEs. BTW, if folks know about >>> other work on this topic, I'd appreciate a pointer (or >>> pointers) to that work. >>> >>> thnx, >>> >>> --dmm >>> > > ----- End forwarded message ----- > > > <reference anchor="ATNAC2006" > <front> > <title Projecting Future IPv4 Router Requirements from > Trends in Dynamic BGP Behaviour > > > Huston, G. and G. Armitage > > > > value="http://www.potaroo.net/papers/phd/atnac-2006/bgp- > atnac2006.pdf"/> > > _______________________________________________ > 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 Dec 20 18:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAlB-0006NH-S4; Wed, 20 Dec 2006 18:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAlA-0006LB-79 for ram@iab.org; Wed, 20 Dec 2006 18:22:04 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAl8-00051e-Rv for ram@iab.org; Wed, 20 Dec 2006 18:22:04 -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 kBKNM1Qk021878; Wed, 20 Dec 2006 15:22:01 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBKNM1Tx021877; Wed, 20 Dec 2006 15:22:01 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 20 Dec 2006 15:22:01 -0800 From: David Meyer To: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061220232201.GA21784@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> Mime-Version: 1.0 In-Reply-To: <674D3434-399A-4499-9D99-8FE329B2C221@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: 82c9bddb247d9ba4471160a9a865a5f3 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="===============1447078490==" Errors-To: ram-bounces@iab.org --===============1447078490== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tony, > If the sole point is to build a large RIB, I can get you one that's =20 > extremely large for very, very cheap. It'll hold about 10^11 entries =20 > and it'll cost you about USD $1000. >=20 > It's called a 'disk'. ;-) :-) > More seriously, the point is that performance and cost play a =20 > significant role, and if you do not take those into consideration, =20 > then you'll be missing a significant fraction of the problem. =20 Yes, that was (in part) of the point of my note.=20 > Please recall that BGP convergence time, for example, is > bounded by DRAM access times and that order of magnitude > improvements in size do not help at all in convergence. =20 Yep. > An Internet that does not converge does not do anyone any good. No, it isn't. > I think that whether or not the promised technology is deployable is =20 > VERY much an IETF problem. The E is for engineering after all. No disagreement at all. These numbers were flying around on various I* lists and I wanted to do some trivial math to see what they implied, hence my message. We're not disagreeing.=20 --dmm --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFicWZORgD1qCZ2KcRAuFlAJ48q0dFBSISnHa+PYSabUEbJSBZxgCfdQtY AkpKJUziiFTfmBh6d8H84Po= =0uo+ -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- --===============1447078490== 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 --===============1447078490==-- From ram-bounces@iab.org Wed Dec 20 18:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAki-00065s-MW; Wed, 20 Dec 2006 18:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAeM-00030a-Pm for ram@iab.org; Wed, 20 Dec 2006 18:15:02 -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 1GxAeL-0003cw-61 for ram@iab.org; Wed, 20 Dec 2006 18:15:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Dec 2006 15:15:01 -0800 X-IronPort-AV: i="4.12,193,1165219200"; d="scan'208"; a="353115506:sNHT55919402" 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 kBKNF09j003399; Wed, 20 Dec 2006 15:15:00 -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 kBKNEuZg008736; Wed, 20 Dec 2006 15:14:56 -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); Wed, 20 Dec 2006 15:14:55 -0800 Received: from [171.71.55.60] ([171.71.55.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 15:14:55 -0800 In-Reply-To: <20061220170024.GA4735@1-4-5.net> References: <20061220170024.GA4735@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: <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Date: Wed, 20 Dec 2006 15:14:48 -0800 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Dec 2006 23:14:55.0795 (UTC) FILETIME=[A94FD030:01C7248C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6827; t=1166656500; x=1167520500; 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=20[RAM]=20moving=20a=20discussion=20from=20various=20I* =20lists=20to=20ram@iab.org |Sender:=20; bh=yh5smXQvufnjqH9dwsPc+FREb7w28RjSyD/txu4ycw8=; b=V8NdENWvRNLPzNjPJgOo7BAMNQ5BYjE23lq8Ic2zLSxNsNUqkBFZL02wYfx0F9yhBPHKrKGS vZB/RfnAjl2rQgohru+SxlLM8Gqutr0pzWPqUBE/XHG0fnKAMiF5jCyH; 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: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Wed, 20 Dec 2006 18:21:36 -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 Dave, If the sole point is to build a large RIB, I can get you one that's extremely large for very, very cheap. It'll hold about 10^11 entries and it'll cost you about USD $1000. It's called a 'disk'. ;-) More seriously, the point is that performance and cost play a significant role, and if you do not take those into consideration, then you'll be missing a significant fraction of the problem. Please recall that BGP convergence time, for example, is bounded by DRAM access times and that order of magnitude improvements in size do not help at all in convergence. An Internet that does not converge does not do anyone any good. I think that whether or not the promised technology is deployable is VERY much an IETF problem. The E is for engineering after all. Tony On Dec 20, 2006, at 9:00 AM, David Meyer wrote: > The context here was that Leslie and I (and others) were > discussing the implications of the fact that vendors are > telling us that hardware that can hold RIB/FIBs of sizes > like 1 x 10^6 entries can be built today, and of sizes > like 1 x 10^7 in the 3-5 year time frame (I think the > term used was "not scared of 10M entry RIBs" or something > like that). We're hearing these kinds of numbers from > most vendors now. > > So I did a calculation based on Geoff's projections (see > reference below) in an effort to understand what the "not > scared" numbers would mean for RIB/FIB headroom over the > next several years. This is what I came up with: > > Let the "not scared" 3-5 year {R,F}IB size is 1 x 10^7 > RIB and/or FIB entries. In that case, we have a factor of > 40x headroom in the next 3-5 years at constant RIB > size. That is, > > "the not scared" {R,F}IB size/sizeof(todays DFZ RIB) > ~ 1 X 10^7/2.5 x 10^5 > ~ 40 > > (and yeah, the DFZ RIB is more like 200K, but this is > back of the envelope stuff in any event). > > So do we expect more than 40x growth in the appearance (in > the DFZ RIB) of prefixes designed to enable multihoming > (and/or TE) say, in the next 5 years? Geoff predicts > (again, ATNAC reference, see below) the growth from 2008 > to 2010 to be something like 3.75 x 10^5, so with that > number (same calculation), you get something like: > > 1 x 10^7/3.75 x 10^5 ~ 27 > > So again that would appear that 27x is quite a bit of > headroom (or maybe not), or so it would seem. > > Of course, this "no problem at 1 x 10^7 RIB/FIB entries" > analysis is vastly simplified, since it doesn't consider > many important factors, including: > > - All components of capital cost, including power, all > varieties of real estate (ASIC, pin-out, LC, PoP, ...), > etc, > > - The need for multiple copies of the RIB, VPN routes, > more specifics, other special purpose routes, > > - The advent of wildcards such as the widespread > deployment of IPv6, mobility and its interaction with > the routing system, etc. > > - It also assumes that the trends that Geoff identified > don't qualitatively change. > > I'll just note here that while RIB/FIB sizes are issues > to be concerned about, I am equally concerned (or perhaps > more concerned) about the trend toward carrying > increasingly fine-grained information in the routing > system (Geoff has a bit to say about this as well in > reference cited below). This is because carrying this > kind of information in the routing system exposes the > core to dynamics that might not be too attractive. That > is, the network's dynamics are closely related to how big > RIBs and FIBs are. BTW, why exactly would you need a RIB > of size 10^7? > > So the concern is that the RIB/FIBs are growing, addition > to some organic growth, precisely because we're carrying > increasingly fine grained information in the routing > system. This in turn exposes the core of the network to > "edge burstiness UPDATE stream", and we have a very poor > handle on the exact nature of that burstiness. The point > is that this is a function, at least in part, of our > protocol design and has deep implications for processing > resources. > > In any event, all of that prompted Leslie to ask a few > questions. The following is my response to Leslie's > questions. I'd be interested in others reflections on all > of this. > >>>> Thanks -- that helps me understand your point to be that >>>> the easiest thing to measure (DFZ FIB/RIB projections and >>>> ability to accommodate that growth in hardware) >>> >>> >>> Well, we definitely can look at what's out there now (and >>> over the past 8-10 years), and try to see the trends. We >>> also are hearing that building RIB/FIBs that are sized on >>> the order 10M entries is also not an issue. So yes, that >>> seems accurate. >>> >>> >>>> is not the measure of the ultimate issues: >>>> >>>> . still don't know if such hardware is deployable >>>> [doesn't strike me as an IETF-able problem] >>> >>> >>> Me either. >>> >>> >>>> . haven't begun to discuss the impact(s) of the >>>> forces driving the FIB/RIB growth (progressively >>>> finer-grained information held in the DFZ; impact >>>> on computation requirements & convergence times) >>>> [do strike me as IETF-able problems] >>> >>> >>> Yes, and these do seem like protocol issues (combined >>> with RIR policy, but to some extent, those policies are >>> driven by what protocols we've built/deployed). >>> >>> >>>> . apart from what's up in the core, there are other >>>> things desired in the routing system, maybe. >>>> [does strike me as an IETF-able problem] >>> >>> >>> Yes. >>> >>> >>>> And there are no particular studies to measure the above. >>> >>> >>> Regarding the second point, my sense is that while Geoff >>> and some others have good work on what is happening *now* >>> with RIB and UPDATE growth, we don't know too much about >>> the dynamic nature of UPDATEs. BTW, if folks know about >>> other work on this topic, I'd appreciate a pointer (or >>> pointers) to that work. >>> >>> thnx, >>> >>> --dmm >>> > > ----- End forwarded message ----- > > > > Trends in Dynamic BGP Behaviour > > > Huston, G. and G. Armitage > > > > value="http://www.potaroo.net/papers/phd/atnac-2006/bgp- > atnac2006.pdf"/> > > _______________________________________________ > 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 Dec 20 18:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAuZ-0001dK-Rk; Wed, 20 Dec 2006 18:31:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAuX-0001U2-VB for ram@iab.org; Wed, 20 Dec 2006 18:31:46 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxAuV-0007GD-CB for ram@iab.org; Wed, 20 Dec 2006 18:31:45 -0500 Received: from [192.168.0.105] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Dec 2006 18:31:09 -0500 id 0158C308.4589C7BE.00001663 Message-ID: <4589C7CC.5090102@thinkingcat.com> Date: Wed, 20 Dec 2006 18:31:24 -0500 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> In-Reply-To: <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 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 Since the "deployable" comment was mine, let me defend it -- it doesn't have enough context in the bit Dave forwarded. The specific issue of deployability was whether or not core network providers would be willing/able to pay for the hardware vendors can build to accommodate the large sizes (with suitable speed for convergence, etc). So, it was primarily referring to economic/business questions of deployability, not E questions. Leslie. Tony Li wrote: > > Dave, > > If the sole point is to build a large RIB, I can get you one that's > extremely large for very, very cheap. It'll hold about 10^11 entries > and it'll cost you about USD $1000. > > It's called a 'disk'. ;-) > > More seriously, the point is that performance and cost play a > significant role, and if you do not take those into consideration, then > you'll be missing a significant fraction of the problem. Please recall > that BGP convergence time, for example, is bounded by DRAM access times > and that order of magnitude improvements in size do not help at all in > convergence. An Internet that does not converge does not do anyone any > good. > > I think that whether or not the promised technology is deployable is > VERY much an IETF problem. The E is for engineering after all. > > Tony > > > On Dec 20, 2006, at 9:00 AM, David Meyer wrote: > >> The context here was that Leslie and I (and others) were >> discussing the implications of the fact that vendors are >> telling us that hardware that can hold RIB/FIBs of sizes >> like 1 x 10^6 entries can be built today, and of sizes >> like 1 x 10^7 in the 3-5 year time frame (I think the >> term used was "not scared of 10M entry RIBs" or something >> like that). We're hearing these kinds of numbers from >> most vendors now. >> >> So I did a calculation based on Geoff's projections (see >> reference below) in an effort to understand what the "not >> scared" numbers would mean for RIB/FIB headroom over the >> next several years. This is what I came up with: >> >> Let the "not scared" 3-5 year {R,F}IB size is 1 x 10^7 >> RIB and/or FIB entries. In that case, we have a factor of >> 40x headroom in the next 3-5 years at constant RIB >> size. That is, >> >> "the not scared" {R,F}IB size/sizeof(todays DFZ RIB) >> ~ 1 X 10^7/2.5 x 10^5 >> ~ 40 >> >> (and yeah, the DFZ RIB is more like 200K, but this is >> back of the envelope stuff in any event). >> >> So do we expect more than 40x growth in the appearance (in >> the DFZ RIB) of prefixes designed to enable multihoming >> (and/or TE) say, in the next 5 years? Geoff predicts >> (again, ATNAC reference, see below) the growth from 2008 >> to 2010 to be something like 3.75 x 10^5, so with that >> number (same calculation), you get something like: >> >> 1 x 10^7/3.75 x 10^5 ~ 27 >> >> So again that would appear that 27x is quite a bit of >> headroom (or maybe not), or so it would seem. >> >> Of course, this "no problem at 1 x 10^7 RIB/FIB entries" >> analysis is vastly simplified, since it doesn't consider >> many important factors, including: >> >> - All components of capital cost, including power, all >> varieties of real estate (ASIC, pin-out, LC, PoP, ...), >> etc, >> >> - The need for multiple copies of the RIB, VPN routes, >> more specifics, other special purpose routes, >> >> - The advent of wildcards such as the widespread >> deployment of IPv6, mobility and its interaction with >> the routing system, etc. >> >> - It also assumes that the trends that Geoff identified >> don't qualitatively change. >> >> I'll just note here that while RIB/FIB sizes are issues >> to be concerned about, I am equally concerned (or perhaps >> more concerned) about the trend toward carrying >> increasingly fine-grained information in the routing >> system (Geoff has a bit to say about this as well in >> reference cited below). This is because carrying this >> kind of information in the routing system exposes the >> core to dynamics that might not be too attractive. That >> is, the network's dynamics are closely related to how big >> RIBs and FIBs are. BTW, why exactly would you need a RIB >> of size 10^7? >> >> So the concern is that the RIB/FIBs are growing, addition >> to some organic growth, precisely because we're carrying >> increasingly fine grained information in the routing >> system. This in turn exposes the core of the network to >> "edge burstiness UPDATE stream", and we have a very poor >> handle on the exact nature of that burstiness. The point >> is that this is a function, at least in part, of our >> protocol design and has deep implications for processing >> resources. >> >> In any event, all of that prompted Leslie to ask a few >> questions. The following is my response to Leslie's >> questions. I'd be interested in others reflections on all >> of this. >> >>>>> Thanks -- that helps me understand your point to be that >>>>> the easiest thing to measure (DFZ FIB/RIB projections and >>>>> ability to accommodate that growth in hardware) >>>> >>>> >>>> Well, we definitely can look at what's out there now (and >>>> over the past 8-10 years), and try to see the trends. We >>>> also are hearing that building RIB/FIBs that are sized on >>>> the order 10M entries is also not an issue. So yes, that >>>> seems accurate. >>>> >>>> >>>>> is not the measure of the ultimate issues: >>>>> >>>>> . still don't know if such hardware is deployable >>>>> [doesn't strike me as an IETF-able problem] >>>> >>>> >>>> Me either. >>>> >>>> >>>>> . haven't begun to discuss the impact(s) of the >>>>> forces driving the FIB/RIB growth (progressively >>>>> finer-grained information held in the DFZ; impact >>>>> on computation requirements & convergence times) >>>>> [do strike me as IETF-able problems] >>>> >>>> >>>> Yes, and these do seem like protocol issues (combined >>>> with RIR policy, but to some extent, those policies are >>>> driven by what protocols we've built/deployed). >>>> >>>> >>>>> . apart from what's up in the core, there are other >>>>> things desired in the routing system, maybe. >>>>> [does strike me as an IETF-able problem] >>>> >>>> >>>> Yes. >>>> >>>> >>>>> And there are no particular studies to measure the above. >>>> >>>> >>>> Regarding the second point, my sense is that while Geoff >>>> and some others have good work on what is happening *now* >>>> with RIB and UPDATE growth, we don't know too much about >>>> the dynamic nature of UPDATEs. BTW, if folks know about >>>> other work on this topic, I'd appreciate a pointer (or >>>> pointers) to that work. >>>> >>>> thnx, >>>> >>>> --dmm >>>> >> >> ----- End forwarded message ----- >> >> >> > >> > Trends in Dynamic BGP Behaviour >> >> >> Huston, G. and G. Armitage >> >> >> >> > >> value="http://www.potaroo.net/papers/phd/atnac-2006/bgp-atnac2006.pdf"/> >> >> _______________________________________________ >> 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 Wed Dec 20 20:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDCf-0003q7-Bq; Wed, 20 Dec 2006 20:58:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDCe-0003pa-Hz for ram@iab.org; Wed, 20 Dec 2006 20:58:36 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxDCe-0007Ck-5X for ram@iab.org; Wed, 20 Dec 2006 20:58:36 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id D88A617618; Thu, 21 Dec 2006 01:58:05 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GxDC9-00052R-FQ; Wed, 20 Dec 2006 20:58:05 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: Leslie Daigle Message-Id: Date: Wed, 20 Dec 2006 20:58:05 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: iab@ietf.org, iesg@ietf.org, ram@iab.org Subject: [RAM] Routing & Addressing -- activities X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 recent IAB workshop (see draft-iab-raws-report-00) established that a significant fraction of the Internet operations community and their equipment vendors believe that we face a scaling problem for routing in the core of the Internet, on a worrying timescale. They further believe that timely action is needed. Enough evidence was available to the workshop to convince the IAB and IESG members present that the problem is real, even if the timescale and details are debatable, and that the solution will lie in certain specific areas mentioned below. It is also evident that the Internet community has everything to gain if efforts in the IETF and IRTF are closely coordinated with those in the operations and vendor communities, and much to lose otherwise. While these problems are pressing, we believe there is time for a coordinated approach. Therefore, the IAB & IESG have worked together to identify key paths for progress in discussing and resolving this problem, and have agreed to establish an advisory group for coordinating information flow and awareness of activities (more on this group, below). We note that although this topic is of primary concern to backbone network operators and their equipment makers, many other parts of the community have an interest. These include other ISPs, enterprise network operators, mobile operators, server and host software makers, and standards development organizations other than the IETF. KEY PATHS FOR PROGRESS Regarding possible solutions, the current understanding of the cause of the scaling problem is that it is driven not by growth of the size of the Internet as such, but by growth in the demand for routing of individual address prefixes that cannot be aggregated into coarser routes. This implies that the solution will lie in the direction of separating the usage of address prefixes to identify sites from their usage for wide-area routing. There is a variety of ways that such a separation could be achieved. Following various discussions at IETF67, we set out below the main lines of action that we propose, followed by a suggested arrangement to drive these actions forward in parallel. (1) Complete the problem statement, addressing the issues raised in the IAB workshop and others as applicable. (2) Determine applicable objective metrics and identify applicable trend analyses for them. (3) Document the underlying causes of perceived scaling problems. (4) Review proposed solution directions in terms of expected impact in addressing scaling issues as well as architectural soundness. (5) Encourage and nurture short term solution proposals, prototypes and appropriate standards activity. (6) Encourage and nurture relevant research activities directed towards long term solutions. INTEGRATION WITH EXISTING IETF FUNCTIONS The IAB and IESG intend to take their full part in these actions, but specifically as part of a broad community effort. The IAB would expect to focus on actions to promote (1), (2), (3) and (4), and expects the IRTF to work with other research entities on (6). The IAB in particular publishes informational documents, convenes workshops, and supports IRTF work as necessary and possible. The IESG will play its normal role in chartering BoFs and WGs and reviewing WG and individual submission (IETF stream) documents as appropriate and in particular for (5). To be as inclusive as possible, while sustaining the effort over a number of years, the IAB and IESG propose a tiered approach to project coordination: (A) We assume that detailed work will be carried out by ad hoc or chartered teams, and there is no grand plan for structuring these teams. As always in the development of the Internet, we expect analysis and solutions to come from the community at large. (B) IAB workshops, BOFs, IETF WGs and IRTF RGs can be organized in the normal way, as issues and proposals arise in the community. (C) General discussion is already proceeding on the ram@iab.org list. More specialized lists can be created as needed. COORDINATION The IETF and IAB Chairs will appoint a Directorate, including roughly ten people with different experience and expertise, to stay abreast of activities, provide coordinated updates, as well as input to the IESG and IAB about progress against the noted actions above. We use the name "Directorate" simply because it is a recognized term in the IETF; we expect it to focus on communication and coordination. It will not be charged with picking solutions or choosing a technical direction. That will be a community decision. This Directorate is expected to have a lifetime of about 5 years (with an annual review of membership). The Directorate will be organized and reviewed periodically to ensure it is running smoothly and reporting on overall progress. Specific objectives of the Directorate will be: (i) On a continuing basis, survey existing efforts on the lines of action listed above, and facilitate discussion of effectiveness and timeliness of proposals and problem statements, etc. (ii) Report to the IAB, IESG and the community regularly (at least once per IETF meeting) about those efforts, and highlight specific gaps or concerns about progress. (iii) Provide feedback to IESG, IAB and IRSG on any relevant proposed activities in the area (e.g., WG or RG charters, BOF or workshop proposals, etc). The Directorate will be charged with encouraging appropriate communication with all the identified constituencies. Leslie & Brian, for the IAB & IESG. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 20 21:08:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDMN-0000uv-UH; Wed, 20 Dec 2006 21:08:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDMM-0000uG-R1 for ram@iab.org; Wed, 20 Dec 2006 21:08:38 -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 1GxDMI-000753-VP for ram@iab.org; Wed, 20 Dec 2006 21:08:38 -0500 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JAL00D7MPY4Y6@firewall.mci.com> for ram@iab.org; Thu, 21 Dec 2006 02:08:28 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JAL00G8HPY4ZZ@dgismtp01.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 02:08:28 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JAL00G4CPY3SN@dgismtp01.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 02:08:28 +0000 (GMT) Date: Thu, 21 Dec 2006 02:08:27 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-reply-to: <674D3434-399A-4499-9D99-8FE329B2C221@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: <20061220170024.GA4735@1-4-5.net> <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, 20 Dec 2006, Tony Li wrote: > help at all in convergence. An Internet that does not converge does > not do anyone any good. this seems to be a very real fear, please don't lose track of the fact that size of RIB/FIB is not the only problem, updates from RIB -> FIB are also a problem... > On Dec 20, 2006, at 9:00 AM, David Meyer wrote: > > > The context here was that Leslie and I (and others) were > > discussing the implications of the fact that vendors are > > telling us that hardware that can hold RIB/FIBs of sizes > > like 1 x 10^6 entries can be built today, and of sizes > > like 1 x 10^7 in the 3-5 year time frame (I think the > > term used was "not scared of 10M entry RIBs" or something > > like that). We're hearing these kinds of numbers from > > most vendors now. As a customer of some of the vendors I'd ask: "why do I not have that today? Why does it appear in testing that the 'latest' devices off the assembly line tip over dramatically at 500k or so routes?" Even setting this asside vendor engineers have said point-blank to our eng folks that there are serious problems scaling the current systems (hardware) and maintaining the current restrictions on convergence speed. I don't think that modeling the update rate increase/change over time has happened yet, and I don't think that modeling that against hardware capabilties has really happened either. So, I don't think that vendor folks are really in a position to express 'non-fear' about 10M routes in the table (and the associated churn rates that would come along with that increase). -Chris _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 20 21:16:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDU4-0005nN-GJ; Wed, 20 Dec 2006 21:16:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxDU2-0005nE-05 for ram@iab.org; Wed, 20 Dec 2006 21:16:34 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxDU0-0000Br-3h for ram@iab.org; Wed, 20 Dec 2006 21:16:33 -0500 Received: from webmail03.lax.untd.com (webmail03.lax.untd.com [10.131.27.143]) by smtpout03.lax.untd.com with SMTP id AABC2V5V3AXW462A for (sender ); Wed, 20 Dec 2006 18:16:25 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKR7BX+nbOJs/fwbm8XQX+TQ== Received: (from fergdawg@netzero.net) by webmail03.lax.untd.com (jqueuemail) id L933QRKQ; Wed, 20 Dec 2006 18:15:29 PST Received: from [24.23.201.115] by webmail03.lax.untd.com with HTTP: Thu, 21 Dec 2006 02:14:56 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Thu, 21 Dec 2006 02:14:56 GMT To: christopher.morrow@verizonbusiness.com Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061220.181529.8794.1737766@webmail03.lax.untd.com> X-ContentStamp: 13:6:2988452608 X-MAIL-INFO: 29174f936bc74fc717ae170b57a3cfbebedef72abeb7ab575e9acadb5b73734f7f3a6a93 X-UNTD-Peer-Info: 10.131.27.143|webmail03.lax.untd.com|webmail03.lax.untd.com|fergdawg@netzero.net 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 - -- "Chris L. Morrow" wrote: >As a customer of some of the vendors I'd ask: "why do I not have that >today? Why does it appear in testing that the 'latest' devices off the >assembly line tip over dramatically at 500k or so routes?" Even settin= g >this asside vendor engineers have said point-blank to our eng folks tha= t >there are serious problems scaling the current systems (hardware) and >maintaining the current restrictions on convergence speed. > >I don't think that modeling the update rate increase/change over time h= as >happened yet, and I don't think that modeling that against hardware >capabilties has really happened either. So, I don't think that vendor >folks are really in a position to express 'non-fear' about 10M routes i= n >the table (and the associated churn rates that would come along with th= at >increase). I share your concern here -- although it certainly affects backbone carriers more than it does leaf-node networks. I find it curious, however, that with the plethora of router vendors participating in the IETF process(es), none of them seem to be forthcoming on this concern. In other words, it would be nice to hear from the router what they are doing to meet the obvious future needs here. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFie4Xq1pz9mNUZTMRAqIVAKCBSnuR6YUYjwESaC04UN1HUkuM9QCgiwQk 6nLrXR5Af7vIsyVLPdFXAkE=3D =3DEA/A -----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 Dec 20 22:02:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxEBN-00039c-EE; Wed, 20 Dec 2006 22:01:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxEBL-00034g-Et for ram@iab.org; Wed, 20 Dec 2006 22:01:19 -0500 Received: from out001.apptix.savvis.net ([216.91.32.44] helo=out001a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxEBK-0001dP-8g for ram@iab.org; Wed, 20 Dec 2006 22:01:19 -0500 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out001a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 21:01:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] moving a discussion from various I* lists to ram@iab.org Date: Wed, 20 Dec 2006 21:00:38 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] moving a discussion from various I* lists to ram@iab.org Thread-Index: AcckphbElfph9vsDT7aZbEIGE0F/CgABI5hg From: "Schliesser, Benson" To: "Fergie" , X-OriginalArrivalTime: 21 Dec 2006 03:01:11.0843 (UTC) FILETIME=[45445730:01C724AC] 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 > From: Fergie [mailto:fergdawg@netzero.net]=20 > [...] > In other words, it would be nice to hear from the router what they > are doing to meet the obvious future needs here. I'll posit that the router vendors see competitive advantage in capitalizing a solution to this problem and aren't inclined to share openly. (Though perhaps I am too cynical?) Generally speaking, this is the sort of problem that's already been solved in other domains. So, I'd expect to see some reasonable innovation in the router space. That doesn't make me any less nervous, though, especially nervous about the deployability/economics... Cheers, -Benson _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 20 22:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxELB-0008HW-6a; Wed, 20 Dec 2006 22:11:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxEL9-0008CB-IT for ram@iab.org; Wed, 20 Dec 2006 22:11:27 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxEL7-0003PI-Cm for ram@iab.org; Wed, 20 Dec 2006 22:11:26 -0500 Received: from webmail03.lax.untd.com (webmail03.lax.untd.com [10.131.27.143]) by smtpout05.lax.untd.com with SMTP id AABC2V84JAFFHWDJ for (sender ); Wed, 20 Dec 2006 19:11:04 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKIEPkY+sZUTmG7yi/NMr83A== Received: (from fergdawg@netzero.net) by webmail03.lax.untd.com (jqueuemail) id L936V3EX; Wed, 20 Dec 2006 19:10:49 PST Received: from [24.23.201.115] by webmail03.lax.untd.com with HTTP: Thu, 21 Dec 2006 03:10:36 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Thu, 21 Dec 2006 03:10:36 GMT To: bensons@savvis.net Subject: RE: [RAM] moving a discussion from various I* lists to ram@iab.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061220.191049.8794.1738242@webmail03.lax.untd.com> X-ContentStamp: 14:7:2393763193 X-MAIL-INFO: 55e34b1fa73b4b3be3cfe39bbb87c727270aceee27bfe7bbeb67027b4e8f8f4b5e47431f X-UNTD-Peer-Info: 10.131.27.143|webmail03.lax.untd.com|webmail03.lax.untd.com|fergdawg@netzero.net 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 - -- "Schliesser, Benson" wrote: >> In other words, it would be nice to hear from the router what they >> are doing to meet the obvious future needs here. >I'll posit that the router vendors see competitive advantage in >capitalizing a solution to this problem and aren't inclined to share >openly. >(Though perhaps I am too cynical?) No, I don't think you are, but I'm generally willing to give them the benefit of the doubt in a public forum. :-) >Generally speaking, this is the sort of problem that's already been >solved in other domains. So, I'd expect to see some reasonable >innovation in the router space. That doesn't make me any less nervous, >though, especially nervous about the deployability/economics... > I'm personally 'nervous' over the silence on the matter from the people that we all buy hardware from. It doesn't fill one with an abundance of confidence, especially given that we're in the process of discussing architectural models without the gratis/assurances of fundamental forwarding capacity functions. This should disturb us all. Greatly. To be frank: We are moving ahead with trepidity on a 'next- generation' architecture without some basic assurances, and from the data that has already been presented, the scaling v. time-to-availability issues for ASIC support just doesn't match up. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFifslq1pz9mNUZTMRAquPAJ9SJ7QLl1emHbAW1LbesYJiOOnl9gCgnzEB TgpJGt8J08cOV55id/jal+g=3D =3DGnxu -----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 Dec 20 22:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxEjc-0004j2-Ce; Wed, 20 Dec 2006 22:36:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxEja-0004ix-Jx for ram@iab.org; Wed, 20 Dec 2006 22:36:42 -0500 Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxEjX-00010s-9g for ram@iab.org; Wed, 20 Dec 2006 22:36:42 -0500 Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JAL00547U0V6H@firewall.mci.com> for ram@iab.org; Thu, 21 Dec 2006 03:36:31 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([127.0.0.1]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JAL004LEU0VFQ@dgismtp01.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 03:36:31 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JAL0043HU0VKV@dgismtp01.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 03:36:31 +0000 (GMT) Date: Thu, 21 Dec 2006 03:36:31 +0000 (GMT) From: "Chris L. Morrow" Subject: RE: [RAM] moving a discussion from various I* lists to ram@iab.org In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: "Schliesser, Benson" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: X-Spam-Score: 0.1 (/) 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 On Wed, 20 Dec 2006, Schliesser, Benson wrote: > > > From: Fergie [mailto:fergdawg@netzero.net] > > [...] > > In other words, it would be nice to hear from the router what they > > are doing to meet the obvious future needs here. > > I'll posit that the router vendors see competitive advantage in > capitalizing a solution to this problem and aren't inclined to share > openly. that could be, which would be unfortunate I think. I don't see how many of the currently proposed directions will work in a single vendor world. > (Though perhaps I am too cynical?) > Generally speaking, this is the sort of problem that's already been > solved in other domains. So, I'd expect to see some reasonable > innovation in the router space. That doesn't make me any less nervous, > though, especially nervous about the deployability/economics... Agreed, I think it's important to not discard any thing out of hand at this point in the game though. Given a solid-ish problem statement some requirements could arise and better selection of direction may be simple, right? -Chris _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 00:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxGkS-0001MV-UV; Thu, 21 Dec 2006 00:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxGkR-0001MK-60 for ram@iab.org; Thu, 21 Dec 2006 00:45:43 -0500 Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxGkP-0001oo-R6 for ram@iab.org; Thu, 21 Dec 2006 00:45:43 -0500 Received: (qmail 9115 invoked by uid 211); 21 Dec 2006 05:45:39 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 21 Dec 2006 05:45:39 -0000 Message-ID: <458A1F7F.2020803@vijaygill.com> Date: Wed, 20 Dec 2006 21:45:35 -0800 From: vijay gill User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> In-Reply-To: <20061220170024.GA4735@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 David Meyer wrote: > The context here was that Leslie and I (and others) were > discussing the implications of the fact that vendors are > telling us that hardware that can hold RIB/FIBs of sizes > like 1 x 10^6 entries can be built today, and of sizes > like 1 x 10^7 in the 3-5 year time frame (I think the > term used was "not scared of 10M entry RIBs" or something > like that). We're hearing these kinds of numbers from > most vendors now. Of course the vendors can build it, after all, it just results in another upgrade cycle analogous to the gsr/jnx core upgrades in the late 90s timeframe. The question is who all can afford to pay for these? We from the operational side are getting strong pushback to amortize routers over longer and longer periods from the finance folks. To be economically viable, we have to upgrade on a scale that lags the vendor sales cycle. /vijay > > So I did a calculation based on Geoff's projections (see > reference below) in an effort to understand what the "not > scared" numbers would mean for RIB/FIB headroom over the > next several years. This is what I came up with: > > Let the "not scared" 3-5 year {R,F}IB size is 1 x 10^7 > RIB and/or FIB entries. In that case, we have a factor of > 40x headroom in the next 3-5 years at constant RIB > size. That is, > > "the not scared" {R,F}IB size/sizeof(todays DFZ RIB) > ~ 1 X 10^7/2.5 x 10^5 > ~ 40 > > (and yeah, the DFZ RIB is more like 200K, but this is > back of the envelope stuff in any event). > > So do we expect more than 40x growth in the appearance (in > the DFZ RIB) of prefixes designed to enable multihoming > (and/or TE) say, in the next 5 years? Geoff predicts > (again, ATNAC reference, see below) the growth from 2008 > to 2010 to be something like 3.75 x 10^5, so with that > number (same calculation), you get something like: > > 1 x 10^7/3.75 x 10^5 ~ 27 > > So again that would appear that 27x is quite a bit of > headroom (or maybe not), or so it would seem. > > Of course, this "no problem at 1 x 10^7 RIB/FIB entries" > analysis is vastly simplified, since it doesn't consider > many important factors, including: > > - All components of capital cost, including power, all > varieties of real estate (ASIC, pin-out, LC, PoP, ...), > etc, > > - The need for multiple copies of the RIB, VPN routes, > more specifics, other special purpose routes, > > - The advent of wildcards such as the widespread > deployment of IPv6, mobility and its interaction with > the routing system, etc. > > - It also assumes that the trends that Geoff identified > don't qualitatively change. > > I'll just note here that while RIB/FIB sizes are issues > to be concerned about, I am equally concerned (or perhaps > more concerned) about the trend toward carrying > increasingly fine-grained information in the routing > system (Geoff has a bit to say about this as well in > reference cited below). This is because carrying this > kind of information in the routing system exposes the > core to dynamics that might not be too attractive. That > is, the network's dynamics are closely related to how big > RIBs and FIBs are. BTW, why exactly would you need a RIB > of size 10^7? > > So the concern is that the RIB/FIBs are growing, addition > to some organic growth, precisely because we're carrying > increasingly fine grained information in the routing > system. This in turn exposes the core of the network to > "edge burstiness UPDATE stream", and we have a very poor > handle on the exact nature of that burstiness. The point > is that this is a function, at least in part, of our > protocol design and has deep implications for processing > resources. > > In any event, all of that prompted Leslie to ask a few > questions. The following is my response to Leslie's > questions. I'd be interested in others reflections on all > of this. > >>>> Thanks -- that helps me understand your point to be that >>>> the easiest thing to measure (DFZ FIB/RIB projections and >>>> ability to accommodate that growth in hardware) >>> >>> Well, we definitely can look at what's out there now (and >>> over the past 8-10 years), and try to see the trends. We >>> also are hearing that building RIB/FIBs that are sized on >>> the order 10M entries is also not an issue. So yes, that >>> seems accurate. >>> >>> >>>> is not the measure of the ultimate issues: >>>> >>>> . still don't know if such hardware is deployable >>>> [doesn't strike me as an IETF-able problem] >>> >>> Me either. >>> >>> >>>> . haven't begun to discuss the impact(s) of the >>>> forces driving the FIB/RIB growth (progressively >>>> finer-grained information held in the DFZ; impact >>>> on computation requirements & convergence times) >>>> [do strike me as IETF-able problems] >>> >>> Yes, and these do seem like protocol issues (combined >>> with RIR policy, but to some extent, those policies are >>> driven by what protocols we've built/deployed). >>> >>> >>>> . apart from what's up in the core, there are other >>>> things desired in the routing system, maybe. >>>> [does strike me as an IETF-able problem] >>> >>> Yes. >>> >>> >>>> And there are no particular studies to measure the above. >>> >>> Regarding the second point, my sense is that while Geoff >>> and some others have good work on what is happening *now* >>> with RIB and UPDATE growth, we don't know too much about >>> the dynamic nature of UPDATEs. BTW, if folks know about >>> other work on this topic, I'd appreciate a pointer (or >>> pointers) to that work. >>> >>> thnx, >>> >>> --dmm >>> > > ----- End forwarded message ----- > > > > Trends in Dynamic BGP Behaviour > > > Huston, G. and G. Armitage > > > > value="http://www.potaroo.net/papers/phd/atnac-2006/bgp-atnac2006.pdf"/> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Dec 21 05:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxLUB-000066-4S; Thu, 21 Dec 2006 05:49:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxLU9-000057-Br for ram@iab.org; Thu, 21 Dec 2006 05:49:13 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxLU6-0005XS-N5 for ram@iab.org; Thu, 21 Dec 2006 05:49:13 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 78F78898C4; Thu, 21 Dec 2006 12:49:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 25C53898C2; Thu, 21 Dec 2006 12:49:02 +0200 (EET) Message-ID: <458A669E.10404@piuha.net> Date: Thu, 21 Dec 2006 12:49:02 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> In-Reply-To: <20061220170024.GA4735@1-4-5.net> 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: 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 Dave, Thanks for posting this. I would like to see more work in understanding both the growth that we are seeing, as well as the predicted capabilities of routers. With that in mind, I'm commenting some of the items that you mentioned you had not taken into account: > - The need for multiple copies of the RIB, VPN routes, > more specifics, other special purpose routes, > > - The advent of wildcards such as the widespread > deployment of IPv6, mobility and its interaction with > the routing system, etc. > I would like to see better models than we have seen so far about these parts. Anyone interested on working on this? I started working on some back-of-the-envelope calculations. The results are not so interesting at this stage, but I would be interested in talking about the the assumptions that would be needed for a model. For instance, my simple model used these assumptions: - IPv6 not turned on a single day, but rather grows gradually - Number of IPv6 prefixes will be smaller than in IPv4, for the same number of users, because of more flexible addressing architecture. - IPv4 keeps on growing until a certain day at which point all the growth is in IPv6 (even if we run out of Ipv4 addresses, we can split the current prefixes in smaller units... so the day is far in the future) - No upper bound on IPv6 growth - Internal/vpn/external RIBs all have to be in the same device (this may not be such a great assumption) - Mobility is not a significant source of this problem * But all of this could probably improved, and if I recall correctly the workshop and plenary assumptions were even simpler, such as turning on IPv6 immediately. Thoughts? Jari *) None of the large mobile network deployments that I see are based on reliance on the routing infrastructure for mobility purposes. There's a scale impact in adding a few billion new nodes, but I'm not sure this is qualitatively different from, say, DSL deployment. We also have Connexion-like designs that DO show up in the routing system. For that we need to find a solution, as everyone agrees that taken to a global extreme with a large number of vehicles this would be a problem. But this is network mobility, not the same thing as the large cellular network deployments, for instance. Also, we intend to re-charter the NEMO working group in the Internet area to look first into the requirements around this problem and then later also solutions. So I am relatively confident that we can do something about it. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 06:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxM1U-0003qi-M3; Thu, 21 Dec 2006 06:23:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxM1T-0003qY-Js for ram@iab.org; Thu, 21 Dec 2006 06:23:39 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxM1R-0008EI-57 for ram@iab.org; Thu, 21 Dec 2006 06:23:39 -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 kBLBNZUX036038 for ; Thu, 21 Dec 2006 11:23:35 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 kBLBNZ813203176 for ; Thu, 21 Dec 2006 12:23:35 +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 kBLBNZdg029562 for ; Thu, 21 Dec 2006 12:23:35 +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 kBLBNYm8029541; Thu, 21 Dec 2006 12:23:34 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA107292; Thu, 21 Dec 2006 12:23:33 +0100 Message-ID: <458A6EB6.5000006@zurich.ibm.com> Date: Thu, 21 Dec 2006 12:23:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fergie Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220.181529.8794.1737766@webmail03.lax.untd.com> In-Reply-To: <20061220.181529.8794.1737766@webmail03.lax.untd.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- "Chris L. Morrow" wrote: > > >>As a customer of some of the vendors I'd ask: "why do I not have that >>today? Why does it appear in testing that the 'latest' devices off the >>assembly line tip over dramatically at 500k or so routes?" Even setting >>this asside vendor engineers have said point-blank to our eng folks that >>there are serious problems scaling the current systems (hardware) and >>maintaining the current restrictions on convergence speed. >> >>I don't think that modeling the update rate increase/change over time has >>happened yet, and I don't think that modeling that against hardware >>capabilties has really happened either. So, I don't think that vendor >>folks are really in a position to express 'non-fear' about 10M routes in >>the table (and the associated churn rates that would come along with that >>increase). > > > I share your concern here -- although it certainly affects backbone > carriers more than it does leaf-node networks. A question I asked a while back, and didn't get answered, is whether anybody has a mathematical model of a hypothetical network with an assumed number of PI sites (say 10 million) and a representative topology of transit ISPs and core ISPs distributed across the continents? And can run BGP4 convergence simulations on this model for various assumed rates of access link outages, changes of transit ISP, and the like? If we can't model BGP dynamics at the scale we expect it to reach ten or twenty years from now, our grasp on the problem remains weak. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 09:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP5f-0000PL-0O; Thu, 21 Dec 2006 09:40:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxIiT-0005e6-VF for ram@iab.org; Thu, 21 Dec 2006 02:51:49 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxIiS-0003UQ-N0 for ram@iab.org; Thu, 21 Dec 2006 02:51:49 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id A1D522ACA5; Thu, 21 Dec 2006 07:51:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GxIhy-00071x-E0; Thu, 21 Dec 2006 02:51:18 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: Brian Carpenter Message-Id: Date: Thu, 21 Dec 2006 02:51:18 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Thu, 21 Dec 2006 09:40:09 -0500 Cc: Subject: [RAM] Re: Routing & Addressing -- activities (BOF) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ram@iab.org List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org 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. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 09:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP6C-0000aH-Ig; Thu, 21 Dec 2006 09:40:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO7C-0008CU-7w for ram@iab.org; Thu, 21 Dec 2006 08:37:43 -0500 Received: from mailsc21.usdoj.gov ([149.101.1.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxO7A-0000Dk-Vi for ram@iab.org; Thu, 21 Dec 2006 08:37:42 -0500 Received: from ems06.usdoj.gov ([10.222.4.39]) by mailsc21.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBLDbewE009616 for ; Thu, 21 Dec 2006 08:37:40 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems06.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBLDbdAn023973 for ; Thu, 21 Dec 2006 08:37:39 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id 5CE223803A1 for ; Thu, 21 Dec 2006 08:34:25 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id 5134A38032D for ; Thu, 21 Dec 2006 08:34:25 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Thu, 21 Dec 2006 08:37:36 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Thu, 21 Dec 2006 08:37:21 -0500 From: "Jeremy Hall" To: "Tony Li" , "Chris Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-21_04:2006-12-20, 2006-12-21, 2006-12-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612210016 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 21 Dec 2006 09:40:44 -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 Hi, I'm joining this a little late, but what other options do we have to routing based on ip-address? It may be a silly question, but what about routing based on origin as? It might be harder to control it, even harder to implement it given the current inconsistent announcements, and not practicle to implement, and would require a global flag day, all sound bad to me. Maybe I am too simplistic, but it seems to me you either have to change what you key on, increase memory/cpu/whatever to continue to use the existing ipv4 protocol for routing decisions, or come up with a totally new way of routing. But one thing I do believe is that this problem will not go away, people will not be willing to discard multihoming, and it will get more costly. So what about a hybrid solution between as-based and ipaddress-based routing? ip-address routing is preferred over regional-based routing, so that we split the world into domains and only hints to that domain are leaked into other domains. I tend to have some-what of a US-centric view myself, so I would be interested to hear from those who have more modern exposure to emea and asia routing practices. Is there a large desire to cross the continents? Would it be reasonable to entertain one or more of the following suggestions: 1: impose sprint-like rules on continent boundaries desiring /10s or larger? (I'm willing to negotiate up to /16) 2: form a consortium of "international" players that are willing to abide by common goals and interests, possibly sharing the international bandwidth as a single entity? I'm not *THAT* optimistic any of these ideas are new, but worth thinking about if for the moment it takes you to read this note. _J _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 09:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP5f-0000PL-0O; Thu, 21 Dec 2006 09:40:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxIiT-0005e6-VF for ram@iab.org; Thu, 21 Dec 2006 02:51:49 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxIiS-0003UQ-N0 for ram@iab.org; Thu, 21 Dec 2006 02:51:49 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id A1D522ACA5; Thu, 21 Dec 2006 07:51:18 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GxIhy-00071x-E0; Thu, 21 Dec 2006 02:51:18 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: Brian Carpenter Message-Id: Date: Thu, 21 Dec 2006 02:51:18 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Thu, 21 Dec 2006 09:40:09 -0500 Cc: Subject: [RAM] Re: Routing & Addressing -- activities (BOF) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ram@iab.org List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org 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. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 09:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxP6C-0000aH-Ig; Thu, 21 Dec 2006 09:40:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO7C-0008CU-7w for ram@iab.org; Thu, 21 Dec 2006 08:37:43 -0500 Received: from mailsc21.usdoj.gov ([149.101.1.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxO7A-0000Dk-Vi for ram@iab.org; Thu, 21 Dec 2006 08:37:42 -0500 Received: from ems06.usdoj.gov ([10.222.4.39]) by mailsc21.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBLDbewE009616 for ; Thu, 21 Dec 2006 08:37:40 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems06.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBLDbdAn023973 for ; Thu, 21 Dec 2006 08:37:39 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id 5CE223803A1 for ; Thu, 21 Dec 2006 08:34:25 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id 5134A38032D for ; Thu, 21 Dec 2006 08:34:25 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Thu, 21 Dec 2006 08:37:36 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Thu, 21 Dec 2006 08:37:21 -0500 From: "Jeremy Hall" To: "Tony Li" , "Chris Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-21_04:2006-12-20, 2006-12-21, 2006-12-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 spamscore=1 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612210016 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 21 Dec 2006 09:40:44 -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 Hi, I'm joining this a little late, but what other options do we have to routing based on ip-address? It may be a silly question, but what about routing based on origin as? It might be harder to control it, even harder to implement it given the current inconsistent announcements, and not practicle to implement, and would require a global flag day, all sound bad to me. Maybe I am too simplistic, but it seems to me you either have to change what you key on, increase memory/cpu/whatever to continue to use the existing ipv4 protocol for routing decisions, or come up with a totally new way of routing. But one thing I do believe is that this problem will not go away, people will not be willing to discard multihoming, and it will get more costly. So what about a hybrid solution between as-based and ipaddress-based routing? ip-address routing is preferred over regional-based routing, so that we split the world into domains and only hints to that domain are leaked into other domains. I tend to have some-what of a US-centric view myself, so I would be interested to hear from those who have more modern exposure to emea and asia routing practices. Is there a large desire to cross the continents? Would it be reasonable to entertain one or more of the following suggestions: 1: impose sprint-like rules on continent boundaries desiring /10s or larger? (I'm willing to negotiate up to /16) 2: form a consortium of "international" players that are willing to abide by common goals and interests, possibly sharing the international bandwidth as a single entity? I'm not *THAT* optimistic any of these ideas are new, but worth thinking about if for the moment it takes you to read this note. _J _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 09:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPJf-0000jV-Ez; Thu, 21 Dec 2006 09:54:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPJe-0000jF-8u for ram@iab.org; Thu, 21 Dec 2006 09:54:38 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPJb-0007Gg-RQ for ram@iab.org; Thu, 21 Dec 2006 09:54:38 -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 kBLEsW70008059; Thu, 21 Dec 2006 06:54:32 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLEsW3S008058; Thu, 21 Dec 2006 06:54:32 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 06:54:32 -0800 From: David Meyer To: "Chris L. Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221145432.GB7783@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <674D3434-399A-4499-9D99-8FE329B2C221@cisco.com> 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Content-Type: multipart/mixed; boundary="===============0908257243==" Errors-To: ram-bounces@iab.org --===============0908257243== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2006 at 02:08:27AM +0000, Chris L. Morrow wrote: >=20 >=20 > On Wed, 20 Dec 2006, Tony Li wrote: >=20 > > help at all in convergence. An Internet that does not converge does > > not do anyone any good. >=20 > this seems to be a very real fear, please don't lose track of the fact > that size of RIB/FIB is not the only problem, updates from RIB -> FIB are > also a problem... Yep. BTW, I've been told (I don't have examples) that there are architectures in which the RIB->FIB update rate, while a factor in convergence times, isn't the dominate factor.=20 > > On Dec 20, 2006, at 9:00 AM, David Meyer wrote: > > > > > The context here was that Leslie and I (and others) were > > > discussing the implications of the fact that vendors are > > > telling us that hardware that can hold RIB/FIBs of sizes > > > like 1 x 10^6 entries can be built today, and of sizes > > > like 1 x 10^7 in the 3-5 year time frame (I think the > > > term used was "not scared of 10M entry RIBs" or something > > > like that). We're hearing these kinds of numbers from > > > most vendors now. >=20 > As a customer of some of the vendors I'd ask: "why do I not have that > today? Why does it appear in testing that the 'latest' devices off the > assembly line tip over dramatically at 500k or so routes?" Even setting > this asside vendor engineers have said point-blank to our eng folks that > there are serious problems scaling the current systems (hardware) and > maintaining the current restrictions on convergence speed. >=20 > I don't think that modeling the update rate increase/change over time has > happened yet, and I don't think that modeling that against hardware > capabilties has really happened either. I've been surveying the research on "BGP UPDATE characterization" and haven't found a whole lot of work in this area. So our understanding of these dynamics is at best weak (my characterization). I'm speculating that this is in part because folks have been focused on properties of the Internet's AS graph, and the size of the DFZ RIB (so far).=20 That being said, IMO the time to study the dynamics of BGP UPDATEs seems to have come. We really need a better (both qualitative and quantitative) understanding of this. > So, I don't think that vendor folks are really in a position to > express 'non-fear' about 10M routes in the table (and the > associated churn rates that would come along with that increase). Don't shoot the messenger? :-) --dmm --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiqAoORgD1qCZ2KcRAvADAJ9kfL7il0d0tB+TFjHZYyeqvueV7ACggVrp 80PpzJZ8eIsJXAwveikFPBY= =nWdB -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- --===============0908257243== 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 --===============0908257243==-- From ram-bounces@iab.org Thu Dec 21 10:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPP5-0002oC-FP; Thu, 21 Dec 2006 10:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPP3-0002o7-RK for ram@iab.org; Thu, 21 Dec 2006 10:00:13 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPP1-0000Nw-1q for ram@iab.org; Thu, 21 Dec 2006 10:00: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 kBLF0AAQ008180; Thu, 21 Dec 2006 07:00:10 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLF06Vi008179; Thu, 21 Dec 2006 07:00:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 07:00:06 -0800 From: David Meyer To: Fergie Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221150006.GC7783@1-4-5.net> References: <20061220.181529.8794.1737766@webmail03.lax.untd.com> Mime-Version: 1.0 In-Reply-To: <20061220.181529.8794.1737766@webmail03.lax.untd.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: 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: , Content-Type: multipart/mixed; boundary="===============1041621118==" Errors-To: ram-bounces@iab.org --===============1041621118== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1ccMZA6j1vT5UqiK" Content-Disposition: inline --1ccMZA6j1vT5UqiK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2006 at 02:14:56AM +0000, Fergie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > - -- "Chris L. Morrow" wrote: >=20 > >As a customer of some of the vendors I'd ask: "why do I not have that > >today? Why does it appear in testing that the 'latest' devices off the > >assembly line tip over dramatically at 500k or so routes?" Even setting > >this asside vendor engineers have said point-blank to our eng folks that > >there are serious problems scaling the current systems (hardware) and > >maintaining the current restrictions on convergence speed. > > > >I don't think that modeling the update rate increase/change over time has > >happened yet, and I don't think that modeling that against hardware > >capabilties has really happened either. So, I don't think that vendor > >folks are really in a position to express 'non-fear' about 10M routes in > >the table (and the associated churn rates that would come along with that > >increase). >=20 > I share your concern here -- although it certainly affects backbone > carriers more than it does leaf-node networks. As I mentioned in my response to Chris, we need to start looking at the nature of the burstiness of UPDATEs. I think that kind of research will help inform both our operational and architecture/protocol design concerns. --dmm --1ccMZA6j1vT5UqiK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiqF2ORgD1qCZ2KcRAnAfAKCEBAsT3fYsEQ90wCSa/oNJx2zK3QCfdyPN YrdIdOW4m7lPiTbiMGpxPmA= =RQcL -----END PGP SIGNATURE----- --1ccMZA6j1vT5UqiK-- --===============1041621118== 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 --===============1041621118==-- From ram-bounces@iab.org Thu Dec 21 10:23:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPl6-0007sY-9I; Thu, 21 Dec 2006 10:23:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPl5-0007sR-1g for ram@iab.org; Thu, 21 Dec 2006 10:22:59 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPl3-0005NE-L0 for ram@iab.org; Thu, 21 Dec 2006 10:22:59 -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 kBLFMu9N008584; Thu, 21 Dec 2006 07:22:57 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLFMg6M008583; Thu, 21 Dec 2006 07:22:42 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 07:22:42 -0800 From: David Meyer To: "Schliesser, Benson" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221152242.GE7783@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: 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: , Content-Type: multipart/mixed; boundary="===============0833066090==" Errors-To: ram-bounces@iab.org --===============0833066090== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2006 at 09:00:38PM -0600, Schliesser, Benson wrote: >=20 > > From: Fergie [mailto:fergdawg@netzero.net]=20 > > [...] > > In other words, it would be nice to hear from the router what they > > are doing to meet the obvious future needs here. >=20 > I'll posit that the router vendors see competitive advantage in > capitalizing a solution to this problem and aren't inclined to share > openly. > (Though perhaps I am too cynical?) > Generally speaking, this is the sort of problem that's already been > solved in other domains.=20 Can you provide an example from another domain? That might be informative. > So, I'd expect to see some reasonable innovation in the router > space. That doesn't make me any less nervous, though, > especially nervous about the deployability/economics...=20 Sure, and to be direct: The size of the RIB/FIB also reflects the granularity of the information that the routing system is carrying. The finer-grained that information is, the more the core of the network will "see" the dynamics of the edges, which converts, more or less, to BGP UPDATE rates. So the size of the RIB (or FIB) is not independent of the dynamics of the network. That being said, my concern about the UPDATE dynamics stuff is that we don't know if there are non-linear effects in the system that have the potential to overwhelm *any* hardware solution. I don't know the answer to that, but I'll just note that if the 2.8 x 10^6 daily UPDATEs (that Geoff predicts by the end of 2010) arrive in a small number of bursts, well, that would be challenging. That is, how many UPDATEs/sec can we handle, with what kind of burstiness, and with what kind of prefix packing? Then trigger all of the other components of BGP convergence (i.e., FIB download, as Chris was mentioning). There's quite a bit that we don't understand in that equation. =20 =09 And BTW, if the UPDATE stream exhibits some kind of LRD (Long Range Dependence), and has a Hurst parameter (H) [0] that is something > 0.5 (0.0 <=3D H <=3D 1.0), then the burstiness of the UPDATE stream is "chaotic" (and in addition, there can be unattractive feedback effects), so we need to think carefully about that. But as I said above, our understanding of all of this is weak. I knew I'd figure out a way to work my favorite topic (complexity) into this discussion :-) --dmm [0] FWIW (and very briefly), the Hurst parameter (H) is a measure of the level self-similarity of a time series that exhibits some kind of LRD. --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiqbCORgD1qCZ2KcRAvYcAJ9+9YPmu/veIhsfOv8zCcpHc1a4/gCffVpG cBPDDfXqOutPRKp6kWaSSqQ= =NNQP -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- --===============0833066090== 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 --===============0833066090==-- From ram-bounces@iab.org Thu Dec 21 10:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPnP-0000JT-Lm; Thu, 21 Dec 2006 10:25:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPnO-0000Gl-2t for ram@iab.org; Thu, 21 Dec 2006 10:25:22 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxPnM-0005pP-KG for ram@iab.org; Thu, 21 Dec 2006 10:25:22 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 01E59898C7; Thu, 21 Dec 2006 17:25:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A9857898C5; Thu, 21 Dec 2006 17:25:18 +0200 (EET) Message-ID: <458AA75F.7040101@piuha.net> Date: Thu, 21 Dec 2006 17:25:19 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: vijay gill Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <458A1F7F.2020803@vijaygill.com> In-Reply-To: <458A1F7F.2020803@vijaygill.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: 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 Vijay, > Of course the vendors can build it, after all, it just results in > another upgrade cycle analogous to the gsr/jnx core upgrades in the > late 90s timeframe. The question is who all can afford to pay for > these? We from the operational side are getting strong pushback to > amortize routers over longer and longer periods from the finance folks. > > To be economically viable, we have to upgrade on a scale that lags the > vendor sales cycle. Right. One of the basic problems is that everything comes out of the same silicon & finance budget. For instance, we need to simultaneously handle line rate growth, new functions, routing, etc. If you spend everything your silicon engineers can create on new features, line rate and routing have no room to increase. The other side of the same issue is that there may be other reasons why you must go into an upgrade cycle, such as line rate increases. Are you saying that the routing part is what is currently driving the upgrade cycle, or in danger of becoming the driver? Or are you saying that finances are pushing the upgrade cycles to be longer, and the first thing we will hit is the routing capability? In any case, I think we all would like to get routing to scale better. Why this discussion is still important is attempting to determine where the worst pain is (e.g., size vs. updates) as that will help us think what to look for in solutions. Also, the seriousness of the problem determines how much pain the Internet community is willing to take in terms the side effects of a solution. E.g., its typically very easy to create something that runs between consenting adults, but it would be harder to create something that removes pain from one point but also adds some pain in another point (such as the DNS or the host). --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 10:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ8e-0006CE-8a; Thu, 21 Dec 2006 10:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ8d-0006C9-EZ for ram@iab.org; Thu, 21 Dec 2006 10:47:19 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQ8b-0001cV-Vd for ram@iab.org; Thu, 21 Dec 2006 10:47: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 kBLFkp6C010210; Thu, 21 Dec 2006 07:46:51 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLFkpUU010209; Thu, 21 Dec 2006 07:46:51 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 07:46:51 -0800 From: David Meyer To: Jari Arkko Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221154650.GA9598@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> Mime-Version: 1.0 In-Reply-To: <458A669E.10404@piuha.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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="===============0931090917==" Errors-To: ram-bounces@iab.org --===============0931090917== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jari, > Thanks for posting this. I would like to see My pleasure (I think :-). > more work in understanding both the > growth that we are seeing, as well as > the predicted capabilities of routers. > With that in mind, I'm commenting some > of the items that you mentioned you > had not taken into account: > > - The need for multiple copies of the RIB, VPN routes, > > more specifics, other special purpose routes,=20 > > > > - The advent of wildcards such as the widespread > > deployment of IPv6, mobility and its interaction with > > the routing system, etc. > > =20 > I would like to see better models than we have seen > so far about these parts. Anyone interested on working > on this? Obviously I am :) > I started working on some back-of-the-envelope > calculations. The results are not so interesting at this > stage, but I would be interested in talking about the > the assumptions that would be needed for a model. > For instance, my simple model used these assumptions: >=20 > - IPv6 not turned on a single day, but rather grows gradually Not turned on a single day would seem a reasonable assumption (clearly). However, "grows gradually" is an interesting assumption. I could see this go either way. If all of a sudden every mobile handset has IPv6 and HIP burned into it, is that "gradual"? What about Microsoft's bet with Vista? >=20 > - Number of IPv6 prefixes will be smaller than in IPv4, for the > same number of users, because of more flexible addressing > architecture. I don't think you can support that. In fact, recent RIR policy argues against this assertion. > - IPv4 keeps on growing until a certain day at which point > all the growth is in IPv6 (even if we run out of Ipv4 addresses, > we can split the current prefixes in smaller units... so the > day is far in the future) I agree that the growth in IPv4 RIBs is bounded by some O(m*2^32), a description of the meshiness of the Internet, and IPv4 FIBs are bounded by something like O(2^32). The corresponding update streams have no such bounds. So in that sense, if we got to /32 everything in v4, it would stop growing.=20 Regarding all the growth being in IPv6, that is a loaded assumption. What happenes if there is *no* v6 deployment, but rather we see an (further) explosion of NAT (or similar technology)? All that being said, the assumption is ok for purposes of modeling. > - No upper bound on IPv6 growth Meaning? No upper bound on the growth of the RIB? Well, that would seem to be O(m*2^128). > - Internal/vpn/external RIBs all have to be in the same device > (this may not be such a great assumption) Not sure about this one. > - Mobility is not a significant source of this problem * Huh? Its one of the 3Ms (Multihoming, Mobility, and Migration (to v6)). Regarding the note below (*), we do need to understand how these technogies (i.e., HIP, SHIM6, etc) interact with the routing system. > But all of this could probably improved, and if I recall > correctly the workshop and plenary assumptions were > even simpler, such as turning on IPv6 immediately. >=20 > Thoughts? How would you suggest moving forward with the modeling exercise? --dmm >=20 > Jari >=20 > *) None of the large mobile network deployments that > I see are based on reliance on the routing infrastructure > for mobility purposes. There's a scale impact in adding > a few billion new nodes, but I'm not sure this is qualitatively > different from, say, DSL deployment. We also have > Connexion-like designs that DO show up in the routing > system. For that we need to find a solution, as everyone > agrees that taken to a global extreme with a large number > of vehicles this would be a problem. But this is network > mobility, not the same thing as the large cellular network > deployments, for instance. Also, we intend to re-charter > the NEMO working group in the Internet area to look > first into the requirements around this problem and then > later also solutions. So I am relatively confident that > we can do something about it. --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiqxqORgD1qCZ2KcRAtskAJ9VaWCL8rOYdz3wtRALupg4zJDxSwCcCI1h huleT7sE56eaFXHy7ttzpuQ= =Qxax -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============0931090917== 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 --===============0931090917==-- From ram-bounces@iab.org Thu Dec 21 10:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQGM-0000CF-Gz; Thu, 21 Dec 2006 10:55:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQGL-0000C8-Dn for ram@iab.org; Thu, 21 Dec 2006 10:55:17 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQGK-00035H-1p for ram@iab.org; Thu, 21 Dec 2006 10:55:17 -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 kBLFstPo010535; Thu, 21 Dec 2006 07:54:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLFsl3r010534; Thu, 21 Dec 2006 07:54:47 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 07:54:47 -0800 From: David Meyer To: Fergie Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221155447.GA10515@1-4-5.net> References: <20061220.191049.8794.1738242@webmail03.lax.untd.com> Mime-Version: 1.0 In-Reply-To: <20061220.191049.8794.1738242@webmail03.lax.untd.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: 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: , Content-Type: multipart/mixed; boundary="===============0699533543==" Errors-To: ram-bounces@iab.org --===============0699533543== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable BTW, this from the agenda announcement for the upcoming NANOG (this in the BOFs section): =20 Pushing the FIB limits, perspectives on pressures confronting modern routers. - Joel Jaeggli =20 -dmm --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiq5HORgD1qCZ2KcRAmA6AJ4vTNbKMQsFS3fIxCI0resU+kt6xwCgkpIY MdllGk4JGkez0hpFVpzYW7E= =ukwv -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- --===============0699533543== 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 --===============0699533543==-- From ram-bounces@iab.org Thu Dec 21 11:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQvR-0006q7-HU; Thu, 21 Dec 2006 11:37:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQvQ-0006pw-DR; Thu, 21 Dec 2006 11:37:44 -0500 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQvP-0001Xd-2K; Thu, 21 Dec 2006 11:37:44 -0500 Received: from HeinerHummel@aol.com by imo-d03.mx.aol.com (mail_out_v38_r7.6.) id n.c80.9c014ef (14502); Thu, 21 Dec 2006 11:37:35 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 21 Dec 2006 11:37:32 EST Subject: Re: [RAM] Re: Routing & Addressing -- activities (BOF) To: ram@iab.org, ietf-announce@ietf.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: 2e8fc473f5174be667965460bd5288ba 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="===============0350536062==" Errors-To: ram-bounces@iab.org --===============0350536062== Content-Type: multipart/alternative; boundary="-----------------------------1166719052" -------------------------------1166719052 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 The first goal is accomplished:The discussion has finally moved to the =20 RAM-list. There are still some skirmish battles in hope of better hardware and as to=20 keep on going with current internet-1. =20 However with a hierarchical model (instead of flat BGP and respective =20 orthogonal OSPF) not only whatever growth rate of the internet may be compli= ed with=20 but also qualitative improvements may come along: multipath routing, =20 multi-topology, multipath routing combined with multi-topology, yes inter-d= omain.=20 Enhanced routing capabilities which makes the current loop-control by primi= tive=20 TTL obsolete.Enhanced traffic engineering! Even graceful restart mechanism=20 may benefit! And of course, the routing churn will be well restricted (why= =20 should I care in Europe when a router tips over in Japan). =20 I like the idea of Rekhter's Law"): "Addressing can follow topology or =20 topology can follow addressing. Choose one." Yes indeed:You can point to so= me=20 shopping mall at some specific road junction and add, just like attributes,=20= which=20 stores of which companies (ISPs!) you may find there. As well, you may poin= t=20 to individual stores and add, just like an attribute, that it is located at= =20 said road junction's shopping mall. Yes both will work, just choose which =20 information shall become the the primary naming and which the secondary =20 attribute. But nevertheless make the better choice: Finding a destination is= not the=20 only goal. Filtering may be another valuable capability. It is is not about= =20 right or wrong, but which way to go is more or less advantageous.=20 =20 Heiner=20 =20 In einer eMail vom 21.12.2006 15:40:49 Westeurop=E4ische Normalzeit schreibt= =20 brc@zurich.ibm.com: 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 =20 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=20 Ross and Mark will be collecting proposals for the goals and content of the BOF. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -------------------------------1166719052 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
The first goal is accomplished:The discussion has finally moved to the=20 RAM-list.
There are still some skirmish battles in hope of better hardware a= nd=20 as to keep on going with  current internet-1.
 
However with a hierarchical model (instead of flat BGP and respective=20 orthogonal OSPF) not only whatever growth rate of the internet may be compli= ed=20 with but also qualitative improvements may come along: multipath routing,=20 multi-topology, multipath routing combined with multi-topology, yes=20 inter-domain. Enhanced routing capabilities which makes the current loop-con= trol=20 by primitive TTL obsolete.Enhanced traffic engineering! Even graceful=20 restart mechanism may benefit! And of course, the  routing churn will b= e=20 well restricted (why should I care in Europe when a router tips over in=20 Japan).
 
I like the idea of Rekhter's Law"): "Addressing can follow topology or=20 topology can follow addressing. Choose one." Yes indeed:You can point t= o=20 some shopping mall at some specific road junction and add, just like attribu= tes,=20 which stores of which companies (ISPs!) you may find there. As well, you may= =20 point to individual stores and add, just like an attribute, that it is locat= ed=20 at said road junction's shopping mall. Yes both will work, just choose which= =20 information shall become the the primary naming and which the secondary=20 attribute. But nevertheless make the better choice: Finding a destination is= not=20 the only goal. Filtering may be another valuable capability. It is is n= ot=20 about right or wrong, but which way to go is more or less=20 advantageous. 
 
Heiner
 
In einer eMail vom 21.12.2006 15:40:49 Westeurop=E4ische Normalzeit sch= reibt=20 brc@zurich.ibm.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>As part=20 of the routing and addressing activities, a BOF is planned
during IETF=20= 68,=20 as a plenary activity (day and time to be
announced later). This will b= e=20 tracked in the BOF wiki at=20
http://www1.tools.ietf.org/bof/trac/wiki

Details so=20 far:

   * ROAP
          o=20 ROuting and Addressing Problem BOF
          o= =20 Joint with Internet Area; will be a plenary session
     = ;=20     o Status: preliminary discussions
      &n= bsp;=20   o Background: RAWS report
          o=20 Responsible ADs: Ross Callon, Mark Townsley

Ross and Mark will be=20 collecting proposals for the goals
and content of the=20 BOF.

_______________________________________________
RAM mailing= =20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1166719052-- --===============0350536062== 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 --===============0350536062==-- From ram-bounces@iab.org Thu Dec 21 12:16:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRVx-00035b-JH; Thu, 21 Dec 2006 12:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRVw-00031t-Cz for ram@iab.org; Thu, 21 Dec 2006 12:15:28 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRVt-0005vl-QZ for ram@iab.org; Thu, 21 Dec 2006 12:15:28 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 32D33898C5; Thu, 21 Dec 2006 19:15:24 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D8F68898C4; Thu, 21 Dec 2006 19:15:23 +0200 (EET) Message-ID: <458AC12C.6040901@piuha.net> Date: Thu, 21 Dec 2006 19:15:24 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> In-Reply-To: <20061221154650.GA9598@1-4-5.net> 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: b132cb3ed2d4be2017585bf6859e1ede 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 seems that my plan of posting bad assumptions in an effort to get you figure out the right ones worked... ;-) Inline: > > Not turned on a single day would seem a reasonable > assumption (clearly). However, "grows gradually" is an > interesting assumption. I could see this go either > way. If all of a sudden every mobile handset has IPv6 and > HIP burned into it, is that "gradual"? What about > Microsoft's bet with Vista? > Right. Its hard to estimate this, of course. But there are a number of factors to consider. For instance, as long as the hosts aren't getting native IPv6 from their ISP, I'm not sure the global routing table is affected by hosts that have IPv6 but don't use it or use it via a tunnel. In any case, even a new mobile network or a popular OS version takes some time to actually be deployed and used. What I did in my model was to set a fairly aggressive IPv6 growth, in my case assuming 10% of the network would turn to IPv6 each year, i.e., take 10 years for full IPv6 deployment. We could talk about whether this covers the sudden events. But is certainly much more aggressive than we are seeing today. >> - Number of IPv6 prefixes will be smaller than in IPv4, for the >> same number of users, because of more flexible addressing >> architecture. >> > > I don't think you can support that. In fact, recent RIR > policy argues against this assertion. > Ok. Can you point to the policy that you were thinking of? >> - IPv4 keeps on growing until a certain day at which point >> all the growth is in IPv6 (even if we run out of Ipv4 addresses, >> we can split the current prefixes in smaller units... so the >> day is far in the future) >> > > I agree that the growth in IPv4 RIBs is bounded by some > O(m*2^32), a description of the meshiness of the > Internet, and IPv4 FIBs are bounded by something like > O(2^32). The corresponding update streams have no such > bounds. So in that sense, if we got to /32 everything in > v4, it would stop growing. > Right. > Regarding all the growth being in IPv6, that is a loaded > assumption. What happenes if there is *no* v6 deployment, > but rather we see an (further) explosion of NAT (or > similar technology)? > Indeed, that's also a possible future. I guess we want to see the worst scenario (within reasonable bounds) from the point of view of routing. To me that's the ability for people to get as much address space as they like. If it turns that we continue on the NAT path... I guess we would see somewhat less entries in the table. There would still be growth in the table, as the IPv4 space gets broken in smaller pieces. I don't have a good idea how to model this, do you? Or perhaps we don't need to. > All that being said, the assumption is ok for purposes of > modeling. > > >> - No upper bound on IPv6 growth >> > > Meaning? No upper bound on the growth of the RIB? Well, > that would seem to be O(m*2^128). > Right. Of course from our router construction point of view the crucial question is whether _speed_ of the allocation exceeds the speed of hardware improvement and whether the improvement stops at some future time. (Such as running out of steam on Moore's Law, as has been often predicted.) >> - Mobility is not a significant source of this problem * >> > > Huh? Its one of the 3Ms (Multihoming, Mobility, and > Migration (to v6)). I think we can account for multihoming and provider independence based on the projected growth in the prefixes. The open question is whether the currently seen growth will change somehow, e.g., because more people will suddenly need provider independence. What's our best estimate for this now? Migration to Ipv6 is handled as long as we count both Ipv4 and Ipv6 routes for the same users. But what I was saying was that I do not see any evidence of mobility suddenly changing the allocation or update rates, except for the network mobility part. But as I explained that it at least for now a very small part of the entire mobile market, and we might be able to find solutions for that. > Regarding the note below (*), we do > need to understand how these technogies (i.e., HIP, > SHIM6, etc) interact with the routing system. > The mobility mechanisms for current and all planned mobile networks that I know of do not interact with the routing system. They use mechanisms that hide the mobility either from the Internet or even the host itself. > How would you suggest moving forward with the modeling > exercise? > Talking some more about the assumptions and growth predictions on this list would be useful. At some point the discussion needs to be turned into papers that have the full picture and which can be reviewed by others in the IETF and outside. And of course, if you can point us to existing work that would be great too. --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 12:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRif-0000b2-1E; Thu, 21 Dec 2006 12:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRie-0000ax-BK for ram@iab.org; Thu, 21 Dec 2006 12:28:36 -0500 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRid-000870-Ha for ram@iab.org; Thu, 21 Dec 2006 12:28:36 -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.43) id 1GxRiT-00038n-WF; Thu, 21 Dec 2006 17:28:26 +0000 Message-ID: <458AC45C.5030001@dial.pipex.com> Date: Thu, 21 Dec 2006 17:29:00 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [RAM] Traffic engineering and the network model X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org A while back Pekka Nikander wrote: > Noel Chiappa wrote: >> When I look at what the problem seems to be ..., it seems to be >> growth in the size of the routing table (with dynamics of routing >> table entries coming in second). The two main drivers of growth seem >> to be i) multi-homing, and ii) general entropy and lack of >> aggregation. Is this correct? > > I've been told that traffic engineering is another major factor. > However, I have to admit not understanding what people mean with it. > (A good reference would help.) Networks use traffic engineering to maximise the utility (in the economic sense) of their network assets. To do this they have to limit the accepted portion of the offered traffic and direct the accepted traffic towards its intended destination subject to a number of constraints, especially: - Capacity and availability of plant (routers, links etc) - Policies (business, regulatory, political, etc.) - Contractual (customer SLAs, transit agreements, etc) It was clear from the IAB Routing and Addressing workshop, and also from other discussions which I have had, that traffic engineering is very important to network operators and some of the ways in which it is done utilize the capabilities of the routing system (deliberate deaggregation of prefixes in particular) so that it contributes significantly to the growth of the core routing tables. Traffic engineering only becomes 'interesting' if there are multiple, comparably effective paths between many pairs of points in the network: traffic engineering on a simple network where there is exactly one path between a pair of (end-)points degenerates into limiting the accepted traffic to the capacity of bottleneck link - the classical model for which TCP is optimized! The core network today is increasingly 'meshy' for economic and robustness reasons, and the desirable but inexorable growth of traffic means that link capacity is increasingly well- or over-used. Accordingly traffic engineering is an essential tool for network owners and operators. Observation 1: Multihoming is a form of traffic engineering. On the architecture discussion list there was some limited amount of thought about the model we use for the network in the core. I would like to take this a bit further and see how the network model fits with the classical and current reality, and how it interacts with multihoming/traffic engineering. Application View: ================= Seen from the point of view of an application running on a node, the network *internet* layer provides, at its most abstract: - a path for packets from 'here-to-anywhere' which is not necessarily reliable - unconstrained capacity for delivery of packets There are no assumptions about how the network implements the path and there are no assumptions about constraints on the size of the path. In particular - there is no assumption about uniqueness of path (in time or topology) - there is no specific guarantee of ordered delivery Aside: At this level, the distinction between a 'user' application running on an end-point and the 'routing application' running at intermediate points is that the user application expects symmetric 'anywhere-to-here' connectivity whereas the routing application doesn't. Interestingly, the transport layer may make additional assumptions about and requirements on the internet layer that are not specifically provided by the classical model of the internet layer: - the transport layer (e.g., TCP) may assume that the network is of limited capacity - the transport layer may make relatively strong assumptions about ordered delivery The constraints applied by the transport layer reflect the classical model of Internet routing where there was a unique best path which had a bottleneck segment that might change relatively slowly with time, but would generally be stable during the lifetime of most application flows. The development of the modern Internet with multihoming and traffic engineering across multiple equally capable paths appears to be well matched to the basic assumptions (no assumption of unique path, unconstrained capacity) on the internet layer but struggles to meet the constraints applied by the transport layer. Routing View ============ The routing system in the classical model: - assumes there is a single best path from here-to-anywhere at any given time - does not worry about capacity constraints Adapting the routing system to the newer model and the real world has required a number of hacks such as the TE extensions (constraining the single best path due to capacity limits) and ECMP allowing some utilization of multiple parallel paths. Overall this has not been very satisfactory and it is certainly not an architecturally pure solution. Moreover the distribution of traffic across multiple paths by ECMP typically relies on hashing the whole of the destination and maybe the source addresses and other info in the packet to ensure that the transport layer constraints on ordering are met. In many cases this splitting is very fine grained and relies on using more information than is required for routing. This may limit our ability to do information hiding in the routing system. The deliberate disaggregation of prefixes is a response to the need to force the routing system to distribute traffic over multiple paths leading to the same destination where the specific tools are inadequate. So what... ========== Observation 2: The routing system today is not a very good match for the reality of the network model today. This is partly caused by a mismatch between the assumptions at the internet layer and the transport layer, and partly by the development of meshy networks. In today's meshy network, it is not just multihomed end sites that see multiple useful routes from here-to-anywhere. Many routers in the core network could, if the routing system allowed it, also see multiple useful routes. I would therefore claim that traffic engineering and multihoming contain a common problem that does not just manifest itself at the edge of the network. Observation 3: A good solution to the routing (scalability) problem needs to embrace the availability of (and need to use) multiple routes between both edge and interior points in the network. The id/locator split solution which we have been looking at attempts to hide this situation at one particular locus in the network (somewhere between the end host and the first provider edge), rather than solving it generally. It would presumably leave the traffic engineering problem in the core using the existing routing based techniques. In essence, unlike today's network, where the internet layer uses reasonably uniform routing techniques throughout and crafts traffic engineering/multihoming solutions from the same tools everywhere, the network would be partitioned, with the edge and core using different techniques to achieve the required traffic engineering. Observation 4: Adopting multiple different solutions to the multihoming/traffic enginering problems at different places in the network is likely to lead to interactions between the solutions. One area of interaction that I can see is the need to extract information from inner headers in core routers to correctly execute ECMP and other classification schemes if a form of encapsulation is used. This will increase the processing and memory bandwidth burden on core routers, particularly during the transition. Observation 5: Disguising a problem rather than solving it will likely lead to needing a more complex solution in the future. There is a significant risk that network growth and increases in core connectivity will lead to the routing table size problem reasserting itself due to the use of complex traffic engineering. The problem would thus be postponed rather than solved, and the result might be the need to combine solutions rather than using a common one. Conclusion: =========== Whilst it is highly likely that the id/loc split is a good idea, we shouldn't assume that it is a panacea for the multiple path problem. A uniform routing solution which manages the existence of multiple paths may well constrain the growth of the routing tables better than multiple partial solutions and provide a solution to the multihoming aspects of the core and edge problems. In the longer term we need to look at the assumptions of the network model we are using and determine if we can modify them to make the multiple path problem more tractable. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 12:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRw5-0007uJ-QS; Thu, 21 Dec 2006 12:42:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRw4-0007t6-IX for ram@iab.org; Thu, 21 Dec 2006 12:42:28 -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 1GxRw2-0001sj-9L for ram@iab.org; Thu, 21 Dec 2006 12:42:28 -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 kBLHXT413563; Thu, 21 Dec 2006 12:33:29 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id MAA23889; Thu, 21 Dec 2006 12:45:46 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Thu, 21 Dec 2006 12:45:46 -0500 (EST) From: Ted Seely X-X-Sender: To: Fergie Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-Reply-To: <20061220.181529.8794.1737766@webmail03.lax.untd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 21 Dec 2006, Fergie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- "Chris L. Morrow" wrote: > > >As a customer of some of the vendors I'd ask: "why do I not have that > >today? Why does it appear in testing that the 'latest' devices off the > >assembly line tip over dramatically at 500k or so routes?" Even setting > >this asside vendor engineers have said point-blank to our eng folks that > >there are serious problems scaling the current systems (hardware) and > >maintaining the current restrictions on convergence speed. > > > >I don't think that modeling the update rate increase/change over time has > >happened yet, and I don't think that modeling that against hardware > >capabilties has really happened either. So, I don't think that vendor > >folks are really in a position to express 'non-fear' about 10M routes in > >the table (and the associated churn rates that would come along with that > >increase). > > I share your concern here -- although it certainly affects backbone > carriers more than it does leaf-node networks. > > I find it curious, however, that with the plethora of router vendors > participating in the IETF process(es), none of them seem to be > forthcoming on this concern. > > In other words, it would be nice to hear from the router what they > are doing to meet the obvious future needs here. It all depends who you ask at the repective vendors. Some folks will tell you there is no problem, others will acknowledge that there is one, but nobody is sure how to address solving it yet. I guess thats what this list is for huh? :) -ted > > Cheers, > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.2 (Build 4075) > > wj8DBQFFie4Xq1pz9mNUZTMRAqIVAKCBSnuR6YUYjwESaC04UN1HUkuM9QCgiwQk > 6nLrXR5Af7vIsyVLPdFXAkE= > =EA/A > -----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 > Ted Seely Principal Network Design Engineer Internet Engineering - SprintLink (W) 703.689.6425 (M) 703.967.3289 AIM - wanpro00 Yahoo IM - tseely01 "can be maintained, upgraded, enhanced, and scaled without requiring service interruption" _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 12:54:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxS7l-00078c-N7; Thu, 21 Dec 2006 12:54:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxS7k-00078W-LA for ram@iab.org; Thu, 21 Dec 2006 12:54:32 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxS7j-0003oS-1C for ram@iab.org; Thu, 21 Dec 2006 12:54:32 -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 kBLHsSRB014205; Thu, 21 Dec 2006 09:54:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLHsOd7014204; Thu, 21 Dec 2006 09:54:24 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 09:54:24 -0800 From: David Meyer To: Jari Arkko Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221175424.GA14066@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> Mime-Version: 1.0 In-Reply-To: <458AC12C.6040901@piuha.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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="===============0736155391==" Errors-To: ram-bounces@iab.org --===============0736155391== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2006 at 07:15:24PM +0200, Jari Arkko wrote: > It seems that my plan of posting bad assumptions > in an effort to get you figure out the right ones > worked... ;-) :-) > > > > Not turned on a single day would seem a reasonable > > assumption (clearly). However, "grows gradually" is an > > interesting assumption. I could see this go either > > way. If all of a sudden every mobile handset has IPv6 and > > HIP burned into it, is that "gradual"? What about > > Microsoft's bet with Vista? > > =20 > Right. Its hard to estimate this, of course. But there > are a number of factors to consider. For instance, as > long as the hosts aren't getting native IPv6 from their > ISP, I'm not sure the global routing table is affected > by hosts that have IPv6 but don't use it or use it via > a tunnel. So this is the "IPv6 deployment stalls" argument? =20 > In any case, even a new mobile network or a popular > OS version takes some time to actually be deployed > and used. What I did in my model was to set a fairly > aggressive IPv6 growth, in my case assuming 10% > of the network would turn to IPv6 each year, i.e., > take 10 years for full IPv6 deployment. We could > talk about whether this covers the sudden events. > But is certainly much more aggressive than we are > seeing today. Ok, its certainly worth looking at.=20 > >> - Number of IPv6 prefixes will be smaller than in IPv4, for the > >> same number of users, because of more flexible addressing > >> architecture. > >> =20 > > > > I don't think you can support that. In fact, recent RIR > > policy argues against this assertion. > > =20 > Ok. Can you point to the policy that you were thinking of? http://www.arin.net/policy/proposals/2005_1.html (for example) > >> - IPv4 keeps on growing until a certain day at which point > >> all the growth is in IPv6 (even if we run out of Ipv4 addresses, > >> we can split the current prefixes in smaller units... so the > >> day is far in the future) > >> =20 > > > > I agree that the growth in IPv4 RIBs is bounded by some > > O(m*2^32), a description of the meshiness of the > > Internet, and IPv4 FIBs are bounded by something like > > O(2^32). The corresponding update streams have no such > > bounds. So in that sense, if we got to /32 everything in > > v4, it would stop growing.=20 > > =20 > Right. mod whatever dm/dt turns out to be, where dm/dt is (my notation for) the rate of change of the interconnection meshiness. =20 > > Regarding all the growth being in IPv6, that is a loaded > > assumption. What happenes if there is *no* v6 deployment, > > but rather we see an (further) explosion of NAT (or > > similar technology)? > > =20 > Indeed, that's also a possible future. I guess we want to > see the worst scenario (within reasonable bounds) > from the point of view of routing. To me that's the ability > for people to get as much address space as they like. > If it turns that we continue on the NAT path... I guess > we would see somewhat less entries in the table. There > would still be growth in the table, as the IPv4 space > gets broken in smaller pieces. I don't have a good idea > how to model this, do you? Or perhaps we don't need to. I'm not sure we need to either. > > All that being said, the assumption is ok for purposes of > > modeling. > > > > =20 > >> - No upper bound on IPv6 growth > >> =20 > > > > Meaning? No upper bound on the growth of the RIB? Well, > > that would seem to be O(m*2^128). > > =20 > Right. Of course from our router construction point of > view the crucial question is whether _speed_ of the > allocation exceeds the speed of hardware improvement > and whether the improvement stops at some future > time. (Such as running out of steam on Moore's Law, as > has been often predicted.) > > >> - Mobility is not a significant source of this problem * > >> =20 > > > > Huh? Its one of the 3Ms (Multihoming, Mobility, and > > Migration (to v6)). > I think we can account for multihoming and provider independence based > on the projected growth in the prefixes. The open question is whether > the currently seen growth will change somehow, e.g., because more > people will suddenly need provider independence. What's our best > estimate for this now? Perhaphs Geoff's current work (the ATNAC2006 paper I've been citing)? Another issue (re: mobility) is the effect the larger effect of the impact of say, HIP, on the routing system. > Migration to Ipv6 is handled as long as we count > both Ipv4 and Ipv6 routes for the same users. Can you say a few more words about this? I'm not sure what you meant. > But what I was saying was that I do not see any evidence of > mobility suddenly changing the allocation or update rates, > except for the network mobility part. But as I explained > that it at least for now a very small part of the entire mobile > market, and we might be able to find solutions for that. Sure. > > Regarding the note below (*), we do > > need to understand how these technogies (i.e., HIP, > > SHIM6, etc) interact with the routing system. > > =20 > The mobility mechanisms for current and all planned mobile > networks that I know of do not interact with the routing > system.=20 Right, which many folks think is a problem. So there will likely be some pressure to have the routing system become more "aware" of all of this. That is where the concern is, and where some good thinking will be required. > They use mechanisms that hide the mobility > either from the Internet or even the host itself. Sure, see my previous comment. > > How would you suggest moving forward with the modeling > > exercise? > > =20 > Talking some more about the assumptions and growth > predictions on this list would be useful. At some point > the discussion needs to be turned into papers that > have the full picture and which can be reviewed by others > in the IETF and outside. And of course, if you can point > us to existing work that would be great too. Sure. Have you read Geoff's stuff yet? --dmm --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFispQORgD1qCZ2KcRAiFFAJ47ug51EaIWOwT3zSXs8jop/NDdmQCbBbX5 jLBQfB1mOxj3BoALiv/7EkM= =+lAI -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- --===============0736155391== 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 --===============0736155391==-- From ram-bounces@iab.org Thu Dec 21 13:12:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSOu-0000wF-L9; Thu, 21 Dec 2006 13:12:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSOt-0000w7-61 for ram@iab.org; Thu, 21 Dec 2006 13:12:15 -0500 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSOm-0006kR-UF for ram@iab.org; Thu, 21 Dec 2006 13:12:15 -0500 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JAM00A7NYK465@firewall.mci.com> for ram@iab.org; Thu, 21 Dec 2006 18:12:04 +0000 (GMT) Received: from dgismtp05.wcomnet.com ([127.0.0.1]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JAM00J0BYK35Z@dgismtp05.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 18:12:03 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JAM00HBCYK3BA@dgismtp05.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 18:12:03 +0000 (GMT) Date: Thu, 21 Dec 2006 18:12:03 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-reply-to: <458AC12C.6040901@piuha.net> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Jari Arkko Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> 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 Thu, 21 Dec 2006, Jari Arkko wrote: > The mobility mechanisms for current and all planned mobile > networks that I know of do not interact with the routing > system. They use mechanisms that hide the mobility > either from the Internet or even the host itself. it'd sure be nice to fix that wouldn't it? remove some of the complexity, let the host just migrate gracefully from attachment point to attachment point... _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 13:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSc1-0008Id-Hg; Thu, 21 Dec 2006 13:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSbz-0008I3-Eq for ram@iab.org; Thu, 21 Dec 2006 13:25:47 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSbx-0000Qu-4s for ram@iab.org; Thu, 21 Dec 2006 13:25:47 -0500 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JAM00LLAZ6RVI@firewall.mci.com> for ram@iab.org; Thu, 21 Dec 2006 18:25:39 +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 <0JAM006TDZ6RZC@dgismtp02.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 18:25:39 +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 <0JAM0072HZ6QPL@dgismtp02.mcilink.com> for ram@iab.org; Thu, 21 Dec 2006 18:25:39 +0000 (GMT) Date: Thu, 21 Dec 2006 18:25:38 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Jeremy Hall Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: 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 Thu, 21 Dec 2006, Jeremy Hall wrote: > That is kindda what I meant by as-routing. yup, this gets back to the possible solution (which for now I think we can't really talk about until we know there is a problem, or have written down that there is a problem and everyone or 'most everyone' agrees to that problem.) of loc/id split. I believe Dino was working toward some code that maybe looks like tunnel endpoints inside AS's with a way to find the tunnel that and endpoint is behind. Certainly one way to think about that is: "as routing", another might be 'giant nat', still another seems a lot like 'interprovider mpls'. but, we should really agree on a problem first :) > > >>> "Chris L. Morrow" 12/21/06 > 1:12 PM >>> > > On Thu, 21 Dec 2006, Jari Arkko wrote: > > > The mobility mechanisms for current and all planned mobile > > networks that I know of do not interact with the routing > > system. They use mechanisms that hide the mobility > > either from the Internet or even the host itself. > > it'd sure be nice to fix that wouldn't it? remove some of the > complexity, > let the host just migrate gracefully from attachment point to > attachment > point... > > > > _______________________________________________ > 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 Dec 21 13:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSfR-0002o9-6x; Thu, 21 Dec 2006 13:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSZA-0004UR-KH for ram@iab.org; Thu, 21 Dec 2006 13:22:52 -0500 Received: from mailsc23.usdoj.gov ([149.101.1.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSZ8-0008TM-VX for ram@iab.org; Thu, 21 Dec 2006 13:22:52 -0500 Received: from ems04.usdoj.gov ([10.222.4.48]) by mailsc23.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBLIMoVh009599 for ; Thu, 21 Dec 2006 13:22:50 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems04.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBLIMnZU016267 for ; Thu, 21 Dec 2006 13:22:49 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id B4E16380973 for ; Thu, 21 Dec 2006 13:19:34 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id A9466380871 for ; Thu, 21 Dec 2006 13:19:34 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Thu, 21 Dec 2006 13:22:44 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Thu, 21 Dec 2006 13:22:19 -0500 From: "Jeremy Hall" To: "Jari Arkko" , "Chris Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-21_10:2006-12-21, 2006-12-21, 2006-12-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612210027 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Thu, 21 Dec 2006 13:29:19 -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 That is kindda what I meant by as-routing. _J >>> "Chris L. Morrow" 12/21/06 1:12 PM >>> On Thu, 21 Dec 2006, Jari Arkko wrote: > The mobility mechanisms for current and all planned mobile > networks that I know of do not interact with the routing > system. They use mechanisms that hide the mobility > either from the Internet or even the host itself. it'd sure be nice to fix that wouldn't it? remove some of the complexity, let the host just migrate gracefully from attachment point to attachment point... _______________________________________________ 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 Dec 21 14:16:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTOo-0001cm-6t; Thu, 21 Dec 2006 14:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTOm-0001ch-V0 for ram@iab.org; Thu, 21 Dec 2006 14:16:12 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxTOk-00086q-Du for ram@iab.org; Thu, 21 Dec 2006 14:16:12 -0500 Received: from webmail04.lax.untd.com (webmail04.lax.untd.com [10.131.27.144]) by smtpout03.lax.untd.com with SMTP id AABC2XZMPA3N3H62 for (sender ); Thu, 21 Dec 2006 11:15:57 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKjDgip7+0cvdNuuwHKe349w== Received: (from fergdawg@netzero.net) by webmail04.lax.untd.com (jqueuemail) id L95V4SER; Thu, 21 Dec 2006 11:15:41 PST Received: from [66.35.254.64] by webmail04.lax.untd.com with HTTP: Thu, 21 Dec 2006 19:14:51 GMT X-Originating-IP: [66.35.254.64] Mime-Version: 1.0 From: "Fergie" Date: Thu, 21 Dec 2006 19:14:51 GMT To: dmm@1-4-5.net Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061221.111541.28.1742706@webmail04.lax.untd.com> X-ContentStamp: 11:5:3985688211 X-MAIL-INFO: 5bbd8014b905800505a5bdd5104db4404038c4dd4004301021117415c1717180e539d914 X-UNTD-Peer-Info: 10.131.27.144|webmail04.lax.untd.com|webmail04.lax.untd.com|fergdawg@netzero.net 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- David Meyer wrote: >On Thu, Dec 21, 2006 at 02:14:56AM +0000, Fergie wrote: > >> = >> I share your concern here -- although it certainly affects backbone >> carriers more than it does leaf-node networks. > > As I mentioned in my response to Chris, we need to start > looking at the nature of the burstiness of UPDATEs. I > think that kind of research will help inform both our > operational and architecture/protocol design concerns. > = I think that is an important goal. :-) And perhaps (also?) not necessarily the burstiness of the updates, but the how the routing system reacts as a "sea" with hundreds of thousands of "waves" of updates -- this also contributes to issues of scale and stability. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFit0dq1pz9mNUZTMRAt7yAJ9QqVFlgiRLg9boTFsvnLaBqon25ACg0GKa +fHGOLR3l3Frdg0oYxPOdTM=3D =3DLhcX -----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 Dec 21 14:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTSI-0002jQ-CG; Thu, 21 Dec 2006 14:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTSG-0002el-7B for ram@iab.org; Thu, 21 Dec 2006 14:19:48 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTSD-0000Dn-Rg for ram@iab.org; Thu, 21 Dec 2006 14:19:48 -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 kBLJJhYI018537; Thu, 21 Dec 2006 11:19:43 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLJJhlx018536; Thu, 21 Dec 2006 11:19:43 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 11:19:43 -0800 From: David Meyer To: Fergie Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221191943.GA18494@1-4-5.net> References: <20061221.111541.28.1742706@webmail04.lax.untd.com> Mime-Version: 1.0 In-Reply-To: <20061221.111541.28.1742706@webmail04.lax.untd.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: 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: , Content-Type: multipart/mixed; boundary="===============0733703078==" Errors-To: ram-bounces@iab.org --===============0733703078== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2006 at 07:14:51PM +0000, Fergie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > - -- David Meyer wrote: >=20 > >On Thu, Dec 21, 2006 at 02:14:56AM +0000, Fergie wrote: > > > >>=20 > >> I share your concern here -- although it certainly affects backbone > >> carriers more than it does leaf-node networks. > > > > As I mentioned in my response to Chris, we need to start > > looking at the nature of the burstiness of UPDATEs. I > > think that kind of research will help inform both our > > operational and architecture/protocol design concerns. > > > =09 >=20 > I think that is an important goal. :-) >=20 > And perhaps (also?) not necessarily the burstiness of the updates, > but the how the routing system reacts as a "sea" with hundreds of > thousands of "waves" of updates -- this also contributes to issues > of scale and stability. Sure, well taken. --dmm --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFit5PORgD1qCZ2KcRAqd2AJ9+9K/D5EK6aLE/m5wL2FRYOMHgAwCfUdA8 zqH3XmnSi6Xm0qpLwgwbv8o= =r82z -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- --===============0733703078== 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 --===============0733703078==-- From ram-bounces@iab.org Thu Dec 21 14:27:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTZB-0006VJ-28; Thu, 21 Dec 2006 14:26:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTZA-0006VE-Ka for ram@iab.org; Thu, 21 Dec 2006 14:26:56 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTZ8-0001OS-Bw for ram@iab.org; Thu, 21 Dec 2006 14:26:56 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 360B459BD1; Thu, 21 Dec 2006 14:26:48 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Thu, 21 Dec 2006 14:26:48 -0500 X-Sasl-enc: tMFMLTz5gdlYYgaMTtWBo+JjqVoIRHdqsGpsBU3kDs4z 1166729206 Received: from [127.0.0.1] (tf-consult.com [87.106.27.17]) by mail.messagingengine.com (Postfix) with ESMTP id 674DE15B81; Thu, 21 Dec 2006 14:26:39 -0500 (EST) Message-ID: <458ADFD8.6080607@eml.cc> Date: Thu, 21 Dec 2006 20:26:16 +0100 From: Per Heldal User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> <20061221175424.GA14066@1-4-5.net> In-Reply-To: <20061221175424.GA14066@1-4-5.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-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 List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org David Meyer wrote: [snip] >>>> - Number of IPv6 prefixes will be smaller than in IPv4, for the >>>> same number of users, because of more flexible addressing >>>> architecture. >>>> >>> I don't think you can support that. In fact, recent RIR >>> policy argues against this assertion. >>> >> Ok. Can you point to the policy that you were thinking of? > > http://www.arin.net/policy/proposals/2005_1.html > > (for example) > PI (because of a lack of via alternative for multihoming) with a policy equal to that of IPv4 only makes the number of potential visible entities (AS:es in current technology) on the net the same for IPv6. I believe the reduction Jari referred to was the fact that most organizations should manage with only one (or very few) V6 assignments as opposed to an average of more than 8 IPv4 prefixes per AS today (http://ispcolumn.isoc.org/2006-06/bgpupds.html) //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 14:42:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTnd-0007ps-3l; Thu, 21 Dec 2006 14:41:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTnc-0007pN-2t for ram@iab.org; Thu, 21 Dec 2006 14:41: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 1GxTnZ-0003O9-KD for ram@iab.org; Thu, 21 Dec 2006 14:41:52 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2006 11:41:28 -0800 X-IronPort-AV: i="4.12,200,1165219200"; d="scan'208"; a="757200371:sNHT3792522590" 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 kBLJfSL5027559; Thu, 21 Dec 2006 11:41:28 -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 kBLJfJ4k006378; Thu, 21 Dec 2006 11:41:19 -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, 21 Dec 2006 11:41:03 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 11:41:03 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 21 Dec 2006 13:40:58 -0600 Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org From: David Ward To: Jeremy Hall , Jari Arkko , Chris Morrow , David Ward Message-ID: Thread-Topic: [RAM] moving a discussion from various I* lists to ram@iab.org Thread-Index: AcclN+/NLkVuo5ErEdusngAX8sbpFw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Dec 2006 19:41:03.0575 (UTC) FILETIME=[F3202E70:01C72537] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1420; t=1166730088; x=1167594088; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[RAM]=20moving=20a=20discussion=20from=20various=20I* =20lists=20to=20ram@iab.org |Sender:=20; bh=lL/voFmkLjwadh2FU4tQSAH5saVa4rtXZhGvL2zJ8h0=; b=IJYfLHEO4ecIgQFnuaQ7owSTeBr/mhA3rh302dKOI9xycWYIOUQQkvjROocuEpB6dkC6+Njn 3p6uul0VxyuSLPDjAXxNg16l3p04mvujmxXXYVEl3QuQYpoKV68EcVWu; Authentication-Results: sj-dkim-1; header.From=dward@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1002 verified; ); 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 I'd like to mention for the old folks on the list that Jeremy is perhaps suggesting the routing paradigm of the NSFNET back in the early 90s. Some may remember cutting and pasting the new list of AS' and prefixes out of email to put into their FIB. :-) Anyways, a wander down memory lane for those that still had it in their personal memory buffers and a nod to the history books. Kirk, Yakov and Eric may rolling over in their cubes ... -DWard On 12/21/06 12:22 PM, "Jeremy Hall" wrote: > That is kindda what I meant by as-routing. > > _J > >>>> "Chris L. Morrow" 12/21/06 > 1:12 PM >>> > > On Thu, 21 Dec 2006, Jari Arkko wrote: > >> The mobility mechanisms for current and all planned mobile >> networks that I know of do not interact with the routing >> system. They use mechanisms that hide the mobility >> either from the Internet or even the host itself. > > it'd sure be nice to fix that wouldn't it? remove some of the > complexity, > let the host just migrate gracefully from attachment point to > attachment > point... > > > > _______________________________________________ > 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 Dec 21 14:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxU4U-0000xt-Hj; Thu, 21 Dec 2006 14:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxU4T-0000xn-Ie for ram@iab.org; Thu, 21 Dec 2006 14:59:17 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxU4S-0006ag-4D for ram@iab.org; Thu, 21 Dec 2006 14:59:17 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 362C0898C5; Thu, 21 Dec 2006 21:59:14 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D395B898C4; Thu, 21 Dec 2006 21:59:13 +0200 (EET) Message-ID: <458AE792.4090804@piuha.net> Date: Thu, 21 Dec 2006 21:59:14 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: "Chris L. Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 Chris, >> The mobility mechanisms for current and all planned mobile >> networks that I know of do not interact with the routing >> system. They use mechanisms that hide the mobility >> either from the Internet or even the host itself. >> > > it'd sure be nice to fix that wouldn't it? remove some of the complexity, > let the host just migrate gracefully from attachment point to attachment > point... > I was talking about predictions for the future, based on what we know about technology today, growth patterns, etc. The fact is that none of that is done today or planned to be done in a way that impacts global routing table. Not even in solutions that run on top of IP and can migrate from attachment point to attachment point. Don't get me wrong. I'm all for having a clean, generic and simple solution that handles many of the things that we currently handle with point solutions or even outside IP stack. And has direct IP connectivity as opposed to tunnels. I have worked on that and people in my lab are working on it as we speak. But I see this more of an opportunity, as in, say, id-loc split possibly streamlining the existing protocols and packet flows. Better architecture. We just can not claim that the global routing table is going to see a big effect from the movement of mobile nodes. > yup, this gets back to the possible solution (which for now I think we > can't really talk about until we know there is a problem, or have written > down that there is a problem and everyone or 'most everyone' agrees to > that problem.) I believe the plain is to pursue a number of things in parallel, including working on the problem definition and a set of different solutions. Solution discussion is well within scope. --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 15:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUCL-00040X-0W; Thu, 21 Dec 2006 15:07:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUCI-0003uX-Hn for ram@iab.org; Thu, 21 Dec 2006 15:07:22 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxU81-00077m-ML for ram@iab.org; Thu, 21 Dec 2006 15:03:01 -0500 Received: from webmail04.lax.untd.com (webmail04.lax.untd.com [10.131.27.144]) by smtpout05.lax.untd.com with SMTP id AABC2X4B2A45WB4A for (sender ); Thu, 21 Dec 2006 12:02:00 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKw69liFBNk68S104vhHBz8w== Received: (from fergdawg@netzero.net) by webmail04.lax.untd.com (jqueuemail) id L95YRJLQ; Thu, 21 Dec 2006 12:01:58 PST Received: from [66.35.254.64] by webmail04.lax.untd.com with HTTP: Thu, 21 Dec 2006 20:01:43 GMT X-Originating-IP: [66.35.254.64] Mime-Version: 1.0 From: "Fergie" Date: Thu, 21 Dec 2006 20:01:43 GMT To: dward@cisco.com Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061221.120158.28.1743191@webmail04.lax.untd.com> X-ContentStamp: 8:4:569487212 X-MAIL-INFO: 14d995a818dc95dcdcb5d9f85948014949ede1f94928995939759d355cadad95c531d1a8 X-UNTD-Peer-Info: 10.131.27.144|webmail04.lax.untd.com|webmail04.lax.untd.com|fergdawg@netzero.net 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- David Ward wrote: >I'd like to mention for the old folks on the list that Jeremy is perhap= s >suggesting the routing paradigm of the NSFNET back in the early 90s. So= me >may remember cutting and pasting the new list of AS' and prefixes out o= f >email to put into their FIB. :-) Anyways, a wander down memory lane for= >those that still had it in their personal memory buffers and a nod to t= he >history books. Kirk, Yakov and Eric may rolling over in their cubes ...= > You mean, like, where everything is one-hop away from the center of the universe? :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFiugeq1pz9mNUZTMRAh8OAJ0fyftRUICy9ksdcToQoq+UiSoARQCglq3H Z6vr3hxYnoFwPhM8W/E/hMs=3D =3DcxPK -----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 Dec 21 15:27:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUVJ-00073n-T9; Thu, 21 Dec 2006 15:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUVI-0006xz-6c for ram@iab.org; Thu, 21 Dec 2006 15:27:00 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxUV2-00036B-FO for ram@iab.org; Thu, 21 Dec 2006 15:26:48 -0500 Received: from gihm3.apnic.net (dhcp16.potaroo.net [203.10.60.16]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kBLKQUQS099954; Fri, 22 Dec 2006 07:26:31 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061222072442.0037c8e8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 22 Dec 2006 07:26:26 +1100 To: "Fergie" , dward@cisco.com From: Geoff Huston Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-Reply-To: <20061221.120158.28.1743191@webmail04.lax.untd.com> References: <20061221.120158.28.1743191@webmail04.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) 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 >You mean, like, where everything is one-hop away from the >center of the universe? :-) yep As a technology model it could work, and indeed could probably work well for a while. The associated economic model (for me) appears to be doomed from the start! Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 16:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVL4-0001t8-OO; Thu, 21 Dec 2006 16:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVA8-0001mJ-C9 for ram@iab.org; Thu, 21 Dec 2006 16:09:12 -0500 Received: from mailsc21.usdoj.gov ([149.101.1.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxV8g-0004AZ-2n for ram@iab.org; Thu, 21 Dec 2006 16:07:43 -0500 Received: from ems07.usdoj.gov ([10.222.4.19]) by mailsc21.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBLL7ftn023203 for ; Thu, 21 Dec 2006 16:07:41 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems07.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBLL7Vqe012355 for ; Thu, 21 Dec 2006 16:07:31 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id 2553DF7858D for ; Thu, 21 Dec 2006 16:04:06 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id 18B10F400BC for ; Thu, 21 Dec 2006 16:04:06 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Thu, 21 Dec 2006 16:07:20 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Thu, 21 Dec 2006 16:06:47 -0500 From: "Jeremy Hall" To: "Chris Morrow" Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-21_10:2006-12-21, 2006-12-21, 2006-12-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612210044 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Thu, 21 Dec 2006 16:20:30 -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 >>> "Chris L. Morrow" 12/21/06 1:25 PM >>> On Thu, 21 Dec 2006, Jeremy Hall wrote: > That is kindda what I meant by as-routing. yup, this gets back to the possible solution (which for now I think we can't really talk about until we know there is a problem, or have written down that there is a problem and everyone or 'most everyone' agrees to that problem.) of loc/id split. I believe Dino was working toward some code that maybe looks like tunnel endpoints inside AS's with a way to find the tunnel that and endpoint is behind. ah good, perhaps he will share his findings soon. Certainly one way to think about that is: "as routing", another might be 'giant nat', still another seems a lot like 'interprovider mpls'. I didn't write down interprovider mpls because there is too much room for mistrust and manipulation imho. I doubt it would actually get implemented fairly. but, we should really agree on a problem first :) I thought we did that? or am I just being optimistic? I have seen a lot of good descriptions of problems, so maybe now it would be good to order them in priority of which ones we want to solve first. _J > > >>> "Chris L. Morrow" 12/21/06 > 1:12 PM >>> > > On Thu, 21 Dec 2006, Jari Arkko wrote: > > > The mobility mechanisms for current and all planned mobile > > networks that I know of do not interact with the routing > > system. They use mechanisms that hide the mobility > > either from the Internet or even the host itself. > > it'd sure be nice to fix that wouldn't it? remove some of the > complexity, > let the host just migrate gracefully from attachment point to > attachment > point... > > > > _______________________________________________ > 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 Dec 21 16:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVLo-0002Jy-K3; Thu, 21 Dec 2006 16:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUXU-0007bl-Uj for ram@iab.org; Thu, 21 Dec 2006 15:29:16 -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 1GxUXR-0003Zl-II for ram@iab.org; Thu, 21 Dec 2006 15:29:16 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Dec 2006 12:29:13 -0800 X-IronPort-AV: i="4.12,200,1165219200"; d="scan'208"; a="757211576:sNHT44716204" 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 kBLKTCEZ024847; Thu, 21 Dec 2006 12:29:12 -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 kBLKTC4g017885; Thu, 21 Dec 2006 12:29:12 -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, 21 Dec 2006 12:29:12 -0800 Received: from [171.71.55.60] ([171.71.55.60]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 12:29:12 -0800 In-Reply-To: <458ADFD8.6080607@eml.cc> References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> <20061221175424.GA14066@1-4-5.net> <458ADFD8.6080607@eml.cc> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Date: Thu, 21 Dec 2006 12:29:10 -0800 To: Per Heldal X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Dec 2006 20:29:12.0145 (UTC) FILETIME=[ACD8FC10:01C7253E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1233; t=1166732952; x=1167596952; 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]=20moving=20a=20discussion=20from=20various=20I* =20lists=20to=20ram@iab.org |Sender:=20; bh=FNdTrbkJg79YMzQLSAZEa1MLg0s5gVQ69uzNjAHVImk=; b=eHxTvOG2Wj3Y8dpfohyy30UbP91eNVjZZNhNZUQNFQtwTjL0ghNets8C2yLYBZ+zAW73tgWY fZxKKqgHSjSeNY1ls3LkwCY6MA1C+p+woAXqRm/2CGIHu+YUM8jUtuME; 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: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Thu, 21 Dec 2006 16:21:16 -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 On Dec 21, 2006, at 11:26 AM, Per Heldal wrote: > David Meyer wrote: > [snip] >>>>> - Number of IPv6 prefixes will be smaller than in IPv4, for the >>>>> same number of users, because of more flexible addressing >>>>> architecture. >>>>> >>>> I don't think you can support that. In fact, recent RIR >>>> policy argues against this assertion. >>>> >>> Ok. Can you point to the policy that you were thinking of? >> >> http://www.arin.net/policy/proposals/2005_1.html >> >> (for example) >> > > PI (because of a lack of via alternative for multihoming) with a > policy > equal to that of IPv4 only makes the number of potential visible > entities (AS:es in current technology) on the net the same for IPv6. I > believe the reduction Jari referred to was the fact that most > organizations should manage with only one (or very few) V6 assignments > as opposed to an average of more than 8 IPv4 prefixes per AS today > (http://ispcolumn.isoc.org/2006-06/bgpupds.html) My impression was that those 8 prefixes per AS included traffic engineering prefixes. I haven't heard anything about IPv6 decreasing or changing the pressure for traffic engineering in any way, shape or form. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 16:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVly-0001qw-R3; Thu, 21 Dec 2006 16:48:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVlx-0001qA-Nw for ram@iab.org; Thu, 21 Dec 2006 16:48:17 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxVlw-0003WB-AG for ram@iab.org; Thu, 21 Dec 2006 16:48:17 -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 kBLLm8ej021444; Thu, 21 Dec 2006 13:48:08 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBLLm4VE021443; Thu, 21 Dec 2006 13:48:04 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 21 Dec 2006 13:48:04 -0800 From: David Meyer To: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org Message-ID: <20061221214804.GA21429@1-4-5.net> References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> <20061221175424.GA14066@1-4-5.net> <458ADFD8.6080607@eml.cc> <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> Mime-Version: 1.0 In-Reply-To: <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@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: 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="===============0665930296==" Errors-To: ram-bounces@iab.org --===============0665930296== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2006 at 12:29:10PM -0800, Tony Li wrote: >=20 > On Dec 21, 2006, at 11:26 AM, Per Heldal wrote: >=20 > >David Meyer wrote: > >[snip] > >>>>>- Number of IPv6 prefixes will be smaller than in IPv4, for the > >>>>> same number of users, because of more flexible addressing > >>>>> architecture. > >>>>> > >>>> I don't think you can support that. In fact, recent RIR > >>>> policy argues against this assertion. > >>>> > >>>Ok. Can you point to the policy that you were thinking of? > >> > >> http://www.arin.net/policy/proposals/2005_1.html > >> > >> (for example) > >> > > > >PI (because of a lack of via alternative for multihoming) with a =20 > >policy > >equal to that of IPv4 only makes the number of potential visible > >entities (AS:es in current technology) on the net the same for IPv6. I > >believe the reduction Jari referred to was the fact that most > >organizations should manage with only one (or very few) V6 assignments > >as opposed to an average of more than 8 IPv4 prefixes per AS today > >(http://ispcolumn.isoc.org/2006-06/bgpupds.html) >=20 >=20 > My impression was that those 8 prefixes per AS included traffic =20 > engineering prefixes. >=20 > I haven't heard anything about IPv6 decreasing or changing the =20 > pressure for traffic engineering in any way, shape or form. Me either. --dmm --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFiwEUORgD1qCZ2KcRAkcMAJ9/Z/hHJK3Ll/dpEaNgNWFe3Z+P5wCdFlmi OmL5HNMA9/SXK53mcD3bDJM= =nE8A -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- --===============0665930296== 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 --===============0665930296==-- From ram-bounces@iab.org Thu Dec 21 17:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWj4-0002ay-HM; Thu, 21 Dec 2006 17:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWj3-0002as-7m for ram@iab.org; Thu, 21 Dec 2006 17:49:21 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxWj1-0004pM-BG for ram@iab.org; Thu, 21 Dec 2006 17:49:20 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1GxWir-0006a4-00; Thu, 21 Dec 2006 17:49:09 -0500 Date: Thu, 21 Dec 2006 17:49:09 -0500 (EST) From: Scott Leibrand To: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org In-Reply-To: <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> Message-ID: References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> <20061221175424.GA14066@1-4-5.net> <458ADFD8.6080607@eml.cc> <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 12/21/06 at 12:29pm -0800, Tony Li wrote: > On Dec 21, 2006, at 11:26 AM, Per Heldal wrote: > > > PI (because of a lack of via alternative for multihoming) with a > > policy equal to that of IPv4 only makes the number of potential > > visible entities (AS:es in current technology) on the net the same for > > IPv6. I believe the reduction Jari referred to was the fact that most > > organizations should manage with only one (or very few) V6 assignments > > as opposed to an average of more than 8 IPv4 prefixes per AS today > > (http://ispcolumn.isoc.org/2006-06/bgpupds.html) > > My impression was that those 8 prefixes per AS included traffic > engineering prefixes. > > I haven't heard anything about IPv6 decreasing or changing the > pressure for traffic engineering in any way, shape or form. Someone else has presented the actual numbers, but IIRC the number of TE prefixes is less than the number of prefixes announced due to disjoint allocations. -Scott _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 21 17:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWl2-0002ol-Ap; Thu, 21 Dec 2006 17:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWl1-0002og-3l for ram@iab.org; Thu, 21 Dec 2006 17:51:23 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxWkx-00058n-SC for ram@iab.org; Thu, 21 Dec 2006 17:51:23 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 8C4855909B; Thu, 21 Dec 2006 17:51:13 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Thu, 21 Dec 2006 17:51:13 -0500 X-Sasl-enc: OfHjOhLL6wqwoUxNcUW+LJcoeu59yeIOe913Gnhwi25+ 1166741472 Received: from [127.0.0.1] (unknown [69.20.97.236]) by mail.messagingengine.com (Postfix) with ESMTP id 1527E17EA2; Thu, 21 Dec 2006 17:51:11 -0500 (EST) Message-ID: <458B0FCC.6090200@eml.cc> Date: Thu, 21 Dec 2006 23:50:52 +0100 From: Per Heldal User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org References: <20061220170024.GA4735@1-4-5.net> <458A669E.10404@piuha.net> <20061221154650.GA9598@1-4-5.net> <458AC12C.6040901@piuha.net> <20061221175424.GA14066@1-4-5.net> <458ADFD8.6080607@eml.cc> <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> In-Reply-To: <166F29CA-1DDA-4477-BF8B-AF4A1A6E71F2@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Tony Li wrote: >> >> PI (because of a lack of via alternative for multihoming) with a policy >> equal to that of IPv4 only makes the number of potential visible >> entities (AS:es in current technology) on the net the same for IPv6. I >> believe the reduction Jari referred to was the fact that most >> organizations should manage with only one (or very few) V6 assignments >> as opposed to an average of more than 8 IPv4 prefixes per AS today >> (http://ispcolumn.isoc.org/2006-06/bgpupds.html) > > > My impression was that those 8 prefixes per AS included traffic > engineering prefixes. True. 8 is excessive. Yet, according to the most recent CIDR-report: 23906 - Number of ASes in routing system 132190 - CIDR aggregated prefixes ~ 5.5 pfx/as > > I haven't heard anything about IPv6 decreasing or changing the pressure > for traffic engineering in any way, shape or form. Certainly not. Requirements for traffic engineering remains one of the main arguments in parts of the ops community against architectural changes which involve certain forms of aggregation. (fear loss of control). //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 27 10:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzaid-0001tB-Jd; Wed, 27 Dec 2006 10:29:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzaic-0001t4-0B for ram@iab.org; Wed, 27 Dec 2006 10:29:26 -0500 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzaiZ-0007HI-HX for ram@iab.org; Wed, 27 Dec 2006 10:29:25 -0500 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.132044674; Wed, 27 Dec 2006 10:44:02 -0500 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Dec 2006 10:28:54 -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: [RAM] moving a discussion from various I* lists to ram@iab.org Date: Wed, 27 Dec 2006 10:28:59 -0500 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DD25@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] moving a discussion from various I* lists to ram@iab.org Thread-Index: AcclKQrWbxPlQ5s1TCO/03wNDb0oAwEnU7Mw From: "Azinger, Marla" To: "David Meyer" , "Jari Arkko" X-OriginalArrivalTime: 27 Dec 2006 15:28:54.0303 (UTC) FILETIME=[B7DAFAF0:01C729CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 > >> - Number of IPv6 prefixes will be smaller than in IPv4, for the > >> same number of users, because of more flexible addressing > >> architecture. > >> =20 > > > > I don't think you can support that. In fact, recent RIR > > policy argues against this assertion. > > =20 > Ok. Can you point to the policy that you were thinking of? >http://www.arin.net/policy/proposals/2005_1.html >(for example) I think a point of clarification is useful here for folks only quickly = reading these postings. ARIN Policy does not specifically (in written = form) argue or support any theory of the number of IPV6 prefixes vs the = number of IPV4 prefixes. However, some analysis of the implementation = of the referenced policy (2005-1 Provider Independent IPV6 Assignments = for End Sites)reveals that utilization of this policy can lead to a = larger number of IPV6 prefixes than IPV4 prefixes in the future. This = is speculation right now, but it can become our reality. Marla -----Original Message----- From: David Meyer [mailto:dmm@1-4-5.net] Sent: Thursday, December 21, 2006 9:54 AM To: Jari Arkko Cc: ram@iab.org Subject: Re: [RAM] moving a discussion from various I* lists to ram@iab.org On Thu, Dec 21, 2006 at 07:15:24PM +0200, Jari Arkko wrote: > It seems that my plan of posting bad assumptions > in an effort to get you figure out the right ones > worked... ;-) :-) > > > > Not turned on a single day would seem a reasonable > > assumption (clearly). However, "grows gradually" is an > > interesting assumption. I could see this go either > > way. If all of a sudden every mobile handset has IPv6 and > > HIP burned into it, is that "gradual"? What about > > Microsoft's bet with Vista? > > =20 > Right. Its hard to estimate this, of course. But there > are a number of factors to consider. For instance, as > long as the hosts aren't getting native IPv6 from their > ISP, I'm not sure the global routing table is affected > by hosts that have IPv6 but don't use it or use it via > a tunnel. So this is the "IPv6 deployment stalls" argument? =20 > In any case, even a new mobile network or a popular > OS version takes some time to actually be deployed > and used. What I did in my model was to set a fairly > aggressive IPv6 growth, in my case assuming 10% > of the network would turn to IPv6 each year, i.e., > take 10 years for full IPv6 deployment. We could > talk about whether this covers the sudden events. > But is certainly much more aggressive than we are > seeing today. Ok, its certainly worth looking at.=20 > >> - Number of IPv6 prefixes will be smaller than in IPv4, for the > >> same number of users, because of more flexible addressing > >> architecture. > >> =20 > > > > I don't think you can support that. In fact, recent RIR > > policy argues against this assertion. > > =20 > Ok. Can you point to the policy that you were thinking of? http://www.arin.net/policy/proposals/2005_1.html (for example) > >> - IPv4 keeps on growing until a certain day at which point > >> all the growth is in IPv6 (even if we run out of Ipv4 addresses, > >> we can split the current prefixes in smaller units... so the > >> day is far in the future) > >> =20 > > > > I agree that the growth in IPv4 RIBs is bounded by some > > O(m*2^32), a description of the meshiness of the > > Internet, and IPv4 FIBs are bounded by something like > > O(2^32). The corresponding update streams have no such > > bounds. So in that sense, if we got to /32 everything in > > v4, it would stop growing.=20 > > =20 > Right. mod whatever dm/dt turns out to be, where dm/dt is (my notation for) the rate of change of the interconnection meshiness. =20 > > Regarding all the growth being in IPv6, that is a loaded > > assumption. What happenes if there is *no* v6 deployment, > > but rather we see an (further) explosion of NAT (or > > similar technology)? > > =20 > Indeed, that's also a possible future. I guess we want to > see the worst scenario (within reasonable bounds) > from the point of view of routing. To me that's the ability > for people to get as much address space as they like. > If it turns that we continue on the NAT path... I guess > we would see somewhat less entries in the table. There > would still be growth in the table, as the IPv4 space > gets broken in smaller pieces. I don't have a good idea > how to model this, do you? Or perhaps we don't need to. I'm not sure we need to either. > > All that being said, the assumption is ok for purposes of > > modeling. > > > > =20 > >> - No upper bound on IPv6 growth > >> =20 > > > > Meaning? No upper bound on the growth of the RIB? Well, > > that would seem to be O(m*2^128). > > =20 > Right. Of course from our router construction point of > view the crucial question is whether _speed_ of the > allocation exceeds the speed of hardware improvement > and whether the improvement stops at some future > time. (Such as running out of steam on Moore's Law, as > has been often predicted.) > > >> - Mobility is not a significant source of this problem * > >> =20 > > > > Huh? Its one of the 3Ms (Multihoming, Mobility, and > > Migration (to v6)). > I think we can account for multihoming and provider independence based > on the projected growth in the prefixes. The open question is whether > the currently seen growth will change somehow, e.g., because more > people will suddenly need provider independence. What's our best > estimate for this now? Perhaphs Geoff's current work (the ATNAC2006 paper I've been citing)? Another issue (re: mobility) is the effect the larger effect of the impact of say, HIP, on the routing system. > Migration to Ipv6 is handled as long as we count > both Ipv4 and Ipv6 routes for the same users. Can you say a few more words about this? I'm not sure what you meant. > But what I was saying was that I do not see any evidence of > mobility suddenly changing the allocation or update rates, > except for the network mobility part. But as I explained > that it at least for now a very small part of the entire mobile > market, and we might be able to find solutions for that. Sure. > > Regarding the note below (*), we do > > need to understand how these technogies (i.e., HIP, > > SHIM6, etc) interact with the routing system. > > =20 > The mobility mechanisms for current and all planned mobile > networks that I know of do not interact with the routing > system.=20 Right, which many folks think is a problem. So there will likely be some pressure to have the routing system become more "aware" of all of this. That is where the concern is, and where some good thinking will be required. > They use mechanisms that hide the mobility > either from the Internet or even the host itself. Sure, see my previous comment. > > How would you suggest moving forward with the modeling > > exercise? > > =20 > Talking some more about the assumptions and growth > predictions on this list would be useful. At some point > the discussion needs to be turned into papers that > have the full picture and which can be reviewed by others > in the IETF and outside. And of course, if you can point > us to existing work that would be great too. Sure. Have you read Geoff's stuff yet? --dmm _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 09:37:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0IqQ-0002VM-4f; Fri, 29 Dec 2006 09:36:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0IqO-0002Si-Oj for ram@iab.org; Fri, 29 Dec 2006 09:36:24 -0500 Received: from centrmmtao02.cox.net ([70.168.83.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0IqL-0007ll-Eu for ram@iab.org; Fri, 29 Dec 2006 09:36:24 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061229143620.SCZY25837.centrmmtao02.cox.net@eastrmimpo01.cox.net> for ; Fri, 29 Dec 2006 09:36:20 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 4eb71W0040pnMhQ0000000; Fri, 29 Dec 2006 09:35:07 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 29 Dec 2006 09:36:19 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [RAM] Terminology: Routing Entropy X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 I think the absolute size of the RIB/FIB is a practical issue, separately there is a broader architectural issue about the entropy in the routing table. If I might, let me try to define a term in the interest of clarity and a more focused discussion... "Routing Entropy" is the measure of how much additional detail, beyond the bare minimum needed to reach all advertised destinations, exists in the Routing table in (the, any) Default-Free Zone. For example, if one advertised 3.0/8 then it is not strictly required for *reachability* (ignoring other aspects like multi-homing) to advertise 3.1.0/24. More Examples: A routing table with minimum entropy has zero more-specific prefixes. A routing table with high entropy has many more-specific prefixes. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 09:42:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0IwE-0005As-Q4; Fri, 29 Dec 2006 09:42:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0IwD-0005An-Ko for ram@iab.org; Fri, 29 Dec 2006 09:42:25 -0500 Received: from centrmmtao01.cox.net ([70.168.83.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0IwB-0000BI-Qc for ram@iab.org; Fri, 29 Dec 2006 09:42:25 -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 <20061229144221.RDVU23868.centrmmtao01.cox.net@eastrmimpo01.cox.net> for ; Fri, 29 Dec 2006 09:42:21 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 4eh71W00L0pnMhQ0000000; Fri, 29 Dec 2006 09:41:07 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 29 Dec 2006 09:42:20 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [RAM] Goal: Minimising Routing Entropy X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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'd like to suggest that an architectural goal for any new effort should be to reduce/minimise Routing Entropy. We know that doing this will address the near-term engineering issues identified by tli and others. It also will fundamentally improve the scalability of the Internet (including but not limited to the IPv6 Internet) over the longer term. I'd really like to ensure that the global Internet will be capable of scaling for at least my own lifetime (even as I remain open to some new approach to networking that would obviate the current packet network approaches :-). My belief is that if we move to a different ("better") naming/routing/addressing architecture, that we really can minimise the Routing Entropy (at least within the DFZ), while retaining existing capabilities (e.g. site multi-homing) and maybe also adding some new practical-to-use capabilities (e.g. native mobility support, host multi-homing). I have some concrete ideas on ways that this might be approached, in an incrementally-deployable way, but I'd like to see whether there is agreement on terminology and goals first. Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 09:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0J7J-0001B0-7F; Fri, 29 Dec 2006 09:53:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0J7I-0001Av-Ha for ram@iab.org; Fri, 29 Dec 2006 09:53:52 -0500 Received: from centrmmtao03.cox.net ([70.168.83.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0J7G-0002fb-LA for ram@iab.org; Fri, 29 Dec 2006 09:53:51 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao03.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061229145348.MEVZ13993.centrmmtao03.cox.net@eastrmimpo01.cox.net> for ; Fri, 29 Dec 2006 09:53:48 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 4esa1W00L0pnMhQ0000000; Fri, 29 Dec 2006 09:52:34 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 29 Dec 2006 09:53:46 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [RAM] Traffic Engineering X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 that some folks on this list are not familiar with what issues/problems are currently being addressed with traffic engineering. There was concern expressed at NANOG about potential loss of ability to use "traffic engineering" if SHIM6 were widely deployed, but the details of those concerns haven't been widely explained. I also think that different parts of the Internet are using traffic engineering to address different sets of issues/problems. It would be helpful if operators [1] could enumerate the myriad ways that traffic engineering is currently being used, including what solution folks are trying to achieve. That is, the kind of detail that I'm looking for something more like "force traffic off of link A until that link can be upgraded, because that link is heavily congested just now" not "re-route traffic". Then maybe someone, ideally some operator person, could maintain a list of these uses and problem/solution information. This would help in evaluating whether potential solutions are sufficient to meet existing known operational needs. Thanks, Ran rja@extremenetworks.com [1] "operator" in MY parlance means any person/organisation that operates a chunk of network. It is in no way limited to ISPs or NSPs, at least in my own usage of the word. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 10:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JNu-00076Y-IE; Fri, 29 Dec 2006 10:11:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JNs-00076R-RV for ram@iab.org; Fri, 29 Dec 2006 10:11:00 -0500 Received: from centrmmtao04.cox.net ([70.168.83.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0JNc-0007Uh-0N for ram@iab.org; Fri, 29 Dec 2006 10:11:00 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao04.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061229151041.OXXT5993.centrmmtao04.cox.net@eastrmimpo01.cox.net>; Fri, 29 Dec 2006 10:10:41 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 4f9T1W00W0pnMhQ0000000; Fri, 29 Dec 2006 10:09:27 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3419EBF8-C4C8-4AB7-90C3-FC5696E82E4B@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Terminology: Routing Entropy Date: Fri, 29 Dec 2006 10:10:39 -0500 To: "Jeremy Hall" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 29 Dec 2006, at 09:53, Jeremy Hall wrote: > Are you talking about auto-summarization? Surely not. No -- and I am NOT talking about ANY specific mechanism or protocol. I'm talking about architecture here. Kindly zoom up several thousand metres in altitude. :-) Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 10:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JqN-0001sc-Jd; Fri, 29 Dec 2006 10:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JUz-0002Lh-4O for ram@iab.org; Fri, 29 Dec 2006 10:18:21 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0JUx-0001U3-Se for ram@iab.org; Fri, 29 Dec 2006 10:18:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2006 07:18:18 -0800 X-IronPort-AV: i="4.12,219,1165219200"; d="scan'208"; a="49637698:sNHT45346520" 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 kBTFIHMV022730; Fri, 29 Dec 2006 10:18:17 -0500 Received: from [68.49.215.202] (che-vpn-cluster-1-277.cisco.com [10.86.241.22]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBTFIFgT003376; Fri, 29 Dec 2006 10:18:17 -0500 (EST) In-Reply-To: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <983f0edbc2c1359315496968b09144ad@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 29 Dec 2006 10:18:10 -0500 To: RJ Atkinson X-Mailer: Apple Mail (2.624) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2201; t=1167405497; x=1168269497; c=relaxed/simple; s=rtpdkim2001; 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]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20 |To:=20RJ=20Atkinson=20; bh=k6zsiyXgVXvUt0rN9IEObbDON1+JkWnZ2T3AcCyGCoI=; b=woVCpZk3aNw06nnAbm1GlB7R5v0LgkNolOxSc/DQpkL+L6qg1sH82Tibaa3yHZqcrD5R9fg8 XR007IAgIRbralf5EZ+Qkd0Tj72Ult9FqDmC8aE0WObZ7C/+Ok4NtK5k; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 29 Dec 2006 10:40:25 -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 On Dec 29, 2006, at 9:42 AM, RJ Atkinson wrote: > > I'd like to suggest that an architectural goal > for any new effort should be to reduce/minimise Routing > Entropy. We know that doing this will address the near-term > engineering issues identified by tli and others. It also > will fundamentally improve the scalability of the Internet > (including but not limited to the IPv6 Internet) over the > longer term. One step toward agreement on terminology might be to replace "minimizing" here with "limiting growth of". Strictly minimizing is likely to produce impractical results. Are there analytic results that suggest practical bounds on routing entropy or its growth? > I'd really like to ensure that the global Internet > will be capable of scaling for at least my own lifetime > (even as I remain open to some new approach to networking > that would obviate the current packet network approaches :-). > > My belief is that if we move to a different ("better") > naming/routing/addressing architecture, that we really > can miniFrom ram-bounces@iab.org Fri Dec 29 10:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JqN-0001sc-Jd; Fri, 29 Dec 2006 10:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JUz-0002Lh-4O for ram@iab.org; Fri, 29 Dec 2006 10:18:21 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0JUx-0001U3-Se for ram@iab.org; Fri, 29 Dec 2006 10:18:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2006 07:18:18 -0800 X-IronPort-AV: i="4.12,219,1165219200"; d="scan'208"; a="49637698:sNHT45346520" 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 kBTFIHMV022730; Fri, 29 Dec 2006 10:18:17 -0500 Received: from [68.49.215.202] (che-vpn-cluster-1-277.cisco.com [10.86.241.22]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBTFIFgT003376; Fri, 29 Dec 2006 10:18:17 -0500 (EST) In-Reply-To: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <983f0edbc2c1359315496968b09144ad@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 29 Dec 2006 10:18:10 -0500 To: RJ Atkinson X-Mailer: Apple Mail (2.624) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2201; t=1167405497; x=1168269497; c=relaxed/simple; s=rtpdkim2001; 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]=20Goal=3A=20Minimising=20Routing=20Entropy |Sender:=20 |To:=20RJ=20Atkinson=20; bh=k6zsiyXgVXvUt0rN9IEObbDON1+JkWnZ2T3AcCyGCoI=; b=woVCpZk3aNw06nnAbm1GlB7R5v0LgkNolOxSc/DQpkL+L6qg1sH82Tibaa3yHZqcrD5R9fg8 XR007IAgIRbralf5EZ+Qkd0Tj72Ult9FqDmC8aE0WObZ7C/+Ok4NtK5k; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 29 Dec 2006 10:40:25 -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 On Dec 29, 2006, at 9:42 AM, RJ Atkinson wrote: > > I'd like to suggest that an architectural goal > for any new effort should be to reduce/minimise Routing > Entropy. We know that doing this will address the near-term > engineering issues identified by tli and others. It also > will fundamentally improve the scalability of the Internet > (including but not limited to the IPv6 Internet) over the > longer term. One step toward agreement on terminology might be to replace "minimizing" here with "limiting growth of". Strictly minimizing is likely to produce impractical results. Are there analytic results that suggest practical bounds on routing entropy or its growth? > I'd really like to ensure that the global Internet > will be capable of scaling for at least my own lifetime > (even as I remain open to some new approach to networking > that would obviate the current packet network approaches :-). > > My belief is that if we move to a different ("better") > naming/routing/addressing architecture, that we really > can minimise the Routing Entropy (at least within the DFZ), > while retaining existing capabilities (e.g. site multi-homing) I fear even "site multi-homing" is actually ambiguous, despite that we all feel we know that that means. Of course it means that there is more than one last hop from the DFZ to the site. But what does it imply about how far the multiple paths to the site extend. Shall we make hot-potato routing, which is often implicit, explicit, or can this assumption be relaxed to limit how far routing entropy extends to other realms? One way to clarify this is to ask against what failures site multi-homing is to protect. > and maybe also adding some new practical-to-use capabilities > (e.g. native mobility support, host multi-homing). > > I have some concrete ideas on ways that this might > be approached, in an incrementally-deployable way, but I'd like > to see whether there is agreement on terminology and goals first. Please share your ideas while consensus forms on terminology and goals. Sometimes the terminology "discussion" lasts longer than the problem. ;-) John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 10:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JqN-0001sX-Dv; Fri, 29 Dec 2006 10:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0J7a-0001F2-Nq for ram@iab.org; Fri, 29 Dec 2006 09:54:10 -0500 Received: from mailsc21.usdoj.gov ([149.101.1.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0J7Y-0002hd-FU for ram@iab.org; Fri, 29 Dec 2006 09:54:10 -0500 Received: from ems03.usdoj.gov ([10.222.4.38]) by mailsc21.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBTEs80g022321 for ; Fri, 29 Dec 2006 09:54:08 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems03.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBTEs69W016415 for ; Fri, 29 Dec 2006 09:54:06 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id F4009380888 for ; Fri, 29 Dec 2006 09:50:34 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id E859D38061A for ; Fri, 29 Dec 2006 09:50:34 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Fri, 29 Dec 2006 09:54:06 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Fri, 29 Dec 2006 09:53:54 -0500 From: "Jeremy Hall" To: "RJ Atkinson" , Subject: Re: [RAM] Terminology: Routing Entropy Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-29_05:2006-12-29, 2006-12-29, 2006-12-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612290014 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Fri, 29 Dec 2006 10:40:25 -0500 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 Are you talking about auto-summarization? Surely not. Part of the problem here is that not all routers have the smise the Routing Entropy (at least within the DFZ), > while retaining existing capabilities (e.g. site multi-homing) I fear even "site multi-homing" is actually ambiguous, despite that we all feel we know that that means. Of course it means that there is more than one last hop from the DFZ to the site. But what does it imply about how far the multiple paths to the site extend. Shall we make hot-potato routing, which is often implicit, explicit, or can this assumption be relaxed to limit how far routing entropy extends to other realms? One way to clarify this is to ask against what failures site multi-homing is to protect. > and maybe also adding some new practical-to-use capabilities > (e.g. native mobility support, host multi-homing). > > I have some concrete ideas on ways that this might > be approached, in an incrementally-deployable way, but I'd like > to see whether there is agreement on terminology and goals first. Please share your ideas while consensus forms on terminology and goals. Sometimes the terminology "discussion" lasts longer than the problem. ;-) John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 10:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0JqN-0001sX-Dv; Fri, 29 Dec 2006 10:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0J7a-0001F2-Nq for ram@iab.org; Fri, 29 Dec 2006 09:54:10 -0500 Received: from mailsc21.usdoj.gov ([149.101.1.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0J7Y-0002hd-FU for ram@iab.org; Fri, 29 Dec 2006 09:54:10 -0500 Received: from ems03.usdoj.gov ([10.222.4.38]) by mailsc21.usdoj.gov (8.13.7/8.13.7) with ESMTP id kBTEs80g022321 for ; Fri, 29 Dec 2006 09:54:08 -0500 Received: from Mail.unicor.gov (localhost [127.0.0.1]) by ems03.usdoj.gov (8.12.10+Sun/8.12.10) with SMTP id kBTEs69W016415 for ; Fri, 29 Dec 2006 09:54:06 -0500 (EST) Received: from Mail.unicor.gov (localhost [127.0.0.1]) by Mail.unicor.gov (Postfix) with ESMTP id F4009380888 for ; Fri, 29 Dec 2006 09:50:34 -0500 (EST) Received: from central.unicor.gov (unknown [148.180.125.220]) by Mail.unicor.gov (Postfix) with ESMTP id E859D38061A for ; Fri, 29 Dec 2006 09:50:34 -0500 (EST) Received: from GWIADOM-MTA by central.unicor.gov with Novell_GroupWise; Fri, 29 Dec 2006 09:54:06 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.5 Date: Fri, 29 Dec 2006 09:53:54 -0500 From: "Jeremy Hall" To: "RJ Atkinson" , Subject: Re: [RAM] Terminology: Routing Entropy Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.5446:2.3.11, 1.2.37, 4.0.164 definitions=2006-12-29_05:2006-12-29, 2006-12-29, 2006-12-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0612050001 definitions=main-0612290014 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Fri, 29 Dec 2006 10:40:25 -0500 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 Are you talking about auto-summarization? Surely not. Part of the problem here is that not all routers have the same "view" and only the best path is propogated in BGP. If one upstream router were to pick a path not in his "space", i.e. another peer that grafts onto the default-free zone, other routers would not have the ability to pick the correct path, causing huge traffic swings. The only way aggregation can be properly handled is if the originating as aggregates his traffic. _J >>> RJ Atkinson 12/29/06 9:36 AM >>> While I think the absolute size of the RIB/FIB is a practical issue, separately there is a broader architectural issue about the entropy in the routing table. If I might, let me try to define a term in the interest of clarity and a more focused discussion... "Routing Entropy" is the measure of how much additional detail, beyond the bare minimum needed to reach all advertised destinations, exists in the Routing table in (the, any) Default-Free Zone. For example, if one advertised 3.0/8 then it is not strictly required for *reachability* (ignoring other aspects like multi-homing) to advertise 3.1.0/24. More Examples: A routing table with minimum entropy has zero more-specific prefixes. A routing table with high entropy has many more-specific prefixes. 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 ame "view" and only the best path is propogated in BGP. If one upstream router were to pick a path not in his "space", i.e. another peer that grafts onto the default-free zone, other routers would not have the ability to pick the correct path, causing huge traffic swings. The only way aggregation can be properly handled is if the originating as aggregates his traffic. _J >>> RJ Atkinson 12/29/06 9:36 AM >>> While I think the absolute size of the RIB/FIB is a practical issue, separately there is a broader architectural issue about the entropy in the routing table. If I might, let me try to define a term in the interest of clarity and a more focused discussion... "Routing Entropy" is the measure of how much additional detail, beyond the bare minimum needed to reach all advertised destinations, exists in the Routing table in (the, any) Default-Free Zone. For example, if one advertised 3.0/8 then it is not strictly required for *reachability* (ignoring other aspects like multi-homing) to advertise 3.1.0/24. More Examples: A routing table with minimum entropy has zero more-specific prefixes. A routing table with high entropy has many more-specific prefixes. 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 Dec 29 11:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KHs-00048L-CH; Fri, 29 Dec 2006 11:08:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KHr-00048E-BH for ram@iab.org; Fri, 29 Dec 2006 11:08:51 -0500 Received: from eastrmmtao03.cox.net ([68.230.240.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0KHm-0000cs-PL for ram@iab.org; Fri, 29 Dec 2006 11:08:49 -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 <20061229160843.QPER28701.eastrmmtao03.cox.net@eastrmimpo01.cox.net>; Fri, 29 Dec 2006 11:08:43 -0500 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 4g7V1W00b0pnMhQ0000000; Fri, 29 Dec 2006 11:07:29 -0500 In-Reply-To: <983f0edbc2c1359315496968b09144ad@cisco.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AE4B870-EB9D-48B1-9C68-F253015418F7@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 29 Dec 2006 11:08:41 -0500 To: John Schnizlein X-Mailer: Apple Mail (2.752.2) 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 On 29 Dec 2006, at 10:18, John Schnizlein wrote: > On Dec 29, 2006, at 9:42 AM, RJ Atkinson wrote: >> >> I'd like to suggest that an architectural goal >> for any new effort should be to reduce/minimise Routing >> Entropy. We know that doing this will address the near-term >> engineering issues identified by tli and others. It also >> will fundamentally improve the scalability of the Internet >> (including but not limited to the IPv6 Internet) over the >> longer term. > > One step toward agreement on terminology might be to replace > "minimizing" here with "limiting growth of". I prefer my original formulation which was "reduce/minimise". The "/" was deliberate as was my NOT saying "strictly minimise". Thanks for the feedback. > I fear even "site multi-homing" is actually ambiguous, despite that > we all feel we know that that means. Of course it means that there > is more than one last hop from the DFZ to the site. But what does > it imply about how far the multiple paths to the site extend. "site multi-homing" doesn't imply anything. I meant what I said, nothing more and nothing less. (A good general principle, at least with words I write, is that trying to read between my words is a waste of the reader's energy. I'm plain spoken.) Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 11:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KM1-0005UE-SL; Fri, 29 Dec 2006 11:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KLx-0005Rj-RZ for ram@iab.org; Fri, 29 Dec 2006 11:13:05 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0KLt-0007QP-4C for ram@iab.org; Fri, 29 Dec 2006 11:13:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2006 11:12:50 -0500 X-IronPort-AV: i="4.12,219,1165208400"; d="scan'208"; a="110521620:sNHT31531266258" 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 kBTGCnJu003340 for ; Fri, 29 Dec 2006 11:12:49 -0500 Received: from [70.6.81.235] (rtp-vpn1-222.cisco.com [10.82.224.222]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBTGCTG9005765 for ; Fri, 29 Dec 2006 11:12:41 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 08:12:12 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1221; t=1167408769; x=1168272769; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=LuAusg4TddFBwyXzmWp0jrbY3mad88Gy/6bkm2dj1nI=; b=a3l5ikRhoqLuaJmm6LHIee2+dfJwHWUshy5OXb8CPn+aaMuUqTeJubPcwMmPwuZnmBhN3Evj We6ciTkMkAvByTFq2iPSFa4eDA2euVZp9xoQ0Q5xazZ0LLeD6qcrIyKr; 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 Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: > ms are currently being addressed with > traffic engineering. There was concern expressed at NANOG > about potential loss of ability to use "traffic engineering" > if SHIM6 were widely deployed, but the details of those concerns > haven't been widely explained. SHIM6 simply isn't practical for a number of reasons, difficulties in traffic engineering with an architecture of this type being least among them. Just handing off path-selection functionality to the endstation and the concept of multiple addresses on the endstation creates a troubleshooting and support nightmare which neither enterprises nor individuals can be expected to accept. The problem SHIM6 purported to solve is a) much more fundamental and larger in scope than the SHIM6 proponents realized (read all of RFC4192 for a sense of this) and b) is rendered moot by the fact that registries are now providing PI space to organizations which need it, anyways. ----------------------------------------------------------------------- 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 Fri Dec 29 11:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KX9-0001di-F2; Fri, 29 Dec 2006 11:24:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KX8-0001dc-2j for ram@iab.org; Fri, 29 Dec 2006 11:24:38 -0500 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0KX5-0002xu-Jt for ram@iab.org; Fri, 29 Dec 2006 11:24: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 kBTGOKgd005370; Fri, 29 Dec 2006 08:24:20 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBTGOFa1005369; Fri, 29 Dec 2006 08:24:15 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 29 Dec 2006 08:24:15 -0800 From: David Meyer To: RJ Atkinson Subject: Re: [RAM] Terminology: Routing Entropy Message-ID: <20061229162415.GA5059@1-4-5.net> References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> Mime-Version: 1.0 In-Reply-To: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 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="===============1537263329==" Errors-To: ram-bounces@iab.org --===============1537263329== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Ran, > While I think the absolute size of the RIB/FIB is a > practical issue, separately there is a broader architectural issue > about the entropy in the routing table. >=20 > If I might, let me try to define a term in the interest > of clarity and a more focused discussion... >=20 > "Routing Entropy" is the measure of how much additional detail, > beyond the bare minimum needed to reach all advertised destinations, > exists in the Routing table in (the, any) Default-Free Zone. >=20 > For example, if one advertised 3.0/8 then it is not strictly > required for *reachability* (ignoring other aspects like > multi-homing) to advertise 3.1.0/24. >=20 > More Examples: > A routing table with minimum entropy has zero more-specific prefixes. > A routing table with high entropy has many more-specific prefixes. Interesting you should mention this. I'm in the process of embarking on some work to see if we can measure the Hurst parameter for UPDATEs; the idea is basically to look for any LRD (Long Range Dependence) in that signal. Currently its just a pilot study; I'm not sure if the "passive instrument" we're using (www.routevivews.org or the like) produces the kind of data we need to detect a signal that lives in low-frequency events, but in any event, that result would be nice to have.=20 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 Back to the routing entropy issue: The nature of the dynamics of the UPDATE stream is directly related to the amount (and the granularity of) the information that is carried in the DFZ. All of this will effect not only the cost of providing Internet service, as well as its quality. --dmm =09 =09 --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFlUEvORgD1qCZ2KcRAplKAJ4rkw8QurpdBTlnZgI4lc/QsK5fCACfR8hT rqLjLFVsaodvgGr1vHke3G0= =cWZ6 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- --===============1537263329== 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 --===============1537263329==-- From ram-bounces@iab.org Fri Dec 29 11:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KcN-0003Uk-Ck; Fri, 29 Dec 2006 11:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0KcL-0003Ua-UW for ram@iab.org; Fri, 29 Dec 2006 11:30:01 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0KcH-0004Lt-IF for ram@iab.org; Fri, 29 Dec 2006 11:30:01 -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 kBTGTs8X005453; Fri, 29 Dec 2006 08:29:54 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBTGTski005452; Fri, 29 Dec 2006 08:29:54 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 29 Dec 2006 08:29:54 -0800 From: David Meyer To: RJ Atkinson Subject: Re: [RAM] Traffic Engineering Message-ID: <20061229162954.GB5059@1-4-5.net> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> Mime-Version: 1.0 In-Reply-To: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.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: 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: , Content-Type: multipart/mixed; boundary="===============0482455925==" Errors-To: ram-bounces@iab.org --===============0482455925== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2006 at 09:53:46AM -0500, RJ Atkinson wrote: >=20 > I think that some folks on this list are not familiar > with what issues/problems are currently being addressed with > traffic engineering. There was concern expressed at NANOG > about potential loss of ability to use "traffic engineering" > if SHIM6 were widely deployed, but the details of those concerns > haven't been widely explained. >=20 > I also think that different parts of the Internet are > using traffic engineering to address different sets of issues/problems. >=20 > It would be helpful if operators [1] could enumerate the > myriad ways that traffic engineering is currently being used, > including what solution folks are trying to achieve. That is, > the kind of detail that I'm looking for something more like "force > traffic off of link A until that link can be upgraded, because that > link is heavily congested just now" not "re-route traffic". >=20 Jason Schiller has a couple of nice presentations on this topic. See e.g., http://www.nanog.org/mtg-0510/schiller.html http://www.nanog.org/mtg-0505/schiller.html he also had a nice presentation at the R&A workshop. I'll see if I can get that publicly available somewhere. > Then maybe someone, ideally some operator person, could > maintain a list of these uses and problem/solution information. > This would help in evaluating whether potential solutions are > sufficient to meet existing known operational needs. Good idea, though I'm not sure why it would need to be an ops type (they're already under quite a bit of stress in the day job, etc). --dmm --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFlUKCORgD1qCZ2KcRAjTHAJ0f/X7OwJDr9Lys1KP2yNLqai9o+QCfW8RC cEWOaMat6xr3GXFoIq3aMTw= =hIMv -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- --===============0482455925== 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 --===============0482455925==-- From ram-bounces@iab.org Fri Dec 29 11:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Kej-0003ke-V8; Fri, 29 Dec 2006 11:32:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Kei-0003kT-Hp for ram@iab.org; Fri, 29 Dec 2006 11:32:28 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0KeP-00052i-3v for ram@iab.org; Fri, 29 Dec 2006 11:32:28 -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 kBTGW34P005487; Fri, 29 Dec 2006 08:32:03 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBTGW3bm005486; Fri, 29 Dec 2006 08:32:03 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 29 Dec 2006 08:32:03 -0800 From: David Meyer To: John Schnizlein Subject: Re: [RAM] Goal: Minimising Routing Entropy Message-ID: <20061229163203.GC5059@1-4-5.net> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> Mime-Version: 1.0 In-Reply-To: <983f0edbc2c1359315496968b09144ad@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: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============0571165536==" Errors-To: ram-bounces@iab.org --===============0571165536== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZLFUWh1odzi/v6L" Content-Disposition: inline --4ZLFUWh1odzi/v6L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2006 at 10:18:10AM -0500, John Schnizlein wrote: >=20 > On Dec 29, 2006, at 9:42 AM, RJ Atkinson wrote: > > > > I'd like to suggest that an architectural goal > >for any new effort should be to reduce/minimise Routing > >Entropy. We know that doing this will address the near-term > >engineering issues identified by tli and others. It also > >will fundamentally improve the scalability of the Internet > >(including but not limited to the IPv6 Internet) over the > >longer term. >=20 > One step toward agreement on terminology might be to replace=20 > "minimizing" here with "limiting growth of". Strictly minimizing is=20 > likely to produce impractical results. Are there analytic results that= =20 > suggest practical bounds on routing entropy or its growth? To that point, are there more precise definitions (and measurements) of "Routing Entropy" around? --dmm --4ZLFUWh1odzi/v6L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFlUMDORgD1qCZ2KcRAok+AJwM3ufEAGfChth99QxgAKaFVmX0qgCfYB/6 Im+Fqfa3NvJhf/KGdWVXb8I= =UWLo -----END PGP SIGNATURE----- --4ZLFUWh1odzi/v6L-- --===============0571165536== 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 --===============0571165536==-- From ram-bounces@iab.org Fri Dec 29 11:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Kqf-0000Hk-GF; Fri, 29 Dec 2006 11:44:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Kqd-0000Hb-Uw for ram@iab.org; Fri, 29 Dec 2006 11:44:47 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0Kqb-0004mi-LU for ram@iab.org; Fri, 29 Dec 2006 11:44:47 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net[24.125.117.214]) by comcast.net (sccrmhc13) with SMTP id <2006122916442901300ppslee>; Fri, 29 Dec 2006 16:44:45 +0000 In-Reply-To: <20061229162415.GA5059@1-4-5.net> References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@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: <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.com> Content-Transfer-Encoding: 7bit From: tvest@eyeconomics.com Subject: Re: [RAM] Terminology: Routing Entropy Date: Fri, 29 Dec 2006 11:44:18 -0500 To: David Meyer X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.3 (/) 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: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 29, 2006, at 11:24 AM, David Meyer wrote: > Back to the routing entropy issue: The nature of the > dynamics of the UPDATE stream is directly related to the > amount (and the granularity of) the information that is > carried in the DFZ. All of this will effect not only the > cost of providing Internet service, as well as its > quality. Is it actually, today? I thought GIH's work last year showed that recent/current update dynamics were substantially driven by a relatively small number of operators with questionable configs/ competence? http://202.12.29.20/meetings/21/docs/sigs/routing/routing-pres-huston- routing-update.pdf http://streaming.apnic.net/meetings/21/video/routing/huston.mov Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFlUXoUHTO4sHEFsERApsRAJ9z4qeRSFw0S3HiC6IJLK3NnmT8xQCePwx8 ANAuCszP7GWOZh6G2GO+vD4= =Rz+x -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 12:04:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0L9n-0007zS-I2; Fri, 29 Dec 2006 12:04:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0L9m-0007zM-GW for ram@iab.org; Fri, 29 Dec 2006 12:04:34 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0L9k-0004z3-0d for ram@iab.org; Fri, 29 Dec 2006 12:04:34 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 55135898C4; Fri, 29 Dec 2006 19:04:28 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 02801898C0; Fri, 29 Dec 2006 19:04:27 +0200 (EET) Message-ID: <45954A9D.7080606@piuha.net> Date: Fri, 29 Dec 2006 19:04:29 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Roland Dobbins , rja@extremenetworks.com Subject: Re: [RAM] Traffic Engineering References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> In-Reply-To: <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.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: 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 Roland, Ran >> ms are currently being addressed with >> traffic engineering. There was concern expressed at NANOG >> about potential loss of ability to use "traffic engineering" >> if SHIM6 were widely deployed, but the details of those concerns >> haven't been widely explained. > > SHIM6 simply isn't practical for a number of reasons, difficulties in > traffic engineering with an architecture of this type being least > among them. > > Just handing off path-selection functionality to the endstation and > the concept of multiple addresses on the endstation creates a > troubleshooting and support nightmare which neither enterprises nor > individuals can be expected to accept. The problem SHIM6 purported to > solve is a) much more fundamental and larger in scope than the SHIM6 > proponents realized (read all of RFC4192 for a sense of this) and b) > is rendered moot by the fact that registries are now providing PI > space to organizations which need it, anyways. Let me take a slightly different viewpoint into this. There are legitimate needs for providers to perform traffic engineering, including TE related to multihomed sites. Most of the pain that NANOG people and others are feeling comes from the fact that we really have no good, scaleable solution for this. We are starting to hand off PI space, which we know works but (a) may increase the overall Internet routing difficulties and (b) is unlikely to be given to organizations of all sizes. But it does not necessarily follow that Shim6 is a bad solution. The question you have to ask is who are these solutions targeted for. I fully agree that Shim6 is not -- at least as defined now -- a solution that makes allows centralized TE and control of multihoming, and it does not look appealing for very big sites where PI space looks a lot more attractive. But at the same time, a host based solution is very attractive in SOHO and when you either are or want to be independent of provider decisions in what you do. I don't think we want the multihoming decisions of my multi-interface laptop to be handled by the network; that wouldn't scale. My personal belief at the moment is that we will be needing both network/provider based and host based solutions. It might even be that we can discover a mechanism that allows us to do both. Yes, provider TE is a requirement but that's not the same thing as provider-based solutions being the only one that we need. In getting to those solutions, it is indeed important that we understand the different TE requirements. Its also good to keep in mind that many of the problems we are seeing are not only multihoming issues, but a combination of issues related to provider independence, renumbering, TE, peering complexity growth, limitations of the protocols we have, and even errors and malicious acts. So lets solve a bigger problem than just multihoming TE. (Also, we've already got multiple addresses on endstations, quite independent of Shim6 or other host-based multihoming solutions. And we are starting to see devices that make multihoming decisions on the host, regardless of any specific support in the IP layer for that. As an example, I have a cell phone that has seven radio interfaces, most of which can run IP and some of which will appear as separate interfaces from an IP perspective.) --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 12:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LL4-0003g4-2l; Fri, 29 Dec 2006 12:16:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LL2-0003eF-2W for ram@iab.org; Fri, 29 Dec 2006 12:16:12 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LL0-0000LY-RV for ram@iab.org; Fri, 29 Dec 2006 12:16:12 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2006 09:16:11 -0800 X-IronPort-AV: i="4.12,219,1165219200"; d="scan'208"; a="49644856:sNHT45921538" 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 kBTHGADB026080 for ; Fri, 29 Dec 2006 12:16:10 -0500 Received: from [70.6.81.235] (rtp-vpn3-748.cisco.com [10.82.218.239]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBTHG8G9020688 for ; Fri, 29 Dec 2006 12:16:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45954A9D.7080606@piuha.net> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 09:15:53 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2058; t=1167412570; x=1168276570; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=8mC8Ft5zJfvyWa0LNU59Plq9xM/y7nbPfWtA8BtXnyw=; b=r+KK3r9Q4eGnW61ovrBbx3qViRkixzG9hePoJ0vJ/989UMUP2vAjR+Q4v1cgeKOzBQ+6ZZxr rSNHTOWk+lOB1cgcvb0HYW9yyrI06ZSLepKJtITmCyhrKu2/1BPyfJRv; 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: 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 Dec 29, 2006, at 9:04 AM, Jari Arkko wrote: > But at the same time, a host based > solution is very attractive in SOHO and when > you either are or want to be independent of > provider decisions in what you do. I don't believe this is attractive to SOHO users in the least; the technical complexity of troubleshooting has shot up significantly. > I don't > think we want the multihoming decisions of > my multi-interface laptop to be handled by > the network; that wouldn't scale. I'm not sure I agree with this statement. > (Also, we've already got multiple addresses > on endstations, quite independent of Shim6 > or other host-based multihoming solutions. > And we are starting to see devices that > make multihoming decisions on the host, > regardless of any specific support in the > IP layer for that. As an example, I have > a cell phone that has seven radio interfaces, > most of which can run IP and some of which > will appear as separate interfaces from an > IP perspective.) Yes, and merely utilizing such a system as an end-user is difficult for even fairly technical folks, and this paradigm in general is quite problematic for enterprises who wish to integrate more-or-less- universally mobile network end-points into their networks. 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. ----------------------------------------------------------------------- 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 Fri Dec 29 12:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LMP-00049G-UD; Fri, 29 Dec 2006 12:17:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LMP-000498-9e for ram@iab.org; Fri, 29 Dec 2006 12:17:37 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LMO-0000tp-0n for ram@iab.org; Fri, 29 Dec 2006 12:17:37 -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 5917869; Fri, 29 Dec 2006 12:17:33 -0500 In-Reply-To: <20061229163203.GC5059@1-4-5.net> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> <20061229163203.GC5059@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/mixed; boundary=Apple-Mail-15-126890021 Message-Id: <60552A9B-F0E1-44FE-8D6A-93CC2164BFFD@multicasttech.com> From: Marshall Eubanks Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 29 Dec 2006 12:17:30 -0500 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 --Apple-Mail-15-126890021 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello; On Dec 29, 2006, at 11:32 AM, David Meyer wrote: > > On Fri, Dec 29, 2006 at 10:18:10AM -0500, John Schnizlein wrote: >> >> On Dec 29, 2006, at 9:42 AM, RJ Atkinson wrote: >>> >>> I'd like to suggest that an architectural goal >>> for any new effort should be to reduce/minimise Routing >>> Entropy. We know that doing this will address the near-term >>> engineering issues identified by tli and others. It also >>> will fundamentally improve the scalability of the Internet >>> (including but not limited to the IPv6 Internet) over the >>> longer term. >> >> One step toward agreement on terminology might be to replace >> "minimizing" here with "limiting growth of". Strictly minimizing is >> likely to produce impractical results. Are there analytic results >> that >> suggest practical bounds on routing entropy or its growth? > > To that point, are there more precise definitions (and > measurements) of "Routing Entropy" around? There is a routing entropy defined in US Patent 5596722 --Apple-Mail-15-126890021 Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name=spacer.gif Content-Disposition: inline; filename=spacer.gif R0lGODlhAQABAIAAAAAAAAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw== --Apple-Mail-15-126890021 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Packet routing system and method for achieving uniform link usage and minimizing link load; US Patent Issued on January 21, 1997 This defines it as follows : for any pair of nodes in network, find all paths between then, and the link usage probability (LUP) for each link in such path, the LUP being F / TC, where F is the load on the link, C is the link capacity, and T is the total network load. The NRE (normalized routing entropy) is - (1/T) * Sum (LUP log LUP), the sum being over all links. This patent picks the routing that maximizes the NRE for the network. Suppose that there are 2 links, of equal capacity, and 2 cases. In one, all traffic goes over link 1; in the other, both links share the traffic. (Let T = 1 for simplicity.) Case 1 : LUP 1 = 1, LUP 2 = 0, NRE = 0 Care 2 : LUP 1 = 1/2, LUP 2 = 1/2, NRE = 0.693 so case 2 would be chosen. In other words, this technique equalizes the load over all links. Note that this routing entropy is a "global" concept. In other words, if I have a choice to send packets through link 1 or link 2, how do I determine which choice has a lower entropy ? I need to know the complete routing table for the entire network. Wouldn't a useful design principle be to favor local concepts over global ones ? Regards Marshall > > --dmm > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram --Apple-Mail-15-126890021 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 --Apple-Mail-15-126890021-- From ram-bounces@iab.org Fri Dec 29 12:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LTR-0006Uh-3X; Fri, 29 Dec 2006 12:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LTP-0006Ub-LZ for ram@iab.org; Fri, 29 Dec 2006 12:24:51 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LTM-0002Qs-8y for ram@iab.org; Fri, 29 Dec 2006 12:24:51 -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 kBTHOeAk006532; Fri, 29 Dec 2006 09:24:40 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBTHOeP8006531; Fri, 29 Dec 2006 09:24:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 29 Dec 2006 09:24:40 -0800 From: David Meyer To: tvest@eyeconomics.com Subject: Re: [RAM] Terminology: Routing Entropy Message-ID: <20061229172440.GA6359@1-4-5.net> References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@1-4-5.net> <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.com> Mime-Version: 1.0 In-Reply-To: <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.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.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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="===============2140215210==" Errors-To: ram-bounces@iab.org --===============2140215210== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Tom, > > Back to the routing entropy issue: The nature of the > > dynamics of the UPDATE stream is directly related to the > > amount (and the granularity of) the information that is > > carried in the DFZ. All of this will effect not only the > > cost of providing Internet service, as well as its > > quality. >=20 > Is it actually, today? I thought GIH's work last year showed that =20 > recent/current update dynamics were substantially driven by a =20 > relatively small number of operators with questionable configs/=20 > competence? >=20 > http://202.12.29.20/meetings/21/docs/sigs/routing/routing-pres-huston-=20 > routing-update.pdf > http://streaming.apnic.net/meetings/21/video/routing/huston.mov A couple of points:=20 (i). It defintely appears that the distribution is heavy-tailed (which, BTW is a characteristic of the autocovariance function of long-memory processes). However, these studies didn't focus on the burstiness or memory ("lag") of the UPDATE stream time series (process), which is what I'm after here. (ii). These studies were not, to the best of my knowledge, looking for LRD. And as I mentioned, there is all kinds of noise in the signal, such as the (inherent) smoothing properties of the MRAI timer, various effects in the incoming messasge queue, to name a few. Further, LRD, while mathematically well definted, is a particularly difficult property to work with, precisely because such a signal "hides" in low-frequency events. =20 =09 In any event, to the best of my knowledge, no one has looked at the UPDATE signal stream from this (LRD) perspective (and BTW, someone please correct me if I'm wrong). =20 --dmm --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFlU9YORgD1qCZ2KcRAr0yAKCMxHrY765XBBXP04rYVuYummRj3ACdF1nc nDnyidZEJ39bJEm9wI3Qoug= =oDLt -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- --===============2140215210== 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 --===============2140215210==-- From ram-bounces@iab.org Fri Dec 29 12:37:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LfP-0002bl-6E; Fri, 29 Dec 2006 12:37:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LfO-0002Xx-D0 for ram@iab.org; Fri, 29 Dec 2006 12:37:14 -0500 Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LfL-0005iW-4m for ram@iab.org; Fri, 29 Dec 2006 12:37:14 -0500 Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 42C72599C7; Fri, 29 Dec 2006 12:35:44 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 29 Dec 2006 12:35:44 -0500 X-Sasl-enc: EwqGZbJQrCF63aMRKKkRs1We+9NYX2zEkK9gjCuLtrNX 1167413743 Received: from [127.0.0.1] (unknown [149.9.0.57]) by mail.messagingengine.com (Postfix) with ESMTP id EDCFD1407E; Fri, 29 Dec 2006 12:35:42 -0500 (EST) Message-ID: <45955234.9060302@eml.cc> Date: Fri, 29 Dec 2006 18:36:52 +0100 From: Per Heldal User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] Traffic Engineering References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> In-Reply-To: <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Roland Dobbins wrote: > > On Dec 29, 2006, at 9:04 AM, Jari Arkko wrote: > >> But at the same time, a host based >> solution is very attractive in SOHO and when >> you either are or want to be independent of >> provider decisions in what you do. > > I don't believe this is attractive to SOHO users in the least; the > technical complexity of troubleshooting has shot up significantly. How do you know what type of tools will be available at deployment time for a technology for which the specification is not yet complete, and currently lacks implementations to even play with? [snip] > > Yes, and merely utilizing such a system as an end-user is difficult for > even fairly technical folks, and this paradigm in general is quite > problematic for enterprises who wish to integrate > more-or-less-universally mobile network end-points into their networks. > > 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. Isn't it premature to assume that there will be no tools and developments happening on top on shim6? Would you similarly dismiss the original specifications for e.g. TCP on the assumption that there will be no such things as stateful firewalls and load-balancers? I'm not convinced that shim6 is the final solution. Still it's not impossible to imagine solutions to coordinate path-selection among large numbers of hosts in an end-network to achieve site-wide policies for traffic-management. //per _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 13:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0MSw-00041i-Tx; Fri, 29 Dec 2006 13:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0MSu-00041a-OM for ram@iab.org; Fri, 29 Dec 2006 13:28:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0MSs-0002rt-Gn for ram@iab.org; Fri, 29 Dec 2006 13:28:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2006 13:28:23 -0500 X-IronPort-AV: i="4.12,219,1165208400"; d="scan'208"; a="110530735:sNHT43507868" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBTISLjs015892; Fri, 29 Dec 2006 13:28:22 -0500 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBTISADo013112; Fri, 29 Dec 2006 10:28:15 -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); Fri, 29 Dec 2006 10:28:14 -0800 Received: from [192.168.0.101] ([10.21.148.97]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 10:28:14 -0800 In-Reply-To: <60552A9B-F0E1-44FE-8D6A-93CC2164BFFD@multicasttech.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> <20061229163203.GC5059@1-4-5.net> <60552A9B-F0E1-44FE-8D6A-93CC2164BFFD@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95BECB70-1F5D-4BAC-98C3-9276056AA861@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Goal: Minimising Routing Entropy Date: Fri, 29 Dec 2006 10:28:12 -0800 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Dec 2006 18:28:14.0061 (UTC) FILETIME=[19FF41D0:01C72B77] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=149; t=1167416902; x=1168280902; c=relaxed/simple; s=rtpdkim1001; 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 |To:=20Marshall=20Eubanks=20; bh=PtTlMnwh1cWPRGC8M/ww/gpj2oDveDiU91nmKOLWqxo=; b=nX2ArSZQoPti3YkLz1T5mDKHVBPz+gdWdvNdfT3HjtGB0g25MDPai3sLLYGB4DzSGtgy6nuD 26DogdstZoi2XaBVmEH9ChcNhPrQW1aFpbnJw5UjyrarvnSwR/58t9qx; Authentication-Results: rtp-dkim-1; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: RJ Atkinson , John Schnizlein , 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 > Wouldn't a useful design principle be to favor local concepts over > global ones ? Not if you're trying to address global issues. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 13:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Mfi-0000n6-Kw; Fri, 29 Dec 2006 13:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Mfg-0000i7-UK for ram@iab.org; Fri, 29 Dec 2006 13:41:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Mff-00052y-8k for ram@iab.org; Fri, 29 Dec 2006 13:41:36 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2006 10:41:35 -0800 X-IronPort-AV: i="4.12,219,1165219200"; d="scan'208"; a="49652976:sNHT46303082" 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 kBTIfZsi031012 for ; Fri, 29 Dec 2006 13:41:35 -0500 Received: from [70.6.81.235] (rtp-vpn3-748.cisco.com [10.82.218.239]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBTIfWG9013206 for ; Fri, 29 Dec 2006 13:41:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45955234.9060302@eml.cc> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> <45955234.9060302@eml.cc> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 10:41: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=2013; t=1167417695; x=1168281695; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=fwF6ZShhhS3gNSbi2suLZ8a3tYgX1AIWQj8KjOsGHxY=; b=ajnCMmUKg2pNh22LDCUTs7yrOo2OkjEQ5/gwZAHFueHmDfGSZLyVQ+lnrHV5UVa2RSh+7ffN +BYf9QjF7ZWaCx7RTpbctIyUQ+ChzDOZB/8IAIE+lXrgF/jOde5M81SN; 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 On Dec 29, 2006, at 9:36 AM, Per Heldal wrote: > How do you know what type of tools will be available at deployment > time > for a technology for which the specification is not yet complete, and > currently lacks implementations to even play with? I believe the basic concept to be so fatally flawed that there is no way a set of tools would make this technology feasible. > > Isn't it premature to assume that there will be no tools and > developments happening on top on shim6? Would you similarly > dismiss the > original specifications for e.g. TCP on the assumption that there will > be no such things as stateful firewalls and load-balancers? Absent a fundamental change to the loosely-coupled nature of the protocol stack, the deconflation of the host and locator IDs, and a complete revolution in network-management tools/systems (and a vendor renaissance to implement all of this) inspired by SHIM (in other words, this sort of technology applied to something which most definitively is not IPv6 or even a closely-related derivative thereof), I can forecast no tools or developments which would make this technology less problematic and more supportable on any kind of scale beyond networking enthusiasts and tinkerers. > Still it's not > impossible to imagine solutions to coordinate path-selection among > large > numbers of hosts in an end-network to achieve site-wide policies for > traffic-management. Although the desirability and operational complexity of such a system are deserving of serious discussion and investigation, it is a reasonable extrapolation to at least posit something of this sort, hich is why I stated that the possibility of traffic engineering issues raised by SHIM6 were the least of its problems. ----------------------------------------------------------------------- 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 Fri Dec 29 16:10:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Oz0-0002Qt-FG; Fri, 29 Dec 2006 16:09:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Oyz-0002Qj-SV for ram@iab.org; Fri, 29 Dec 2006 16:09:41 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Oyz-0003dp-3B for ram@iab.org; Fri, 29 Dec 2006 16:09:41 -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 kBTL9a1T029857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Dec 2006 15:09:38 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> Message-Id: <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> From: Bruce Curtis Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 15:09:34 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba X-BeenThere: ram@iab.org X-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="===============1347569329==" Errors-To: ram-bounces@iab.org --===============1347569329== Content-Type: multipart/alternative; boundary=Apple-Mail-18-140813980 --Apple-Mail-18-140813980 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 29, 2006, at 10:12 AM, Roland Dobbins wrote: > > On Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: > >> ms are currently being addressed with >> traffic engineering. There was concern expressed at NANOG >> about potential loss of ability to use "traffic engineering" >> if SHIM6 were widely deployed, but the details of those concerns >> haven't been widely explained. > > SHIM6 simply isn't practical for a number of reasons, difficulties > in traffic engineering with an architecture of this type being > least among them. While SHIM6 may make traffic engineering more difficult there may still be potential architectures with hierarchical routing and multiple addresses on the endstation that still allow traffic engineering. For example there was a discussion on architecture- discuss@ietf.org of a model where all of the multiple addresses of both endstations are included in each packet. > Just handing off path-selection functionality to the endstation and > the concept of multiple addresses on the endstation creates a > troubleshooting and support nightmare which neither enterprises nor > individuals can be expected to accept. While having a single global address for the end station is certainly simpler I'm not sure that having multiple addresses for an endstation is totally unacceptable. Endstations already deal with a simple form of multiple addresses since they have a localhost address and an IPv4 address on the network and with dual stack an IPv6 link local address plus an IPv6 global address. And essentially enterprises have already accepted the concept of multiple addresses for and endstation when they implement NAT, the endstation has a local/private address and a global address. On a historical note I'm glad to see them go but it wasn't considered unacceptable for an endstation to have an IPv4 address, an IPX address plus an Appletalk/Ethertalk address. Also I'm not a fan of VPN clients but that is another example of an endstation with multiple addresses that has largely been accepted. > The problem SHIM6 purported to solve is a) much more fundamental > and larger in scope than the SHIM6 proponents realized (read all of > RFC4192 for a sense of this) and b) is rendered moot by the fact > that registries are now providing PI space to organizations which > need it, anyways. > > ---------------------------------------------------------------------- > - > 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 --Apple-Mail-18-140813980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 29, 2006, = at 10:12 AM, Roland Dobbins wrote:


On Dec = 29, 2006, at 6:53 AM, RJ Atkinson wrote:

ms are currently being addressed with
traffic engineering.=A0 There was concern expressed = at NANOG
about potential loss of ability = to use "traffic engineering"
if SHIM6 were = widely deployed, but the details of those concerns
haven't been widely explained.
=

SHIM6 simply isn't practical for a number of = reasons, difficulties in traffic engineering with an architecture of = this type being least among them.

=A0 While SHIM6 may make = traffic engineering more difficult there may still be potential = architectures with hierarchical routing and multiple addresses on the = endstation that still allow traffic engineering.=A0 For example there = was a discussion on=A0architecture-discuss@ietf.or= g of a model where all of the multiple addresses of both endstations = are included in each packet.


Just handing off path-selection functionality to the = endstation and the concept of multiple addresses on the endstation = creates a troubleshooting and support nightmare which neither = enterprises nor individuals can be expected to accept.=A0

=A0 While having a single = global address for the end station is certainly simpler I'm not sure = that having multiple addresses for an endstation is totally = unacceptable.=A0 Endstations already deal with a simple form of multiple = addresses since they have a localhost address and an IPv4 address on the = network and with dual stack an=A0 IPv6=A0 link local address plus an = IPv6 global address.

=A0 And essentially = enterprises have already accepted the concept of multiple addresses for = and endstation when they implement NAT, the endstation has a = local/private address and a global address.

=A0 On a historical note = I'm glad to see them go but it wasn't considered unacceptable for an = endstation to have an IPv4 address, an IPX address plus an = Appletalk/Ethertalk address.

=A0 Also I'm not a fan of = VPN clients but that is another example of an endstation with multiple = addresses that has largely been accepted.

The problem SHIM6 purported to = solve is a) much more fundamental and larger in scope than the SHIM6 = proponents realized (read all of RFC4192 for a sense of this) and b) is = rendered moot by the fact that registries are now providing PI space to = organizations which need it, anyways.

Roland Dobbins <rdobbins@cisco.com> // = 408.527.6376 voice
All battles are = perpetual.

=A0=A0 =A0 =A0 = -- Milton Friedman




RAM mailing list



---

Bruce Curtis =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-18-140813980-- --===============1347569329== 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 --===============1347569329==-- From ram-bounces@iab.org Fri Dec 29 16:26:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PEN-0000uI-L6; Fri, 29 Dec 2006 16:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PEM-0000uC-Gh for ram@iab.org; Fri, 29 Dec 2006 16:25:34 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0PEK-0007OT-Jo for ram@iab.org; Fri, 29 Dec 2006 16:25:34 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 40955121A94; Fri, 29 Dec 2006 22:25:31 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 396E312078B; Fri, 29 Dec 2006 22:25:19 +0100 (CET) In-Reply-To: <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: other requirement? (was Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 22:25:12 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 Hi Roland, El 29/12/2006, a las 17:12, Roland Dobbins escribi=F3: > > On Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: > >> ms are currently being addressed with >> traffic engineering. There was concern expressed at NANOG >> about potential loss of ability to use "traffic engineering" >> if SHIM6 were widely deployed, but the details of those concerns >> haven't been widely explained. > > SHIM6 simply isn't practical for a number of reasons, difficulties in=20= > traffic engineering with an architecture of this type being least=20 > among them. > > Just handing off path-selection functionality to the endstation and=20 > the concept of multiple addresses on the endstation creates a=20 > troubleshooting and support nightmare which neither enterprises nor=20 > individuals can be expected to accept. I think this is an important point. As i read your input, a solution that results in that the end points=20 need to manage multiple IP addresses is simply a non starter, right? So, do people agree that a solution MUST expose a SINGLE IP address to=20= the hosts within the multihomed site? In your opinion, is there any other design choice made by the shim6=20 protocol that is flawed that we can also learn from and try to avoid=20 repeating? Regards, marcelo > The problem SHIM6 purported to solve is a) much more fundamental and=20= > larger in scope than the SHIM6 proponents realized (read all of=20 > RFC4192 for a sense of this) and b) is rendered moot by the fact that=20= > registries are now providing PI space to organizations which need it,=20= > anyways. > > = ----------------------------------------------------------------------- > 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 Fri Dec 29 16:34:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PMU-0005fl-QC; Fri, 29 Dec 2006 16:33:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PMT-0005e0-Gs for ram@iab.org; Fri, 29 Dec 2006 16:33:57 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0PMS-00007W-83 for ram@iab.org; Fri, 29 Dec 2006 16:33:57 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2006 13:33:54 -0800 X-IronPort-AV: i="4.12,219,1165219200"; d="scan'208"; a="49669803:sNHT47108656" 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 kBTLXsWk008859 for ; Fri, 29 Dec 2006 16:33:54 -0500 Received: from [70.6.81.235] (rtp-vpn3-748.cisco.com [10.82.218.239]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBTLXpG9002190 for ; Fri, 29 Dec 2006 16:33:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C49B8A2-3F3D-40A5-916C-EDF429BB52F0@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 13:33: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=3149; t=1167428034; x=1168292034; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=NyYXGuLjrIwrLAApZbmFkU65PTSyh0Y0Xa7YjoazjSU=; b=M0STxniCJqyICAQBtVWHXYnrNbmq2xnhTaA8XVqmYDSHTAY+F7UmaeFbDkRzHLX8gLtni32Z 6nIz/+cSrnmSaTmf3mu2/hUdJ58e45bGAI1NdycKOiKhh6aOLL4ayuow; 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: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 29, 2006, at 1:09 PM, Bruce Curtis wrote: > While having a single global address for the end station is > certainly simpler I'm not sure that having multiple addresses for > an endstation is totally unacceptable. Endstations already deal > with a simple form of multiple addresses since they have a > localhost address and an IPv4 address on the network and with dual > stack an IPv6 link local address plus an IPv6 global address. The percentage of hosts with IPv4/IPv6 dual-stack enabled which is not the result of an OS vendor default and which is consciously used for anything is nil. Multiple addresses are fine in terms of domain/functional separation. When multiple addresses are utilized to access a single logical domain on a workstation owned/used by a human being, things get out of hand very quickly in terms of supportability. > > And essentially enterprises have already accepted the concept of > multiple addresses for and endstation when they implement NAT, the > endstation has a local/private address and a global address. See above - where NAT is implemented, there is generally an 'inside' address used for the domain of intranet communications and an external address for the domain of everything else (i.e., the Internet). Even in extranet-types of deployments with dual-NATting taking place on both sides, with all the headaches and troubleshooting complexities a setup of that type entails, it is still orders of magnitude easier to support a special-purpose installation of this type within the bounded domain of site-to-site/ org-to-org connectivity than attempting to do so with a general user population within an enterprise, much less a population of home/SOHO users. > On a historical note I'm glad to see them go but it wasn't > considered unacceptable for an endstation to have an IPv4 address, > an IPX address plus an Appletalk/Ethertalk address. These worked pretty well when they were necessary; they gave way to translational gateways and then proxies, and then have for the most part withered away entirely. Again, there was no 'casual' use of such systems at the whim of the user population, and therefore the supportability problems of such architectures, ugly and problematic as they were, pales in comparison to what will be encountered on a general system intended for casual use by everyone in the world to do anything and everything he wants, anytime he wishes to do so. > Also I'm not a fan of VPN clients but that is another example of > an endstation with multiple addresses that has largely been accepted. Again, see above - firstly, VPN support for enterprises is a bounded logical domain (and even supporting VPN users is no fun, if you've ever done it; so, the argument undermines itself completely even apart from the logical domain issue). ----------------------------------------------------------------------- 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 Fri Dec 29 17:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Q01-0004Xs-Qi; Fri, 29 Dec 2006 17:14:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Q00-0004Xm-QL for ram@iab.org; Fri, 29 Dec 2006 17:14:48 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Pzz-0002X8-HR for ram@iab.org; Fri, 29 Dec 2006 17:14:48 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 1FBF27DC6 for ; Fri, 29 Dec 2006 14:14:41 -0800 (PST) Received: from JMHLap3.joelhalpern.com (pool-70-104-228-188.fred.east.verizon.net [70.104.228.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id BCF507DB0 for ; Fri, 29 Dec 2006 14:14:38 -0800 (PST) Message-Id: <7.0.1.0.0.20061229170702.0376bea8@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 29 Dec 2006 17:14:22 -0500 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering In-Reply-To: <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> 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: 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 At 04:25 PM 12/29/2006, marcelo bagnulo braun wrote: >So, do people agree that a solution MUST expose a SINGLE IP address >to the hosts within the multihomed site? No. While I would like to see a solution where the host does not have to be aware of multiple addresses, a) it may be that even in such a solution, some hosts may benefit by such awareness b) if we can spell out how the hosts make sensible choices, and why they need to make those choices, then it may be beneficial to require the host to have visibility to the multiple addresses. Further, it may be possible that hosts need / want to be aware of multiple remote addresses, without necessarily having awareness of their own multiplicity. There are many possibilities. While I have preferences and hopes as to what can work, and what is "simple", the guideline has to be "simple enough to do the job", not "simple enough to meet an arbitrary standard." Yours, Joel M. Halpern PS: The biggest problem with most of the multiple address work on hosts in the past (including some of the deprecated IPv6 address forms) was that hosts had no sensible way to understand how to use the addresses. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 17:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0QGE-0002Pg-Dq; Fri, 29 Dec 2006 17:31:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0QGD-0002PV-Hh for ram@iab.org; Fri, 29 Dec 2006 17:31:33 -0500 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0QGC-0008FD-Ma for ram@iab.org; Fri, 29 Dec 2006 17:31:33 -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 kBTMVVIa002017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Dec 2006 16:31:31 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1C49B8A2-3F3D-40A5-916C-EDF429BB52F0@cisco.com> 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> Message-Id: <400F21D4-E2A6-424F-B783-BD6F4F034C14@ndsu.edu> From: Bruce Curtis Subject: Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 16:31:28 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.7 (--) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 X-BeenThere: ram@iab.org X-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="===============0352121312==" Errors-To: ram-bounces@iab.org --===============0352121312== Content-Type: multipart/alternative; boundary=Apple-Mail-20-145727412 --Apple-Mail-20-145727412 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 29, 2006, at 3:33 PM, Roland Dobbins wrote: > > On Dec 29, 2006, at 1:09 PM, Bruce Curtis wrote: > >> While having a single global address for the end station is >> certainly simpler I'm not sure that having multiple addresses for >> an endstation is totally unacceptable. Endstations already deal >> with a simple form of multiple addresses since they have a >> localhost address and an IPv4 address on the network and with dual >> stack an IPv6 link local address plus an IPv6 global address. > > The percentage of hosts with IPv4/IPv6 dual-stack enabled which is > not the result of an OS vendor default and which is consciously > used for anything is nil. But dual stack was well discussed and accepted as the best method to migrate from IPv4 to IPv6. > Multiple addresses are fine in terms of domain/functional > separation. When multiple addresses are utilized to access a > single logical domain on a workstation owned/used by a human being, > things get out of hand very quickly in terms of supportability. What if an endstation had a single address that contained the information about prefixes from it's multiple ISPs? If the endstation just considered it a single address but the address contained information about multiple paths that could be used by devices in the core of the Internet for Traffic Engineering would you consider that acceptable? >> And essentially enterprises have already accepted the concept of >> multiple addresses for and endstation when they implement NAT, the >> endstation has a local/private address and a global address. > > See above - where NAT is implemented, there is generally an > 'inside' address used for the domain of intranet communications and > an external address for the domain of everything else (i.e., the > Internet). Even in extranet-types of deployments with dual-NATting > taking place on both sides, with all the headaches and > troubleshooting complexities a setup of that type entails, it is > still orders of magnitude easier to support a special-purpose > installation of this type within the bounded domain of site-to-site/ > org-to-org connectivity than attempting to do so with a general > user population within an enterprise, much less a population of > home/SOHO users. We will have to agree to disagree on this point. I don't agree that multiple addresses would be orders of magnitude more difficult to support than NAT. In fact given the choice I would rather support a network with multiple addresses on endstations than one with NAT. >> On a historical note I'm glad to see them go but it wasn't >> considered unacceptable for an endstation to have an IPv4 address, >> an IPX address plus an Appletalk/Ethertalk address. > > These worked pretty well when they were necessary; they gave way to > translational gateways and then proxies, and then have for the most > part withered away entirely. Again, there was no 'casual' use of > such systems at the whim of the user population, and therefore the > supportability problems of such architectures, ugly and problematic > as they were, pales in comparison to what will be encountered on a > general system intended for casual use by everyone in the world to > do anything and everything he wants, anytime he wishes to do so. But wouldn't the user be limited to using one of the multiple addresses for the endstation? They couldn't just casually chose any address. >> Also I'm not a fan of VPN clients but that is another example of >> an endstation with multiple addresses that has largely been accepted. > > Again, see above - firstly, VPN support for enterprises is a > bounded logical domain (and even supporting VPN users is no fun, if > you've ever done it; so, the argument undermines itself completely > even apart from the logical domain issue). Well, I agree that supporting VPN users is no fun. So we do agree on at least one thing. :-) However the problems I've encountered didn't seem to stem from the endstations essentially having multiple addresses. > > ---------------------------------------------------------------------- > - > 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 --Apple-Mail-20-145727412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 29, 2006, = at 3:33 PM, Roland Dobbins wrote:


On Dec = 29, 2006, at 1:09 PM, Bruce Curtis wrote:

=A0 = While having a single global address for the end station is = certainly simpler I'm not sure that having multiple addresses for an = endstation is totally unacceptable.=A0= Endstations already deal with a simple form of multiple = addresses since they have a localhost address and an IPv4 address on the = network and with dual stack an=A0 = IPv6=A0 link local = address plus an IPv6 global address.

The = percentage of hosts with IPv4/IPv6 dual-stack enabled which is not the = result of an OS vendor default and which is consciously used for = anything is nil.

=A0 But dual stack was well = discussed and accepted as the best method to migrate from IPv4 to = IPv6.

Multiple = addresses are fine in terms of domain/functional separation.=A0 When multiple addresses are = utilized to access a single logical domain on a workstation owned/used = by a human being, things get out of hand very quickly in terms of = supportability.

=A0 What if an endstation = had a single address that contained the information about prefixes from = it's multiple ISPs?=A0 If the endstation just considered it a single = address but the address contained information about multiple paths that = could be used by devices in the core of the Internet for Traffic = Engineering would you consider that acceptable?


=A0=A0And essentially enterprises = have already accepted the concept of multiple addresses for and = endstation when they implement NAT, the endstation has a local/private = address and a global address.

See above - = where NAT is implemented, there is generally an 'inside' address used = for the domain of intranet communications and an external address for = the domain of everything else (i.e., the Internet).=A0 Even in extranet-types of = deployments with dual-NATting taking place on both sides, with all the = headaches and troubleshooting complexities a setup of that type entails, = it is still orders of magnitude easier to support a special-purpose = installation of this type within the bounded domain of = site-to-site/org-to-org connectivity than attempting to do so with a = general user population within an enterprise, much less a population of = home/SOHO users.

=A0=A0 =A0We will have to agree = to disagree on this point.=A0 I don't agree that multiple addresses = would be orders of magnitude more difficult to support than NAT.=A0 In = fact given the choice I would rather support a network with multiple = addresses on endstations than one with NAT.

=A0=A0On a historical note I'm = glad to see them go but it wasn't considered unacceptable for an = endstation to have an IPv4 address, an IPX address plus an = Appletalk/Ethertalk address.

These worked = pretty well when they were necessary; they gave way to translational = gateways and then proxies, and then have for the most part withered away = entirely.=A0 Again, there = was no 'casual' use of such systems at the whim of the user population, = and therefore the supportability problems of such architectures, ugly = and problematic as they were, pales in comparison to what will be = encountered on a general system intended for casual use by everyone in = the world to do anything and everything he wants, anytime he wishes to = do so.

=A0 But wouldn't the user be = limited to using one of the multiple addresses for the endstation?=A0 = They couldn't just casually chose any address.


=A0Also I'm not a fan of VPN = clients but that is another example of an endstation with multiple = addresses that has largely been accepted.

Again, = see above - firstly, VPN support for enterprises is a bounded logical = domain (and even supporting VPN users is no fun, if you've ever done it; = so, the argument undermines itself completely even apart from the = logical domain issue).

=A0 Well, I agree that = supporting VPN users is no fun.=A0 So we do agree on at least one = thing.=A0 :-)

=A0= However the problems I've encountered didn't seem to stem from the = endstations essentially having multiple = addresses.


Roland Dobbins <rdobbins@cisco.com> // = 408.527.6376 voice
All battles are = perpetual.

=A0=A0 =A0 =A0 = -- Milton Friedman




RAM mailing list



---

Bruce Curtis =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-20-145727412-- --===============0352121312== 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 --===============0352121312==-- From ram-bounces@iab.org Fri Dec 29 17:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Qb9-0001F2-V4; Fri, 29 Dec 2006 17:53:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Qb8-0001Ed-Mw for ram@iab.org; Fri, 29 Dec 2006 17:53:10 -0500 Received: from inferno.ny1.corp.yahoo.com ([64.157.137.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Qb6-0005Le-Ch for ram@iab.org; Fri, 29 Dec 2006 17:53:10 -0500 Received: from assassin.hjny.corp.yahoo.com (assassin.hjny.corp.yahoo.com [63.209.167.137]) by inferno.ny1.corp.yahoo.com (8.13.8/8.13.4/pop-ny) with ESMTP id kBTMr8W6039013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Dec 2006 17:53:08 -0500 (EST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type:content-id; b=P0gwdJydqz3Zaw3U9QIe9ZElgF/HHvrZB48aFy+nLBAsJC33ojPDbldRxBqtf3ry Date: Fri, 29 Dec 2006 17:52:26 -0500 (EST) From: Igor Gashinsky X-X-Sender: igor@assassin.hjny.corp.yahoo.com To: Bruce Curtis Subject: Re: [RAM] Traffic Engineering In-Reply-To: <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> Message-ID: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="===============1347569329==" Content-ID: X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============1347569329== Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: some comments in-line... On Fri, 29 Dec 2006, Bruce Curtis wrote: :: :: On Dec 29, 2006, at 10:12 AM, Roland Dobbins wrote: :: :: > :: > On Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: :: > :: > > ms are currently being addressed with :: > > traffic engineering. There was concern expressed at NANOG :: > > about potential loss of ability to use "traffic engineering" :: > > if SHIM6 were widely deployed, but the details of those concerns :: > > haven't been widely explained. :: :: While SHIM6 may make traffic engineering more difficult there may still :: be potential architectures with hierarchical routing and multiple :: addresses on the endstation that still allow traffic engineering. For :: example there was a discussion on architecture-discuss@ietf.org of a :: model where all of the multiple addresses of both endstations are :: included in each packet. :: :: > Just handing off path-selection functionality to the endstation and the :: > concept of multiple addresses on the endstation creates a troubleshooting :: > and support nightmare which neither enterprises nor individuals can be :: > expected to accept. :: :: While having a single global address for the end station is certainly :: simpler I'm not sure that having multiple addresses for an endstation is :: totally unacceptable. Endstations already deal with a simple form of :: multiple addresses since they have a localhost address and an IPv4 address on :: the network and with dual stack an IPv6 link local address plus an IPv6 :: global address. So, let's take a look at the scalability of this solution -- lets say that I'm a very large global content provider, with a very complex TE requirement for my outbound traffic (business reasons, performance driven, politics, etc). I also have 100k-200k servers which serve end-users. Currently, all of my TE decisions happen on relatively few (100-200) routers that have full BGP feeds, several million paths in the routing table, and understand that if I have pathX and pathY to an end user, they should prefer pathX (ie basic BGP-based TE). With Shim6, even if every end-station will provide me with all of their endpoint ip's during the initial handshake (ie establish shim state immediately), I now have 200k *servers* that each must deal with the overhead (albeit very small) of maintaining that state, as well as be loaded with full routing tables (and all of those paths) to make the Te decisions (ipX is via pathX, and ipY is via pathY, and since we prefer pathX vs pathY, chose ipX), which is a rather huge overhead for every server and every connection for that server. This is absolutely a non-starter for any decent size content provider based on that lack of scalability alone. And, yes, I know we can come up with some sort of a centralized TE server which will hold the full tables, and when queried will reply with which IP to use, but now you are essentially delaying every new connection, inserting another element and a point of failure/complexity into the equation, and that is something that most of us are not willing to live with (well, we might be willing to live with the complexity, but our users are not willing to live with the connection delays -- u should see the number of complaints we get if we drop the first SYN of a connection, and this would be a very similar delay). -igor ----------------------+----------------------+------------------ Igor Gashinsky, CISSP | Network Architecture | Yahoo! Inc. igor@yahoo-inc.com | cell 917.807.2213 | Do You... Yahoo? ----------------------+----------------------+------------------ --===============1347569329== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1347569329== 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 --===============1347569329==-- From ram-bounces@iab.org Fri Dec 29 19:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0SVf-0002fl-6e; Fri, 29 Dec 2006 19:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0SVd-0002fg-Jt for ram@iab.org; Fri, 29 Dec 2006 19:55:37 -0500 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0SVc-0005k0-B8 for ram@iab.org; Fri, 29 Dec 2006 19:55:37 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (alnrmhc14) with SMTP id <20061230005535b1400mk031e>; Sat, 30 Dec 2006 00:55:35 +0000 Message-ID: <06e001c72bac$bb7ab960$6a01a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com><7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Fri, 29 Dec 2006 18:52:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit 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: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Thank you for asking. One topic that came up repeatedly at NANOG was concern about SHIM6 reliance on hosts that are massively vulnerable to viruses and botnetting (visualize a botnet controller switching all owned hosts selecting transit paths from TWC to SBCGLOBAL, within a minute or two). Spencer From: "marcelo bagnulo braun" To: "Roland Dobbins" Cc: Sent: Friday, December 29, 2006 3:25 PM Subject: other requirement? (was Re: [RAM] Traffic Engineering Hi Roland, El 29/12/2006, a las 17:12, Roland Dobbins escribió: > > On Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: > >> ms are currently being addressed with >> traffic engineering. There was concern expressed at NANOG >> about potential loss of ability to use "traffic engineering" >> if SHIM6 were widely deployed, but the details of those concerns >> haven't been widely explained. > > SHIM6 simply isn't practical for a number of reasons, difficulties in > traffic engineering with an architecture of this type being least among > them. > > Just handing off path-selection functionality to the endstation and the > concept of multiple addresses on the endstation creates a troubleshooting > and support nightmare which neither enterprises nor individuals can be > expected to accept. I think this is an important point. As i read your input, a solution that results in that the end points need to manage multiple IP addresses is simply a non starter, right? So, do people agree that a solution MUST expose a SINGLE IP address to the hosts within the multihomed site? In your opinion, is there any other design choice made by the shim6 protocol that is flawed that we can also learn from and try to avoid repeating? Regards, marcelo > The problem SHIM6 purported to solve is a) much more fundamental and > larger in scope than the SHIM6 proponents realized (read all of RFC4192 > for a sense of this) and b) is rendered moot by the fact that registries > are now providing PI space to organizations which need it, anyways. > > ----------------------------------------------------------------------- > 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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 22:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0UiQ-0006wY-4a; Fri, 29 Dec 2006 22:16:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0UiO-0006uh-OY for ram@iab.org; Fri, 29 Dec 2006 22:16:56 -0500 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0UiK-0006bv-G2 for ram@iab.org; Fri, 29 Dec 2006 22:16:56 -0500 Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JB20083TH41D6@firewall.mci.com> for ram@iab.org; Sat, 30 Dec 2006 03:16:50 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JB200GMQH41S1@pmismtp04.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 03:16:49 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JB200J1NH414M@pmismtp04.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 03:16:49 +0000 (GMT) Date: Sat, 30 Dec 2006 03:16:49 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Terminology: Routing Entropy In-reply-to: <20061229162415.GA5059@1-4-5.net> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: ram@iab.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@1-4-5.net> X-Spam-Score: 0.1 (/) 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 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). 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? How 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). I look forward to the study though :) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 22:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V30-0005Sj-1G; Fri, 29 Dec 2006 22:38:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V2z-0005Sb-5w for ram@iab.org; Fri, 29 Dec 2006 22:38:13 -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 1H0V2x-0003gT-QZ for ram@iab.org; Fri, 29 Dec 2006 22:38:13 -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.52) id 1H0V2w-0007Mt-E6 for ram@iab.org; Fri, 29 Dec 2006 19:38:10 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Dec 2006 04:38:01 +0100 To: Tony Li ,Marshall Eubanks From: JFCM Subject: Re: [RAM] Goal: Minimising Routing Entropy In-Reply-To: <95BECB70-1F5D-4BAC-98C3-9276056AA861@cisco.com> References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> <20061229163203.GC5059@1-4-5.net> <60552A9B-F0E1-44FE-8D6A-93CC2164BFFD@multicasttech.com> <95BECB70-1F5D-4BAC-98C3-9276056AA861@cisco.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: 2.0 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Content-Type: multipart/mixed; boundary="===============1357579957==" Errors-To: ram-bounces@iab.org Message-Id: --===============1357579957== Content-Type: multipart/alternative; boundary="----MTrjktsiqnzczaqjnqvqymmzgflrtapume" ------MTrjktsiqnzczaqjnqvqymmzgflrtapume Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-14C52AD At 19:28 29/12/2006, Tony Li wrote: >>Wouldn't a useful design principle be to favor local concepts over >>global ones ? > >Not if you're trying to address global issues. We are trying to address global issues from local diversity. This is the difference between (de)centralised and distributed (user centric) architectures. Question is to understand if a better decentralisation is possible or if we must switch to decentralisation, with all the resulting consequences for the architecture, the IETF and the Internet culture and governance. Not a small thing, but IMO the network development is such that decentralised (network centric) solutions have become too complex. jfc ------MTrjktsiqnzczaqjnqvqymmzgflrtapume Content-Type: text/html At 19:28 29/12/2006, Tony Li wrote:
>>Wouldn't a useful design principle be to favor local concepts over
>>global ones ?
>
>Not if you're trying to address global issues.

We are trying to address global issues from local diversity. This is
the difference between (de)centralised and distributed (user centric)
architectures. Question is to understand if a better decentralisation
is possible or if we must switch to decentralisation, with all the
resulting consequences for the architecture, the IETF and the
Internet culture and governance. Not a small thing, but IMO the
network development is such that decentralised (network centric)
solutions have become too complex.
jfc

------MTrjktsiqnzczaqjnqvqymmzgflrtapume-- --===============1357579957== 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 --===============1357579957==-- From ram-bounces@iab.org Fri Dec 29 22:39:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V3z-0005oU-IS; Fri, 29 Dec 2006 22:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V3y-0005oP-Bb for ram@iab.org; Fri, 29 Dec 2006 22:39:14 -0500 Received: from pmesmtp04.mci.com ([199.249.20.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0V3v-0003pO-3h for ram@iab.org; Fri, 29 Dec 2006 22:39:14 -0500 Received: from pmismtp02.mcilink.com ([166.37.158.162]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JB20048LI0XYK@firewall.mci.com> for ram@iab.org; Sat, 30 Dec 2006 03:36:33 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JB200JP5I0X6V@pmismtp02.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 03:36:33 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JB200M2CI0WH4@pmismtp02.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 03:36:33 +0000 (GMT) Date: Sat, 30 Dec 2006 03:36:32 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Goal: Minimising Routing Entropy In-reply-to: <983f0edbc2c1359315496968b09144ad@cisco.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: John Schnizlein Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <4F587A0E-AF10-4B7C-BD06-A0B79AEBE5D1@extremenetworks.com> <983f0edbc2c1359315496968b09144ad@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Fri, 29 Dec 2006, John Schnizlein wrote: > realms? One way to clarify this is to ask against what failures site > multi-homing is to protect. it's probably also important to keep in mind that site-multihoming is sometimes done for reasons not related to failure too... perhaps just performance improvements (or percieved improvements). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Dec 29 23:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Vc4-0000SD-Ek; Fri, 29 Dec 2006 23:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Vc2-0000S8-U3 for ram@iab.org; Fri, 29 Dec 2006 23:14:26 -0500 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Vc1-0007wR-Nf for ram@iab.org; Fri, 29 Dec 2006 23:14:26 -0500 Received: from pmismtp02.mcilink.com ([166.37.158.162]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JB200H5RJRZ5C@firewall.mci.com> for ram@iab.org; Sat, 30 Dec 2006 04:14:23 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JB2001KZJRZ4Y@pmismtp02.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 04:14:23 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JB20034UJRZF6@pmismtp02.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 04:14:23 +0000 (GMT) Date: Sat, 30 Dec 2006 04:14:23 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Traffic Engineering In-reply-to: <400F21D4-E2A6-424F-B783-BD6F4F034C14@ndsu.edu> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Bruce Curtis Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII 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> X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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 would it be possible to not have html email on this list? :) it's just ugly and unnecessary. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 00:28:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlU-0000fL-V5; Sat, 30 Dec 2006 00:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlT-0000f5-PR for ram@iab.org; Sat, 30 Dec 2006 00:28:15 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0WlS-0007GV-39 for ram@iab.org; Sat, 30 Dec 2006 00:28:15 -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 SAA06233; Sat, 30 Dec 2006 18:28:08 +1300 In-Reply-To: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> <45955234.9060302@eml.cc> 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] Traffic Engineering Date: Sat, 30 Dec 2006 18:28:08 +1300 To: Roland Dobbins X-Mailer: Apple Mail (2.752.2) 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 On 30/12/2006, at 7:41 AM, Roland Dobbins wrote: > > On Dec 29, 2006, at 9:36 AM, Per Heldal wrote: > >> How do you know what type of tools will be available at deployment >> time >> for a technology for which the specification is not yet complete, and >> currently lacks implementations to even play with? > > I believe the basic concept to be so fatally flawed that there is > no way a set of tools would make this technology feasible. Inasmuch as there are HIP implementations available and their characteristics are similar to those a SHIM6 implementation would have, I disagree. They're very easy to use, in fact can be largely ignored once in operation. Now, it is true that in a multi-homed situation path selection may be a problem, but I believe simply paying attention to ECN notification would be sufficient to allow a good balance between administration and ease of use. > >> >> Isn't it premature to assume that there will be no tools and >> developments happening on top on shim6? Would you similarly >> dismiss the >> original specifications for e.g. TCP on the assumption that there >> will >> be no such things as stateful firewalls and load-balancers? > > Absent a fundamental change to the loosely-coupled nature of the > protocol stack, the deconflation of the host and locator IDs, and a > complete revolution in network-management tools/systems (and a > vendor renaissance to implement all of this) inspired by SHIM (in > other words, this sort of technology applied to something which > most definitively is not IPv6 or even a closely-related derivative > thereof), I can forecast no tools or developments which would make > this technology less problematic and more supportable on any kind > of scale beyond networking enthusiasts and tinkerers. That's an assertion, I'd like to see some discussion as to why you believe this. Andrew McGregor _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 03:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZLX-0004ZF-7g; Sat, 30 Dec 2006 03:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZLV-0004Z7-Vg for ram@iab.org; Sat, 30 Dec 2006 03:13:37 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ZLU-0006gp-1x for ram@iab.org; Sat, 30 Dec 2006 03:13:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9A51B898C0; Sat, 30 Dec 2006 10:13:32 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 470E6898B9; Sat, 30 Dec 2006 10:13:32 +0200 (EET) Message-ID: <45961FAE.8060005@piuha.net> Date: Sat, 30 Dec 2006 10:13:34 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: tvest@eyeconomics.com Subject: Re: [RAM] Terminology: Routing Entropy References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@1-4-5.net> <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.com> In-Reply-To: <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Tom, > > >> Back to the routing entropy issue: The nature of the > >> dynamics of the UPDATE stream is directly related to the > >> amount (and the granularity of) the information that is > >> carried in the DFZ. All of this will effect not only the > >> cost of providing Internet service, as well as its > >> quality. > > Is it actually, today? I thought GIH's work last year showed that > recent/current update dynamics were substantially driven by a > relatively small number of operators with questionable configs/competence? I have also understood that its a big component of what we're seeing today. But at the same time Dave is right -- the more details we pour into the table about the edge of the network, the more likely it is that we will encounter bad setups and bad links. And I don't think the entire update load can be classified under questionable practices. (An interesting question is what we can do about the part that can be classified as such. Its very hard for, say, an ISP to push back on a questionable practice of its peer because there are economic incentives to stay connected, and because the price to this one ISP is small, even if the price to the entire world is great. Tragedy of the commons. Are the best practices documents that the operator community could write? Has the IETF done enough to provide guidance on how to use its tools to do routing and TE?) --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 03:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZWi-00087r-DT; Sat, 30 Dec 2006 03:25:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZWh-00087m-3d for ram@iab.org; Sat, 30 Dec 2006 03:25:11 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ZWe-0001QS-QH for ram@iab.org; Sat, 30 Dec 2006 03:25:11 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1C5A8898C0; Sat, 30 Dec 2006 10:25:08 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C7F3B898B9; Sat, 30 Dec 2006 10:25:07 +0200 (EET) Message-ID: <45962265.2050308@piuha.net> Date: Sat, 30 Dec 2006 10:25:09 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Spencer Dawkins 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> In-Reply-To: <06e001c72bac$bb7ab960$6a01a8c0@china.huawei.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: 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 Hi Spencer, > > Thank you for asking. One topic that came up repeatedly at NANOG was > concern about SHIM6 reliance on hosts that are massively vulnerable to > viruses and botnetting (visualize a botnet controller switching all > owned hosts selecting transit paths from TWC to SBCGLOBAL, within a > minute or two). Botnet effects on any networking technology is always an important concern. But in this case I think you also have to ask whether its host-based multihoming designs (SHIM6, MOBIKE, HIP) that create this problem or something else. It would seem that a botnet can send using the source and destination prefixes it wants to, so it appears that it has the same denial of service capability irrespective of any functionality in the IP layer. Or did I miss something? --Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 07:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0dc5-0005Fd-NL; Sat, 30 Dec 2006 07:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0dc4-0005FX-Kz for ram@iab.org; Sat, 30 Dec 2006 07:47:00 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0dc3-000286-E3 for ram@iab.org; Sat, 30 Dec 2006 07:47:00 -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 5919591; Sat, 30 Dec 2006 07:46:59 -0500 In-Reply-To: <45962265.2050308@piuha.net> 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> 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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 07:46:56 -0500 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Dear Jari; On Dec 30, 2006, at 3:25 AM, Jari Arkko wrote: > Hi Spencer, >> >> Thank you for asking. One topic that came up repeatedly at NANOG was >> concern about SHIM6 reliance on hosts that are massively >> vulnerable to >> viruses and botnetting (visualize a botnet controller switching all >> owned hosts selecting transit paths from TWC to SBCGLOBAL, within a >> minute or two). > Botnet effects on any networking technology is always > an important concern. But in this case I think you also > have to ask whether its host-based multihoming designs > (SHIM6, MOBIKE, HIP) that create this problem or something > else. It would seem that a botnet can send using the > source and destination prefixes it wants to, so it appears that > it has the same denial of service capability irrespective > of any functionality in the IP layer. Or did I miss something? > 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. If you are using announced PI or even PA space, the multi-homing is hidden from the host in most cases, so I don't see how you could make that switch. What's not clear to me is what, exactly, the feared attack is. How is switching an outbound DOS from provider A to provider B and back worse than just blasting packets out of provider A, which can be done now ? > --Jari > Regards Marshall > > _______________________________________________ > 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 Dec 30 08:50:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0eZy-0007ju-AU; Sat, 30 Dec 2006 08:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0eZx-0007jo-6m for ram@iab.org; Sat, 30 Dec 2006 08:48:53 -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 1H0eZv-0006fj-Ov for ram@iab.org; Sat, 30 Dec 2006 08:48:53 -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.52) id 1H0eZt-0008Hl-TQ for ram@iab.org; Sat, 30 Dec 2006 05:48:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Dec 2006 14:48:39 +0100 To: Tony Li ,Marshall Eubanks 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 - 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: 1.3 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: RJ Atkinson , ram@iab.org, John Schnizlein Subject: [RAM] (de)centralised or distributed X-BeenThere: ram@iab.org X-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="===============0717373276==" Errors-To: ram-bounces@iab.org Message-Id: --===============0717373276== Content-Type: multipart/alternative; boundary="----MTjxnwshpcijkoxrtzjckhxgkcnnnffkzn" ------MTjxnwshpcijkoxrtzjckhxgkcnnnffkzn Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-14C52AD Sorry for the typos. I also answer two private remarks/questions. At 19:28 29/12/2006, Tony Li wrote: >>Wouldn't a useful design principle be to favor local concepts over >>global ones ? > >Not if you're trying to address global issues. We are trying to address global issues from a local diversity point of view, not any more from a single united network point of view. This is the difference between (de)centralised and distributed (user centric) architectures. Question is to understand if a better decentralisation is possible or if we must switch to a _distributed_ approach. This will have consequences on the architecture, the IETF, and the Internet culture and governance. This is not a small thing, but IMO the network development is such that decentralised (unique network centric) solutions have become too complex (and then insecure what increases their complexity). In cases under debate, why would everyone's routing be the same? why would everyone's naming by the same? why would a solution be the only IESG approved solution? Containing diversity is a layer violation by the network of networks, which can only be addressed by a decentralised architecture of networks of the network of networks. The IPv6 experience shown that having a solution B to replace a solution A is not easy to deploy: we need a constant evolution of function A staying consistent with the constant evolution of all the other functions (namings, routings, addressings, transportings, etc.). This can only lead to an increasing diversity, hence granularity. Rough consensus is then meaningless (except locally). It must be replaced by concerted standards interoperability, based upon a multiconsensus over an underlying normative model. This means that IAB should attempt to document the observation of the digital ecosystem and the needs of its users/co-owners. The job of IETF is to document the accidental solutions which belong to the standards' area. jfc ------MTjxnwshpcijkoxrtzjckhxgkcnnnffkzn Content-Type: text/html Sorry for the typos. I also answer two private remarks/questions.

At 19:28 29/12/2006, Tony Li wrote:
>>Wouldn't a useful design principle be to favor local concepts over
>>global ones ?
>
>Not if you're trying to address global issues.

We are trying to address global issues from a local diversity point
of view, not any more from a single united network point of view.
This is the difference between (de)centralised and distributed (user
centric) architectures. Question is to understand if a better
decentralisation is possible or if we must switch to a _distributed_
approach. This will have consequences on the architecture, the IETF,
and the Internet culture and governance. This is not a small thing,
but IMO the network development is such that decentralised (unique
network centric) solutions have become too complex (and then insecure
what increases their complexity).

In cases under debate, why would everyone's routing be the same? why
would everyone's naming by the same? why would a solution be the only
IESG approved solution? Containing diversity is a layer violation by
the network of networks, which can only be addressed by a
decentralised architecture of networks of the network of networks.

The IPv6 experience shown that having a solution B to replace a
solution A is not easy to deploy: we need a constant evolution of
function A staying consistent with the constant evolution of all the
other functions (namings, routings, addressings, transportings,
etc.). This can only lead to an increasing diversity, hence
granularity. Rough consensus is then meaningless (except locally). It
must be replaced by concerted standards interoperability, based upon
a multiconsensus over an underlying normative model. This means that
IAB should attempt to document the observation of the digital
ecosystem and the needs of its users/co-owners. The job of IETF is to
document the accidental solutions which belong to the standards' area.

jfc  

------MTjxnwshpcijkoxrtzjckhxgkcnnnffkzn-- --===============0717373276== 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 --===============0717373276==-- From ram-bounces@iab.org Sat Dec 30 10:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0fhi-0005qB-Hv; Sat, 30 Dec 2006 10:00:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0fhg-0005q5-Vv for ram@iab.org; Sat, 30 Dec 2006 10:00:56 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0fhb-0002iy-FH for ram@iab.org; Sat, 30 Dec 2006 10:00: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 6EACC34008; Sat, 30 Dec 2006 10:00:48 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Dec 2006 10:00:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:00:42 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FCF43@tayexc14.americas.cpqcorp.net> In-Reply-To: <12E26632-8D8F-468F-A78F-34D8F5D3810B@ndsu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Traffic Engineering Thread-Index: AccrjceA1XIgoaEPQA2cQFSFqOlxHAAlS6OA From: "Bound, Jim" To: "Bruce Curtis" , X-OriginalArrivalTime: 30 Dec 2006 15:00:44.0553 (UTC) FILETIME=[47ECD790:01C72C23] X-Spam-Score: 0.1 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 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="===============0064714642==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============0064714642== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72C23.479BE28B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72C23.479BE28B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable My view is any TE future architecture uses that does not assume all but the IP Headers and possibly some new options before the data payload (e.g. TCP, SCTP, future-transport-updates) is encrypted is a non-starter. Use of Identifiers, ports, et al should not be assumed, thus TE needs an overhaul too. =20 /jim ________________________________ From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20 Sent: Friday, December 29, 2006 4:10 PM To: ram@iab.org Subject: Re: [RAM] Traffic Engineering =09 =09 On Dec 29, 2006, at 10:12 AM, Roland Dobbins wrote: On Dec 29, 2006, at 6:53 AM, RJ Atkinson wrote: ms are currently being addressed with traffic engineering. There was concern expressed at NANOG about potential loss of ability to use "traffic engineering" if SHIM6 were widely deployed, but the details of those concerns haven't been widely explained. SHIM6 simply isn't practical for a number of reasons, difficulties in traffic engineering with an architecture of this type being least among them. While SHIM6 may make traffic engineering more difficult there may still be potential architectures with hierarchical routing and multiple addresses on the endstation that still allow traffic engineering. For example there was a discussion on architecture-discuss@ietf.org of a model where all of the multiple addresses of both endstations are included in each packet. Just handing off path-selection functionality to the endstation and the concept of multiple addresses on the endstation creates a troubleshooting and support nightmare which neither enterprises nor individuals can be expected to accept.=20 =09 While having a single global address for the end station is certainly simpler I'm not sure that having multiple addresses for an endstation is totally unacceptable. Endstations already deal with a simple form of multiple addresses since they have a localhost address and an IPv4 address on the network and with dual stack an IPv6 link local address plus an IPv6 global address. And essentially enterprises have already accepted the concept of multiple addresses for and endstation when they implement NAT, the endstation has a local/private address and a global address. On a historical note I'm glad to see them go but it wasn't considered unacceptable for an endstation to have an IPv4 address, an IPX address plus an Appletalk/Ethertalk address. Also I'm not a fan of VPN clients but that is another example of an endstation with multiple addresses that has largely been accepted. The problem SHIM6 purported to solve is a) much more fundamental and larger in scope than the SHIM6 proponents realized (read all of RFC4192 for a sense of this) and b) is rendered moot by the fact that registries are now providing PI space to organizations which need it, anyways. =09 ----------------------------------------------------------------------- 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 =09 =09 --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University =20 ------_=_NextPart_001_01C72C23.479BE28B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
My view is any TE future architecture uses that = does not=20 assume all but the IP Headers and possibly some new options before the = data=20 payload (e.g. TCP, SCTP, future-transport-updates) is encrypted is a=20 non-starter. Use of Identifiers, ports, et al should not be assumed, = thus TE=20 needs an overhaul too.
 
/jim

From: Bruce Curtis=20 [mailto:bruce.curtis@ndsu.edu]
Sent: Friday, December 29, = 2006 4:10=20 PM
To: ram@iab.org
Subject: Re: [RAM] Traffic=20 Engineering


On Dec 29, 2006, at 10:12 AM, Roland Dobbins wrote:

On Dec 29, 2006, at 6:53 AM, RJ Atkinson=20 wrote:

ms are currently being addressed = with
traffic engineering.  There was concern = expressed at=20 NANOG
about potential loss of ability to use = "traffic=20 engineering"
if SHIM6 were widely deployed, but the = details of=20 those concerns
haven't been widely = explained.

SHIM6 simply isn't practical for a number = of=20 reasons, difficulties in traffic engineering with an architecture of = this=20 type being least among them.

  While SHIM6 may make traffic engineering more difficult = there may=20 still be potential architectures with hierarchical routing and = multiple=20 addresses on the endstation that still allow traffic = engineering.  For=20 example there was a discussion on architecture-discuss@ietf.o= rg=20 of a model where all of the multiple addresses of both endstations are = included in each packet.


Just handing off path-selection = functionality to=20 the endstation and the concept of multiple addresses on the = endstation=20 creates a troubleshooting and support nightmare which neither = enterprises=20 nor individuals can be expected to accept. 

  While having a single global address for the end station = is=20 certainly simpler I'm not sure that having multiple addresses for an=20 endstation is totally unacceptable.  Endstations already deal = with a=20 simple form of multiple addresses since they have a localhost address = and an=20 IPv4 address on the network and with dual stack an  IPv6  = link local=20 address plus an IPv6 global address.

  And essentially enterprises have already accepted the = concept of=20 multiple addresses for and endstation when they implement NAT, the = endstation=20 has a local/private address and a global address.

  On a historical note I'm glad to see them go but it wasn't = considered unacceptable for an endstation to have an IPv4 address, an = IPX=20 address plus an Appletalk/Ethertalk address.

  Also I'm not a fan of VPN clients but that is another = example of=20 an endstation with multiple addresses that has largely been=20 accepted.

The=20 problem SHIM6 purported to solve is a) much more fundamental and = larger in=20 scope than the SHIM6 proponents realized (read all of RFC4192 for a = sense of=20 this) and b) is rendered moot by the fact that registries are now = providing=20 PI space to organizations which need it, anyways.

--------------------------------------------------------------------= ---
Roland Dobbins <rdobbins@cisco.com> // = 408.527.6376=20 voice

All battles are perpetual.

  =20   =   = -- Milton=20 Friedman




_______________________________________________
RAM mailing list
https://www1.ietf.org= /mailman/listinfo/ram



---

Bruce Curtis   =    =20                   bruce.curtis@ndsu.edu

Certified NetAnalyst II            =  =20   701-231-8527

North Dakota State University      =20  


------_=_NextPart_001_01C72C23.479BE28B-- --===============0064714642== 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 --===============0064714642==-- From ram-bounces@iab.org Sat Dec 30 10:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0fkO-0006la-Ld; Sat, 30 Dec 2006 10:03:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0fkN-0006lU-GL for ram@iab.org; Sat, 30 Dec 2006 10:03:43 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0fkI-0003Ev-8x for ram@iab.org; Sat, 30 Dec 2006 10:03:43 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id B900F3407C; Sat, 30 Dec 2006 10:03:50 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Dec 2006 10:03: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: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:03:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FCF45@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Traffic Engineering Thread-Index: AccryQ1kqRegI4UNQ5+uNZFG/al7JAAWoygw From: "Bound, Jim" To: "Chris L. Morrow" , "Bruce Curtis" X-OriginalArrivalTime: 30 Dec 2006 15:03:37.0894 (UTC) FILETIME=[AF3E9460:01C72C23] 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 Not to be me-too on the mail list but I would appreciate that too. Greatly in fact. /jim=20 > -----Original Message----- > From: Chris L. Morrow [mailto:christopher.morrow@verizonbusiness.com]=20 > Sent: Friday, December 29, 2006 11:14 PM > To: Bruce Curtis > Cc: ram@iab.org > Subject: Re: [RAM] Traffic Engineering >=20 >=20 > would it be possible to not have html email on this list? :)=20 > it's just ugly and unnecessary. >=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 Sat Dec 30 10:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0gTx-0005ES-9E; Sat, 30 Dec 2006 10:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0gTw-0005EN-JB for ram@iab.org; Sat, 30 Dec 2006 10:50:48 -0500 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0gTv-0002BD-CB for ram@iab.org; Sat, 30 Dec 2006 10:50:48 -0500 Received: from HeinerHummel@aol.com by imo-m27.mx.aol.com (mail_out_v38_r7.6.) id j.bf2.dbebfc8 (48600); Sat, 30 Dec 2006 10:50:28 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sat, 30 Dec 2006 10:50:26 EST Subject: Re: [RAM] Goal: Minimising Routing Entropy To: tme@multicasttech.com, dmm@1-4-5.net 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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: rja@extremenetworks.com, jschnizl@cisco.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="===============0434558718==" Errors-To: ram-bounces@iab.org --===============0434558718== Content-Type: multipart/alternative; boundary="-----------------------------1167493826" -------------------------------1167493826 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The start of this thread was: A routing table with minimum entropy has zero more-specific prefixes. A routing table with high entropy has many more-specific prefixes. I like to recall Rekther's law : "Addressing can follow topology or topology can follow addressing. Choose one." In a previous email I commented on it in more detail, but essentially saying: yes, but choose the right way to go. This EITHER-OR is worth to be discussed in great detail and what is here termed routing entropy is in my view the essential criteria. A good start would be to table Rekther's law using more words than just a bon mot :-) Heiner -------------------------------1167493826 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
The start of this thread was:
A routing table with minimum entropy has zero more-specific prefixes.A=20 routing table with high entropy has many more-specific prefixes.
 
I like to recall Rekther's law : 
        "Addressing can follow topol= ogy=20 or topology can follow
        =20 addressing. Choose one."
 
In a previous email I commented on it in more detail, but essentia= lly=20 saying: yes, but choose the right way to go. This EITHER-OR is worth to be=20 discussed in great detail and what is here termed routing entropy is in my v= iew=20 the essential criteria.
A good start would be to table Rekther's law using more words than just= a=20 bon mot :-)
 
Heiner
 
 
 
 -------------------------------1167493826-- --===============0434558718== 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 --===============0434558718==-- From ram-bounces@iab.org Sat Dec 30 13:17:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0iki-00089I-87; Sat, 30 Dec 2006 13:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ikg-00089D-SH for ram@iab.org; Sat, 30 Dec 2006 13:16:14 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ikd-00026r-Kd for ram@iab.org; Sat, 30 Dec 2006 13:16:14 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 10:16:09 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49720953:sNHT45367772" 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 kBUIG97Z028914 for ; Sat, 30 Dec 2006 13:16:09 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBUIG9gT029541 for ; Sat, 30 Dec 2006 13:16:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:15:53 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1575; t=1167502569; x=1168366569; 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=CWG0wlPcyF1nhcWqfbWFHkQZkzlPF9ByY1PF43bo7Wg=; b=mnrNJMvs3rmtMuTx2AGViiHWoBDmYe32BywrdpwFUb06vr+bU151D6YwA3on9T905eA0uZHc tAwIIcNKsM0GuHk+s6M4PMqerLZNR2lAVhKkb76cHSrHoFnktZPeft9z; 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 Dec 29, 2006, at 1:25 PM, marcelo bagnulo braun wrote: > As i read your input, a solution that results in that the end > points need to manage multiple IP addresses is simply a non > starter, right? Yes, because of the administrative and resource overhead (think iACLs, firewall rules, etc., the burden of maintain twice or more the number as are currently maintained, and consuming twice or more the TCAM space in ASICs to hold those iACLs and other filtering/policy enforcement mechanisms, MAC/CAM table sizes, along with things like uRPF, and so forth) and because of the support burden (think help- desk) and because of the potential for abuse (think compromised endpoints). > > So, do people agree that a solution MUST expose a SINGLE IP address > to the hosts within the multihomed site? I'm not sure what you mean by this. My preference (due to the abovementioned reasons) is that any posited solution work with each endpoint a) having a minimum of 1 IP address and b) not being required to participate in routing decisions itself, but rather leaving path selection to the networking infrastructure unless the endpoint is explicitly configured to participate in routing via a routing daemon or what-have-you (which today is mainly done on servers, and not on many of those, in the scheme of things). ----------------------------------------------------------------------- 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 Sat Dec 30 13:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ip4-00013s-A3; Sat, 30 Dec 2006 13:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ip3-00013l-Go for ram@iab.org; Sat, 30 Dec 2006 13:20:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ip2-0002ks-9m for ram@iab.org; Sat, 30 Dec 2006 13:20:45 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 10:20:44 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49721062:sNHT44361996" 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 kBUIKipI029707 for ; Sat, 30 Dec 2006 13:20:44 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBUIKhgT000202 for ; Sat, 30 Dec 2006 13:20:43 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7.0.1.0.0.20061229170702.0376bea8@joelhalpern.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <7.0.1.0.0.20061229170702.0376bea8@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:20: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=1300; t=1167502844; x=1168366844; 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=E8Ahz1g1FnmCrw7LxbEoWZAfQPXxDlt+k4x6jwNF9js=; b=dDTJTlnUkxGkIdJdMVPzUiVHMZJ476Ciqo7eI5xveIcZxg3r0VqLQvA/8n0ydvcay84Op1rB un2vU9UcE6vvsAiRsjwpmP9IXhr9NURaSibdTxt9sfvxIJWgUFKYwV55; 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: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 29, 2006, at 2:14 PM, Joel M. Halpern wrote: > b) if we can spell out how the hosts make sensible choices, and why > they need to make those choices, then it may be beneficial to > require the host to have visibility to the multiple addresses. > > Further, it may be possible that hosts need / want to be aware of > multiple remote addresses, without necessarily having awareness of > their own multiplicity. From an end-user standpoint (enterprise or SOHO/consumer), from a help-desk standpoint (enterprise or SP), from an administrative standpoint (enterprise or SP), from a security standpoint (i.e., mandating that compromised endpoints must have the capability of participating in routing decisions), and from a hardware resource standpoint (TCAMs for iACLs, MAC/CAM table info, etc.), mandating this type of behavior is a recipe for disaster, IMHO. If you can make it optional, fine - I think it's all wasted effort because folks won't make use of it for the above reasons, anyways (again, how many endpoints run routing daemons today?). ----------------------------------------------------------------------- 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 Sat Dec 30 13:32:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0j0a-0004eZ-Qn; Sat, 30 Dec 2006 13:32:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0j0Y-0004eU-Un for ram@iab.org; Sat, 30 Dec 2006 13:32:38 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0j0T-0004C3-Rm for ram@iab.org; Sat, 30 Dec 2006 13:32:38 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 13:32:34 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110601739:sNHT49277728" 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 kBUIWXRb031453 for ; Sat, 30 Dec 2006 13:32:33 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUIWXG9021597 for ; Sat, 30 Dec 2006 13:32:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <400F21D4-E2A6-424F-B783-BD6F4F034C14@ndsu.edu> 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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B216644-A4C0-4297-8083-B7540665D1B4@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:32: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=3918; t=1167503553; x=1168367553; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=scH9TxI/WJttIp4DlWgshtlxqAPXjA2c+9BLUNz7kQA=; b=bLG6y+kxz/WsYhUvHqC/y06XuBMJS5V99nHzXE4BKZg6mvkf6WQ24kFjXeutPF/zHbMEG8eA OKGgLJn/G7d+4TRxFoRsZr8xWZ47HJVQrldMdDy1weADalog8M6wEcPd; 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 29, 2006, at 2:31 PM, Bruce Curtis wrote: > But dual stack was well discussed and accepted as the best method > to migrate from IPv4 to IPv6. Yes, people posit this. I believe it remains to be seen whether this is the best method. > > What if an endstation had a single address that contained the > information about prefixes from it's multiple ISPs? If the > endstation just considered it a single address but the address > contained information about multiple paths that could be used by > devices in the core of the Internet for Traffic Engineering would > you consider that acceptable? I believe that the help-desk/troubleshooting issues surrounding this sort of thing, not to mention the security considerations, make this highly undesirable as mandatory behavior. Again, how many endpoints run routing daemons today? > > > We will have to agree to disagree on this point. I don't agree > that multiple addresses would be orders of magnitude more difficult > to support than NAT. In fact given the choice I would rather > support a network with multiple addresses on endstations than one > with NAT. That's because you've never been tasked with a) maintaining and updating large numbers of iACLs/firewall rules/SNMP ACLs/vty ACL/etc. (these things are more fluid than you think, especially in the Cloud Cuckoo-Land world in which some portion of an organization's internal addressing would change according to the whims of business relationships), and you've never had to deal with the effects of overflowing finite ASIC resources due to the doubled/trebled/ quadrupled/quintupled number of ACEs/firewall rules/etc. such a scheme would require. Multihomed <> dual-homed, keep in mind. > > But wouldn't the user be limited to using one of the multiple > addresses for the endstation? They couldn't just casually chose > any address. Most users don't know or care what IP addresses -are- in the first place. I recently came to the surprising realization that apparently, most of the casual users of the Internet today seem to not type in URLs or make much use of bookmarks at all; rather, they make use of Google or Yahoo or some intranet search engine as their homepages, and simply type in what it is they believe they're looking for and then noodle through the proffered links until they find whatever seems to meet their needs. I'm still gobsmacked by this. Users use applications. The applications then make use of APIs to talk down the networking stack in order to, ultimately, generate packets. With a mandatory multiple address scenario, the troubleshooting process a tech-savvy individual would engage in to resolve an issue has been made much more complex, much less the process followed by a help-desk working with non-technical users. > > >>> Also I'm not a fan of VPN clients but that is another example of >>> an endstation with multiple addresses that has largely been >>> accepted. >> >> Again, see above - firstly, VPN support for enterprises is a >> bounded logical domain (and even supporting VPN users is no fun, >> if you've ever done it; so, the argument undermines itself >> completely even apart from the logical domain issue). > > Well, I agree that supporting VPN users is no fun. So we do > agree on at least one thing. :-) > > However the problems I've encountered didn't seem to stem from > the endstations essentially having multiple addresses. I agree with you; that's not the main problem with VPNs at all. It's one of the problems, but it's a bit down-list. ----------------------------------------------------------------------- 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 Sat Dec 30 13:56:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jMW-0003Yc-ES; Sat, 30 Dec 2006 13:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jMU-0003YX-O5 for ram@iab.org; Sat, 30 Dec 2006 13:55:18 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0jMS-0007dh-1m for ram@iab.org; Sat, 30 Dec 2006 13:55:18 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 13:55:16 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110602276:sNHT47362776" 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 kBUItFZ2032441 for ; Sat, 30 Dec 2006 13:55:15 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUItFG9024643 for ; Sat, 30 Dec 2006 13:55:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> <45955234.9060302@eml.cc> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C033381-7745-4A7D-89D7-5ECED405E7BC@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 10:55: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=2306; t=1167504915; x=1168368915; 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]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=IxnBG3jgAldEHBhffEWgpaLf6T/bW0FpMCTfp0MQdjc=; b=XuameZ/Iys7/JwXNK91q6w92+j9eKcpZvK72yDFDVGcsxJw8Zf5+LOrTgCmoa60cophAqwKL ig2i7/smVlcPOtFrBQZnpuSi7BJ1Hc0rRarYNPdh2rmTvBZukgsBU4sY; 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: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 29, 2006, at 9:28 PM, Andrew McGregor wrote: > Inasmuch as there are HIP implementations available and their > characteristics are similar to those a SHIM6 implementation would > have, I disagree. They're very easy to use, in fact can be largely > ignored once in operation. Now, it is true that in a multi-homed > situation path selection may be a problem, but I believe simply > paying attention to ECN notification would be sufficient to allow a > good balance between administration and ease of use. I was unclear; I'm talking about all overhead required for things like iACLs, SNMP ACLs, vty ACLs, firewall rules, QoS policies, etc., and what would be required to both support those things in hardware and simply maintain/update them from an administrative standpoint, and the ever-present help-desk burden. > That's an assertion, I'd like to see some discussion as to why you > believe this. I believe that the loosely-coupled nature of IPv4, which was a big asset in terms of getting something implemented and deployed, was a huge asset which helped TCP/IP win out over other competing protocols. I also believe that this loosely-coupled paradigm, while being an asset during the adoption phase, has now become a millstone round our necks, because it has led us to rely on Rube Goldbergian mechanisms such as ACLs, firewall rules, etc. due to the lack of coupling and feedback mechanism for establishing identity/entitlement/ authentication/authorization up and down the stack. The current conflation of host and locator information in TCP/IP (both IPv4 and IPv6) contributes to this brittleness. As long as we are stuck with what are essentially approximated out-of- band mechanisms for trying to implement policy, the administrative burden and potential for outages related to mistakes during the administrative process, and as long as we must have help-desks for enterprise users and SP customers, any proposal which mandates multiple IP addresses and endpoint routing decisions is DOA, 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 From ram-bounces@iab.org Sat Dec 30 14:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jem-00015T-Sb; Sat, 30 Dec 2006 14:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jel-000102-Am for ram@iab.org; Sat, 30 Dec 2006 14:14:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0jek-0002mc-2h for ram@iab.org; Sat, 30 Dec 2006 14:14:11 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 11:14:10 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49722298:sNHT46190888" 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 kBUJE9UJ002940 for ; Sat, 30 Dec 2006 14:14:09 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBUJE9gT013814 for ; Sat, 30 Dec 2006 14:14:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45962265.2050308@piuha.net> 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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 11:13:53 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2024; t=1167506049; x=1168370049; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=SI2EyYUU2ZaSuYCtkEZR+t9doeEoeGNqVvsLvnEk7CE=; b=NrKxaezO3PU/kzZc81m/doqqXy3b9hWK785GIXPBL1TBGlz/kyB01BYVlVKyYi4yZc7oGq6k Omz6L7NOWGSAolDpN+HiHbgW218Obx+Rb4lw+l/yBPIwjhWWf2WdKc89; 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: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 30, 2006, at 12:25 AM, Jari Arkko wrote: > Botnet effects on any networking technology is always > an important concern. But in this case I think you also > have to ask whether its host-based multihoming designs > (SHIM6, MOBIKE, HIP) that create this problem or something > else. It would seem that a botnet can send using the > source and destination prefixes it wants to, so it appears that > it has the same denial of service capability irrespective > of any functionality in the IP layer. Or did I miss something? A simple thought-experiment would be to consider what the current situation with regards to outbound DDoS from botted hosts would be like today if a routing daemon were mandated for each and every host in the network. Ensuring that each and every compromised host provides attacker with a mechanism to make path selection for his DoS packets is an unwelcome innovation, IMHO. This would allow the attacker to select/ vary his path based upon performance, impact to the infrastructure, capacity, and to complicate traceback. It's pretty obviosu that there would be considerable benefits in terms of reachability and resiliency in *today's IPv4 world* if each and every host ran a routing daemon and participated in the IGP(s) of the network(s) on which they are deployed. The fact that the overwhelming majority of hosts today do *not* run routing daemons, and that mechanisms such as HSRP/GLBP/VRRP/CARP have proven popular mechanisms for maximizing said reachability/resiliency, strongly implies that any and all proposals which aim to mandate host-based path-selection have significant drawbacks which make them impractical and undesirable - else we'd already be running routing daemons on the majority of IPv4 hosts today. ----------------------------------------------------------------------- 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 Sat Dec 30 14:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jzR-00073G-CB; Sat, 30 Dec 2006 14:35:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0jzP-000703-OK for ram@iab.org; Sat, 30 Dec 2006 14:35:31 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0jzO-0006Ak-4X for ram@iab.org; Sat, 30 Dec 2006 14:35:31 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3AA421223E1; Sat, 30 Dec 2006 20:35:29 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 2CF68122414; Sat, 30 Dec 2006 20:35:27 +0100 (CET) In-Reply-To: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 20:35:37 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 El 30/12/2006, a las 19:15, Roland Dobbins escribi=F3: > > On Dec 29, 2006, at 1:25 PM, marcelo bagnulo braun wrote: > >> As i read your input, a solution that results in that the end points=20= >> need to manage multiple IP addresses is simply a non starter, right? > > Yes, because of the administrative and resource overhead (think iACLs,=20= > firewall rules, etc., the burden of maintain twice or more the number=20= > as are currently maintained, and consuming twice or more the TCAM=20 > space in ASICs to hold those iACLs and other filtering/policy=20 > enforcement mechanisms, MAC/CAM table sizes, along with things like=20 > uRPF, and so forth) and because of the support burden (think=20 > help-desk) and because of the potential for abuse (think compromised=20= > endpoints). i can see these are valid concerns for medium/big sites. but do you think these are issues for soho sites? i mean, my home=20 network doesn't have ACL, no TCAM for storing filters no MAC tables and=20= a very simple firewall. otoh, from perspective of each ISP the site is singlehomed, and it=20 should only care about the prefix it has delegated to the site, so i=20 fail to see why this would be a problem > >> >> So, do people agree that a solution MUST expose a SINGLE IP address=20= >> to the hosts within the multihomed site? > > I'm not sure what you mean by this. My preference (due to the=20 > abovementioned reasons) is that any posited solution work with each=20 > endpoint a) having a minimum of 1 IP address i guess you mean a maximum of 1 IP address... i mean, you sure need a=20 minimum of 1 ip address if you want to be part of an IP network :-) in other words, hosts must have only one IP (global) address and not=20 more (not talking about link local) > and b) not being required to participate in routing decisions itself,=20= > but rather leaving path selection to the networking infrastructure=20 > unless the endpoint is explicitly configured to participate in routing=20= > via a routing daemon or what-have-you (which today is mainly done on=20= > servers, and not on many of those, in the scheme of things). understand this point. Regards, marcelo > > = ----------------------------------------------------------------------- > 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 Sat Dec 30 14:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kEx-0003J7-2w; Sat, 30 Dec 2006 14:51:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kEw-0003J0-CR for ram@iab.org; Sat, 30 Dec 2006 14:51:34 -0500 Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0kEu-0000JI-2S for ram@iab.org; Sat, 30 Dec 2006 14:51:34 -0500 Received: from pmismtp03.mcilink.com ([166.37.158.163]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JB300H79R5R7M@firewall.mci.com> for ram@iab.org; Sat, 30 Dec 2006 19:51:27 +0000 (GMT) Received: from pmismtp03.mcilink.com ([127.0.0.1]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JB300FCGR5R7U@pmismtp03.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 19:51:27 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JB300G83R5R1L@pmismtp03.mcilink.com> for ram@iab.org; Sat, 30 Dec 2006 19:51:27 +0000 (GMT) Date: Sat, 30 Dec 2006 19:51:27 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering In-reply-to: <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: marcelo bagnulo braun Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=X-UNKNOWN Content-transfer-encoding: QUOTED-PRINTABLE References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> 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 On Sat, 30 Dec 2006, marcelo bagnulo braun wrote: > El 30/12/2006, a las 19:15, Roland Dobbins escribi=F3: > > On Dec 29, 2006, at 1:25 PM, marcelo bagnulo braun wrote: > > > >> As i read your input, a solution that results in that the end points > >> need to manage multiple IP addresses is simply a non starter, right? > > > > Yes, because of the administrative and resource overhead (think iACLs, > > firewall rules, etc., the burden of maintain twice or more the number > > as are currently maintained, and consuming twice or more the TCAM > > space in ASICs to hold those iACLs and other filtering/policy > > enforcement mechanisms, MAC/CAM table sizes, along with things like > > uRPF, and so forth) and because of the support burden (think > > help-desk) and because of the potential for abuse (think compromised > > endpoints). > > i can see these are valid concerns for medium/big sites. > but do you think these are issues for soho sites? i mean, my home > network doesn't have ACL, no TCAM for storing filters no MAC tables and > a very simple firewall. I think that trying to put limits on the number if ip addresses a host has is folly... There will always be corner cases where more/less are required/mandated/in-use. I think that the core issue is, which I think roland is getting at, that maintaining a limited number of addresses is desirable. Probably someone will jump on 'addresses' and ask: "locator or id or both?" I'm not sure that right now it matters... 'limited number of globally known things' is the point, less state for each end point in the larger world view is desirable. Perhaps one way to view shim6 and it's breathren is as parts of the puzzle, maybe they aren't THE multihoming solution, but maybe they work for some portion of the multihoming crowd? Perhaps your SOHO solution provided by your helpdesk relies on SHIM6 (and they accept the burdens it brings, or doesn't tools-dependent). 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. -chris _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 15:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0koP-0005vz-4o; Sat, 30 Dec 2006 15:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0koN-0005rB-QB for ram@iab.org; Sat, 30 Dec 2006 15:28:11 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0koJ-0007Gb-Hq for ram@iab.org; Sat, 30 Dec 2006 15:28:11 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 12:28:07 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49723615:sNHT45919160" 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 kBUKS7gY013207 for ; Sat, 30 Dec 2006 15:28:07 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUKS6G9021847 for ; Sat, 30 Dec 2006 15:28:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28CFBECB-BF56-4074-9B97-C17E62354D5D@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 12:27:51 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1581; t=1167510487; x=1168374487; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=EG7COYTiZBVVXdbo399K8Nu2QpbFfRF8qrvYPLvLuLA=; b=p/P0r8iYRh38NaycrrVJEUsLzSMQgwP2f8+SuPMw5MyAShAOOW2ywt2PxIFWbdYRoYpfNuV8 vEJKdrW9LwOdfE5J1Lt+hGslecS6SAmwUDJSsicsLAfUv79E/PfjnLTz; 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: 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 Dec 30, 2006, at 11:51 AM, Chris L. Morrow wrote: > I think that the core issue is, which I think > roland is getting at, that maintaining a limited number of > addresses is > desirable. Probably someone will jump on 'addresses' and ask: > "locator or > id or both?" I'm not sure that right now it matters... 'limited > number of > globally known things' is the point, less state for each end point > in the > larger world view is desirable. Very aptly put, Chris - that is the crux of the matter, and I believe it to be a generalizable principle. > > Perhaps one way to view shim6 and it's breathren is as parts of the > puzzle, maybe they aren't THE multihoming solution, but maybe they > work > for some portion of the multihoming crowd? Perhaps your SOHO solution > provided by your helpdesk relies on SHIM6 (and they accept the > burdens it > brings, or doesn't tools-dependent). Yes, people do all sorts of outwardly-seemingly crazy/inefficient things on their own networks (often for very good situationally- specific reasons), and will continue to do so. What we must not do is attempt to mandate such behaviors for the global Internet (I say 'attempt' because such proposals will fail under their own weight and limitations; best not to waste any more time trying to breathe life into the stillborn, 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 From ram-bounces@iab.org Sat Dec 30 15:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kqL-0006RM-Ra; Sat, 30 Dec 2006 15:30:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kqK-0006RG-Vo for ram@iab.org; Sat, 30 Dec 2006 15:30:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0kqI-0007ZE-Nn for ram@iab.org; Sat, 30 Dec 2006 15:30:12 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 15:30:11 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110604104:sNHT45924468" 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 kBUKUA9Q013518 for ; Sat, 30 Dec 2006 15:30:10 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBUKUAgT003668 for ; Sat, 30 Dec 2006 15:30:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 12:29:54 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2025; t=1167510610; x=1168374610; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=+DT5GVCOOvCn5im0dUjYHaDl5xpATgWslUG4nJurvSM=; b=be/pD5gVbWatO5fS2Ra2nrOPUdlYPTa5DjTzPUHnUjM71v3NwfOW9UzF2Lt2e7tYMZHynFeA WYzTvUxHZ6ndq2FRzJbvvVSYl17HdJczrXxla8OLQQClwpJ9mddM8UHQ; 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: 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 Dec 30, 2006, at 11:35 AM, marcelo bagnulo braun wrote: > i can see these are valid concerns for medium/big sites. > but do you think these are issues for soho sites? i mean, my home > network doesn't have ACL, no TCAM for storing filters no MAC tables > and a very simple firewall. So, are we positing that SOHO users should run with what is essentially one protocol set/paradigm, and larger sites another, with all that entails in terms of fragmenting the global Internet, creating interesting issues for application developers, etc.? The majority of home users/SOHO sites are not multihomed, nor will they be for quite some time unless/until MANET-type networking becomes the norm, and probably not even then in the sense of multiple simultaneous links, but rather in a failover type of scenario. It's a bit more blurry in terms of some mobile devices, but the direction seems to be devices which can opportunistically leverage whatever the 'best' network is at any given moment (based upon performance, cost, administrative policies, content/service availability, etc.). I believe that the help-desk/troubleshooting problems discussed previously at length precludes *mandating* multiple IP addresses, it is a nonstarter. > i guess you mean a maximum of 1 IP address... i mean, you sure need > a minimum of 1 ip address if you want to be part of an IP network :-) No, I meant minimum - in other words, whatever solution is decided upon, it must work with a minimum of one IP address per host, and with a maximum of whatever someone chooses to configure on his host. > in other words, hosts must have only one IP (global) address and > not more (not talking about link local) No, see above - one or more, but the minimum requirement = 1. ----------------------------------------------------------------------- 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 Sat Dec 30 16:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0lh9-0005TY-V4; Sat, 30 Dec 2006 16:24:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0lh8-0005Rp-CQ for ram@iab.org; Sat, 30 Dec 2006 16:24:46 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0lh6-0000rj-6L for ram@iab.org; Sat, 30 Dec 2006 16:24:46 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AB67686AE9; Sat, 30 Dec 2006 16:24:43 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> Date: Sat, 30 Dec 2006 16:24:43 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: Roland Dobbins >> a solution that results in that the end points need to manage multiple >> IP addresses is simply a non starter, right? > Yes, because of the administrative and resource overhead (think iACLs, > firewall rules, etc. .. and consuming twice or more the TCAM space in > ASICs to hold those iACLs and other filtering/policy enforcement > mechanisms, MAC/CAM table sizes, along with things like uRPF, and so > forth) and because of the support burden The problem, at an archtectural level, is that you all are using the term "IP addresses" for these names, and then assuming we're going to use them the same way we use IP addresses today. If we had another namespace, then normal hosts would have only one name each from the "identification namespace" (hence zero hassle in handling multiple of them per host), and then access controls, etc should/would apply to that namespace, and a lot of the problems you're talking about would just go away. Stop saying - and thinking - "IP addresses". "IP addresses", as currently constituted, are totally broken, and any attempt to fix the system using "IP addreses" is doomed to failure. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 16:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0lmJ-0007ET-3S; Sat, 30 Dec 2006 16:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0lmI-0007EO-E9 for ram@iab.org; Sat, 30 Dec 2006 16:30:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0lmH-0001tM-7x for ram@iab.org; Sat, 30 Dec 2006 16:30:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F08CE86AE9; Sat, 30 Dec 2006 16:30:04 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061230213004.F08CE86AE9@mercury.lcs.mit.edu> Date: Sat, 30 Dec 2006 16:30:04 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: Roland Dobbins > It's pretty obviosu that there would be considerable benefits in terms > of reachability and resiliency in *today's IPv4 world* if each and > every host ran a routing daemon and participated in the IGP(s) of the > network(s) on which they are deployed. Except that I don't know of any routing experts who are proposing that hosts "participate[] in the IGP(s) of the network(s) on which they are deployed" - at least, for any current IGP's, and in any routing architecture that looks anything at all like the current one (i.e. hop-by-hop path selection, using an overall Destination-Vector paradigm). So let's dispense with that pointless straw man, OK? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 16:48:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0m3Y-0003yZ-Hb; Sat, 30 Dec 2006 16:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0m3X-0003yT-Vt for ram@iab.org; Sat, 30 Dec 2006 16:47:55 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0m3U-0007D3-V0 for ram@iab.org; Sat, 30 Dec 2006 16:47:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 16:47:52 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110605513:sNHT43344172" 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 kBULlqYX026995 for ; Sat, 30 Dec 2006 16:47:52 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBULlqG9015541 for ; Sat, 30 Dec 2006 16:47:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061230213004.F08CE86AE9@mercury.lcs.mit.edu> References: <20061230213004.F08CE86AE9@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 13:47:36 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=754; t=1167515272; x=1168379272; 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=x7slU4HbYakQWTTBebwvKZYMZKbOcknUyTPbNtmvSgk=; b=fssHRkNdAhZ5wxOtj1IJGwYHJIFmnOew9O2nGsfAWS1/2HpoDwPvPArJSvSS3ojvn4KQyJuY IFgxQcPe1emcxDAkvy8Pjs9h5XNh+FYf2rWRYH3SJS02XZuRye4/mmcd; 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: 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 Dec 30, 2006, at 1:30 PM, Noel Chiappa wrote: > So let's dispense with that pointless straw man, OK? This was the closest analogy I could think of to what has been proposed with SHIM6 and related proposals in terms of endpoints making path selection decisions for themselves. Would virtual IPs on servers would be a better analogy? Is there some other paradigm or architecture in place today which would serve as a useful analogy in terms of extrapolating the need for/desirability of hosts making path selection decisions? ----------------------------------------------------------------------- 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 Sat Dec 30 16:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0m4V-0004Od-VA; Sat, 30 Dec 2006 16:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0m4U-0004OY-V0 for ram@iab.org; Sat, 30 Dec 2006 16:48:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0m4T-0007V3-MZ for ram@iab.org; Sat, 30 Dec 2006 16:48:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 13:48:51 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49725140:sNHT42545424" 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 kBULmp3g024576 for ; Sat, 30 Dec 2006 16:48:51 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBULlqGA015541 for ; Sat, 30 Dec 2006 16:48:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> References: <20061230212443.AB67686AE9@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 13:48: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=682; t=1167515331; x=1168379331; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=2xYMHeI574kancSEy2Xv+ZBtIaf+3dlRLOf9R3Js7NI=; b=FAxqz5uSz9T35dQfK1LpkuKOTy5f1qtXDzHJ4001Jomb6PuuR2w/uixBaKq2+qNeJWnRpb6W vBT/kMsWoewNvoMNw1SJdOoBIqA/9mKt7BPg4SSREeEC5rZdlBwvp+J3; 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: 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 Dec 30, 2006, at 1:24 PM, Noel Chiappa wrote: > > Stop saying - and thinking - "IP addresses". "IP addresses", as > currently > constituted, are totally broken, and any attempt to fix the system > using "IP > addreses" is doomed to failure. You are correct, something like 'host IDs' is a better term. But I do believe that whatever we end up with in terms of 'host IDs', that people will still refer to them as 'IP addresses' for some time to come. ;> ----------------------------------------------------------------------- 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 Sat Dec 30 17:00:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mFI-0007SJ-4n; Sat, 30 Dec 2006 17:00:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mFG-0007S3-Uh for ram@iab.org; Sat, 30 Dec 2006 17:00:02 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0mFF-0000nb-Nz for ram@iab.org; Sat, 30 Dec 2006 17:00:02 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4D06986AF1; Sat, 30 Dec 2006 17:00:01 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> Date: Sat, 30 Dec 2006 17:00:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: Roland Dobbins > what has been proposed with SHIM6 and related proposals in terms of > endpoints making path selection decisions for themselves. Perhaps I'm confused, but I thought the main goal of SHIM6 was to allow widespread site muti-homing without overwhelming the existing global routing system with zillions of PI advertisements. If anyone's trying to support users/endpoints making path selection decisions with just SHIM6, they are seriously confused, IMO. You need a lot more than just multiple routing-names to do user/endpoint path selection in any reasonable way; for a start, you need information about the network topology (sorry, JohnD :-), and a way to actually control the path (and no, the source routing of today isn't it), etc, etc. In other words, it's a major architectural change, way past anything that's being discussed even here. > Is there some other paradigm or architecture in place today which would > serve as a useful analogy in terms of extrapolating the need > for/desirability of hosts making path selection decisions? Well, I don't know about you, but a majority of North American individuals make numerous path-selection choices every day, as a fundamental aspect of their daily lives. I'm talking, of course, about driving cars from A to B across the road network. And while some people are happy to take the default path, and if there's an outage (read accident) or congestion, they are happy to wait, I see plenty of people who are interested in availing themselves of the flexibility the system gives them to make independent decisions, and when they encounter outages or congestion, use alternative routes they select themselves. Too bad the data network doesn't give us all the same opportunity. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 17:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mI2-0007kR-45; Sat, 30 Dec 2006 17:02:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mI0-0007kM-Tn for ram@iab.org; Sat, 30 Dec 2006 17:02:52 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0mHz-0001F8-OK for ram@iab.org; Sat, 30 Dec 2006 17:02:52 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 86E5E86AF1; Sat, 30 Dec 2006 17:02:51 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061230220251.86E5E86AF1@mercury.lcs.mit.edu> Date: Sat, 30 Dec 2006 17:02:51 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: Roland Dobbins > whatever we end up with in terms of 'host IDs', that people will still > refer to them as 'IP addresses' for some time to come. Hey, if they really are "host ID's", people can call them Foobersnicky Wangerdoodles for all I care - the point is, they won't be the names that the path-selection mechanisms use as their fundamental data. And that's pretty much all I *do* care about... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 17:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mV7-0003ka-QX; Sat, 30 Dec 2006 17:16:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mV7-0003kV-2b for ram@iab.org; Sat, 30 Dec 2006 17:16:25 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0mV5-0000vV-Or for ram@iab.org; Sat, 30 Dec 2006 17:16:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 17:16:24 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110606002:sNHT46918376" 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 kBUMGNLo028282 for ; Sat, 30 Dec 2006 17:16:23 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUMGNG9023986 for ; Sat, 30 Dec 2006 17:16:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> References: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B2C4D6A-229D-47FC-851C-20150ACEF843@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 14:16:07 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1452; t=1167516983; x=1168380983; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=ISdtZfUFNHjff7KkONercki9lGLauZo/EB36fWNZ33Q=; b=kyXxqOUMbxUDLfwoQovA1M2NdV52QidSVkaD4D005Y6d5/sIF+5nnUJg4X+iUEQaaV7Eiq0F U3mwCKGNQlnp05fTfjoL+fAEOy3bW1SrQzXBhioJCwcor71eUePdwyH8; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 30, 2006, at 2:00 PM, Noel Chiappa wrote: > Perhaps I'm confused, but I thought the main goal of SHIM6 was to > allow > widespread site muti-homing without overwhelming the existing > global routing > system with zillions of PI advertisements. [Because this is being discussed in the context of IPv6, which still utilizes 'IP addresses', I have elected to use that term in this particular context, based upon common usage.] That is what the SHIM6 authors assert they are trying to accomplish, and it's what the authors of similar proposals assert they are trying to accomplish. Based upon the way that networks are constructed today, it seems to me that by mandating that each endpoint in a multihomed network have multiple IP addresses from multiple provider- assigned netblocks and that each endpoint then make a determination as to which of its multiple IP addresses is utilized as the source IP for each packet it emits, that this is in essence giving each endpoint a say in the initial path selection for the traffic it originates. By all means, please correct me if I'm mistaken in this interpretation. Perhaps I've read something into these proposals which really isn't there? ----------------------------------------------------------------------- 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 Sat Dec 30 17:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0n6z-00060Z-Kd; Sat, 30 Dec 2006 17:55:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0n6x-00060R-QC for ram@iab.org; Sat, 30 Dec 2006 17:55:31 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0n6v-0005u9-T6 for ram@iab.org; Sat, 30 Dec 2006 17:55:31 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 73B46122565; Sat, 30 Dec 2006 23:55:28 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 4B025122560; Sat, 30 Dec 2006 23:55:26 +0100 (CET) In-Reply-To: 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 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <62801b13a99370c9e05404c5d72c281e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 23:55:21 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 El 30/12/2006, a las 21:29, Roland Dobbins escribi=F3: > > On Dec 30, 2006, at 11:35 AM, marcelo bagnulo braun wrote: > >> i can see these are valid concerns for medium/big sites. >> but do you think these are issues for soho sites? i mean, my home=20 >> network doesn't have ACL, no TCAM for storing filters no MAC tables=20= >> and a very simple firewall. > > So, are we positing that SOHO users should run with what is=20 > essentially one protocol set/paradigm, and larger sites another, with=20= > all that entails in terms of fragmenting the global Internet, creating=20= > interesting issues for application developers, etc.? i guess so. but let me put in other words. As i see it multihoming means very different things for different users Suppose a big site, which is geographically distributed, with different=20= ISPs in different countries and has thousands of nodes and network=20 admin team very qualified. This type of site has strong TE requirements=20= and really needs centralized management. OTOH, these type of sites are=20= likely to be a reduced number, so from the global routing system=20 perspective, they do not have high scalability requirements (e.g. we=20 could give them PI blocks and they could do BGP) Suppose a home that has CATV and dsl line. This type of sites are=20 likely to have very limited management and their TE requirements seems=20= to be much more reduced (they don't have links in different countries=20 to choose from). OTOH, the number of potential multihomed sites of this=20= type for the medium term future may be really high, so the scalabilty=20 requirements of a solution for this type of sites will be really=20 important (we cannot give them PI and BGP, first because the=20 contribution to the global routing table would be very high and second,=20= they are no likely to be able to configure BGP) So, multihoming solution for big sites and for small sites have very=20 different requirements both from the capabilities they need to provide=20= and from the global routing system scalability p.o.v. (I am not even=20 considering ISP multihoming, which would result in another different=20 set of requirements i guess) So, trying to provide a single solution that fits all the types of=20 multihoming sites imho is a much more complex problem than having=20 different solutions for different type of multihomed sites. Perhaps it is a more accessible approach to try to identify the=20 requirements for the different type of multihomed sites (see Fred's=20 Baker draft on multihoming analysis for example) and then try to define=20= solutions for each of them _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 18:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nEV-0008Fc-3L; Sat, 30 Dec 2006 18:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nEU-0008Db-2H for ram@iab.org; Sat, 30 Dec 2006 18:03:18 -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 1H0nES-0007a5-L9 for ram@iab.org; Sat, 30 Dec 2006 18:03:18 -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 kBUMtT0f080068; Sat, 30 Dec 2006 14:55:29 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sat, 30 Dec 2006 15:02:54 -0800 X-PGP-Universal: processed; by terminus.local on Sat, 30 Dec 2006 15:02:54 -0800 In-Reply-To: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> References: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> From: David Conrad Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 15:02:51 -0800 To: Noel Chiappa 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: 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 Noel, On Dec 30, 2006, at 2:00 PM, Noel Chiappa wrote: > Perhaps I'm confused, but I thought the main goal of SHIM6 was to > allow > widespread site muti-homing without overwhelming the existing > global routing > system with zillions of PI advertisements. This was the goal of multi6, which led up to the shim6 proposal. I believe (and I will no doubt be corrected if I'm wrong) that the folks developing shim6 felt the definition of "site" was sufficiently vague as to imply the only real boundary where multi-homing would make sense was the "host" (arguably an equally vague term, but one that most folks can get their heads around). 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). Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 18:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nFV-0000XH-HA; Sat, 30 Dec 2006 18:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nFU-0000X8-Dy for ram@iab.org; Sat, 30 Dec 2006 18:04:20 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nFK-0007j4-86 for ram@iab.org; Sat, 30 Dec 2006 18:04:20 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 680C812254A; Sun, 31 Dec 2006 00:04:09 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id E98D3122542; Sun, 31 Dec 2006 00:04:07 +0100 (CET) In-Reply-To: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> References: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0fda34ea451ed3f751cca942b9d12194@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 00:04:18 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 Noel, El 30/12/2006, a las 22:24, Noel Chiappa escribi=F3: >> From: Roland Dobbins > >>> a solution that results in that the end points need to manage=20 >>> multiple >>> IP addresses is simply a non starter, right? > >> Yes, because of the administrative and resource overhead (think = iACLs, >> firewall rules, etc. .. and consuming twice or more the TCAM space in >> ASICs to hold those iACLs and other filtering/policy enforcement >> mechanisms, MAC/CAM table sizes, along with things like uRPF, and so >> forth) and because of the support burden > > The problem, at an archtectural level, is that you all are using the=20= > term "IP > addresses" for these names, and then assuming we're going to use them=20= > the > same way we use IP addresses today. > > If we had another namespace, then normal hosts would have only one=20 > name each > from the "identification namespace" (hence zero hassle in handling=20 > multiple > of them per host), and then access controls, etc should/would apply to=20= > that > namespace, and a lot of the problems you're talking about would just=20= > go away. > I am not sure about this... what would packets contain in their headers? They must contain locators (since you need them to route the packet=20 (more precisely, they must contain forwarding tags, which can or cannot=20= be the actual locators, but anyway, the point is that these are not the=20= identifiers)) They may contain the identifiers but they don't need to. So if they do=20= not contain the identifiers, then filters and ACLs not located in the=20 peer itself will need to run on locators (or forwarding tags) rather=20 than in the identifier (since the identifier is not in every packet (i=20= know it is possible to leave the middle boxes implementing the ACL and=20= filter to track the identifiers associated with the locator, but this=20 has more porblems of its own...)) If they do contain the identifiers, then we may come with an important=20= overhead (big locator pair and big identifier pair this assuming you=20 only carry one locator pair) but you will also need to carry security=20 information, so the ACL can validate the binding between the identifier=20= and the locator (if not anyone can include a cool identifier that is=20 allow to pass any acl in his own packets...). Besides, you also need to=20= take into account Jim's comment about what is visible by middle boxes=20 i.e. idendtifers may be encrypted e2e... So, i am not sure that it is possible to run filters and acl on=20 anything else than locators or forwarding tags... Regards, marcelo > > Stop saying - and thinking - "IP addresses". "IP addresses", as=20 > currently > constituted, are totally broken, and any attempt to fix the system=20 > using "IP > addreses" is doomed to failure. > > 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 Sat Dec 30 18:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nFf-0000bu-T2; Sat, 30 Dec 2006 18:04:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nFd-0000bR-Lr for ram@iab.org; Sat, 30 Dec 2006 18:04:29 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nFY-0007lf-Sv for ram@iab.org; Sat, 30 Dec 2006 18:04:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 Dec 2006 18:04:25 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110606782:sNHT44577064" 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 kBUN4OsZ004827 for ; Sat, 30 Dec 2006 18:04:24 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBUN4OgT012868 for ; Sat, 30 Dec 2006 18:04:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <62801b13a99370c9e05404c5d72c281e@it.uc3m.es> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> <62801b13a99370c9e05404c5d72c281e@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BC506E8-11AA-42DE-BECA-15689BE37DDA@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: Sat, 30 Dec 2006 15:04: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=1017; t=1167519864; x=1168383864; 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=FI1otAO6qROGGqvIo4O4FP6cj1Yx+QCzcmp90LYbJkg=; b=HMln0VZ+oU280PbakWgC84dYYfysvMUXQwTl6LI//VVQpS0rw4XAig30HdnqpTYL/EzEJFG5 OYlLvGmyZdMaYdJ/85ttDn6l1TDXC++CXupuyNsGRFKQQv6YnGbDi2MT; 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: 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 Dec 30, 2006, at 2:55 PM, marcelo bagnulo braun wrote: > Perhaps it is a more accessible approach to try to identify the > requirements for the different type of multihomed sites (see Fred's > Baker draft on multihoming analysis for example) and then try to > define solutions for each of them Sure, this is what folks do, anyways. But it's important that any general solution does not impose unwarranted and burdensome requirements on the global Interent. I believe that SHIM6 and similar proposals do this, and so I don't want to see this posited as 'the multihoming solution'; neither do I care if some particular multihomed organization wishes to implement SHIM6 on its own network, just don't force SHIM6 or anything like it on me as a base requirement for multihoming. ----------------------------------------------------------------------- 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 Sat Dec 30 18:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nIN-0001G5-BF; Sat, 30 Dec 2006 18:07:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nIM-0001FW-SK for ram@iab.org; Sat, 30 Dec 2006 18:07:18 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nIL-0008QU-Lm for ram@iab.org; Sat, 30 Dec 2006 18:07:18 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 15:07:17 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49726466:sNHT43911670" 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 kBUN7Hdg005221 for ; Sat, 30 Dec 2006 18:07:17 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUN7HG9003937 for ; Sat, 30 Dec 2006 18:07:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> References: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2636DABF-912F-43BA-8DE9-04DB0B92725D@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 15:07: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=907; t=1167520037; x=1168384037; 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=6Zq5H0/5VaF/DfkwOhS7N9SfeWUL4+5/t0KI9N5ChA4=; b=WKn6ca9tPtCS1TzYc9LAycA5NBtmZ/vpkBiNv2pzZCZXPxlAD00ouMdt80NaXRBIdS1TcmbT Yof8DE7xYPMzHOhVWT5sJe7YpIPcAPxAsdgd1MivaNsrWQtTbtmn3N4/; 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: 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 Dec 30, 2006, at 3:02 PM, David Conrad wrote: > 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). This has been my interpretation of the implications of SHIM6, and so the objections I've raised to SHIM6 (or any proposal with similar characteristics) have been predicated upon this interpretation. It makes the traffic engineering problem (along with all the problems already discussed) worse for enterprises, too. ----------------------------------------------------------------------- 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 Sat Dec 30 18:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nOM-0003I8-SQ; Sat, 30 Dec 2006 18:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nOL-0003Hz-FN for ram@iab.org; Sat, 30 Dec 2006 18:13:29 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nO7-0001lo-7X for ram@iab.org; Sat, 30 Dec 2006 18:13:29 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Dec 2006 15:13:15 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49726606:sNHT43630336" 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 kBUNDEsl003576 for ; Sat, 30 Dec 2006 18:13:15 -0500 Received: from [192.168.1.101] (rtp-vpn3-108.cisco.com [10.82.216.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBUNDEG9004742 for ; Sat, 30 Dec 2006 18:13:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0fda34ea451ed3f751cca942b9d12194@it.uc3m.es> References: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> <0fda34ea451ed3f751cca942b9d12194@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: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 15:12:58 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=910; t=1167520395; x=1168384395; 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=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=caniT4BVbHb/y/mLjPZgAu8KusYJHR1bkaW+b4zT0rw=; b=Ru0dHZ59PiHUEmu6tsnZZXGRl4WDgzObmiJL1wnU3Sv1tiuNmxM18hQMXKpojiTL3pn/uHNY Xx8E51z4oRjjDgkywprrTf8itxCIQemAVntNNJ2BT49HQNkMkVrgv1fH; 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 Dec 30, 2006, at 3:04 PM, marcelo bagnulo braun wrote: > So, i am not sure that it is possible to run filters and acl on > anything else than locators or forwarding tags... Sure it is, with a true host/locator split and some form of coupling up and down the protocol stack (and devices/features which can parse the packets of such a protocol stack). Identity/AAA/entitlement and many other things could be handled much more effectively and less inelegantly than what we're limited to today, IMHO. In other words, something kind of SNA-like, in some respects - which is ironic, given that the OSI model was inspired by the structure and layering model of the SNA stack. ;> ----------------------------------------------------------------------- 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 Sat Dec 30 19:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0oJo-0003Jf-5Q; Sat, 30 Dec 2006 19:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0oJn-0003JX-5V for ram@iab.org; Sat, 30 Dec 2006 19:12:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0oJS-0006QB-22 for ram@iab.org; Sat, 30 Dec 2006 19:12:51 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 Dec 2006 16:12:27 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="96661769:sNHT41951772" 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 kBV0CR9D029051; Sat, 30 Dec 2006 16:12:27 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBV0CJPp021911; Sat, 30 Dec 2006 16:12:24 -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); Sat, 30 Dec 2006 16:12:23 -0800 Received: from [192.168.0.101] ([10.21.122.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Dec 2006 16:12:22 -0800 In-Reply-To: <0fda34ea451ed3f751cca942b9d12194@it.uc3m.es> References: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> <0fda34ea451ed3f751cca942b9d12194@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: <9ADC6028-F2E6-4CC0-8291-F70DA7965793@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 16:12:22 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Dec 2006 00:12:22.0987 (UTC) FILETIME=[582111B0:01C72C70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=473; t=1167523947; x=1168387947; 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=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=Vdx6qRqVj3wMwweGFrcA8nWM5LrHnOYYrgoQQ0bexB8=; b=i4YQQlB2tOeOggDXpQaJ7ffNqq5/793Z4Q/yIHhS4mVT3y8mYQt0jUBi7hnCy4VHdb7prXtx ZnCm+LMTNIGyWqvaUTcd12qR4UHYP2+YbWukMiJFhmFp8TrkP853zfQc; 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: d17f825e43c9aed4fd65b7edddddec89 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 > If they do contain the identifiers, then we may come with an > important overhead (big locator pair and big identifier pair this > assuming you only carry one locator pair) There's an important unstated assumption here that I don't think is necessarily true. The locator need not be 'big'. The identifier need not be 'big'. I refer you to the 8+8 proposal again for one possible encoding that takes no more space than we use today for v6. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Dec 30 19:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0oMn-00044p-0a; Sat, 30 Dec 2006 19:15:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0oMl-00043p-Iz for ram@iab.org; Sat, 30 Dec 2006 19:15:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0oMi-0004eQ-5E for ram@iab.org; Sat, 30 Dec 2006 19:15:55 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 Dec 2006 16:15:51 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBV0FpWO028624; Sat, 30 Dec 2006 16:15:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBV0FoDi018371; Sat, 30 Dec 2006 16:15:50 -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); Sat, 30 Dec 2006 16:15:50 -0800 Received: from [192.168.0.101] ([10.21.122.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Dec 2006 16:15:50 -0800 In-Reply-To: <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> References: <20061230220001.4D06986AF1@mercury.lcs.mit.edu> <8EAD8854-3FFF-4DDE-89D6-55BE4826864A@virtualized.org> 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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sat, 30 Dec 2006 16:15:49 -0800 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Dec 2006 00:15:50.0286 (UTC) FILETIME=[D3B062E0:01C72C70] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=931; t=1167524151; x=1168388151; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=D5OC6feGp0ehxlmGwXUNfd0kzk9y/SToGK8QN0wRuIQ=; b=ocqayPB6HnpkvLxAXY76H/FVfj8bSD2GG03pLNiKzOannhmZBu2WpIosbguWAcFZpOUnnFkd tAXotzIPtpWgd/bz9BW5JP640CSV+XNAXZ2iqOnmrSG9cAxFXXmTwQg1; 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 Dec 30, 2006, at 3:02 PM, David Conrad wrote: > I believe (and I will no doubt be corrected if I'm wrong) that the > folks developing shim6 felt the definition of "site" was > sufficiently vague as to imply the only real boundary where multi- > homing would make sense was the "host" (arguably an equally vague > term, but one that most folks can get their heads around). Well, I guess you're anticipating this then.... The real reason that shim6 came out the way that it did was the intensive pushback that all of the per-site proposals were given. All of those options were rejected as being too NATty for those tastes. Given the constraints that NAT was out, that we need to support multiple addresses, and that the stack can't change so that there must be only a single address seen by the stack, the only reasonable and logical alternative was to move the NAT functionality into the host. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 02:08:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0umU-0004qS-7v; Sun, 31 Dec 2006 02:06:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0umQ-0004qL-TZ for ram@iab.org; Sun, 31 Dec 2006 02:06:51 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0umP-0006wK-6x for ram@iab.org; Sun, 31 Dec 2006 02:06:50 -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 UAA21962; Sun, 31 Dec 2006 20:06:39 +1300 In-Reply-To: <8C033381-7745-4A7D-89D7-5ECED405E7BC@cisco.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <45954A9D.7080606@piuha.net> <18D388A6-8C05-4573-A0BC-39BE99C7B43C@cisco.com> <45955234.9060302@eml.cc> <8C033381-7745-4A7D-89D7-5ECED405E7BC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <007CBE82-5D1C-45B9-9F43-325B1D3F6ACF@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 20:06:43 +1300 To: Roland Dobbins X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 31/12/2006, at 7:55 AM, Roland Dobbins wrote: > > On Dec 29, 2006, at 9:28 PM, Andrew McGregor wrote: > >> Inasmuch as there are HIP implementations available and their >> characteristics are similar to those a SHIM6 implementation would >> have, I disagree. They're very easy to use, in fact can be >> largely ignored once in operation. Now, it is true that in a >> multi-homed situation path selection may be a problem, but I >> believe simply paying attention to ECN notification would be >> sufficient to allow a good balance between administration and ease >> of use. > > I was unclear; I'm talking about all overhead required for things > like iACLs, SNMP ACLs, vty ACLs, firewall rules, QoS policies, > etc., and what would be required to both support those things in > hardware and simply maintain/update them from an administrative > standpoint, and the ever-present help-desk burden. Right, I see. Well, here's one area where HIP has a significant advantage over SHIM6. The concept of an LSI helps a great deal in tidying this up from the point of view of the endpoints, and many of the things we do now (DHCP binding to MAC addresses, for instance) still work for the infrastructure. I don't regard the issues as particularly difficult; yes, things do get a bit different, but the overhead doesn't look nearly as bad as you seem to fear. > >> That's an assertion, I'd like to see some discussion as to why you >> believe this. > > I believe that the loosely-coupled nature of IPv4, which was a big > asset in terms of getting something implemented and deployed, was a > huge asset which helped TCP/IP win out over other competing > protocols. I also believe that this loosely-coupled paradigm, > while being an asset during the adoption phase, has now become a > millstone round our necks, because it has led us to rely on Rube > Goldbergian mechanisms such as ACLs, firewall rules, etc. due to > the lack of coupling and feedback mechanism for establishing > identity/entitlement/authentication/authorization up and down the > stack. The current conflation of host and locator information in > TCP/IP (both IPv4 and IPv6) contributes to this brittleness. Yes, exactly. There's been a lot of discussion about this around the HIP space. There is far too much use of IP address based authentication. IMO a network that relies on that is badly designed anyway, in that doing this creates administrative work. > > As long as we are stuck with what are essentially approximated out- > of-band mechanisms for trying to implement policy, the > administrative burden and potential for outages related to mistakes > during the administrative process, and as long as we must have help- > desks for enterprise users and SP customers, any proposal which > mandates multiple IP addresses and endpoint routing decisions is > DOA, IMHO. Certainly those issues are problems... however, AFAICT there are solutions to the problems of securing networks that do not require fixed IP addresses and that have already been specified by the IETF and other organisations. There's nothing in TLS or SASL that needs constant IP addresses, for example. That network administrators choose other ad-hockery to deal with those issues is really their own problem. In my mind it has been clear for more than a decade that it is best to configure systems such that you don't need to have fixed IP addresses in configurations... Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 02:10:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0uqD-0005pC-3v; Sun, 31 Dec 2006 02:10:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0uqB-0005p4-Va for ram@iab.org; Sun, 31 Dec 2006 02:10:43 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0uqA-0007Zb-9N for ram@iab.org; Sun, 31 Dec 2006 02:10:43 -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 UAA21996; Sun, 31 Dec 2006 20:10:39 +1300 In-Reply-To: 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 (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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 20:10:42 +1300 To: Roland Dobbins X-Mailer: Apple Mail (2.752.2) 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 On 31/12/2006, at 9:29 AM, Roland Dobbins wrote: > > On Dec 30, 2006, at 11:35 AM, marcelo bagnulo braun wrote: > >> i can see these are valid concerns for medium/big sites. >> but do you think these are issues for soho sites? i mean, my home >> network doesn't have ACL, no TCAM for storing filters no MAC >> tables and a very simple firewall. > > So, are we positing that SOHO users should run with what is > essentially one protocol set/paradigm, and larger sites another, > with all that entails in terms of fragmenting the global Internet, > creating interesting issues for application developers, etc.? The > majority of home users/SOHO sites are not multihomed, nor will they > be for quite some time unless/until MANET-type networking becomes > the norm, and probably not even then in the sense of multiple > simultaneous links, but rather in a failover type of scenario. > It's a bit more blurry in terms of some mobile devices, but the > direction seems to be devices which can opportunistically leverage > whatever the 'best' network is at any given moment (based upon > performance, cost, administrative policies, content/service > availability, etc.). In other words, mobile hosts end up multihomed, by default. Since this is the majority of workstations by now (check sales of laptops) and will likely be cellphones as well, the solutions that work for those nodes will become ubiquitous pretty quickly. > > I believe that the help-desk/troubleshooting problems discussed > previously at length precludes *mandating* multiple IP addresses, > it is a nonstarter. I believe that due to the preponderance of highly mobile devices, that argument will very quickly become irrelevant. Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 07:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zhI-0000x2-7E; Sun, 31 Dec 2006 07:21:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zhG-0000wv-QS for ram@iab.org; Sun, 31 Dec 2006 07:21:50 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0zhD-0006z1-79 for ram@iab.org; Sun, 31 Dec 2006 07:21:49 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AE4F3122A28; Sun, 31 Dec 2006 13:21:42 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 72AD8122A0F; Sun, 31 Dec 2006 13:21:37 +0100 (CET) In-Reply-To: <6BC506E8-11AA-42DE-BECA-15689BE37DDA@cisco.com> References: <3A1061DC-C23D-4C0D-9CFF-CEC95B026B8C@extremenetworks.com> <7E775FC0-D622-4A89-94A0-AEC7B95E4140@cisco.com> <56ea3efae121a0e7f413b6cb9821683a@it.uc3m.es> <4ddb59e2d3d64be01f14f1004a6abf4d@it.uc3m.es> <62801b13a99370c9e05404c5d72c281e@it.uc3m.es> <6BC506E8-11AA-42DE-BECA-15689BE37DDA@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3dcbf0d80fadd4693d1c1ad1e91d03e9@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: Sun, 31 Dec 2006 13:21:32 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 El 31/12/2006, a las 0:04, Roland Dobbins escribi=F3: > > On Dec 30, 2006, at 2:55 PM, marcelo bagnulo braun wrote: > >> Perhaps it is a more accessible approach to try to identify the=20 >> requirements for the different type of multihomed sites (see Fred's=20= >> Baker draft on multihoming analysis for example) and then try to=20 >> define solutions for each of them > > Sure, this is what folks do, anyways. good, so, how many different multihoming solutions do we need? i.e.=20 what type of multihoming sites with different requirements do you=20 identify? > But it's important that any general solution does not impose=20 > unwarranted and burdensome requirements on the global Interent. good point actually, so far, the main emphasis was that the solution does not=20 impose additional burden on the routing system, but i agree with you=20 that this should be extended to other domains Regards, marcelo > I believe that SHIM6 and similar proposals do this, and so I don't=20 > want to see this posited as 'the multihoming solution'; neither do I=20= > care if some particular multihomed organization wishes to implement=20 > SHIM6 on its own network, just don't force SHIM6 or anything like it=20= > on me as a base requirement for multihoming. > > = ----------------------------------------------------------------------- > 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 Sun Dec 31 07:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zie-00015v-MR; Sun, 31 Dec 2006 07:23:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zid-00015o-2y for ram@iab.org; Sun, 31 Dec 2006 07:23:15 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0zib-0004aB-Qz for ram@iab.org; Sun, 31 Dec 2006 07:23:15 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (sccrmhc13) with SMTP id <2006123112231301300oe16de>; Sun, 31 Dec 2006 12:23:13 +0000 Message-ID: <014f01c72cd5$f8a11170$6a01a8c0@china.huawei.com> From: "Spencer Dawkins" To: 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> Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 06:19:40 -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: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, of course, I may not understand every part of the concern, but ... I remember two general areas in discussion - a specific concern (the one Marshall is trying to understand) that botnet attacks might be more effect on transit networks if path selection is under host control, and a more general concern that SHIM6 gives botnetters another tool for attacks from hosts with security that generally reeks, so no telling how that tool might be exploited in the future. I know I'm not the only person who was listening at NANOGs recently. Does this sound familiar to anyone else? Thanks, Spencer From: "Marshall Eubanks" To: "Jari Arkko" Cc: "Spencer Dawkins" ; Sent: Saturday, December 30, 2006 6:46 AM Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering > Dear Jari; > > On Dec 30, 2006, at 3:25 AM, Jari Arkko wrote: > >> Hi Spencer, >>> >>> Thank you for asking. One topic that came up repeatedly at NANOG was >>> concern about SHIM6 reliance on hosts that are massively vulnerable to >>> viruses and botnetting (visualize a botnet controller switching all >>> owned hosts selecting transit paths from TWC to SBCGLOBAL, within a >>> minute or two). >> Botnet effects on any networking technology is always >> an important concern. But in this case I think you also >> have to ask whether its host-based multihoming designs >> (SHIM6, MOBIKE, HIP) that create this problem or something >> else. It would seem that a botnet can send using the >> source and destination prefixes it wants to, so it appears that >> it has the same denial of service capability irrespective >> of any functionality in the IP layer. Or did I miss something? >> > > 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. > > If you are using announced PI or even PA space, the multi-homing is > hidden from the host in most cases, so I don't see how you could make > that switch. > > What's not clear to me is what, exactly, the feared attack is. How is > switching an outbound DOS > from provider A to provider B and back worse than just blasting packets > out of provider A, which can > be done now ? > >> --Jari >> > > Regards > Marshall > >> >> _______________________________________________ >> 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 Sun Dec 31 07:29:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zov-0003BQ-S3; Sun, 31 Dec 2006 07:29:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0zou-0003BL-F6 for ram@iab.org; Sun, 31 Dec 2006 07:29:44 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0zot-0005wj-0f for ram@iab.org; Sun, 31 Dec 2006 07:29:44 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 13EF3122ABE; Sun, 31 Dec 2006 13:29:42 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 9F88D122AC9; Sun, 31 Dec 2006 13:29:32 +0100 (CET) In-Reply-To: <9ADC6028-F2E6-4CC0-8291-F70DA7965793@cisco.com> References: <20061230212443.AB67686AE9@mercury.lcs.mit.edu> <0fda34ea451ed3f751cca942b9d12194@it.uc3m.es> <9ADC6028-F2E6-4CC0-8291-F70DA7965793@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: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 13:29:44 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) 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 El 31/12/2006, a las 1:12, Tony Li escribi=F3: >> If they do contain the identifiers, then we may come with an=20 >> important overhead (big locator pair and big identifier pair this=20 >> assuming you only carry one locator pair) > > > There's an important unstated assumption here that I don't think is=20 > necessarily true. The locator need not be 'big'. The identifier need=20= > not be 'big'. I refer you to the 8+8 proposal again for one possible=20= > encoding that takes no more space than we use today for v6. > agree... however, you would still need to include the security information to=20 bind them in the packet itself... Regards, marcelo > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 08:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H10oC-0003Da-0P; Sun, 31 Dec 2006 08:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H10oA-0003DV-Mr for ram@iab.org; Sun, 31 Dec 2006 08:33:02 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H10o6-0004dG-GQ for ram@iab.org; Sun, 31 Dec 2006 08:33:02 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BFD1D872D4; Sun, 31 Dec 2006 08:32:55 -0500 (EST) To: ram@iab.org Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 08:32:55 -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: marcelo bagnulo braun > you would still need to include the security information to bind > them in the packet itself... No, you only need to include the security stuff when you *change* the binding (or add a new one to a set of "authorized" ones). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 08:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H110a-0006KC-BM; Sun, 31 Dec 2006 08:45:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H110Z-0006JU-4v for ram@iab.org; Sun, 31 Dec 2006 08:45:51 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H110X-0007x5-V4 for ram@iab.org; Sun, 31 Dec 2006 08:45:51 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AB2DF872D4; Sun, 31 Dec 2006 08:45:49 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231134549.AB2DF872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 08:45:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: Roland Dobbins > it seems to me that by mandating that each endpoint in a multihomed > network have multiple IP addresses from multiple provider-assigned > netblocks and that each endpoint then make a determination as to > which of its multiple IP addresses is utilized as the source IP for > each packet it emits, that this is in essence giving each endpoint > a say in the initial path selection for the traffic it originates. Well, yes, it allows hosts at multi-homed sites to select using the link to ISP P, as opposed to the connection to ISP Q. But if the link to ISP P is down, you'd *better* be able to select using the link to ISP Q, or your packet isn't going to get very far, is it? The thing is that SHIM6, by itself, is not a complete solution to fault-tolerant multi-homing (of the many different reasons there are to multihome); it needs some mechanism to tell the average host (which isn't monitoring the routing, to know that the link to P is down) which routing-name to put in its packets. But it's a start... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 08:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H116r-0008LH-Vb; Sun, 31 Dec 2006 08:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H116q-0008L4-Mm for ram@iab.org; Sun, 31 Dec 2006 08:52:20 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H116p-0000pp-Gq for ram@iab.org; Sun, 31 Dec 2006 08:52:20 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 44A66872D4; Sun, 31 Dec 2006 08:52: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: <20061231135219.44A66872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 08:52:19 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: Roland Dobbins > But it's important that any general solution does not impose > unwarranted and burdensome requirements on the global Interent. Oh, you mean like forcing every router in the entire default-free zone to carry an advertisement for site X's PI-address? > I believe that SHIM6 and similar proposals do this, and so I don't > want to see this posited as 'the multihoming solution' .. don't > force SHIM6 or anything like it on me as a base requirement for > multihoming. So, what's your concept for the right way to support multi-homing for smaller sites? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 09:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11LJ-0003nZ-Hz; Sun, 31 Dec 2006 09:07:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11LI-0003nU-F1 for ram@iab.org; Sun, 31 Dec 2006 09:07:16 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H11LH-00036E-8k for ram@iab.org; Sun, 31 Dec 2006 09:07:16 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D8E5B872D4; Sun, 31 Dec 2006 09:07:12 -0500 (EST) To: ram@iab.org Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 09:07:12 -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: "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). 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.... 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). 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... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 09:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H124N-00071A-4Z; Sun, 31 Dec 2006 09:53:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H124L-00070L-Ur for ram@iab.org; Sun, 31 Dec 2006 09:53:49 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H124K-0005l3-9i for ram@iab.org; Sun, 31 Dec 2006 09:53:49 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E9ED811185D; Sun, 31 Dec 2006 15:53:46 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id ADDBF120CF8; Sun, 31 Dec 2006 15:53:45 +0100 (CET) In-Reply-To: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4850f4e3cc56ede84e46bb30ea711f64@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: Sun, 31 Dec 2006 15:53:41 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 14:32, Noel Chiappa escribi=F3: >> From: marcelo bagnulo braun > >> you would still need to include the security information to bind >> them in the packet itself... > > No, you only need to include the security stuff when you *change* the > binding (or add a new one to a set of "authorized" ones). > but then the middle box needs to keep track of the authorized locator=20 set associated to each ID, which implies state, which need to be learnt=20= from somewhere, for instance, inspection of packets carrying such=20 information. This is possible but it has problems of its own, like what=20= happens if a new path is used, and the middle boxes there haven't seen=20= the initial packets...? I guess this disucssion may be becoming too into details, but bottom=20 line is that you cannot make filers and ACL based on identifiers unless=20= you can trust them. In the case of routing names, you can have some=20 level of trust, because, if you trust the routing system, then you know=20= this packet will only be delivered to the destiantion locator. However,=20= you do not have this level of trust if you use identifiers and you need=20= to provide additional mechanism (that result in additional overhead or=20= state) to achieve it imho Regards, marcelo 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 Sun Dec 31 10:03:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12DG-000129-HG; Sun, 31 Dec 2006 10:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12DF-00011y-Mk for ram@iab.org; Sun, 31 Dec 2006 10:03:01 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H12DB-0007mM-18 for ram@iab.org; Sun, 31 Dec 2006 10:03:01 -0500 Received: from [10.0.1.2] (c-24-125-117-214.hsd1.va.comcast.net[24.125.117.214]) by comcast.net (rwcrmhc14) with SMTP id <20061231150238m1400gssepe>; Sun, 31 Dec 2006 15:02:54 +0000 In-Reply-To: <45961FAE.8060005@piuha.net> References: <5C8A39ED-6CEA-428F-8082-DC58B783DBC6@extremenetworks.com> <20061229162415.GA5059@1-4-5.net> <1C1E6193-238C-44B1-A434-119E3AEE63F9@eyeconomics.com> <45961FAE.8060005@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <124967E9-8ADC-4353-B434-BE2A23502BC2@eyeconomics.com> Content-Transfer-Encoding: 7bit From: tvest@eyeconomics.com Subject: Re: [RAM] Terminology: Routing Entropy Date: Sun, 31 Dec 2006 10:02:32 -0500 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.2 (/) 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 On Dec 30, 2006, at 3:13 AM, Jari Arkko wrote: > Tom, >> >>>> Back to the routing entropy issue: The nature of the >>>> dynamics of the UPDATE stream is directly related to the >>>> amount (and the granularity of) the information that is >>>> carried in the DFZ. All of this will effect not only the >>>> cost of providing Internet service, as well as its >>>> quality. >> >> Is it actually, today? I thought GIH's work last year showed that >> recent/current update dynamics were substantially driven by a >> relatively small number of operators with questionable configs/ >> competence? > I have also understood that its a big component of > what we're seeing today. But at the same time Dave > is right -- the more details we pour into the table > about the edge of the network, the more likely it > is that we will encounter bad setups and bad links. > > And I don't think the entire update load can be > classified under questionable practices. > > (An interesting question is what we can > do about the part that can be classified as such. Hi Jari, I think that Geoff's presentations on the subject were/are intended to be part of that response. Since "peer pressure" quite literally fails to be sufficient to moderate such behavior, identifying problem operators in public fora might expose them to other motivators (e.g., shame) to do better. Informed self-interest, informed group interest (peer pressure), informed public interest (shame) -- short of changing technology to make such problems physically impossible, all we can do is tweak the "information" and/or "interest" parameters to encourage community members to do better. So, to that end, here again are the networks that Geoff identified last year: AS9121 TR TTnet (Turk Telekom) AS702 US MCI EMEA (Verizon Business) AS721 US DNIC AS17557 PK PKTekecom AS7563 KR KII-AS Korea Internet Infrastructure AS9950 KR Dacom AS17832 KR SIXNGIX AS17974 IN PT Telekom Indonesia AS7545 AU Total Peripheral Group AS2706 HK Pacific Internet Depending on your ontology, 3-4 PSTNs, 2-3 government networks, 3-5 commercial ISPs. All in all, probably not an easy group to move through non-coercive means... > Its very hard for, say, an ISP to push back on > a questionable practice of its peer because > there are economic incentives to stay > connected, and because the price to > this one ISP is small, even if the price > to the entire world is great. Tragedy of > the commons. Are the best practices > documents that the operator community > could write? Has the IETF done enough > to provide guidance on how to use its > tools to do routing and TE?) I'm not really in the right demographic to gives good/representative answers to these questions, but I reckon the implicit answers are (maybe so, apparently not).... HNY all, Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 10:03:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Dh-0001L2-3q; Sun, 31 Dec 2006 10:03:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Df-0001J3-1q for ram@iab.org; Sun, 31 Dec 2006 10:03:27 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H12Dd-0007ta-P5 for ram@iab.org; Sun, 31 Dec 2006 10:03:27 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 07:03:25 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49753386:sNHT47825324" 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 kBVF3Pjb017661 for ; Sun, 31 Dec 2006 10:03:25 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVF3PgT021222 for ; Sun, 31 Dec 2006 10:03:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231134549.AB2DF872D4@mercury.lcs.mit.edu> References: <20061231134549.AB2DF872D4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F1B1B7E-1657-4E92-81FD-D59A6F9F0E51@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 07:03: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=2917; t=1167577405; x=1168441405; 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=T+/N0hoz9tg+8lBE/IYFgEeRnP+rRD5IETpYOqqyf1E=; b=libK8g46hfdGK8pzDTei9K3lDqpnXPL8tm3m3F8o7MWfSfDaZZH0KP5zigS7PYeiXXpGRA63 c0hZg9U0JCYTIMlpjVOaqQ1uWgvlN+B1Dia66Swkg8otY74y+v8gPciA; 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: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 5:45 AM, Noel Chiappa wrote: > Well, yes, it allows hosts at multi-homed sites to select using the > link to > ISP P, as opposed to the connection to ISP Q. But if the link to > ISP P is > down, you'd *better* be able to select using the link to ISP Q, or > your packet > isn't going to get very far, is it? [Firstly, it's important that we remember that packets aren't always destined for the global Internet; they're quite often (especially in the case of large enterprise-type organizations, who are the folks who do the vast majority of multihoming today and who will probably continue to do the vast majority of multihoming for some time into the future) destined for endpoints on an intranet. And yet SHIM6 makes -all TCP/IP networking- for multihomed organizations vastly more complicated and troublesome in the ways outlined previously due to this one (important, granted) global set of destinations.] The question is whether -you- (in your role as endpoint) ought to be - mandated- to make those types of decisions, or whether it's more desirable in most cases to let the network infrastructure make those types of decisions. Endpoints have been capable of running daemons which listen to the IGP and make initial path selection decisions based upon that information for a couple of decades, and yet HSRP/ GLBP/VRRP/CARP were developed due to network operator demand for a way to accomplish this initial path selection without any dynamism on the part of the endpoint, instead handling it within the network infrastructure. There is a reason for this. Now, you in your role as endpoint certainly -ought- to be able to make those types of decisions if you've been configured to do so; but since the overwhelming majority of endpoints in multihomed network topologies are deliberately not configured to this today with currently-available mechanisms, despite the advantages such a configuration would bring, it seems pretty clear that the disadvantages of this type of endpoint behavior in the vast majority of cases outweighs its perceived advantages. Note that the objections I've raised mainly apply to the current model in which we utilize 'IP addresses' which conflate locator and host ID information on a loosely-coupled stack, and which further encourages us to try and (mis)use that conflated information for AAA, entitlement, and the like. If we could achieve a host/locator split and a more tightly coupled stack, many of these problems would in all likelihood go away; but since this doesn't seem likely to happen anytime soon, the objections stand, 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 From ram-bounces@iab.org Sun Dec 31 10:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Nz-0004SG-9D; Sun, 31 Dec 2006 10:14:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Nx-0004SA-LP for ram@iab.org; Sun, 31 Dec 2006 10:14:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H12Nw-00042F-ET for ram@iab.org; Sun, 31 Dec 2006 10:14:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 07:14:04 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49753572:sNHT44810764" 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 kBVFE4Qa016372 for ; Sun, 31 Dec 2006 10:14:04 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVFE3gT022375 for ; Sun, 31 Dec 2006 10:14:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231135219.44A66872D4@mercury.lcs.mit.edu> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13564C25-C0B5-4860-BBFF-D685E4BFD88E@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: Sun, 31 Dec 2006 07:13: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=1388; t=1167578044; x=1168442044; 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=i+dRUHsw0Sk/2DiloX7xmfO1KhFYkAjq0L3S+lAZH7U=; b=qvs7zvEgHaXlhNtupw1GdZcXWA/8hcVdnpIFzocItGgZ5tBAF6zTiHxNujlaHb7mipEICVVh bfoKliRH6ibPFnTBc9bug2K6qDnmaBEAW3Z3yksa9/thCcNT2ag37wVA; 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: 52e1467c2184c31006318542db5614d5 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 5:52 AM, Noel Chiappa wrote: > Oh, you mean like forcing every router in the entire default-free zone > to carry an advertisement for site X's PI-address? This is a problem, we all acknowledge that. But I submit that the proposed SHIM6 solution is iatrogenic in nature due to the reasons outlined previously. > So, what's your concept for the right way to support multi-homing for > smaller sites? I believe that 'the IPv6 mulithoming solution' ought to be generalizable and scalable to sites of all sizes. If folks want to use mechanisms like SHIM6 internally, fine, but the disadvantages of such mechanisms will outweigh their utility for the vast majority, IMHO, and so this class of proposals cannot be realistically considered for 'the IPv6 multihoming solution'. I don't know what the right solution is, yet. But I do know that shifting the problem by mandating that the initial path selection will take place on endpoints with multiple IP addresses which will be assigned and then re-assigned, and then re-assigned again ad infinitum based upon transitory customer-to-SP business relationships isn't 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 Sun Dec 31 10:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Xz-0007Bo-EI; Sun, 31 Dec 2006 10:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12Xy-0007Bh-GK for ram@iab.org; Sun, 31 Dec 2006 10:24:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H12Xr-0007ai-NO for ram@iab.org; Sun, 31 Dec 2006 10:24:26 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 07:24:20 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49753795:sNHT46928304" 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 kBVFOJbR017901 for ; Sun, 31 Dec 2006 10:24:19 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVFOJgT024104 for ; Sun, 31 Dec 2006 10:24:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <763D94E7-9965-486B-A7AC-012313950327@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 07:24: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=1969; t=1167578659; x=1168442659; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20 |To:=20ram@iab.org; bh=W5yWhg6W3eys5k/laEzB8lCr138FKtDOteISGxMqLjk=; b=mw0c+rIY5Nn5ZjChXEb2lj60xquY2jc2cIp7EFnZ2hP5gAoZ2gzcd3mpiTZjWNO1AEtdYeEV cMxNcM3uU6nLrJh6MmCZ4myDGoVhCiij1sXd/AvgAUZq8X3MdD8lUf0g; 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: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 6:07 AM, Noel Chiappa wrote: > 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). Er, that's how things work today for multihomed sites - the 'networking agent' is the network infrastructure. This is what people have wanted, and so that's how it's done. The basic problem with all of this (IPv6 itself, as well as the various IPv6 multihoming proposals which engage in problem-shifting away from the network infrastructure to the endpoints, and the users and help-desk personnel responsible for those endpoints) is that the groups generating these proposals and making decisions in this arena have not been representative of the actual user/customer population and do not grasp the problems faced by those populations nor their actual needs in this space. I'm not saying this in a condemnatory manner - after all, the process has always been open and anyone can participate, but I'm positing that this is the situation on the ground today. One can argue that it's pretty late in the process to start raising objections, but if the process doesn't produce a result which is acceptable to the network operator community (both SP and enterprise) and to the user/ customer base, it's all for naught, anyways; and since IPv6 is largely greenfield, we've still the opportunity to fix at least some of these problems now. ----------------------------------------------------------------------- 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 Sun Dec 31 10:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12zF-0006ne-01; Sun, 31 Dec 2006 10:52:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H12zD-0006mL-Fa for ram@iab.org; Sun, 31 Dec 2006 10:52:35 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H12zC-0007Ny-7Z for ram@iab.org; Sun, 31 Dec 2006 10:52:35 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DC40E872D4; Sun, 31 Dec 2006 10:52:33 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231155233.DC40E872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 10:52:33 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: 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 From ram-bounces@iab.org Sun Dec 31 11:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13XH-0007uJ-E0; Sun, 31 Dec 2006 11:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13XF-0007u9-Sb for ram@iab.org; Sun, 31 Dec 2006 11:27:45 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13X5-0001gS-VF for ram@iab.org; Sun, 31 Dec 2006 11:27:45 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 08:27:33 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49755005:sNHT46126212" 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 kBVGRXIi027035 for ; Sun, 31 Dec 2006 11:27:33 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVGRXgT011404 for ; Sun, 31 Dec 2006 11:27:33 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231155233.DC40E872D4@mercury.lcs.mit.edu> References: <20061231155233.DC40E872D4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7BD74AAF-9EEB-43B6-A688-EDF5F61EB9BF@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: Sun, 31 Dec 2006 08:27:16 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1828; t=1167582453; x=1168446453; 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=ziXELZcOwYf4mj49KDQCNWcU+Iyf4jZpg2/rLoSO+H4=; b=P6Li2Ai2YHFQ0ZFya7BFskPR8Rl+SPaRLN/svbZaV3NICJToCBAQO4fGBk78mtV75oqGGn+B CYlTQ8qCOtYrYWrPGUt2+3pAMaLIsaL0IzmvqFRau4S7A15l1KxDWYxr; 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 Dec 31, 2006, at 7:52 AM, Noel Chiappa wrote: > But if you're against all solutions of the form "multiple routing- > names", > what's left, other than "let the routing do it"? My preference is in fact to 'let the routing do it', because that's the simplest way from an operational/administrative standpoint for the majority of the user/customer base (which is why it's handled this way today in the IPv4 world); but I don't think we ought to bet the farm on that approach due to the many potential issues folks have raised, so we must come up with another set of solutions which are scalable and deployable. We cannot bet the future of internetworking on Moore's Law, no matter how much we'd like to do so. [ Well, that's not entirely true. My real preference would be to declare the 'IPv6 Limited-Deployment Proof-of-Concept Experiment' a success, and then get on with designing IPv10 for general deployment, incorporating the lessons we've learned over the last 30 years with what became IPv4 and what has become IPv6, mandating a host/locator split, ensuring that operational realities and requirements from SP, enterprise, SOHO, and consumer users are taken into account. I would also like a flying pony. ] I'm against all solutions of the form 'require each host to be assigned x number of transitory SP-provided IP addresses, where x=the number of SP transit links required to serve traffic originating from/ destined to said host' due to the reasons stated. My hope is that a more practical solution lies somewhere between these two extremes. ----------------------------------------------------------------------- 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 Sun Dec 31 11:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bq-0000Lm-9y; Sun, 31 Dec 2006 11:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bp-0000LG-EX for ram@iab.org; Sun, 31 Dec 2006 11:32:29 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13bo-0002Tt-3u for ram@iab.org; Sun, 31 Dec 2006 11:32:29 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8373411FF75; Sun, 31 Dec 2006 17:32:27 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 66D2F11EBF3; Sun, 31 Dec 2006 17:32:26 +0100 (CET) In-Reply-To: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> References: <20061231140712.D8E5B872D4@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 17:32:16 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 15:07, Noel Chiappa escribi=F3: > > However, I gather that class of solutions is somewhat constrained=20 > because > of TCP checksum issues; the border router can only do so much, unless=20= > the > host is in on it too. (Which is why GSE proposed to make the TCP=20 > checksum > cover only the ID half, but that horse is long-gone, alas...) Hence=20 > TLi's > comment about "too NAT-like", I suspect... > the other problem is that if you want to make these type of approaches=20= secure enough (to be acceptable), you need to provide means to securely=20= discover the locator set and this requires state (i don't think it can=20= be done stateless like GSE does it), so you end up with state in the=20 middle box, which introduces the other limitations of the NAT... this=20 can be done, but it is not as attractive one could think it would be=20 when you don't consider the security stuff. 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 Sun Dec 31 11:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bq-0000LM-0z; Sun, 31 Dec 2006 11:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bo-0000L3-Dt for ram@iab.org; Sun, 31 Dec 2006 11:32:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13bn-0002Tf-0N for ram@iab.org; Sun, 31 Dec 2006 11:32:28 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C55EC11F770; Sun, 31 Dec 2006 17:32:25 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 381DC11EF18; Sun, 31 Dec 2006 17:32:19 +0100 (CET) In-Reply-To: <13564C25-C0B5-48From ram-bounces@iab.org Sun Dec 31 11:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bq-0000Lm-9y; Sun, 31 Dec 2006 11:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bp-0000LG-EX for ram@iab.org; Sun, 31 Dec 2006 11:32:29 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13bo-0002Tt-3u for ram@iab.org; Sun, 31 Dec 2006 11:32:29 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8373411FF75; Sun, 31 Dec 2006 17:32:27 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 66D2F11EBF3; Sun, 31 Dec 2006 17:32:26 +0100 (CET) In-Reply-To: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> References: <20061231140712.D8E5B872D4@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 17:32:16 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 15:07, Noel Chiappa escribi=F3: > > However, I gather that class of solutions is somewhat constrained=20 > because > of TCP checksum issues; the border router can only do so much, unless=20= > the > host is in on it too. (Which is why GSE proposed to make the TCP=20 > checksum > cover only the ID half, but that horse is long-gone, alas...) Hence=20 > TLi's > comment about "too NAT-like", I suspect... > the other problem is that if you want to make these type of approaches=20= secure enough (to be acceptable), you need to provide means to securely=20= discover the locator set and this requires state (i don't think it can=20= be done stateless like GSE does it), so you end up with state in the=20 middle box, which introduces the other limitations of the NAT... this=20 can be done, but it is not as attractive one could think it would be=20 when you don't consider the security stuff. 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 Sun Dec 31 11:32:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bq-0000LM-0z; Sun, 31 Dec 2006 11:32:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13bo-0000L3-Dt for ram@iab.org; Sun, 31 Dec 2006 11:32:28 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13bn-0002Tf-0N for ram@iab.org; Sun, 31 Dec 2006 11:32:28 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C55EC11F770; Sun, 31 Dec 2006 17:32:25 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 381DC11EF18; Sun, 31 Dec 2006 17:32:19 +0100 (CET) In-Reply-To: <13564C25-C0B5-4860-BBFF-D685E4BFD88E@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@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: Sun, 31 Dec 2006 17:31:39 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 El 31/12/2006, a las 16:13, Roland Dobbins escribi=F3: > I believe that 'the IPv6 mulithoming solution' ought to be=20 > generalizable and scalable to sites of all sizes. This is exactly where we disagree. I think this is very hard because if=20= you add up all the requirements of all type of potential multihomed=20 sites, from a unmanaged lan with a couple of PCs to a highly managed=20 huge corporation site, and you also add al the border constratints,=20 like scalability of the routing system, then you have very very=20 difficult problem That is why i am proposing to identify different type of multihomed=20 sites and find different solutions for them regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram 60-BBFF-D685E4BFD88E@cisco.com> References: <20061231135219.44A66872D4@mercury.lcs.mit.edu> <13564C25-C0B5-4860-BBFF-D685E4BFD88E@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: Sun, 31 Dec 2006 17:31:39 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.624) 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 El 31/12/2006, a las 16:13, Roland Dobbins escribi=F3: > I believe that 'the IPv6 mulithoming solution' ought to be=20 > generalizable and scalable to sites of all sizes. This is exactly where we disagree. I think this is very hard because if=20= you add up all the requirements of all type of potential multihomed=20 sites, from a unmanaged lan with a couple of PCs to a highly managed=20 huge corporation site, and you also add al the border constratints,=20 like scalability of the routing system, then you have very very=20 difficult problem That is why i am proposing to identify different type of multihomed=20 sites and find different solutions for them regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 11:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13dH-00012B-5b; Sun, 31 Dec 2006 11:33:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13dF-00011T-JI for ram@iab.org; Sun, 31 Dec 2006 11:33:57 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13dE-0002hh-DF for ram@iab.org; Sun, 31 Dec 2006 11:33:57 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ED59F872D4; Sun, 31 Dec 2006 11:33:55 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231163355.ED59F872D4@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 11:33:55 -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: Roland Dobbins >> if you're against all solutions of the form "multiple routing- >> names", what's left, other than "let the routing do it"? > My preference is in fact to 'let the routing do it' But earlier you said: >> Oh, you mean like forcing every router in the entire default-free >> zone to carry an advertisement for site X's PI-address? > This is a problem, we all acknowledge that. So then you must not think it's really a problem? > My hope is that a more practical solution lies somewhere between > these two extremes. Ah. Could you please sketch out for us the technical details of such a solution? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 11:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13iw-0002tO-7c; Sun, 31 Dec 2006 11:39:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13iu-0002tH-Qb for ram@iab.org; Sun, 31 Dec 2006 11:39:48 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13it-0003gx-Je for ram@iab.org; Sun, 31 Dec 2006 11:39:48 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 11:39:48 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110635515:sNHT43707760" 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 kBVGdl4s028714 for ; Sun, 31 Dec 2006 11:39:47 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBVGdkG9021782 for ; Sun, 31 Dec 2006 11:39:47 -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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F6C593E-835C-4D8E-8F1B-483826DD1EAA@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: Sun, 31 Dec 2006 08:39: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=854; t=1167583187; x=1168447187; 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=VvHk77rM+SONkwkG8gDZVFfBBi2t5CMOpYv1zKtp54w=; b=HM4H7MBoKEsHzGeRbwV+/dTqTFPOeAS/G0avohxbAkWTzfaPPmcegpU6f9JJg+D3cagP25NP b50yTVv7GPxEf1IaPp4B1k9IvGj8trfd31WCE+dHhMhyrnhrRDNQSqzq; 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 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 From ram-bounces@iab.org Sun Dec 31 11:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13uf-0006C6-Mj; Sun, 31 Dec 2006 11:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13ud-0006Bp-JF for ram@iab.org; Sun, 31 Dec 2006 11:51:55 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13uc-00066J-CK for ram@iab.org; Sun, 31 Dec 2006 11:51:55 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 11:51:53 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110635807:sNHT45123372" 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 kBVGpsqj030680 for ; Sun, 31 Dec 2006 11:51:54 -0500 Received: from [192.168.1.101] (rtp-vpn2-301.cisco.com [10.82.241.45]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVGprgT014104 for ; Sun, 31 Dec 2006 11:51:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231163355.ED59F872D4@mercury.lcs.mit.edu> References: <20061231163355.ED59F872D4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68C68688-54A7-48EA-BB11-2336F131B8B2@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: Sun, 31 Dec 2006 08:51:36 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1271; t=1167583914; x=1168447914; 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=1sC3A6E0kWdgCFQxH3mFnBWlxoAP65rEbZiIlv9RUYA=; b=CdAYUJqCFsA/D9S/4Tvmdrwv9ToIRgZrj0LxpR4Nm7tJu1RdVPYygS3YCsbdYCYQQRvEt9mh mwWmpqYiC6QrZK65WGAImmnfz6DG6tpwb5aiCxuohan+90eRp1SHRmR0; 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 Dec 31, 2006, at 8:33 AM, Noel Chiappa wrote: > Ah. Could you please sketch out for us the technical details of such a > solution? Such solutions don't simply spring forth ex nihilo, as did Athena from Zeus' forehead. However, the fact that I personally haven't yet come up with a solution to a problem which has for quite some time been vexing a large number of people who're a lot smarter than I am doesn't invalidate the widely-shared view within the operational community that SHIM6 as currently constituted will not work for most organizations and in fact has many undesirable properties which outweigh its potential benefits in the vast majority of situations. The point is that *any solution which mandates multiple endpoint IP addresses in multihoming situations is a nonstarter*, and that it would be helpful if all the smart folks who're looking at this problem-set would stop wasting their considerable intellectual energies tilting at this windmill and instead start thinking about Something More Practical. ----------------------------------------------------------------------- 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 Sun Dec 31 12:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H14ql-0005MP-Eg; Sun, 31 Dec 2006 12:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H14qk-0005MJ-C2 for ram@iab.org; Sun, 31 Dec 2006 12:51:58 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H14qi-0006kC-83 for ram@iab.org; Sun, 31 Dec 2006 12:51:57 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc11) with SMTP id <2006123117514901100pmvuue>; Sun, 31 Dec 2006 17:51:49 +0000 In-Reply-To: <68C68688-54A7-48EA-BB11-2336F131B8B2@cisco.com> References: <20061231163355.ED59F872D4@mercury.lcs.mit.edu> <68C68688-54A7-48EA-BB11-2336F131B8B2@cisco.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: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 09:51:51 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 point is that *any solution which mandates multiple endpoint IP > addresses in multihoming situations is a nonstarter*, and that it > would be helpful if all the smart folks who're looking at this > problem-set would stop wasting their considerable intellectual > energies tilting at this windmill and instead start thinking about > Something More Practical. Hmmm... well, that's problematic. You see, the root of this entire discussion is the observation that the current situation, in which every multi-homed site gets a single PI prefix, is also a non-starter from a scalability perspective. Now, if endpoints don't have single addresses, and they don't have multiple addresses, the only logical alternative is that they don't have ANY address. That implies that we simply turn off the Internet, and that's not Practical. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 12:58:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H14wy-0006el-Oz; Sun, 31 Dec 2006 12:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H14wx-0006eY-C1 for ram@iab.org; Sun, 31 Dec 2006 12:58:23 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H14wv-0008Bu-3G for ram@iab.org; Sun, 31 Dec 2006 12:58:23 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (rwcrmhc11) with SMTP id <20061231175802m11003tiije>; Sun, 31 Dec 2006 17:58:19 +0000 In-Reply-To: References: <20061231140712.D8E5B872D4@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: <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 09:58:04 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 >> 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... >> > > the other problem is that if you want to make these type of > approaches secure enough (to be acceptable), you need to provide > means to securely discover the locator set and this requires state > (i don't think it can be done stateless like GSE does it), so you > end up with state in the middle box, which introduces the other > limitations of the NAT... this can be done, but it is not as > attractive one could think it would be when you don't consider the > security stuff. Well, I think we're past the point of something being attractive and we're well into considering the lesser of multiple evils. We can live with the current architecture. We can take a host based solution ala shim6. Or we can have a border solution. Note that the latter two both break current ISP 'traffic engineering' requirements, and the status quo breaks ISP financial requirements. Something has to give... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 13:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H154d-0000gd-A4; Sun, 31 Dec 2006 13:06:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H154b-0000gX-PH for ram@iab.org; Sun, 31 Dec 2006 13:06:17 -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 1H154a-0001dR-G0 for ram@iab.org; Sun, 31 Dec 2006 13:06:17 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 31 Dec 2006 10:06:16 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="454428081:sNHT43827912" 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 kBVI6FeA016797 for ; Sun, 31 Dec 2006 10:06:15 -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 kBVI6Fnc009174 for ; Sun, 31 Dec 2006 10:06:15 -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); Sun, 31 Dec 2006 10:06:13 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 10:06:13 -0800 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.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4348C238-306E-4107-BD36-CA43A5DDF07D@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: Sun, 31 Dec 2006 10:06:16 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Dec 2006 18:06:13.0717 (UTC) FILETIME=[5BD64050:01C72D06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=865; t=1167588375; x=1168452375; 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=d3mLV4HSw1i9T0Q/u1j3SXNZzpWA+BaKHTHso+PSikw=; b=GGpbx0710tHQT6KVcyz/9rkr4wwUypQV4Rly7LvvNCgPTa3dIjXM54TXGZyim/XEOg9E4Aia PskmtFNzUKSMt0rwjmJXAv8kgVbSvN88mr+45XljUDsr2vnKVKDxJswL; 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: 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 >> 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? 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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 13:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15K1-000522-U7; Sun, 31 Dec 2006 13:22:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15K0-00051x-4n for ram@iab.org; Sun, 31 Dec 2006 13:22:12 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H15Jx-0006z4-Qn for ram@iab.org; Sun, 31 Dec 2006 13:22:12 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2006 10:22:07 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="96788410:sNHT43617447" 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 kBVIM70f021005; Sun, 31 Dec 2006 10:22:07 -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 kBVIM6Pn005058; Sun, 31 Dec 2006 10:22:06 -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); Sun, 31 Dec 2006 10:22:05 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 10:22:05 -0800 In-Reply-To: <4850f4e3cc56ede84e46bb30ea711f64@it.uc3m.es> References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> <4850f4e3cc56ede84e46bb30ea711f64@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: Sun, 31 Dec 2006 10:21:13 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Dec 2006 18:22:05.0385 (UTC) FILETIME=[93134390:01C72D08] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1153; t=1167589327; x=1168453327; 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=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=mQrI3DDGb6tDnl8brTXlkb1KIUl0NxbtMWDeDGmV7gw=; b=O/J2J3CXIKOPJ67wQoDryGpmzJ6ZHdoUsbzqLAxZmIH80UstA9mA/cPLDjr4bWAPMdl3Q6Vk RwbrcBbjMlylxpHToOrVe0N3ZsKy1vQdJWtwca8VbDbyVufphrYxq9F8; 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: 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 >>> you would still need to include the security information to bind >>> them in the packet itself... >> >> No, you only need to include the security stuff when you *change* the >> binding (or add a new one to a set of "authorized" ones). >> > > but then the middle box needs to keep track of the authorized > locator set associated to each ID, which implies state, A middle box implies state already. Having a middle box that does a locator lookup per packet is not going to scale and therefore the middle box at least has to cache an ID to locator mapping. > which need to be learnt from somewhere, for instance, inspection of > packets carrying such information. This is possible but it has > problems of its own, like what happens if a new path is used, and > the middle boxes there haven't seen the initial packets...? Well, one of the things that's implied in a middle box solution is that there is a protocol exchange between all of the site border routers, so that all changes are uniformly communicated. Effectively, you need shared state across all of your site border routers. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 13:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15Mw-0005mr-8p; Sun, 31 Dec 2006 13:25:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15Mu-0005ml-Hc for ram@iab.org; Sun, 31 Dec 2006 13:25:12 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H15Mt-0007y5-81 for ram@iab.org; Sun, 31 Dec 2006 13:25:12 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 31 Dec 2006 10:25:10 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBVIPA3t000817; Sun, 31 Dec 2006 10:25:10 -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 kBVIPAnc027685; Sun, 31 Dec 2006 10:25:10 -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); Sun, 31 Dec 2006 10:25:09 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 10:25:09 -0800 In-Reply-To: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> References: <20061231140712.D8E5B872D4@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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 10:25:11 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Dec 2006 18:25:09.0606 (UTC) FILETIME=[00E12860:01C72D09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=590; t=1167589510; x=1168453510; 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=jvUOY501F4dlVQMr0VFcryUJP6S4EOHNn5QDahFt80M=; b=U5gM2D4QlvH4A9wrKMZ9d7B7tWYSJzxrZLQN7eM9KXv79hng2iMrVWSPBh6Hi9SkPqoNipCW jHrWURSGQttUuHPOA8BaIFCt+fZ0V0QeOLBaGeCS5qst7X7dbDX7XuyI; 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: 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 > 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... 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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 14:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H165x-0001wJ-HT; Sun, 31 Dec 2006 14:11:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H165w-0001w6-4e for ram@iab.org; Sun, 31 Dec 2006 14:11:44 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H165j-0001Sp-S8 for ram@iab.org; Sun, 31 Dec 2006 14:11:44 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 3BF5A34022; Sun, 31 Dec 2006 14:11:29 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 14:11:28 -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: Sun, 31 Dec 2006 14:11:26 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> In-Reply-To: <4850f4e3cc56ede84e46bb30ea711f64@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: Accs66Tluk9HqbXDQIG+lHq4X3yBGQAI0aVA From: "Bound, Jim" To: "marcelo bagnulo braun" , "Noel Chiappa" X-OriginalArrivalTime: 31 Dec 2006 19:11:28.0829 (UTC) FILETIME=[796CEED0:01C72D0F] X-Spam-Score: 0.0 (/) 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 =20 > No, you only need to include the security stuff when you *change* the=20 > binding (or add a new one to a set of "authorized" ones). > I guess this disucssion may be becoming too into details, but=20 > bottom line is that you cannot make filers and ACL based on=20 > identifiers unless you can trust them. In the case of routing=20 > names, you can have some level of trust, because, if you=20 > trust the routing system, then you know this packet will only=20 > be delivered to the destiantion locator. However, you do not=20 > have this level of trust if you use identifiers and you need=20 > to provide additional mechanism (that result in additional overhead or > state) to achieve it imho 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. Best, /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 15:47:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17Zm-0001kD-1L; Sun, 31 Dec 2006 15:46:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17Zk-0001iw-RS for ram@iab.org; Sun, 31 Dec 2006 15:46:36 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H17VE-0002xd-QR for ram@iab.org; Sun, 31 Dec 2006 15:41:58 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 15:41:57 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110640444:sNHT46294476" 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 kBVKfutO032493 for ; Sun, 31 Dec 2006 15:41:56 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBVKfuG9001236 for ; Sun, 31 Dec 2006 15:41:56 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16C8375B-ACD3-46E3-8030-764A753E0203@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 12:41:38 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1856; t=1167597716; x=1168461716; 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=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(wasRe=3A=20[RAM]=20Traffic=20Engineering |Sender:=20 |To:=20ram@iab.org; bh=46anQbTDU2skXuFdCVGjlzfn32x5yrB6ureP02jRx3I=; b=CXwBIYS/ArmkwImpav201EJ1D/52xA3cSgTGYGqMqiP2+Q3uCtdYPt4nXo57JeDgZ5RXKPs9 HopBatpbzmPV7oDbHH7UH04+bpPl8kAzehKDbwja1XeaYHBCovecBTud; 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: 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 Dec 31, 2006, at 11:11 AM, Bound, Jim wrote: > 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. An optional capability to encrypt or obfuscate identifiers is something which is nice to have for reasons of privacy and anonymity, but I agree with you completely that this is not a base requirement. Hopefully, we can come up with a solution which, while not necessarily supporting this functionality initially, won't preclude it in later phases. It's also important to note that the conflation of encryption/ obfuscation with 'security' has in fact been harmful by a) providing the incorrect impression that all one has to do to secure one's host/ application/network is to encrypt various random things, with no thought or effort required apart from that, and b) encouraging the overuse of encryption where it really isn't needed, with the net effect that opsec personnel end up losing the ability to analyze and filter undesirable network traffic. So, we should work to avoid promulgating a misimpression similar to that in which some folks drew the incorrect inference that because of 'mandated' IPSEC that IPv6 is magically 'secure'. [ Of course, one operator's undesirable network traffic is another customer's BitTorrent, but that's a different discussion for a different forum, 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 Sun Dec 31 15:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17kH-0004aT-2L; Sun, 31 Dec 2006 15:57:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17kF-0004aH-QI for ram@iab.org; Sun, 31 Dec 2006 15:57:27 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H17kD-0000EO-Bf for ram@iab.org; Sun, 31 Dec 2006 15:57:27 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 12:57:25 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49760469:sNHT43739360" 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 kBVKvPs9004671 for ; Sun, 31 Dec 2006 15:57:25 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBVKvOG9002973 for ; Sun, 31 Dec 2006 15:57:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4348C238-306E-4107-BD36-CA43A5DDF07D@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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <257FB63A-A37D-4505-8538-E5E33CC7EC66@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: Sun, 31 Dec 2006 12:57:07 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1131; t=1167598645; x=1168462645; 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=RN10fI7kH0kpLKqpBuWzULfw+Mt6QDeWvkBU8NT9Xm4=; b=SZfXB/9KW2JJP3P1ZAyHRZw+3pJPfmftnNHBORhn+r4FXRhnAuMa3xrQfjZH/xn6DaI5Esgf Ez3gHGegvxihzjxaTt6pfSLlTxKEMdDmeaYJOqXMmomV3V5MkJnISzUb; 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: 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 Dec 31, 2006, at 10:06 AM, Tony Li wrote: > 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. Concur, as attempting to do so by any objective criteria seems doomed to failure. Also, networks may grow or shrink over time; while some changes are inevitable in such circumstances, a major paradigm-shift in the way traffic is handled ought not to be required. This also applies to sites which are single-homed today, but which may wish to become multi-homed tomorrow, or vice versa. Adding onerous requirements for moving from one mode of global connectivity to another (as if starting from scratch with BGP isn't already hard enough for folks without previous exposure to it, heh) is contraindicated. ----------------------------------------------------------------------- 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 Sun Dec 31 16:39:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18OT-0006er-Oe; Sun, 31 Dec 2006 16:39:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18OS-0006em-SD for ram@iab.org; Sun, 31 Dec 2006 16:39:00 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18OP-00021F-Db for ram@iab.org; Sun, 31 Dec 2006 16:39:00 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4F54C121E76; Sun, 31 Dec 2006 22:38:54 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 91DF5121E41; Sun, 31 Dec 2006 22:38:51 +0100 (CET) In-Reply-To: <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> 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: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 22:38:46 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 31/12/2006, a las 18:58, Tony Li escribi=F3: > >>> However, I gather that class of solutions is somewhat constrained=20 >>> because >>> of TCP checksum issues; the border router can only do so much,=20 >>> unless the >>> host is in on it too. (Which is why GSE proposed to make the TCP=20 >>> checksum >>> cover only the ID half, but that horse is long-gone, alas...) Hence=20= >>> TLi's >>> comment about "too NAT-like", I suspect... >>> >> >> the other problem is that if you want to make these type of=20 >> approaches secure enough (to be acceptable), you need to provide=20 >> means to securely discover the locator set and this requires state (i=20= >> don't think it can be done stateless like GSE does it), so you end up=20= >> with state in the middle box, which introduces the other limitations=20= >> of the NAT... this can be done, but it is not as attractive one could=20= >> think it would be when you don't consider the security stuff. > > > Well, I think we're past the point of something being attractive and=20= > we're well into considering the lesser of multiple evils. We can live=20= > with the current architecture. We can take a host based solution ala=20= > shim6. Or we can have a border solution. > > Note that the latter two both break current ISP 'traffic engineering'=20= > requirements, and the status quo breaks ISP financial requirements. =20= > Something has to give... > fully agree > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 16:41:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18QW-0007Hu-5u; Sun, 31 Dec 2006 16:41:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18QU-0007GZ-Fj for ram@iab.org; Sun, 31 Dec 2006 16:41:06 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18QT-0002NA-5U for ram@iab.org; Sun, 31 Dec 2006 16:41:06 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 766E3121D61; Sun, 31 Dec 2006 22:41:04 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 1EFF2121C88; Sun, 31 Dec 2006 22:41:02 +0100 (CET) In-Reply-To: References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> <4850f4e3cc56ede84e46bb30ea711f64@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: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 22:41:14 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 31/12/2006, a las 19:21, Tony Li escribi=F3: > >>>> you would still need to include the security information to bind >>>> them in the packet itself... >>> >>> No, you only need to include the security stuff when you *change* = the >>> binding (or add a new one to a set of "authorized" ones). >>> >> >> but then the middle box needs to keep track of the authorized locator=20= >> set associated to each ID, which implies state, > > > 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) > Having a middle box that does a locator lookup per packet is not=20 > going to scale and therefore the middle box at least has to cache an=20= > ID to locator mapping. > > >> which need to be learnt from somewhere, for instance, inspection of=20= >> packets carrying such information. This is possible but it has=20 >> problems of its own, like what happens if a new path is used, and the=20= >> middle boxes there haven't seen the initial packets...? > > > Well, one of the things that's implied in a middle box solution is=20 > that there is a protocol exchange between all of the site border=20 > routers, so that all changes are uniformly communicated. Effectively,=20= > you need shared state across all of your site border routers. > we are on the same page, just wanted to make sure that we were thinking=20= about the same thing when we said middle box/border router approach Regards, marcelo > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 16:43:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18Sq-0008Af-EH; Sun, 31 Dec 2006 16:43:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18So-0008Aa-AR for ram@iab.org; Sun, 31 Dec 2006 16:43:30 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18Sn-0003OE-0C for ram@iab.org; Sun, 31 Dec 2006 16:43:30 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 34761121BF1; Sun, 31 Dec 2006 22:43:28 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id CC0FF121CA6; Sun, 31 Dec 2006 22:43:26 +0100 (CET) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7d2996140081b03193d4f16ae9d69f02@it.uc3m.es> 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: Sun, 31 Dec 2006 22:43:38 +0100 To: "Bound, Jim" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 31/12/2006, a las 20:11, Bound, Jim escribi=F3: > >> No, you only need to include the security stuff when you *change* the >> binding (or add a new one to a set of "authorized" ones). > >> I guess this disucssion may be becoming too into details, but >> bottom line is that 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. 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 imho > > 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=20= box will be able to even see the identifier in order to use them in=20 filters and ACLs, right? > Best, > /jim > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 16:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18a7-0001OP-0E; Sun, 31 Dec 2006 16:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18a5-0001OK-QT for ram@iab.org; Sun, 31 Dec 2006 16:51:01 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18a4-0006iY-FU for ram@iab.org; Sun, 31 Dec 2006 16:51:01 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 80213121CA6; Sun, 31 Dec 2006 22:50:59 +0100 (CET) Received: from [163.117.203.84] (unknown [163.117.203.84]) by smtp01.uc3m.es (Postfix) with ESMTP id 300EC121C79; Sun, 31 Dec 2006 22:50:57 +0100 (CET) In-Reply-To: <4348C238-306E-4107-BD36-CA43A5DDF07D@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> 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: Sun, 31 Dec 2006 22:51:09 +0100 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 19:06, Tony Li escribi=F3: > >>> That is why i am proposing to identify different type of multihomed=20= >>> sites and find different solutions for them >> >> This certainly makes sense, but how do we identify 'types' of=20 >> multihomed sites other than by some arbitrary criteria of scale (and=20= >> of which things - number of endpoints, number of PoPs, number of=20 >> transit links, etc.)? Within the current IPv4 and IPv6 paradigms,=20 >> can we identify *qualitative* differences between a home user with a=20= >> /24 and two T1s to different SPs and a large multinational=20 >> corporation with multiple PoPs/SPs on multiple continents? > > > Architecturally, sites that simply differ in traffic volume or=20 > internal complexity shouldn't be dealt with separately. Thus, a=20 > 'clean' solution should not require entirely different solutions for=20= > different market sub-segments. > i though we have already passed the point of a clean solutions and we=20 were trying to find the less of two evils :-) more seriuosly, i think that an important different is management. I=20 mean, big sites have professional network admins that can configure=20 complex protocols (e.g. bgp) Moreover, because of that they are likely=20= to want some centralized way to enforce the configurations. A home=20 network does not have a network admin (ir the network admin is the=20 user) and it is likely he is not able to do complex configurations. I think this is (may be) an important difference 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 Sun Dec 31 16:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18gm-0003HH-Iy; Sun, 31 Dec 2006 16:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H18gl-0003HC-Vr for ram@iab.org; Sun, 31 Dec 2006 16:57:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H18gj-0007tV-OJ for ram@iab.org; Sun, 31 Dec 2006 16:57:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 13:57:51 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49761810:sNHT44357752" 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 kBVLvpBV013046 for ; Sun, 31 Dec 2006 16:57:51 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVLvpgT002962 for ; Sun, 31 Dec 2006 16:57:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C964C00-D23D-4769-9D72-48F8131C0BAF@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 13:57:31 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=986; t=1167602271; x=1168466271; 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=Js/pyD8JHsEft7cawjeOSb8xdqNrNVya2VMbm4ywi6Q=; b=c7cNqjYXJBeE97wrRUaRjRm4M4rE/L9gE88MEGu5qSovVe0ja+LAgFSVYB9YZrxzqlnKScrM QzW1W2/Hi3vu7KZVwhuIJsM+ZcPgblk+Berbd2LMVj0YkW2S0xQI7wCr; 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: 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 Dec 31, 2006, at 9:58 AM, Tony Li wrote: > the status quo breaks ISP financial requirements And the host model breaks enterprise OPEX and CAPEX financial requirements, IMHO - OPEX because of the ongoing admin and support overhead, along with regular renumbering exercises requiring even more overhead, and CAPEX due to increased hardware requirements to handle substantially larger/longer iACLS/firewall rules/QoS policies/ etc. Cost-shifting isn't the correct way to handle this issue. As you say, something has to give; unattractive as it is, perhaps there's some variation of the border model which can be constructed so as to permit sufficient traffic engineering capabilities to satisfy all parties. [ Or we get started on IPv10, stat. ] ----------------------------------------------------------------------- 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 Sun Dec 31 17:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19Hm-00048M-RU; Sun, 31 Dec 2006 17:36:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19Hl-000474-OB for ram@iab.org; Sun, 31 Dec 2006 17:36:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H19Hk-0008FU-GU for ram@iab.org; Sun, 31 Dec 2006 17:36:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 14:36:08 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49763038:sNHT46108412" 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 kBVMa8Qx019026 for ; Sun, 31 Dec 2006 17:36:08 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBVMa7gT015552 for ; Sun, 31 Dec 2006 17:36:07 -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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <644B6E2A-171A-4CD8-9F62-FFA0D692F25E@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: Sun, 31 Dec 2006 14:35:49 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2105; t=1167604568; x=1168468568; 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=E8B49e354l9mTRrCZIMRBhUubRHpqk8kLIDtgmh+5i8=; b=K06vuSpLsMCht05AT2zBZKpzUQqEiMzNeh9ad5zGPK2ZX7KG1LH7ZHWqZlEg8lVWppGkTbr8 o8tXePwrgCpFp13SG0GO114Th3vLG7rTy5lMkB7NiQb7433pxJ7SgSP5; 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: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 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. > I think this is (may be) an important difference In my experience, the difference isn't as great as one would think, 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 From ram-bounces@iab.org Sun Dec 31 18:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1A5u-0000CO-W7; Sun, 31 Dec 2006 18:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1A5u-0000CJ-8K for ram@iab.org; Sun, 31 Dec 2006 18:27:58 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1A5t-0007kd-1R for ram@iab.org; Sun, 31 Dec 2006 18:27:58 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 81F4E86AF3; Sun, 31 Dec 2006 18:27:54 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 18:27:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: Roland Dobbins >> Ah. Could you please sketch out for us the technical details of such a >> solution? > the fact that I personally haven't yet come up with a solution to a > problem which has for quite some time been vexing a large number of > people who're a lot smarter than I am doesn't invalidate the > widely-shared view within the operational community that SHIM6 as > currently constituted will not work for most organizations OK, but the latter point doesn't help with the former one, either. TANSTAAFL. If people want the benefit of widespread multihoming, there is going to be a cost, and, as you indicated, many smart people have failed to come up with a painless one. And when I said "sketch", I meant just that. I don't want a protocol from you, just some idea of the vague outlines of an approach that you think might work. Saying "A won't work because of X, and B won't work because of Y" doesn't really help much. Do you have any idea at all how to make this work? (And a list of goals, like "it should be the same for everyone" or "it should be easy to manage" aren't "how to make it work".) > The point is that *any solution which mandates multiple endpoint IP > addresses in multihoming situations is a nonstarter* If you mean "solutions which mandate multiple IP addresses" above, then I'm OK with that. If you mean "solutions which mandate multiple routing-names", then I have some very bad news for you. Other than "let the routing do it" (and flat - aka PI - routing doesn't scale), *every* proposed solution which I've ever heard of (including ones which simply aren't feasible in the current routing architecture, such as Dave Clark's trailing route fragments, my local topology fragments, etc) involves use of multiple routing-names (the semantics of which vary, but that's what they all are, basically). So if multiple routing-names are out, widespread multi-homing is out. "We are a lighthouse. Your call." Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 18:35:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ADV-0002AI-9u; Sun, 31 Dec 2006 18:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ADU-0002AC-2E for ram@iab.org; Sun, 31 Dec 2006 18:35:48 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ADS-0002Jb-S0 for ram@iab.org; Sun, 31 Dec 2006 18:35:48 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A66FF86AF3; Sun, 31 Dec 2006 18:35:46 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20061231233546.A66FF86AF3@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 18:35:46 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > Hmmm... well, that's problematic. .. if endpoints don't have single > addresses, and they don't have multiple addresses, the only logical > alternative is that they don't have ANY address. That implies that we > simply turn off the Internet This whole multi-homing discussion reminds me incredibly strongly of the CIDR-Deployment discussion. Everyone walks up and say "your solution sucks, because it means I have to do X, which is painful and contrary to my inherent rights, and I refuse to do it". So you explain to them why the choice is X or nothing, and eventually they swallow hard and bite down on X. Then the next person comes up, and the process repeats. Eventually people get tired of banging their heads on the wall, but it takes quite a while. So my prediction is that eventually people will accept that to have widespread multi-homing, they will have to accept that entities have to have multiple routing-names. Whether it will take even longer, because the Internet community is now even bigger, well that's a good question. How exactly, in technical terms, the multiple routing-names will happen (it may be done through border devices, so that individual hosts don't have to get involved, or perhaps we'll automate it somehow, as we do now with TCP retransmission timeouts, which are so complex we keep people away from them) remains to be seen. GSE may look a lot better to people now that they've seen SHIM6. And hey, if all else fails, there's always NAT. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 18:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMC-0004K6-B0; Sun, 31 Dec 2006 18:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMA-0004JC-VL for ram@iab.org; Sun, 31 Dec 2006 18:44:46 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1AM9-00059a-LR for ram@iab.org; Sun, 31 Dec 2006 18:44:46 -0500 Received: from webmail47.lax.untd.com (webmail47.lax.untd.com [10.131.27.187]) by smtpout01.lax.untd.com with SMTP id AABC3SU5JA3J3DLA for (sender ); Sun, 31 Dec 2006 15:44:40 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKz65vNq9JDrSNVCyzTHpK9w== Received: (from fergdawg@netzero.net) by webmail47.lax.untd.com (jqueuemail) id MAX5GAHQ; Sun, 31 Dec 2006 15:44:33 PST Received: from [24.23.201.115] by webmail47.lax.untd.com with HTTP: Sun, 31 Dec 2006 23:44:24 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Sun, 31 Dec 2006 23:44:24 GMT To: jnc@mercury.lcs.mit.edu Subject: Re: one size doesn' fit all (was 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: <20061231.154433.6411.1802873@webmail47.lax.untd.com> X-ContentStamp: 15:7:1142013784 X-MAIL-INFO: 4e11b10c814db14d4d8d11a98920645151d9809051696089a0bd7574216161b170e90d0c X-UNTD-Peer-Info: 10.131.27.187|webmail47.lax.untd.com|webmail47.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Funny that. You and I are in violent agreement. :-) Cheers, - - ferg - -- jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: Everyone walks up and say "your solution sucks, because it means I have = to do X, which is painful and contrary to my inherent rights, and I refuse to = do it". So you explain to them why the choice is X or nothing, and eventual= ly they swallow hard and bite down on X. Then the next person comes up, an= d the process repeats. Eventually people get tired of banging their heads on t= he wall, but it takes quite a while. So my prediction is that eventually people will accept that to have widespread multi-homing, they will have to accept that entities have to have multip= le routing-names. Whether it will take even longer, because the Internet community is now even bigger, well that's a good question. How exactly, in technical terms, the multiple routing-names will happen = (it may be done through border devices, so that individual hosts don't have = to get involved, or perhaps we'll automate it somehow, as we do now with TC= P retransmission timeouts, which are so complex we keep people away from them) remains to be seen. GSE may look a lot better to people now that they've= seen SHIM6. And hey, if all else fails, there's always NAT. Noel -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFmEs8q1pz9mNUZTMRAg8OAJ4x7U8Xgbmh379QZP+xU99ZZURN6wCeO1jw DvMhXrT606R7QSIRzU7WbPM=3D =3DXGq2 -----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 maiFrom ram-bounces@iab.org Sun Dec 31 18:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMC-0004K6-B0; Sun, 31 Dec 2006 18:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMA-0004JC-VL for ram@iab.org; Sun, 31 Dec 2006 18:44:46 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1AM9-00059a-LR for ram@iab.org; Sun, 31 Dec 2006 18:44:46 -0500 Received: from webmail47.lax.untd.com (webmail47.lax.untd.com [10.131.27.187]) by smtpout01.lax.untd.com with SMTP id AABC3SU5JA3J3DLA for (sender ); Sun, 31 Dec 2006 15:44:40 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKz65vNq9JDrSNVCyzTHpK9w== Received: (from fergdawg@netzero.net) by webmail47.lax.untd.com (jqueuemail) id MAX5GAHQ; Sun, 31 Dec 2006 15:44:33 PST Received: from [24.23.201.115] by webmail47.lax.untd.com with HTTP: Sun, 31 Dec 2006 23:44:24 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Sun, 31 Dec 2006 23:44:24 GMT To: jnc@mercury.lcs.mit.edu Subject: Re: one size doesn' fit all (was 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: <20061231.154433.6411.1802873@webmail47.lax.untd.com> X-ContentStamp: 15:7:1142013784 X-MAIL-INFO: 4e11b10c814db14d4d8d11a98920645151d9809051696089a0bd7574216161b170e90d0c X-UNTD-Peer-Info: 10.131.27.187|webmail47.lax.untd.com|webmail47.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Funny that. You and I are in violent agreement. :-) Cheers, - - ferg - -- jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: Everyone walks up and say "your solution sucks, because it means I have = to do X, which is painful and contrary to my inherent rights, and I refuse to = do it". So you explain to them why the choice is X or nothing, and eventual= ly they swallow hard and bite down on X. Then the next person comes up, an= d the process repeats. Eventually people get tired of banging their heads on t= he wall, but it takes quite a while. So my prediction is that eventually people will accept that to have widespread multi-homing, they will have to accept that entities have to have multip= le routing-names. Whether it will take even longer, because the Internet community is now even bigger, well that's a good question. How exactly, in technical terms, the multiple routing-names will happen = (it may be done through border devices, so that individual hosts don't have = to get involved, or perhaps we'll automate it somehow, as we do now with TC= P retransmission timeouts, which are so complex we keep people away from them) remains to be seen. GSE may look a lot better to people now that they've= seen SHIM6. And hey, if all else fails, there's always NAT. Noel -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFmEs8q1pz9mNUZTMRAg8OAJ4x7U8Xgbmh379QZP+xU99ZZURN6wCeO1jw DvMhXrT606R7QSIRzU7WbPM=3D =3DXGq2 -----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 Sun Dec 31 18:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMV-0004Qr-MZ; Sun, 31 Dec 2006 18:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMU-0004Qi-6U for ram@iab.org; Sun, 31 Dec 2006 18:45:06 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1AMS-0005Bs-Ue for ram@iab.org; Sun, 31 Dec 2006 18:45:06 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 18:45:05 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110644570:sNHT46066056" 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 kBVNj4SV026562 for ; Sun, 31 Dec 2006 18:45:04 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBVNj4G9017089 for ; Sun, 31 Dec 2006 18:45:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> 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: Sun, 31 Dec 2006 15:44:45 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2300; t=1167608704; x=1168472704; 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=3A/Hq7VlN1dg3wM6WtPrISEa3j36hvlHR8t5C6ZId6c=; b=FAaVqslmnE9c93zDGiSI+wP7dTotZxk3SmqvugfGVucJMgrPbA1cpLraMfkM6FHBmUQZpSEQ XnZjiBL9dZ1ucbXIJdcQE/11VqnpjJx2rt+ABO2f4X0aUdx7SLD1NM4/; 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: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 3:27 PM, Noel Chiappa wrote: > And when I said "sketch", I meant just that. I don't want a > protocol from > you, just some idea of the vague outlines of an approach that you > think might > work. Saying "A won't work because of X, and B won't work because > of Y" > doesn't really help much. I am thinking about it, as are a lot of other folks. If and when I have something sensible to say on the subject, I'll say it. Right now, I don't. Saying "A won't work because of X, and B won't work because of Y" helps a great deal, actually, especially when apparently nobody involved in developing A and B took X and Y into consideration. That's the situation we find ourselves in today. > If you mean "solutions which mandate multiple IP addresses" above, > then I'm > OK with that. If you mean "solutions which mandate multiple routing- > names", > then I have some very bad news for you. I mean 'mandating multiple identiling list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 18:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMV-0004Qr-MZ; Sun, 31 Dec 2006 18:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1AMU-0004Qi-6U for ram@iab.org; Sun, 31 Dec 2006 18:45:06 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1AMS-0005Bs-Ue for ram@iab.org; Sun, 31 Dec 2006 18:45:06 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 18:45:05 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110644570:sNHT46066056" 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 kBVNj4SV026562 for ; Sun, 31 Dec 2006 18:45:04 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBVNj4G9017089 for ; Sun, 31 Dec 2006 18:45:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231232754.81F4E86AF3@mercury.lcs.mit.edu> 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: Sun, 31 Dec 2006 15:44:45 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2300; t=1167608704; x=1168472704; 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=3A/Hq7VlN1dg3wM6WtPrISEa3j36hvlHR8t5C6ZId6c=; b=FAaVqslmnE9c93zDGiSI+wP7dTotZxk3SmqvugfGVucJMgrPbA1cpLraMfkM6FHBmUQZpSEQ XnZjiBL9dZ1ucbXIJdcQE/11VqnpjJx2rt+ABO2f4X0aUdx7SLD1NM4/; 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: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 3:27 PM, Noel Chiappa wrote: > And when I said "sketch", I meant just that. I don't want a > protocol from > you, just some idea of the vague outlines of an approach that you > think might > work. Saying "A won't work because of X, and B won't work because > of Y" > doesn't really help much. I am thinking about it, as are a lot of other folks. If and when I have something sensible to say on the subject, I'll say it. Right now, I don't. Saying "A won't work because of X, and B won't work because of Y" helps a great deal, actually, especially when apparently nobody involved in developing A and B took X and Y into consideration. That's the situation we find ourselves in today. > If you mean "solutions which mandate multiple IP addresses" above, > then I'm > OK with that. If you mean "solutions which mandate multiple routing- > names", > then I have some very bad news for you. I mean 'mandating multiple identifiers of the type which go into ACLs, firewall rules, QoS rules, etc. for filtering/matching packets' is out. > > Other than "let the routing do it" (and flat - aka PI - routing > doesn't > scale), *every* proposed solution which I've ever heard of > (including ones > which simply aren't feasible in the current routing architecture, > such as > Dave Clark's trailing route fragments, my local topology fragments, > etc) > involves use of multiple routing-names (the semantics of which > vary, but > that's what they all are, basically). Agreed. Which is why I'll say, one last time, the *best* thing to do, while it's not too late, would be to take the lessons learned so far and get to work on a new protocol suite which implements a host/locator split (leveraging your work and that of others) and a bunch of other useful stuff, rather than expending a lot of blood, sweat, and treasure deploying a protocol suite which leaves us with all the problems we had in the first place, along with some new problems - and in -hexadecimal-, no less. ;> ----------------------------------------------------------------------- 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 fiers of the type which go into ACLs, firewall rules, QoS rules, etc. for filtering/matching packets' is out. > > Other than "let the routing do it" (and flat - aka PI - routing > doesn't > scale), *every* proposed solution which I've ever heard of > (including ones > which simply aren't feasible in the current routing architecture, > such as > Dave Clark's trailing route fragments, my local topology fragments, > etc) > involves use of multiple routing-names (the semantics of which > vary, but > that's what they all are, basically). Agreed. Which is why I'll say, one last time, the *best* thing to do, while it's not too late, would be to take the lessons learned so far and get to work on a new protocol suite which implements a host/locator split (leveraging your work and that of others) and a bunch of other useful stuff, rather than expending a lot of blood, sweat, and treasure deploying a protocol suite which leaves us with all the problems we had in the first place, along with some new problems - and in -hexadecimal-, no less. ;> ----------------------------------------------------------------------- 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 Sun Dec 31 19:44:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BGl-0001Ce-PB; Sun, 31 Dec 2006 19:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BGk-0001CY-BQ for ram@iab.org; Sun, 31 Dec 2006 19:43:14 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1BGj-0004sg-3r for ram@iab.org; Sun, 31 Dec 2006 19:43:14 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Dec 2006 19:43:13 -0500 X-IronPort-AV: i="4.12,222,1165208400"; d="scan'208"; a="110645685:sNHT45388068" 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 l010hChb002327 for ; Sun, 31 Dec 2006 19:43:12 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l010hCgT019338 for ; Sun, 31 Dec 2006 19:43:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20061231233546.A66FF86AF3@mercury.lcs.mit.edu> References: <20061231233546.A66FF86AF3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <638A6F9E-CA97-49F6-A8D0-3F4C9A791D90@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: Sun, 31 Dec 2006 16:42:53 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1802; t=1167612192; x=1168476192; 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=vh7JbAdbjDSmJx0+E8tWtfUTqYDoL8+44DfYIz6FewU=; b=pLV8YSd8KCXxmy0dv1Uw+qKiOrrVQcwgLCeCFrfMYoet34VYbsPa4SV2yIhc3i1Qm9HjMUjK Oi8mCH/xRyAQzmpWhga4/Tke3GA5GaoQ5hWQZR+YIUI68sqONTYgGQH6; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 3:35 PM, Noel Chiappa wrote: > This whole multi-homing discussion reminds me incredibly strongly > of the > CIDR-Deployment discussion. The differences between then and now are a) that the set of problems which needed to be solved was better-understood by a large percentage of the relevant parties, b) there were far fewer relevant parties at that time than there are today, c) not as much blood, treasure, and sweat (in absolute terms) was at stake then as there is today, d) we've far less of an excuse to be in this boat at the end of 2006 than we did in 1992-1993 and e) we had time then to do a mid-course correction in the event that CIDR hadn't worked out, and f) CIDR was a pretty good and somewhat elegant solution to the set of problems which needed to be solved. The biggest similarities between then and now are a) that we've waited far too long to come up with a feasible solution which takes into account all the relevant considerations, b) that folks are yet again waking up to the fact that there is in fact a serious problem at the eleventh hour, and c) that an utterly unworkable proposal (then, the attempted CLNP putsch at the 1992 Kobe IAB meeting and the resultant 'palace revolt' at the 1992 Cambridge IETF meeting; now, SHIM6) has served a useful purpose in terms of ensuring that all the major aspects of the problem are finally being taken into consideration and that a larger proportion of the relevant stakeholders are finally taking an active interest in developing a solution. ----------------------------------------------------------------------- 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 Sun Dec 31 19:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BOP-0003O8-Ix; Sun, 31 Dec 2006 19:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BOO-0003O3-Q8 for ram@iab.org; Sun, 31 Dec 2006 19:51:08 -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 1H1BOM-000624-FB for ram@iab.org; Sun, 31 Dec 2006 19:51:08 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 Dec 2006 16:51:03 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="454444634:sNHT43876996" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l010p39w017237 for ; Sun, 31 Dec 2006 16:51:03 -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 l010p3nc020747 for ; Sun, 31 Dec 2006 16:51:03 -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); Sun, 31 Dec 2006 16:51:02 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 16:51:03 -0800 In-Reply-To: <7C964C00-D23D-4769-9D72-48F8131C0BAF@cisco.com> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> <7C964C00-D23D-4769-9D72-48F8131C0BAF@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25B8F939-C583-4958-BF97-DF1528AC51E6@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 16:51:05 -0800 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 00:51:03.0090 (UTC) FILETIME=[E96E7120:01C72D3E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1060; t=1167612663; x=1168476663; 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=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic =20Engineering |Sender:=20; bh=xfeSwJ3V4Ph7CVKVb7p3883uCpirc4VbStBWsbEVduk=; b=dSEGUbGyfyRbt5or5/5+hxS+vPFKyOVZg0/7S9+CynoHuWrKl/T2Wgi3uvlcpfReOyTCCD7b u5WliPZ0xNWRi67rpK5Cd9k1gd3DREow1Vq1RU3BoYdjxn+CkHPaJRnn; 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: 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 > Cost-shifting isn't the correct way to handle this issue. As you > say, something has to give; unattractive as it is, perhaps there's > some variation of the border model which can be constructed so as > to permit sufficient traffic engineering capabilities to satisfy > all parties. This isn't a matter of cost shifting, and I wasn't even close to implying that. I was simply delineating the entire known solution space. Again, the border model doesn't do anything that's fundamentally different from SHIM6, from an ISP perspective. It relieves some enterprise issues, but does nothing to enable longer-prefix traffic engineering, as we have it today. > [ Or we get started on IPv10, stat. ] Whether the architectural changes are in v6 or v10, we need to have consensus as to the architecture for the solution. Clicking our shoes together and saying "v10, v10, v10" does not give us a new conceptual framework to work with. We are still stuck with identifiers, locators and routes. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 19:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BR2-0003jn-FM; Sun, 31 Dec 2006 19:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BR1-0003jf-6f for ram@iab.org; Sun, 31 Dec 2006 19:53:51 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1BQz-0006Ys-TG for ram@iab.org; Sun, 31 Dec 2006 19:53:51 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2006 16:53:49 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="96833053:sNHT43057440" 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 l010rm9U002704; Sun, 31 Dec 2006 16:53:48 -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 l010rl4g006158; Sun, 31 Dec 2006 16:53:47 -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); Sun, 31 Dec 2006 16:53:47 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 16:53:47 -0800 In-Reply-To: <7d2996140081b03193d4f16ae9d69f02@it.uc3m.es> References: <816DD9299957E547B5D758D7F977D6DC011FCFB3@tayexc14.americas.cpqcorp.net> <7d2996140081b03193d4f16ae9d69f02@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: <10CF7D41-DAC0-47AB-BEF2-7EB648FF0C1C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (wasRe: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 16:53:50 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 00:53:47.0308 (UTC) FILETIME=[4B501EC0:01C72D3F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=602; t=1167612829; x=1168476829; 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=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(wasRe=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=d6wV8TnUt63kp/LT8yuN8Xuz9zGcsyRozjbQrRpEXMY=; b=W0RrcWsbttmTYXp7CzCuhXfkbPrLJ+/hEHsMSnvOHAKj4tT/5fuy+DgLQAtFroknF2EK+95S hthhdnogCyx9cRRBIvvURHAhYsuO1KVRl8aJCAiPzYh2ZorLSvChMQIs; 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: cf4fa59384e76e63313391b70cd0dd25 Cc: ram@iab.org, Noel Chiappa , "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 > 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? That's certainly possible. However, that means that the locator is necessarily host-specific, which I'm certainly not convinced is a requirement, or necessary. The locator could only specify a particular LAN or area, for example, and within that, individual identifiers could be used for the final bit of routing. In this scenario, you would want the destination identifier in each packet. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 19:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BWY-0005QT-1E; Sun, 31 Dec 2006 19:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1BWX-0005QN-H5 for ram@iab.org; Sun, 31 Dec 2006 19:59:33 -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 1H1BWV-0007CH-Gp for ram@iab.org; Sun, 31 Dec 2006 19:59:33 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 31 Dec 2006 16:59:30 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="354234294:sNHT43394900" 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 l010xUZh027217; Sun, 31 Dec 2006 16:59:30 -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 l010xU4g010546; Sun, 31 Dec 2006 16:59:30 -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); Sun, 31 Dec 2006 16:59:29 -0800 Received: from [192.168.0.101] ([10.21.152.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Dec 2006 16:59:29 -0800 In-Reply-To: References: <20061231133255.BFD1D872D4@mercury.lcs.mit.edu> <4850f4e3cc56ede84e46bb30ea711f64@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: <8F443235-B93F-4AFD-853F-1DAFAC4B7353@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 16:59:32 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Jan 2007 00:59:29.0516 (UTC) FILETIME=[1748EAC0:01C72D40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=481; t=1167613170; x=1168477170; 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=20filters=20and=20ACLs=20on=20identifiers?=20(was=20Re= 3A=20other=20requirement?=20(was=20Re=3A=20[RAM]=20Traffic=20Engineering |Sender:=20; bh=kgtbHWa9AtUbAs/25UIO8744JUobFVW4Q0D1Uyha8FI=; b=QjD63BZxa3bqc2+9ijuPn6hZZBpz3/sEtEWA0yD3HKdRNI69FH5slHpewuBvQJVg6TphRzPC yKLH2B16CNW26QlqzG1yptb4mc95oVVX3qlUUyCXZ8sBobCXpfNDuDWu; 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: de4f315c9369b71d7dd5909b42224370 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 >> A middle box implies state already. > > GSE doesn't and that it is the beauty of it, but it doesn't work as > 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, somewhere still needs to deal with destination locator selection. You can do it in the host, or in the border, and we know what folks think about doing it in the host. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Dec 31 20:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Bdg-0007If-98; Sun, 31 Dec 2006 20:06:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Bdd-0007Hm-Fw for ram@iab.org; Sun, 31 Dec 2006 20:06:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Bdc-0008RX-8B for ram@iab.org; Sun, 31 Dec 2006 20:06:53 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Dec 2006 17:06:52 -0800 X-IronPort-AV: i="4.12,222,1165219200"; d="scan'208"; a="49765891:sNHT49183892" 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 l0116qMC008206 for ; Sun, 31 Dec 2006 20:06:52 -0500 Received: from [192.168.1.101] (rtp-vpn2-215.cisco.com [10.82.240.215]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0116pG9013371 for ; Sun, 31 Dec 2006 20:06:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <25B8F939-C583-4958-BF97-DF1528AC51E6@cisco.com> References: <20061231140712.D8E5B872D4@mercury.lcs.mit.edu> <0C73396D-27EC-4ECA-B767-BF7B6ED587C5@tony.li> <7C964C00-D23D-4769-9D72-48F8131C0BAF@cisco.com> <25B8F939-C583-4958-BF97-DF1528AC51E6@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <338B975A-6F20-4856-87CF-61CEA0811F23@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering Date: Sun, 31 Dec 2006 17:06:33 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2530; t=1167613612; x=1168477612; 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=mxr7yFB07TgSNnxnkOBTVhnSf1JtOwkOJKBMXbik2Wc=; b=SCOdE94hdteis/NBPmb4qGKyoSzh5EJDAc5oKAfZEc1n14g5t/nKnz5qye4Hus/F9H0qmKIW acCv30mSlUo7bLbqQegjiRNx9xSc38QYVD9cyhPJglPgpOSKzXAKKH4a; 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dec 31, 2006, at 4:51 PM, Tony Li wrote: > This isn't a matter of cost shifting, and I wasn't even close to > implying that. I was simply delineating the entire known solution > space. I didn't mean to imply that you were implying it, heh; I'm merely pointing out that it's an unintended and previously-undiscussed consequence of the SHIM6 host-based solution. > > Again, the border model doesn't do anything that's fundamentally > different from SHIM6, from an ISP perspective. It relieves some > enterprise issues, but does nothing to enable longer-prefix traffic > engineering, as we have it today. As this model currently stands, yes. I've some hopes that perhaps there may be some ways around those limitations, but have nothing intelligent to say on the subject at this time. > Whether the architectural changes are in v6 or v10, we need to have > consensus as to the architecture for the solution. Clicking our > shoes together and saying "v10, v10, v10" does not give us a new > conceptual framework to work with. We are still stuck with > identifiers, locators and routes. The first step on the road to recovery is admitting we've a problem. The second step is ensuring we've a grasp of the real magnitude of the problem and all the relevant aspects of the problem. IMHO, we're coming out of the first step and are maybe 1/5th of the way through the second step. I don't know if we'll get any further than this. Assuming we never make it through step 2, as seems likely, we will most certainly still be stuck with identifiers, locators, and routes. If we somehow make it through step 2, we may still be stuck with locators, identifiers, and routes, but (hopefully) improved versions of same; or we may - mirabile dictu! - halt this headlong push to put new lipstick on the current iteration of IPv6 and grasp the nettle. This would entail coming up with something qualitatively better and which may well be predicated upon a paradigm which differs to one degree or another from the current one. So, what's it to be - step 1, steps 1-1.2, or steps 1-2? I'm currently the only person who seems to believe there's a need for steps 1-2, so I doubt my 'consensus of one' is going to get very far, 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 Sun Dec 31 22:45:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1E6r-0003tX-Ja; Sun, 31 Dec 2006 22:45:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1E6p-0003tI-TQ for ram@iab.org; Sun, 31 Dec 2006 22:45:11 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1E6o-0003Oz-O5 for ram@iab.org; Sun, 31 Dec 2006 22:45:11 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3AB4486AEA; Sun, 31 Dec 2006 22:45:10 -0500 (EST) To: ram@iab.org Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering Message-Id: <20070101034510.3AB4486AEA@mercury.lcs.mit.edu> Date: Sun, 31 Dec 2006 22:45:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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: Roland Dobbins > I mean 'mandating multiple identifiers of the type which go into ACLs, > firewall rules, QoS rules, etc. for filtering/matching packets' is out. Well, I don't have a problem with that. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram