From ram-bounces@iab.org Wed Dec 19 09:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50O0-0005lQ-VB; Wed, 19 Dec 2007 09:59:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50Nz-0005jd-70 for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500 Received: from eastrmmtao107.cox.net ([68.230.240.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50Ny-0007aD-Pz for ram@iab.org; Wed, 19 Dec 2007 09:59:03 -0500 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071219145901.FMUA8815.eastrmmtao107.cox.net@eastrmimpo01.cox.net> for ; Wed, 19 Dec 2007 09:59:01 -0500 Received: from [10.30.20.71] ([68.10.115.26]) by eastrmimpo01.cox.net with bizsmtp id SeyH1Y0080aEP1Q0000000; Wed, 19 Dec 2007 09:58:17 -0500 Message-Id: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> From: RJ Atkinson To: ram@iab.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 19 Dec 2007 09:59:01 -0500 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [RAM] Different approaches for different protocols X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org There seem to be one or two assumptions implicit in most of the notes I see archived here and elsewhere on the R&A topic. A) We only really need to worry about a solution that works for the currently deployed IPv4 network, since that is the only network segment that is in near-term danger of hitting IDR scaling limits. I think the above assumption would be incorrect, since IPv6 has the same architectural limitations as IPv4. Both use the same BGP-based methods for site-multihoming, which is the main driver of RIB/FIB entropy at present according to various papers in the published literature. B) We must use the same solution for both IPv4 and IPv6, since it is the same fundamental problem. I think that assumption is also incorrect, since IPv6 does have many more bits to work with than IPv4. Purely as an example, a solution that is part of the 8+8 family is quite straight-forward to implement/deploy with IPv6 because the IPv6 address already is conceptually split into two separate Routing Prefix and Interface ID components. However, for IPv4, an 8+8-like solution is more challenging. One might use the existing IPv4 "address" as a locator/routing prefix and then add separate Identifiers as an IPv4 option (workable in theory, but not in reality because routers would roll over and whimper like a puppy when trying to send every IPv4 packet via slow-path CPU forwarding). So I would suggest that folks think about IPv4 and IPv6 solution approaches separately. For example, while one might want one of the existing proposal for IPv4 (partly for expediency and partly because IPv4 has more constraints), one might well want a different more architecturally fundamental change for IPv6 (partly because the protocol is more flexible due to extra bits in the header and partly because we have more time to study, prototype, and design a more elegant solution). Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 10:59:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51Kc-0002p5-QN; Wed, 19 Dec 2007 10:59:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J51Kb-0002p0-Gq for ram@iab.org; Wed, 19 Dec 2007 10:59:37 -0500 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J51KV-0000Yb-Se for ram@iab.org; Wed, 19 Dec 2007 10:59:37 -0500 Received: from [IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb] ([IPv6:2001:720:410:1001:21b:63ff:fe92:9fbb]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id lBJFwBvv042276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2007 16:58:12 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <1636F5BF-3424-49F3-98D0-84677EA6D667@muada.com> From: Iljitsch van Beijnum To: RJ Atkinson In-Reply-To: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 16:58:12 +0100 References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> X-Mailer: Apple Mail (2.915) X-Spam-Status: No, score=-2.0 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19 dec 2007, at 15:59, RJ Atkinson wrote: > So I would suggest that folks think about IPv4 and IPv6 solution > approaches separately. For example, while one might want one of > the existing proposal for IPv4 (partly for expediency and partly > because IPv4 has more constraints), one might well want a different > more architecturally fundamental change for IPv6 (partly because > the protocol is more flexible due to extra bits in the header > and partly because we have more time to study, prototype, and > design a more elegant solution). I have no issue with that notion except to add that a solution could be appropriate for both versions of IP despite those differences. However, over on the internet area mailinglist Bob Hinden made the case that new work on IPv4 should stop and we should focus on IPv6 exclusively and only do the necessary maintenance for IPv4. Since apparently the routing situation isn't so dire and solutions aren't coming up so fast that we need to / can address the IPv4 situation before we run out of IPv4 addresses, this makes for a reasonable argument, in my opinion. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 12:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52iO-0000Dy-3B; Wed, 19 Dec 2007 12:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52iM-0000DQ-GP for ram@iab.org; Wed, 19 Dec 2007 12:28:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J52iM-0002Xq-78 for ram@iab.org; Wed, 19 Dec 2007 12:28:14 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Dec 2007 09:28:13 -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 lBJHSDVt017976; Wed, 19 Dec 2007 09:28:13 -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 lBJHS1LK011113; Wed, 19 Dec 2007 17:28:09 GMT 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); Wed, 19 Dec 2007 09:28:01 -0800 Received: from [171.70.245.32] ([171.70.245.32]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:28:01 -0800 In-Reply-To: <1636F5BF-3424-49F3-98D0-84677EA6D667@muada.com> References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <1636F5BF-3424-49F3-98D0-84677EA6D667@muada.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E7662ED-8C2B-4912-919A-C43F57DCB539@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 09:27:59 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 19 Dec 2007 17:28:01.0796 (UTC) FILETIME=[81909C40:01C84264] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=334; t=1198085293; x=1198949293; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=2wrsx52e7Xu0R7S+UGl3rhX6RPQ+r2RKuE+6F/36I5M=; b=NuBiTbhoGqzAd16SzV6yYHkHlRSGzfm0LHNBfuOoUBKi5PnM4U3VejvcRe wOllbdFFrlRF0GLzersqozTTRdFbV5Hv8C1XC6jpcRUGX7UG+ZxiuKNVEqFf uXQx8QVlHB; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Dec 19, 2007, at 7:58 AM, Iljitsch van Beijnum wrote: > However, over on the internet area mailinglist Bob Hinden made the > case that new work on IPv4 should stop and we should focus on IPv6 > exclusively and only do the necessary maintenance for IPv4. I don't think we got rough consensus on that point. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 12:40:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52tq-0001hw-FW; Wed, 19 Dec 2007 12:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52tp-0001g9-Cq for ram@iab.org; Wed, 19 Dec 2007 12:40:05 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J52to-0002k5-W5 for ram@iab.org; Wed, 19 Dec 2007 12:40:05 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lBJHdfps009668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Dec 2007 11:39:41 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lBJHdeYI002313; Wed, 19 Dec 2007 11:39:40 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lBJHdedL002303; Wed, 19 Dec 2007 11:39:40 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 09:39:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 09:39:40 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDD27@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <7E7662ED-8C2B-4912-919A-C43F57DCB539@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Different approaches for different protocols Thread-Index: AchCZatVVDpqfhkcQr2xrbfHl5hOdQAAE0XA References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com><1636F5BF-3424-49F3-98D0-84677EA6D667@muada.com> <7E7662ED-8C2B-4912-919A-C43F57DCB539@cisco.com> From: "Templin, Fred L" To: "Tony Li" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 19 Dec 2007 17:39:40.0249 (UTC) FILETIME=[21E01490:01C84266] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 =20 > -----Original Message----- > From: Tony Li [mailto:tli@cisco.com]=20 > Sent: Wednesday, December 19, 2007 9:28 AM > To: Iljitsch van Beijnum > Cc: RJ Atkinson; ram@iab.org > Subject: Re: [RAM] Different approaches for different protocols >=20 >=20 > On Dec 19, 2007, at 7:58 AM, Iljitsch van Beijnum wrote: >=20 > > However, over on the internet area mailinglist Bob Hinden made the =20 > > case that new work on IPv4 should stop and we should focus on IPv6 =20 > > exclusively and only do the necessary maintenance for IPv4. >=20 >=20 > I don't think we got rough consensus on that point. I second that; IMHO, an IPv6 coexistence with IPv4 is the most likely scenario moving forward. Fred fred.l.templin@boeing.com =20 > Tony >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 12:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J532c-0002zi-EQ; Wed, 19 Dec 2007 12:49:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J532b-0002zd-E5 for ram@iab.org; Wed, 19 Dec 2007 12:49:09 -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 1J532Z-0003TU-6C for ram@iab.org; Wed, 19 Dec 2007 12:49:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Dec 2007 09:48:56 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJHmuMF031311 for ; Wed, 19 Dec 2007 09:48:56 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBJHmlLa002208 for ; Wed, 19 Dec 2007 17:48:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:48:44 -0500 Received: from cisco.com ([10.82.240.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:48:44 -0500 Date: Wed, 19 Dec 2007 12:48:37 -0500 From: Scott Brim To: ram@iab.org Subject: Re: [RAM] Different approaches for different protocols Message-ID: <20071219174837.GA1342@cisco.com> References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 19 Dec 2007 17:48:44.0534 (UTC) FILETIME=[664B6160:01C84267] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: -4.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 Excerpts from RJ Atkinson on Wed, Dec 19, 2007 09:59:01AM -0500: > There seem to be one or two assumptions implicit in most of > the notes I see archived here and elsewhere on the R&A topic. > > A) We only really need to worry about a solution that > works for the currently deployed IPv4 network, since > that is the only network segment that is in near-term > danger of hitting IDR scaling limits. I've only seen that idea in miscellaneous speculation. I don't think anyone seriously believes we will be able to avoid deploying IPv6. > B) We must use the same solution for both IPv4 and IPv6, > since it is the same fundamental problem. > > I think that assumption is also incorrect, since IPv6 does > have many more bits to work with than IPv4. Purely as an > example, a solution that is part of the 8+8 family is quite > straight-forward to implement/deploy with IPv6 because the > IPv6 address already is conceptually split into two separate > Routing Prefix and Interface ID components. Yes, the "split up the address" set of proposed solutions assume IPv6. > So I would suggest that folks think about IPv4 and IPv6 solution > approaches separately. For example, while one might want one of the > existing proposal for IPv4 (partly for expediency and partly because > IPv4 has more constraints), one might well want a different more > architecturally fundamental change for IPv6 (partly because the > protocol is more flexible due to extra bits in the header and partly > because we have more time to study, prototype, and design a more > elegant solution). To start with we need to evaluate whether an 8+8-style approach is better than an map&encap approach *at all*, regardless of address family. If it is -- which is not clear by any means -- then that will be the time to consider multiple routing modes. However, in that case, if production IPv6 routing gets deployed, it might be just as reasonable to let IPv4 routing consolidate into a more PA-style mode and not bother doing anything new for it. swb _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 15:33:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55bO-00018d-Ck; Wed, 19 Dec 2007 15:33:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55bM-00014j-Pc for ram@iab.org; Wed, 19 Dec 2007 15:33:12 -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 1J55bM-0006lR-EU for ram@iab.org; Wed, 19 Dec 2007 15:33:12 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Dec 2007 12:33:11 -0800 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 lBJKXBBu017750; Wed, 19 Dec 2007 12:33:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBJKWg4B013809; Wed, 19 Dec 2007 20:33:07 GMT 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); Wed, 19 Dec 2007 12:32:49 -0800 Received: from normz.cisco.com ([10.21.80.90]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:32:49 -0800 Message-Id: <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> From: Dino Farinacci To: RJ Atkinson In-Reply-To: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 12:32:52 -0800 References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 19 Dec 2007 20:32:49.0070 (UTC) FILETIME=[52185CE0:01C8427E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=899; t=1198096391; x=1198960391; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=trNAuZcVNuGD3it1P51uu9T261TgP8/YHtv+XmIplSQ=; b=n2UXnbY65o9giXpHUhIxYwTMkw43wMBlxVu1DKcoQ3Ltuy14RSm+SZFb5K 6va1d+HgM9OBs4vkWcO0+SI9NYrIu1x6/wWQ0PppDy0+G+SGxG6LoSz6VE7c 7nrJXDKFWd; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.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 Ran, first off, really good post. > So I would suggest that folks think about IPv4 and IPv6 solution > approaches separately. For example, while one might want one of > the existing proposal for IPv4 (partly for expediency and partly > because IPv4 has more constraints), one might well want a different > more architecturally fundamental change for IPv6 (partly because > the protocol is more flexible due to extra bits in the header > and partly because we have more time to study, prototype, and > design a more elegant solution). So let me propose something: 1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft. 2) For IPv6, use header address translation (of the high-order 8-bytes), spec that out as GSE++. 3) Have both use the same mapping database infrastructure. Comments? If we added 2) to the LISP draft would people be happy with that? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 15:46:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55nl-0000rU-F1; Wed, 19 Dec 2007 15:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J55nk-0000pG-6N for ram@iab.org; Wed, 19 Dec 2007 15:46:00 -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 1J55nj-00071n-P2 for ram@iab.org; Wed, 19 Dec 2007 15:46:00 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Dec 2007 12:45:59 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBJKjxpT012642; Wed, 19 Dec 2007 12:45:59 -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 lBJKjrLG001934; Wed, 19 Dec 2007 20:45:58 GMT 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, 19 Dec 2007 12:45:53 -0800 Received: from normz.cisco.com ([10.21.80.90]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:45:53 -0800 Message-Id: <5DD2D898-A66D-4471-96B3-663E71350302@cisco.com> From: Dino Farinacci To: Scott Brim In-Reply-To: <20071219174837.GA1342@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 12:45:57 -0800 References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <20071219174837.GA1342@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 19 Dec 2007 20:45:53.0603 (UTC) FILETIME=[25B69930:01C84280] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2190; t=1198097159; x=1198961159; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=wkWQ5FyTtsb8UkXbPugX5WnSUO3sZv4WkB7//0Bg7Qc=; b=iDxbKDGKfOehHs027cxSdL0TYVDAxMHWmVpCYwLnrvau7wgjO0diD+VWZk aWkjrnCls1RkDoGUDfpmRitZA1OzTCljEDEnJfNOoNooOYOYILUpOmTt4FLM tjmDoucyAO; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.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: , Errors-To: ram-bounces@iab.org > To start with we need to evaluate whether an 8+8-style approach is > better than an map&encap approach *at all*, regardless of address > family. If it is -- which is not clear by any means -- then that will > be the time to consider multiple routing modes. Scott, the comments I have heard in favor of using map&encap is that you maintain the original addresses which the host put in the header. You then can build ACLs in various middle-boxes that are based on those (inner) addresses that don't change. So for IPv4, I see value there. But for IPv6, those middle boxes can setup ACLs based on the lower- order 8-bytes, which, as well as above, will not change. So doing address swaps on the high-order 8-bytes doesn't lose information like it does in IPv4. I think a GSE++ approach could work very well. The only worry I have, with respect to how it is spec'ed out now is that an entire 128-bits is in the DNS. You don't really want to have locators in the DNS. You really want to decouple it. So I would propose this: 1) Put A records in DNS for IPv6 hosts as ::, where is 8- bytes. 2) Have socket connections use the following addresses for tcb lookups: source = :: dest = :: 3) CE routers that participate in the mapping database, will do this: Make :: into :: Make :: into :: where: is the CE's IPv6 address out of the address block from the provider it is attached to is the locator returned from a mapping database lookup for 4) When the packet enters the destination site, the ETR will translate because the locator is it's own address, so it changes the source and destination locator bits to 0. 5) No host changes because the checksums are always based on non-zero bits in the EID field and 0 bits in the locator field. We can do this with LISP-ALT as the mapping database mechanism. Should we prototype this? Comments? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 17:09:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J576H-0000ZJ-Sc; Wed, 19 Dec 2007 17:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J576G-0000ZE-Dv for ram@iab.org; Wed, 19 Dec 2007 17:09:12 -0500 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J576E-0001E1-Hm for ram@iab.org; Wed, 19 Dec 2007 17:09:12 -0500 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071219220910.LGVI24467.eastrmmtao103.cox.net@eastrmimpo02.cox.net> for ; Wed, 19 Dec 2007 17:09:10 -0500 Received: from [10.30.20.71] ([68.10.115.26]) by eastrmimpo02.cox.net with bizsmtp id Sm8k1Y0050aEP1Q0000000; Wed, 19 Dec 2007 17:08:44 -0500 Message-Id: <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> From: RJ Atkinson To: ram@iab.org In-Reply-To: <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 17:09:09 -0500 References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 19 Dec 2007, at 15:32, Dino Farinacci wrote: >> So I would suggest that folks think about IPv4 and IPv6 solution >> approaches separately. For example, while one might want one of >> the existing proposal for IPv4 (partly for expediency and partly >> because IPv4 has more constraints), one might well want a different >> more architecturally fundamental change for IPv6 (partly because >> the protocol is more flexible due to extra bits in the header >> and partly because we have more time to study, prototype, and >> design a more elegant solution). > > So let me propose something: > > 1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft. > 2) For IPv6, use header address translation (of the high-order 8- > bytes), > spec that out as GSE++. > 3) Have both use the same mapping database infrastructure. > > Comments? > > If we added 2) to the LISP draft would people be happy with that? Hmm. Suggestions: (A) I'd encourage keeping your concepts (1) and (2) separate, in separate drafts and ideally with separate names, at least for now. (B) Separately, modularity and clean architecture would argue for keeping the mapping database structure separately specified from any other bits of protocol design. Rationale: For my first suggestion (A), I'll note that approach (1) above might be used for both IPv4 and IPv6 (at least in theory), while approach (2) above isn't obviously applicable to IPv4. For my second suggestion (B), one might use the currently proposed LISP encapsulation, but with some alternative (not yet designed or proposed) mapping database schema [or vice versa]. So keeping things separate and modular seems beneficial all around for now. My two cents. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 17:48:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J57iB-0006M0-7G; Wed, 19 Dec 2007 17:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J57iA-0006Lv-Dx for ram@iab.org; Wed, 19 Dec 2007 17:48:22 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J57iA-0001yM-1q for ram@iab.org; Wed, 19 Dec 2007 17:48:22 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Dec 2007 14:48:21 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBJMmKqJ005250; Wed, 19 Dec 2007 14:48:21 -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 lBJMm711013220; Wed, 19 Dec 2007 22:48:20 GMT 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); Wed, 19 Dec 2007 14:48:07 -0800 Received: from [171.70.245.185] ([171.70.245.185]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 14:48:07 -0800 In-Reply-To: <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 14:48:06 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 19 Dec 2007 22:48:07.0134 (UTC) FILETIME=[38D69FE0:01C84291] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=138; t=1198104501; x=1198968501; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=33Np7xFzDZ1qpgwuUmdS2/8FnGBquMwuqQOFXSlUDV0=; b=iUtvx0eEmOzESkgkKuJkp9sqpGCmn4QTE3KViQMdn/zTxmbib8CbDPOKUd D040NOdD18gV6ujtQjaRWSFcgpmWRvg8grj8kD9Sx74M7cFs09NONa92BKgp bf6jvqjFm7; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Might I again ask that we move this conversation back to the RRG mailing list? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 17:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J57t8-00048f-A3; Wed, 19 Dec 2007 17:59:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J57t7-00048Z-Ak for ram@iab.org; Wed, 19 Dec 2007 17:59:41 -0500 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J57t5-0002AX-RE for ram@iab.org; Wed, 19 Dec 2007 17:59:41 -0500 Received: from [131.179.33.196] (Cs-33-196.CS.UCLA.EDU [131.179.33.196]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id lBJMwpAo019250; Wed, 19 Dec 2007 14:59:32 -0800 (PST) In-Reply-To: References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A9E30FA-2F4E-4CD1-8117-4472B4400019@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 14:59:31 -0800 To: Tony Li X-Mailer: Apple Mail (2.753) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Dec 19, 2007, at 2:48 PM, Tony Li wrote: > > > > Might I again ask that we move this conversation back to the RRG > mailing list? > > > > Tony +1 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Dec 19 20:35:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5AKA-0003mX-6T; Wed, 19 Dec 2007 20:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5AK9-0003mS-8S for ram@iab.org; Wed, 19 Dec 2007 20:35:45 -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 1J5AK7-0004tL-2J for ram@iab.org; Wed, 19 Dec 2007 20:35:45 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Dec 2007 17:35:32 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBK1ZWkg012433; Wed, 19 Dec 2007 17:35:32 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lBK1ZFl7019875; Thu, 20 Dec 2007 01:35:28 GMT 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); Wed, 19 Dec 2007 17:35:18 -0800 Received: from dhcp-171-71-55-230.cisco.com ([171.71.55.230]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:35:17 -0800 Message-Id: From: Dino Farinacci To: RJ Atkinson In-Reply-To: <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [RAM] Different approaches for different protocols Date: Wed, 19 Dec 2007 17:35:16 -0800 References: <8FE686E6-D352-4324-88CC-2C9EC26A5871@extremenetworks.com> <564A8854-E859-4CAE-B299-9343FF6A7E16@cisco.com> <74502AEC-7B9C-456F-AE77-0A81A204A01E@extremenetworks.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 20 Dec 2007 01:35:17.0887 (UTC) FILETIME=[93A210F0:01C842A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1864; t=1198114532; x=1198978532; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Different=20approaches=20for=20 different=20protocols |Sender:=20; bh=9UEhUa5bN5szz0YiXJHu6hkIdahgXNj9MCT5wB6csNQ=; b=H09InAg3Tv8LyclA+mZQFaaY6W2ttRzWjy46jiIlhuTm/zls6Qlkryn79P iE3yFSoTnknPxqBgK/S82gx/3eS+7PpeNFi2Sbnsiba/BnFDP88LhMX2jAmY wToF2g7WLbzNEuFncA1pK5lViMa6nyhypRP3fce4uYe+BD8MS8eqQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.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 > On 19 Dec 2007, at 15:32, Dino Farinacci wrote: >>> So I would suggest that folks think about IPv4 and IPv6 solution >>> approaches separately. For example, while one might want one of >>> the existing proposal for IPv4 (partly for expediency and partly >>> because IPv4 has more constraints), one might well want a different >>> more architecturally fundamental change for IPv6 (partly because >>> the protocol is more flexible due to extra bits in the header >>> and partly because we have more time to study, prototype, and >>> design a more elegant solution). >> >> So let me propose something: >> >> 1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft. >> 2) For IPv6, use header address translation (of the high-order 8- >> bytes), >> spec that out as GSE++. >> 3) Have both use the same mapping database infrastructure. >> >> Comments? >> >> If we added 2) to the LISP draft would people be happy with that? > > > > Hmm. > > Suggestions: > > (A) I'd encourage keeping your concepts (1) and (2) separate, > in separate drafts and ideally with separate names, at least for now. > > (B) Separately, modularity and clean architecture would argue for > keeping the mapping database structure separately specified > from any other bits of protocol design. > > Rationale: > > For my first suggestion (A), I'll note that approach (1) above > might be used for both IPv4 and IPv6 (at least in theory), > while approach (2) above isn't obviously applicable to IPv4. > > For my second suggestion (B), one might use the currently proposed > LISP encapsulation, but with some alternative (not yet designed > or proposed) mapping database schema [or vice versa]. So keeping > things separate and modular seems beneficial all around for now. > > My two cents. > > Ran All good points, thanks. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Dec 20 22:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YQR-0002M0-Is; Thu, 20 Dec 2007 22:19:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YQP-0002Ll-8m for ram@iab.org; Thu, 20 Dec 2007 22:19:49 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5YQN-0002yb-4d for ram@iab.org; Thu, 20 Dec 2007 22:19:49 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 85FAC872ED; Thu, 20 Dec 2007 22:19:46 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] Different approaches for different protocols Message-Id: <20071221031946.85FAC872ED@mercury.lcs.mit.edu> Date: Thu, 20 Dec 2007 22:19:46 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: -4.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: RJ Atkinson > (A) I'd encourage keeping your concepts (1) and (2) separate, in > separate drafts and ideally with separate names, at least for now. > (B) Separately, modularity and clean architecture would argue for > keeping the mapping database structure separately specified from any > other bits of protocol design. > ... > keeping things separate and modular seems beneficial all around for > now. Not just for now - it's even more valuable in the long run. Modularity is your friend when it comes to archiectural lifetime. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram