From tli@cisco.com Sun May 8 10:18:28 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97596E06A1 for ; Sun, 8 May 2011 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.439 X-Spam-Level: X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLann4ppwcoD for ; Sun, 8 May 2011 10:18:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE2BEE0682 for ; Sun, 8 May 2011 10:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tli@cisco.com; l=818; q=dns/txt; s=iport; t=1304875107; x=1306084707; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=iZQhjoci006US69YtMRJn489QGotA2Q7vvKQmtCg9z4=; b=fBkWXRzjAAUj1mBxNaCG+12jlVBpz1m7QCMjL/hVFT/4keKriOoCcRui eAWtEozMGQcBuyi50M92B1dzUimnFYpsypOK5m2iQowZtohjgSKX0a9Mj IoOIVa/Sm8zO4iIB8XROTMW09/JZjG7kf1f2gGaVS5gE5DmAtK8QpzBtF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIHAKnPxk2rRDoJ/2dsb2JhbACYJo1yd6YkgR2dAIMMgwAEhkCJJYQoilU X-IronPort-AV: E=Sophos;i="4.64,335,1301875200"; d="scan'208";a="311018285" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 08 May 2011 17:18:27 +0000 Received: from [10.21.87.50] ([10.21.87.50]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p48HIQjr004258 for ; Sun, 8 May 2011 17:18:27 GMT From: Tony Li Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 May 2011 10:18:26 -0700 Message-Id: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> To: rrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 17:18:28 -0000 Hi all, It's time to start the conversation about where the RRG is headed. = Towards that end, I'd like to open the floor for the discussion of = topics. Any _research_ topic within the broad area of routing and = addressing is appropriate. =20 I propose the following process: we hold this discussion this month, = trying to identify relevant topics. Each topic should have a succinct = statement of its goals. At the end of the month, we poll to determine = the interest level in the various topics. Those that seem to have = critical mass are recommended to the IRTF Chair for consideration. The default answer, if no topic has critical mass, is for the RG to go = on hiatus. Any questions or comments on the process? Any proposals of research topics? The floor is open... Tony From jnc@mercury.lcs.mit.edu Mon May 9 11:57:13 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DC2E0713 for ; Mon, 9 May 2011 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQS2HQXdipQi for ; Mon, 9 May 2011 11:57:13 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0B827E070E for ; Mon, 9 May 2011 11:57:12 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1056D18C0EC; Mon, 9 May 2011 14:57:11 -0400 (EDT) To: rrg@irtf.org Message-Id: <20110509185711.1056D18C0EC@mercury.lcs.mit.edu> Date: Mon, 9 May 2011 14:57:11 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 18:57:13 -0000 > From: Tony Li > I'd like to open the floor for the discussion of topics. Any > _research_ topic within the broad area of routing and addressing is > appropriate. > ... > Any proposals of research topics? > The floor is open... Noting the silence, I do have one topic to suggest. In prior conversations with you, you have suggested that the broad architectural approach I prefer for path selection - i.e. topology distribution, with unified path computation (although perhaps 'monolithic' is a better term than 'unified', since the latter term was used elsewhere in routing) - is problematic. I don't recall your reasoning exactly (not that I ever got it in detail, I don't think), IIRC it was something to do with a combination of: i) ISPs didn't want to hand out topology information ii) ISPs like the kind of policies about traffic flow they can impose with destination vector architectures iii) the overhead of path computation needs to be distributed So perhaps a discussion about what you see as the shortcomings of that approach, and discussion about whether those issues are or are not handlable, would be a good thing to do here? Noel From decoy@iki.fi Mon May 9 18:20:50 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65870E09A0 for ; Mon, 9 May 2011 18:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItTzaEKFpXPw for ; Mon, 9 May 2011 18:20:48 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [217.30.184.167]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA6E099D for ; Mon, 9 May 2011 18:20:40 -0700 (PDT) Received: from lakka.kapsi.fi ([2001:1bc8:1004::1] ident=Debian-exim) by mail.kapsi.fi with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJbcm-0007Nw-3a; Tue, 10 May 2011 04:20:32 +0300 Received: from decoy (helo=localhost) by lakka.kapsi.fi with local-esmtp (Exim 4.69) (envelope-from ) id 1QJbcm-0002Lq-1a; Tue, 10 May 2011 04:20:32 +0300 Date: Tue, 10 May 2011 04:20:31 +0300 (EEST) From: Sampo Syreeni Sender: decoy@kapsi.fi To: Noel Chiappa In-Reply-To: <20110509185711.1056D18C0EC@mercury.lcs.mit.edu> Message-ID: References: <20110509185711.1056D18C0EC@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 2001:1bc8:1004::1 X-SA-Exim-Mail-From: decoy@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:20:50 -0000 On 2011-05-09, Noel Chiappa wrote: > In prior conversations with you, you have suggested that the broad > architectural approach I prefer for path selection - i.e. topology > distribution, with unified path computation [...] I'm sensing NIMROD, here. It'd be nice to see it rehashed why precisely OSPF-like full topology distribution and/or a purely source routing framework could or couldn't be done within a wider, multilevel context. Also the relative pros and cons of going that way, or not. A couple of decades or so more experience certainly couldn't hurt. I also wonder whether there is some unifying factor under the Interplanetary Internet work, the recent, more practical routing work on-list wrt IRON/LISP/whatnot, and the long (thin or thick) network stuff. All three pictures rely heavily on information stored at the edge of the network, which will or should influence routing decisions. Evidently the data should stay at the edge, if at all possible, but all that caching, prediction and compression seems somehow unifiable to me. Is there some overa(r)ching principle lying around here, perhaps having to do with (nondeterministic?) source routing, unconventional prediction by the source, and (soft state?) edge to core (? to edge? one-way?) signaling? With the grand aim of countering otherwise-expected latency and other routing-relevant problems, in an e2e-compatible way? As a much more well-defined problem, a recent I-D-in-queue points out many problems in how IPv6's flow label is defined and constrained. One of the main solutions to the hassle that it proposes is to hide any manipulations of the semantics to within some fixed realm and/or AS and/or something, so that the manipulations aren't visible from the outside. Much of the LISP/IRON/MPLS/whatnot work tries to achieve the precise same thing -- transparent routing from the viewpoint of the edge device, while the core is doing something else entirely. So do we even now have a good description of what the edge device should see, once and for all? If not, nailing that down to pure logic would seem like a worthwhile exercise, and a rather well-defined one at that. As such it would be an academically motivated one, but in practice it might help in unexpected ways wrt the protocols we actually use, right now, including but not limited to IP and ICMP in their two main versions. Van Jacobson et al's content centric networking, of course. Especially if we could somehow make it lighter-weight than it is now. (The inherent copying aspect is just as relevant or irrelevant as it was with TCP, I think, from the purely technical viewpoint. I'm also pretty sure there are efficient ways to compress those long URI-style addresses downto something routable in even current silicon. If not e2e, then at least MPLS-style hop-to-hop FEC-like. I'm thinking about some derivation of 0-complete trees or something to that effect. But that's still research stuff, not real, clear-cut engineering, the precise way HIP used to be.) An evaluation of any and all ways to aggregate and/or cheaply refine existing congestion pricing work done by the IETF at the core routing level would be neat as well. I.e. how might the ConEx work interface with the core routing fabric. Again, there might be a multitude of fundamental interface questions lurking around here, well-suited for IRTF and not so much for IETF. Even a facts-based unification of fundamental internet protocol compressions is very much lacking. It probably could be done at least to a degree, and it would be very useful especially with IPv6, with its fat headers and the current deeply nested protocol stack. But nobody's ever tried to tackle the problem in full, at a fundamental level, at least to my knowledge. These are all newbie ideas, but perhaps one or two of them could also break the silence Noel mentioned. -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From tli@cisco.com Mon May 9 18:33:49 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B970DE09B7 for ; Mon, 9 May 2011 18:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.414 X-Spam-Level: X-Spam-Status: No, score=-9.414 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHJDRM+vsegw for ; Mon, 9 May 2011 18:33:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1966FE09B4 for ; Mon, 9 May 2011 18:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tli@cisco.com; l=1894; q=dns/txt; s=iport; t=1304991229; x=1306200829; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fAbFukZEi7I5RVAdgtdOes+Y3MDGENObaurcGCMtvCI=; b=JD4WIYFNAJ1yvtQ/eCiThf+DVlvO6KaXopsvHNJ/hsxyK6ZPiPPaXQrR Of2iHGraGT1W76qoyV2WDvIE/5TVVED8jUIC6ScsBBPb4+Q3jlw/J95xG 4zwLLUbk3J1ED5kt2odD8gjtV7cQatoT/GDNS+40zOLVHvCkOrR3ddI7S s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuVyE2rRDoJ/2dsb2JhbACmAneIcZ46njKGDASGQIkkhCiKAlQ X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208";a="311978192" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 01:33:48 +0000 Received: from [10.155.35.171] ([10.155.35.171]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4A1Xm4H029446; Tue, 10 May 2011 01:33:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <20110509185711.1056D18C0EC@mercury.lcs.mit.edu> Date: Mon, 9 May 2011 18:33:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85606E2C-5271-46F5-9C2D-2C199BF66B26@cisco.com> References: <20110509185711.1056D18C0EC@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1084) Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:33:49 -0000 Hi Noel, > In prior conversations with you, you have suggested that the broad > architectural approach I prefer for path selection - i.e. topology > distribution, with unified path computation (although perhaps = 'monolithic' > is a better term than 'unified', since the latter term was used = elsewhere > in routing) - is problematic. I don't recall your reasoning exactly = (not > that I ever got it in detail, I don't think), IIRC it was something to = do > with a combination of: >=20 > i) ISPs didn't want to hand out topology information And perhaps more importantly, they are unwilling to disclose their = policy information. Peering policies are a very touchy subject. Being = nice to competitor A and not nice to competitor B is the type of = diplomatic fodder that starts corporate battles. > ii) ISPs like the kind of policies about traffic flow they can impose > with destination vector architectures Specifically, the ability to do hot-potato and cold-potato routing, as = well as destination originated traffic engineering. > iii) the overhead of path computation needs to be distributed This is the least of the issues. Yes, this needs to be distributed for = scalability. But then I come from a church where _everything_ needs to = be distributed for scalability. > So perhaps a discussion about what you see as the shortcomings of that > approach, and discussion about whether those issues are or are not > handlable, would be a good thing to do here? So I'm more than happy to have that conversation, but I would very much = like it to proceed into a concrete topic proposal if we're doing it on = RRG. If we're having just a fun architectural discussion, then = routing-discussion might be more appropriate, so that this list could be = reserved for those developing topics. Warmest regards, Tony From marcelo@it.uc3m.es Tue May 10 02:34:31 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D56E06DC for ; Tue, 10 May 2011 02:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFOCTWd0QB1V for ; Tue, 10 May 2011 02:34:22 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id DAC9DE071B for ; Tue, 10 May 2011 02:34:21 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B8EEA75A3D9 for ; Tue, 10 May 2011 11:10:26 +0200 (CEST) Message-ID: <4DC90101.50403@it.uc3m.es> Date: Tue, 10 May 2011 11:10:25 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rrg@irtf.org References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> In-Reply-To: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18126.006 Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 09:34:31 -0000 Hi, What about doing some work in multi-path routing in the inter-domain? i.e. enabling a router to use multiple paths with potential different characteristics to forward packets across domains. Would people find this topic interesting? regards, marcelo El 08/05/11 19:18, Tony Li escribió: > Hi all, > > It's time to start the conversation about where the RRG is headed. Towards that end, I'd like to open the floor for the discussion of topics. Any _research_ topic within the broad area of routing and addressing is appropriate. > > I propose the following process: we hold this discussion this month, trying to identify relevant topics. Each topic should have a succinct statement of its goals. At the end of the month, we poll to determine the interest level in the various topics. Those that seem to have critical mass are recommended to the IRTF Chair for consideration. > > The default answer, if no topic has critical mass, is for the RG to go on hiatus. > > Any questions or comments on the process? > > Any proposals of research topics? > > The floor is open... > > Tony > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From HeinerHummel@aol.com Tue May 10 03:01:38 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C4FE089A for ; Tue, 10 May 2011 03:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhNUblbginuL for ; Tue, 10 May 2011 03:01:37 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8CE087F for ; Tue, 10 May 2011 03:01:37 -0700 (PDT) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4AA1PYu004823; Tue, 10 May 2011 06:01:25 -0400 Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v42.9.) id 9.1075.53f6eb0 (56011); Tue, 10 May 2011 06:01:21 -0400 (EDT) Received: from smtprly-dd02.mx.aol.com (smtprly-dd02.mx.aol.com [205.188.84.130]) by cia-md07.mx.aol.com (v129.10) with ESMTP id MAILCIAMD075-d3f24dc90ced26; Tue, 10 May 2011 06:01:21 -0400 Received: from webmail-m046 (webmail-m046.sim.aol.com [64.12.101.229]) by smtprly-dd02.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYDD026-d3f24dc90ced26; Tue, 10 May 2011 06:01:17 -0400 References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> To: marcelo@it.uc3m.es, rrg@irtf.org Date: Tue, 10 May 2011 06:01:17 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: <4DC90101.50403@it.uc3m.es> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDDD1056DACE2E_1160_181A_webmail-m046.sysops.aol.com" X-Mailer: AOL Webmail 33668-STANDARD Received: from 95.91.105.21 by webmail-m046.sysops.aol.com (64.12.101.229) with HTTP (WebMailUI); Tue, 10 May 2011 06:01:17 -0400 Message-Id: <8CDDD1056BE3DA2-1160-DD4@webmail-m046.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 10:01:38 -0000 ----------MB_8CDDD1056DACE2E_1160_181A_webmail-m046.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Obviously no one, because this was a main goal of ignored TARA: multipath= forwarding based on a network graph which is composed of=20 inter- AND intra-network links and which not only comprises ECMPs but al= so detouring paths via equidistant or even more remote routers. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: marcelo bagnulo braun An: rrg@irtf.org Verschickt: Di., 10. Mai. 2011, 11:10 Thema: Re: [rrg] Next topic? Hi,=20 =20 What about doing some work in multi-path routing in the inter-domain?=20 i.e. enabling a router to use multiple paths with potential different char= acteristics to forward packets across domains.=20 Would people find this topic interesting?=20 =20 regards, marcelo=20 =20 =20 El 08/05/11 19:18, Tony Li escribi=C3=B3:=20 > Hi all,=20 >=20 > It's time to start the conversation about where the RRG is headed. Towa= rds that end, I'd like to open the floor for the discussion of topics. An= y _research_ topic within the broad area of routing and addressing is appr= opriate.=20 >=20 > I propose the following process: we hold this discussion this month, try= ing to identify relevant topics. Each topic should have a succinct statem= ent of its goals. At the end of the month, we poll to determine the inter= est level in the various topics. Those that seem to have critical mass ar= e recommended to the IRTF Chair for consideration.=20 >=20 > The default answer, if no topic has critical mass, is for the RG to go= on hiatus.=20 >=20 > Any questions or comments on the process?=20 >=20 > Any proposals of research topics?=20 >=20 > The floor is open...=20 >=20 > Tony=20 >=20 > _______________________________________________=20 > rrg mailing list=20 > rrg@irtf.org=20 > http://www.irtf.org/mailman/listinfo/rrg=20 >=20 =20 _______________________________________________=20 rrg mailing list=20 rrg@irtf.org=20 http://www.irtf.org/mailman/listinfo/rrg=20 =20 ----------MB_8CDDD1056DACE2E_1160_181A_webmail-m046.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Obviously no one, because= this was a main goal of ignored TARA: multipath forwarding based on a net= work graph which is composed of 
inter- AND intra-network links and which  not only comprises &nb= sp;ECMPs but also  detouring paths  via equidistant or even more= remote routers.

Heiner



----= -Urspr=C3=BCngliche Mitteilung-----
Von: marcelo bagnulo braun <marcelo@it.uc3m.es>
An: rrg@irtf.org
Verschickt: Di., 10. Mai. 2011, 11:10
Thema: Re: [rrg] Next topic?

Hi, 
 
What about doing some work in multi-path routing in the inter-domain? = ;
i.e. enabling a router to use multiple paths with potential different=20 characteristics to forward packets across domains. 
Would people find this topic interesting? 
 
regards, marcelo 
 
 
El 08/05/11 19:18, Tony Li escribi=C3=B3: 
> Hi all, 
> 
> It's time to start the conversation about where the RRG is headed. = Towards that end, I'd like to open the floor for the discussion of topics= . Any _research_ topic within the broad area of routing and addressing is= appropriate. 
> 
> I propose the following process: we hold this discussion this month,= trying to identify relevant topics. Each topic should have a succinct st= atement of its goals. At the end of the month, we poll to determine the= interest level in the various topics. Those that seem to have critical= mass are recommended to the IRTF Chair for consideration. 
> 
> The default answer, if no topic has critical mass, is for the RG to= go on hiatus. 
> 
> Any questions or comments on the process? 
> 
> Any proposals of research topics? 
> 
> The floor is open... 
> 
> Tony 
> 
> _______________________________________________ 
> rrg mailing list 
> rrg@irtf.o= rg 
> http://www.irtf.org/mailman/listinfo/rrg&= nbsp;
> 
 
_______________________________________________ 
rrg mailing list 
rrg@irtf.org 
http://www.irtf.org/mailman/listinfo/rrg =
----------MB_8CDDD1056DACE2E_1160_181A_webmail-m046.sysops.aol.com-- From hannu.flinck@nsn.com Tue May 10 05:19:37 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37F0E0759 for ; Tue, 10 May 2011 05:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fQt3o+pfyi9 for ; Tue, 10 May 2011 05:19:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id EF268E0708 for ; Tue, 10 May 2011 05:19:34 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4AC3VNF029979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2011 14:03:33 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4AC3UGv010311; Tue, 10 May 2011 14:03:30 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 14:03:30 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 May 2011 15:03:28 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC7358502D9D4B3@FIESEXC035.nsn-intra.net> In-Reply-To: <4DC90101.50403@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Next topic? thread-index: AcwO9Y1T7Iozd7pFQ+6Bjcm+4jEPvQAFH67w References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "ext marcelo bagnulo braun" , X-OriginalArrivalTime: 10 May 2011 12:03:30.0262 (UTC) FILETIME=[4706CF60:01CC0F0A] Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 12:19:37 -0000 Hello Marcelo, In fact I happen to be working on the topic you are suggesting. I am = interested and willing to contribute. Should we have an initial state of = the art description? - Hannu=20 -----Original Message----- From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of = ext marcelo bagnulo braun Sent: Tuesday, May 10, 2011 12:10 PM To: rrg@irtf.org Subject: Re: [rrg] Next topic? Hi, What about doing some work in multi-path routing in the inter-domain? i.e. enabling a router to use multiple paths with potential different=20 characteristics to forward packets across domains. Would people find this topic interesting? regards, marcelo El 08/05/11 19:18, Tony Li escribi=F3: > Hi all, > > It's time to start the conversation about where the RRG is headed. = Towards that end, I'd like to open the floor for the discussion of = topics. Any _research_ topic within the broad area of routing and = addressing is appropriate. > > I propose the following process: we hold this discussion this month, = trying to identify relevant topics. Each topic should have a succinct = statement of its goals. At the end of the month, we poll to determine = the interest level in the various topics. Those that seem to have = critical mass are recommended to the IRTF Chair for consideration. > > The default answer, if no topic has critical mass, is for the RG to go = on hiatus. > > Any questions or comments on the process? > > Any proposals of research topics? > > The floor is open... > > Tony > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg From c.pluntke@ucl.ac.uk Tue May 10 06:02:19 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EA4E06AF for ; Tue, 10 May 2011 06:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj-vYMwzUBUA for ; Tue, 10 May 2011 06:02:18 -0700 (PDT) Received: from vscani-d2.ucl.ac.uk (vscani-d2.ucl.ac.uk [144.82.108.133]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC5E0662 for ; Tue, 10 May 2011 06:02:16 -0700 (PDT) Received: from nat-ee.ucl.ac.uk ([128.40.255.50] helo=[172.16.0.138]) by vscani-d.ucl.ac.uk with esmtps (SSLv3:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QJmZn-0006be-Fn; Tue, 10 May 2011 14:02:11 +0100 From: Christopher Pluntke To: "Flinck, Hannu (NSN - FI/Espoo)" In-Reply-To: <26E5D1C5D5365D47B147E5E62FC7358502D9D4B3@FIESEXC035.nsn-intra.net> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> <26E5D1C5D5365D47B147E5E62FC7358502D9D4B3@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 May 2011 14:02:10 +0100 Message-ID: <1305032530.2182.8.camel@nano> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable X-UCL-MailScanner-Information: Please contact the UCL Helpdesk, helpdesk@ucl.ac.uk for more information X-UCL-MailScanner: Found to be clean X-UCL-MailScanner-From: c.pluntke@ucl.ac.uk Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 13:02:19 -0000 Hi, I think there are many interesting problems to be explored in the context of inter-domain multipath routing. Having mainly done work on intra-domain multipath routing so far, I would be very interested in looking at this as well. Christopher On Tue, 2011-05-10 at 15:03 +0300, Flinck, Hannu (NSN - FI/Espoo) wrote: > Hello Marcelo, >=20 > In fact I happen to be working on the topic you are suggesting. I am inte= rested and willing to contribute. Should we have an initial state of the ar= t description? >=20 > - Hannu=20 >=20 > -----Original Message----- > From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of ext= marcelo bagnulo braun > Sent: Tuesday, May 10, 2011 12:10 PM > To: rrg@irtf.org > Subject: Re: [rrg] Next topic? >=20 > Hi, >=20 > What about doing some work in multi-path routing in the inter-domain? > i.e. enabling a router to use multiple paths with potential different=20 > characteristics to forward packets across domains. > Would people find this topic interesting? >=20 > regards, marcelo >=20 >=20 >=20 > El 08/05/11 19:18, Tony Li escribi=C3=B3: > > Hi all, > > > > It's time to start the conversation about where the RRG is headed. Tow= ards that end, I'd like to open the floor for the discussion of topics. An= y _research_ topic within the broad area of routing and addressing is appro= priate. > > > > I propose the following process: we hold this discussion this month, tr= ying to identify relevant topics. Each topic should have a succinct statem= ent of its goals. At the end of the month, we poll to determine the intere= st level in the various topics. Those that seem to have critical mass are = recommended to the IRTF Chair for consideration. > > > > The default answer, if no topic has critical mass, is for the RG to go = on hiatus. > > > > Any questions or comments on the process? > > > > Any proposals of research topics? > > > > The floor is open... > > > > Tony > > > > _______________________________________________ > > rrg mailing list > > rrg@irtf.org > > http://www.irtf.org/mailman/listinfo/rrg > > >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From hannu.flinck@nsn.com Tue May 10 07:38:45 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC4E0738 for ; Tue, 10 May 2011 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0Frx8bzqDMp for ; Tue, 10 May 2011 07:38:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A5E47E0659 for ; Tue, 10 May 2011 07:38:42 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4AC55KB028253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2011 14:05:05 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4AC5545000572; Tue, 10 May 2011 14:05:05 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 14:05:04 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC0F0A.7F483CEF" Date: Tue, 10 May 2011 15:05:03 +0300 Message-ID: <26E5D1C5D5365D47B147E5E62FC7358502D9D4B9@FIESEXC035.nsn-intra.net> In-Reply-To: <8CDDD1056BE3DA2-1160-DD4@webmail-m046.sysops.aol.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Next topic? thread-index: AcwO+Vcx096rqHn+RxONAeZrhjY0wgAEPWNg References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com><4DC90101.50403@it.uc3m.es> <8CDDD1056BE3DA2-1160-DD4@webmail-m046.sysops.aol.com> From: "Flinck, Hannu (NSN - FI/Espoo)" To: , , X-OriginalArrivalTime: 10 May 2011 12:05:04.0758 (UTC) FILETIME=[7F59C160:01CC0F0A] Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:38:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0F0A.7F483CEF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFzZWQgb24gbXkgcmVhZGluZyBvZiBUQVJBIGl0IHdhcyBhbGwgYWJvdXQgZ2VvZ3JhcGhpY2Fs IGFkZHJlc3NpbmcuDQoNCiANCg0KLSAgICAgICAgICBIYW5udSANCg0KIA0KDQpGcm9tOiBycmct Ym91bmNlc0BpcnRmLm9yZyBbbWFpbHRvOnJyZy1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYg T2YgZXh0IGhlaW5lcmh1bW1lbEBhb2wuY29tDQpTZW50OiBUdWVzZGF5LCBNYXkgMTAsIDIwMTEg MTowMSBQTQ0KVG86IG1hcmNlbG9AaXQudWMzbS5lczsgcnJnQGlydGYub3JnDQpTdWJqZWN0OiBS ZTogW3JyZ10gTmV4dCB0b3BpYz8NCg0KIA0KDQpPYnZpb3VzbHkgbm8gb25lLCBiZWNhdXNlIHRo aXMgd2FzIGEgbWFpbiBnb2FsIG9mIGlnbm9yZWQgVEFSQTogbXVsdGlwYXRoIGZvcndhcmRpbmcg YmFzZWQgb24gYSBuZXR3b3JrIGdyYXBoIHdoaWNoIGlzIGNvbXBvc2VkIG9mICANCg0KaW50ZXIt IEFORCBpbnRyYS1uZXR3b3JrIGxpbmtzIGFuZCB3aGljaCAgbm90IG9ubHkgY29tcHJpc2VzICBF Q01QcyBidXQgYWxzbyAgZGV0b3VyaW5nIHBhdGhzICB2aWEgZXF1aWRpc3RhbnQgb3IgZXZlbiBt b3JlIHJlbW90ZSByb3V0ZXJzLg0KDQogDQoNCkhlaW5lcg0KDQogDQoNCi0tLS0tVXJzcHLDvG5n bGljaGUgTWl0dGVpbHVuZy0tLS0tIA0KVm9uOiBtYXJjZWxvIGJhZ251bG8gYnJhdW4gPG1hcmNl bG9AaXQudWMzbS5lcz4NCkFuOiBycmdAaXJ0Zi5vcmcNClZlcnNjaGlja3Q6IERpLiwgMTAuIE1h aS4gMjAxMSwgMTE6MTANClRoZW1hOiBSZTogW3JyZ10gTmV4dCB0b3BpYz8NCg0KSGksIA0KIA0K V2hhdCBhYm91dCBkb2luZyBzb21lIHdvcmsgaW4gbXVsdGktcGF0aCByb3V0aW5nIGluIHRoZSBp bnRlci1kb21haW4/IA0KaS5lLiBlbmFibGluZyBhIHJvdXRlciB0byB1c2UgbXVsdGlwbGUgcGF0 aHMgd2l0aCBwb3RlbnRpYWwgZGlmZmVyZW50IGNoYXJhY3RlcmlzdGljcyB0byBmb3J3YXJkIHBh Y2tldHMgYWNyb3NzIGRvbWFpbnMuIA0KV291bGQgcGVvcGxlIGZpbmQgdGhpcyB0b3BpYyBpbnRl cmVzdGluZz8gDQogDQpyZWdhcmRzLCBtYXJjZWxvIA0KIA0KIA0KRWwgMDgvMDUvMTEgMTk6MTgs IFRvbnkgTGkgZXNjcmliacOzOiANCj4gSGkgYWxsLCANCj4gDQo+IEl0J3MgdGltZSB0byBzdGFy dCB0aGUgY29udmVyc2F0aW9uIGFib3V0IHdoZXJlIHRoZSBSUkcgaXMgaGVhZGVkLiBUb3dhcmRz IHRoYXQgZW5kLCBJJ2QgbGlrZSB0byBvcGVuIHRoZSBmbG9vciBmb3IgdGhlIGRpc2N1c3Npb24g b2YgdG9waWNzLiBBbnkgX3Jlc2VhcmNoXyB0b3BpYyB3aXRoaW4gdGhlIGJyb2FkIGFyZWEgb2Yg cm91dGluZyBhbmQgYWRkcmVzc2luZyBpcyBhcHByb3ByaWF0ZS4gDQo+IA0KPiBJIHByb3Bvc2Ug dGhlIGZvbGxvd2luZyBwcm9jZXNzOiB3ZSBob2xkIHRoaXMgZGlzY3Vzc2lvbiB0aGlzIG1vbnRo LCB0cnlpbmcgdG8gaWRlbnRpZnkgcmVsZXZhbnQgdG9waWNzLiBFYWNoIHRvcGljIHNob3VsZCBo YXZlIGEgc3VjY2luY3Qgc3RhdGVtZW50IG9mIGl0cyBnb2Fscy4gQXQgdGhlIGVuZCBvZiB0aGUg bW9udGgsIHdlIHBvbGwgdG8gZGV0ZXJtaW5lIHRoZSBpbnRlcmVzdCBsZXZlbCBpbiB0aGUgdmFy aW91cyB0b3BpY3MuIFRob3NlIHRoYXQgc2VlbSB0byBoYXZlIGNyaXRpY2FsIG1hc3MgYXJlIHJl Y29tbWVuZGVkIHRvIHRoZSBJUlRGIENoYWlyIGZvciBjb25zaWRlcmF0aW9uLiANCj4gDQo+IFRo ZSBkZWZhdWx0IGFuc3dlciwgaWYgbm8gdG9waWMgaGFzIGNyaXRpY2FsIG1hc3MsIGlzIGZvciB0 aGUgUkcgdG8gZ28gb24gaGlhdHVzLiANCj4gDQo+IEFueSBxdWVzdGlvbnMgb3IgY29tbWVudHMg b24gdGhlIHByb2Nlc3M/IA0KPiANCj4gQW55IHByb3Bvc2FscyBvZiByZXNlYXJjaCB0b3BpY3M/ IA0KPiANCj4gVGhlIGZsb29yIGlzIG9wZW4uLi4gDQo+IA0KPiBUb255IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQo+IHJyZyBtYWlsaW5n IGxpc3QgDQo+IHJyZ0BpcnRmLm9yZyANCj4gaHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JyZyANCj4gDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyANCnJyZyBtYWlsaW5nIGxpc3QgDQpycmdAaXJ0Zi5vcmcgDQpodHRwOi8vd3d3 LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vcnJnIA0KDQo= ------_=_NextPart_001_01CC0F0A.7F483CEF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5NzY5NTQ5OTY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05OTQ2NDA1NzggMTQzMDkzNjkyOCA2 NzgyOTc2MyA2NzgyOTc2NSA2NzgyOTc2MSA2NzgyOTc2MyA2NzgyOTc2NSA2NzgyOTc2MSA2Nzgy OTc2MyA2NzgyOTc2NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6QXJpYWw7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUZJIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5CYXNlZCBvbiBteSByZWFkaW5nIG9mIFRBUkEgaXQgd2FzIGFs bCBhYm91dCBnZW9ncmFwaGljYWwgYWRkcmVzc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28t bGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9TFRSPjwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGFubnUgPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IHJyZy1ib3VuY2VzQGlydGYub3JnIFttYWlsdG86cnJnLWJvdW5jZXNAaXJ0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+ZXh0IGhlaW5lcmh1bW1lbEBhb2wuY29tPGJyPjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTAsIDIwMTEgMTowMSBQTTxicj48Yj5Ubzo8L2I+IG1hcmNl bG9AaXQudWMzbS5lczsgcnJnQGlydGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3JyZ10g TmV4dCB0b3BpYz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFj ayc+T2J2aW91c2x5IG5vIG9uZSwgYmVjYXVzZSB0aGlzIHdhcyBhIG1haW4gZ29hbCBvZiBpZ25v cmVkIFRBUkE6IG11bHRpcGF0aCBmb3J3YXJkaW5nIGJhc2VkIG9uIGEgbmV0d29yayBncmFwaCB3 aGljaCBpcyBjb21wb3NlZCBvZiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPmludGVyLSBBTkQgaW50cmEtbmV0d29y ayBsaW5rcyBhbmQgd2hpY2ggJm5ic3A7bm90IG9ubHkgY29tcHJpc2VzICZuYnNwO0VDTVBzIGJ1 dCBhbHNvICZuYnNwO2RldG91cmluZyBwYXRocyAmbmJzcDt2aWEgZXF1aWRpc3RhbnQgb3IgZXZl biBtb3JlIHJlbW90ZSByb3V0ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkhlaW5lcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPi0tLS0t VXJzcHLDvG5nbGljaGUgTWl0dGVpbHVuZy0tLS0tIDxicj5Wb246IG1hcmNlbG8gYmFnbnVsbyBi cmF1biAmbHQ7bWFyY2Vsb0BpdC51YzNtLmVzJmd0Ozxicj5BbjogcnJnQGlydGYub3JnPGJyPlZl cnNjaGlja3Q6IERpLiwgMTAuIE1haS4gMjAxMSwgMTE6MTA8YnI+VGhlbWE6IFJlOiBbcnJnXSBO ZXh0IHRvcGljPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IGlkPSJBT0xNc2dQYXJ0XzBfZWZm MDhhMzMtNTFlMy00M2YwLWI3MmMtMmM0OTJlNDVhNDFhIj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5IaSwmbmJzcDs8YnI+Jm5i c3A7PGJyPldoYXQgYWJvdXQgZG9pbmcgc29tZSB3b3JrIGluIG11bHRpLXBhdGggcm91dGluZyBp biB0aGUgaW50ZXItZG9tYWluPyZuYnNwOzxicj5pLmUuIGVuYWJsaW5nIGEgcm91dGVyIHRvIHVz ZSBtdWx0aXBsZSBwYXRocyB3aXRoIHBvdGVudGlhbCBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0aWNz IHRvIGZvcndhcmQgcGFja2V0cyBhY3Jvc3MgZG9tYWlucy4mbmJzcDs8YnI+V291bGQgcGVvcGxl IGZpbmQgdGhpcyB0b3BpYyBpbnRlcmVzdGluZz8mbmJzcDs8YnI+Jm5ic3A7PGJyPnJlZ2FyZHMs IG1hcmNlbG8mbmJzcDs8YnI+Jm5ic3A7PGJyPiZuYnNwOzxicj5FbCAwOC8wNS8xMSAxOToxOCwg VG9ueSBMaSBlc2NyaWJpw7M6Jm5ic3A7PGJyPiZndDsgSGkgYWxsLCZuYnNwOzxicj4mZ3Q7Jm5i c3A7PGJyPiZndDsgSXQncyB0aW1lIHRvIHN0YXJ0IHRoZSBjb252ZXJzYXRpb24gYWJvdXQgd2hl cmUgdGhlIFJSRyBpcyBoZWFkZWQuIFRvd2FyZHMgdGhhdCBlbmQsIEknZCBsaWtlIHRvIG9wZW4g dGhlIGZsb29yIGZvciB0aGUgZGlzY3Vzc2lvbiBvZiB0b3BpY3MuIEFueSBfcmVzZWFyY2hfIHRv cGljIHdpdGhpbiB0aGUgYnJvYWQgYXJlYSBvZiByb3V0aW5nIGFuZCBhZGRyZXNzaW5nIGlzIGFw cHJvcHJpYXRlLiZuYnNwOzxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsgSSBwcm9wb3NlIHRoZSBmb2xs b3dpbmcgcHJvY2Vzczogd2UgaG9sZCB0aGlzIGRpc2N1c3Npb24gdGhpcyBtb250aCwgdHJ5aW5n IHRvIGlkZW50aWZ5IHJlbGV2YW50IHRvcGljcy4gRWFjaCB0b3BpYyBzaG91bGQgaGF2ZSBhIHN1 Y2NpbmN0IHN0YXRlbWVudCBvZiBpdHMgZ29hbHMuIEF0IHRoZSBlbmQgb2YgdGhlIG1vbnRoLCB3 ZSBwb2xsIHRvIGRldGVybWluZSB0aGUgaW50ZXJlc3QgbGV2ZWwgaW4gdGhlIHZhcmlvdXMgdG9w aWNzLiBUaG9zZSB0aGF0IHNlZW0gdG8gaGF2ZSBjcml0aWNhbCBtYXNzIGFyZSByZWNvbW1lbmRl ZCB0byB0aGUgSVJURiBDaGFpciBmb3IgY29uc2lkZXJhdGlvbi4mbmJzcDs8YnI+Jmd0OyZuYnNw Ozxicj4mZ3Q7IFRoZSBkZWZhdWx0IGFuc3dlciwgaWYgbm8gdG9waWMgaGFzIGNyaXRpY2FsIG1h c3MsIGlzIGZvciB0aGUgUkcgdG8gZ28gb24gaGlhdHVzLiZuYnNwOzxicj4mZ3Q7Jm5ic3A7PGJy PiZndDsgQW55IHF1ZXN0aW9ucyBvciBjb21tZW50cyBvbiB0aGUgcHJvY2Vzcz8mbmJzcDs8YnI+ Jmd0OyZuYnNwOzxicj4mZ3Q7IEFueSBwcm9wb3NhbHMgb2YgcmVzZWFyY2ggdG9waWNzPyZuYnNw Ozxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsgVGhlIGZsb29yIGlzIG9wZW4uLi4mbmJzcDs8YnI+Jmd0 OyZuYnNwOzxicj4mZ3Q7IFRvbnkmbmJzcDs8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fJm5ic3A7PGJyPiZndDsgcnJn IG1haWxpbmcgbGlzdCZuYnNwOzxicj4mZ3Q7IHJyZ0BpcnRmLm9yZyZuYnNwOzxicj4mZ3Q7IGh0 dHA6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ycmcmbmJzcDs8YnI+Jmd0OyZuYnNw Ozxicj4mbmJzcDs8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18mbmJzcDs8YnI+cnJnIG1haWxpbmcgbGlzdCZuYnNwOzxicj5ycmdAaXJ0Zi5vcmcmbmJz cDs8YnI+aHR0cDovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JyZyZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CC0F0A.7F483CEF-- From decoy@iki.fi Tue May 10 15:36:13 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1315E0919 for ; Tue, 10 May 2011 15:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeiyLkqJpbi2 for ; Tue, 10 May 2011 15:36:12 -0700 (PDT) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) by ietfa.amsl.com (Postfix) with ESMTP id 0554EE0918 for ; Tue, 10 May 2011 15:36:11 -0700 (PDT) Received: from lakka.kapsi.fi ([2001:1bc8:1004::1] ident=Debian-exim) by mail.kapsi.fi with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QJvXD-0001Dk-QS; Wed, 11 May 2011 01:36:07 +0300 Received: from decoy (helo=localhost) by lakka.kapsi.fi with local-esmtp (Exim 4.69) (envelope-from ) id 1QJvXD-0000Xh-Oc; Wed, 11 May 2011 01:36:07 +0300 Date: Wed, 11 May 2011 01:36:07 +0300 (EEST) From: Sampo Syreeni Sender: decoy@kapsi.fi To: marcelo bagnulo braun In-Reply-To: <4DC90101.50403@it.uc3m.es> Message-ID: References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 2001:1bc8:1004::1 X-SA-Exim-Mail-From: decoy@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 22:36:13 -0000 On 2011-05-10, marcelo bagnulo braun wrote: > What about doing some work in multi-path routing in the inter-domain? > i.e. enabling a router to use multiple paths with potential different > characteristics to forward packets across domains. Would people find > this topic interesting? I'd guess they would, since the idea is so old and also underexploited. But does it bring in real extra value? I.e. does anybody know whether multipath routing could significantly increase the total utilization of the routing fabric, either now or under some theoretically founded future situation? If nobody knows, a preliminary study could be IRTF material. -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From HeinerHummel@aol.com Tue May 10 22:15:34 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32FE0675 for ; Tue, 10 May 2011 22:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbmSS4mkrGus for ; Tue, 10 May 2011 22:15:33 -0700 (PDT) Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEDAE0671 for ; Tue, 10 May 2011 22:15:33 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4B5FUGu023981; Wed, 11 May 2011 01:15:30 -0400 Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v42.9.) id 9.d2b.77167cd9 (55835); Wed, 11 May 2011 01:15:25 -0400 (EDT) Received: from smtprly-dc01.mx.aol.com (smtprly-dc01.mx.aol.com [205.188.170.1]) by cia-md06.mx.aol.com (v129.10) with ESMTP id MAILCIAMD063-d1c64dca1b6917a; Wed, 11 May 2011 01:15:25 -0400 Received: from web-mmc-d08 (web-mmc-d08.sim.aol.com [205.188.103.98]) by smtprly-dc01.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYDC017-d1c64dca1b6917a; Wed, 11 May 2011 01:15:21 -0400 References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com><4DC90101.50403@it.uc3m.es> <8CDDD1056BE3DA2-1160-DD4@webmail-m046.sysops.aol.com> <26E5D1C5D5365D47B147E5E62FC7358502D9D4B9@FIESEXC035.nsn-intra.net> To: hannu.flinck@nsn.com, rrg@irtf.org Date: Wed, 11 May 2011 01:15:21 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: <26E5D1C5D5365D47B147E5E62FC7358502D9D4B9@FIESEXC035.nsn-intra.net> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDDDB18FA094E1_18DC_28F74_web-mmc-d08.sysops.aol.com" X-Mailer: Webmail 33668-STANDARD Received: from 95.91.105.21 by web-mmc-d08.sysops.aol.com (205.188.103.98) with HTTP (WebMailUI); Wed, 11 May 2011 01:15:21 -0400 Message-Id: <8CDDDB18F9970B8-18DC-14A0C@web-mmc-d08.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 05:15:34 -0000 ----------MB_8CDDDB18FA094E1_18DC_28F74_web-mmc-d08.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hannu,=20 please admit that Columbus routing is part of multipath forwarding and I= will admit that I deliberately obstained from submitting a 01-version of= the TARA-draft that contained in detail how to do Columbus routing based= on TARA. I don't know the secret why DV is such sacrosanct but I know for sure that= enhancements for routing via more and more remote nodes would blow up DV. Offlist I received comments about what to do with so many alternative path= s, when provided. Indeed, they need to be utilized for the overall benefit (traffic balancing, congestion avoidance, congestion handling). This howev= er would need a rearview mirror i.e. knowledge about upstream paths from= where the traffic comes from. Again: not possible based on DV. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Flinck, Hannu (NSN - FI/Espoo) An: heinerhummel@aol.com; marcelo@it.uc3m.es; rrg@irtf.org Verschickt: Di., 10. Mai. 2011, 14:05 Thema: RE: [rrg] Next topic? Based on my reading of TARA it was all about geographical addressing. =20 - Hannu=20 =20 From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of ext= heinerhummel@aol.com Sent: Tuesday, May 10, 2011 1:01 PM To: marcelo@it.uc3m.es; rrg@irtf.org Subject: Re: [rrg] Next topic? =20 Obviously no one, because this was a main goal of ignored TARA: multipath= forwarding based on a network graph which is composed of =20 inter- AND intra-network links and which not only comprises ECMPs but al= so detouring paths via equidistant or even more remote routers. =20 Heiner =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: marcelo bagnulo braun An: rrg@irtf.org Verschickt: Di., 10. Mai. 2011, 11:10 Thema: Re: [rrg] Next topic? Hi,=20 =20 What about doing some work in multi-path routing in the inter-domain?=20 i.e. enabling a router to use multiple paths with potential different char= acteristics to forward packets across domains.=20 Would people find this topic interesting?=20 =20 regards, marcelo=20 =20 =20 El 08/05/11 19:18, Tony Li escribi=C3=B3:=20 > Hi all,=20 >=20 > It's time to start the conversation about where the RRG is headed. Towar= ds that end, I'd like to open the floor for the discussion of topics. Any= _research_ topic within the broad area of routing and addressing is appro= priate.=20 >=20 > I propose the following process: we hold this discussion this month, try= ing to identify relevant topics. Each topic should have a succinct stateme= nt of its goals. At the end of the month, we poll to determine the interes= t level in the various topics. Those that seem to have critical mass are= recommended to the IRTF Chair for consideration.=20 >=20 > The default answer, if no topic has critical mass, is for the RG to go= on hiatus.=20 >=20 > Any questions or comments on the process?=20 >=20 > Any proposals of research topics?=20 >=20 > The floor is open...=20 >=20 > Tony=20 >=20 > _______________________________________________=20 > rrg mailing list=20 > rrg@irtf.org=20 > http://www.irtf.org/mailman/listinfo/rrg ; >=20 =20 _______________________________________________=20 rrg mailing list=20 rrg@irtf.org=20 http://www.irtf.org/mailman/listinfo/rrg ; =20 ----------MB_8CDDDB18FA094E1_18DC_28F74_web-mmc-d08.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hannu, 
please admit that Columbus routing is part of multipath forwarding an= d I will admit that I deliberately obstained from submitting a 01-version= of the TARA-draft that contained in detail how to do Columbus routing bas= ed on TARA.

I don't know the secret why DV is such sacrosanct but I know for sure= that enhancements for routing via more and more remote nodes would blow= up DV.

Offlist I received comments about what to do with so many alternative= paths, when provided. Indeed, they need to be utilized for the overall be= nefit
(traffic balancing, congestion avoidance, congestion handling). This= however would need a rearview mirror i.e. knowledge about upstream paths= from where the traffic comes from. Again: not possible based on DV.

Heiner




----= -Urspr=C3=BCngliche Mitteilung-----
Von: Flinck, Hannu (NSN - FI/Espoo) <hannu.flinck@nsn.com>
An: heinerhummel@aol.com; marcelo@it.uc3m.es; rrg@irtf.org
Verschickt: Di., 10. Mai. 2011, 14:05
Thema: RE: [rrg] Next topic?

Based= on my reading of TARA it was all about geographical addressing.
 =
-&nb= sp;         <= span dir=3D"LTR">Hannu=
 =
From: rrg-bou= nces@irtf.org [mailto:rrg-bou= nces@irtf.org] On Behalf Of ext heinerhummel@aol.com
Sent: Tuesday, May 10, 2011 1:01 PM
To: marcelo@it.uc3m.es;= rrg@irtf.org
Subject: Re: [rrg] Next topic?
 
Obviously no one, because= this was a main goal of ignored TARA: multipath forwarding based on a net= work graph which is composed of 
inter- AND intra-network= links and which  not only comprises  ECMPs but also  detou= ring paths  via equidistant or even more remote routers.
 
Heiner
 
-----Urspr=C3=BCngliche Mitteilung-----
Von: marcelo bagnulo braun <marce= lo@it.uc3m.es>
An: rrg@irtf.org
Verschickt: Di., 10. Mai. 2011, 11:10
Thema: Re: [rrg] Next topic?
rrg@irtf.org 
> http://www.irtf.org/mailman/listinfo/rrg ;
> 
 
_______________________________________________ 
rrg mailing list 
rrg@irtf.org 
http://www.irtf.org/mailman/listinfo/rrg ;
 ----------MB_8CDDDB18FA094E1_18DC_28F74_web-mmc-d08.sysops.aol.com-- From jcamacho@it.uc3m.es Wed May 11 15:49:34 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C636E08A5 for ; Wed, 11 May 2011 15:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ5eF4q787EF for ; Wed, 11 May 2011 15:49:33 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id BB464E0870 for ; Wed, 11 May 2011 15:49:32 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.35] (93.Red-88-19-80.staticIP.rima-tde.net [88.19.80.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 059749C51E5; Thu, 12 May 2011 00:49:28 +0200 (CEST) Message-Id: <947F3D89-1ED8-4F83-917B-8317DA15831B@it.uc3m.es> From: Jose Manuel Camacho Camacho To: Sampo Syreeni In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 May 2011 00:49:28 +0200 References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> X-Mailer: Apple Mail (2.936) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18130.002 Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 22:49:34 -0000 I guess there are some potential advantages in deploying multipath =20 inter-domain routing. For instance, currently each border router =20 forwards the traffic for a prefix through the same next AS. Balancing =20= through two different next ASes it is not possible without re-=20 advertising and sending the control plane to reconverge. Using =20 multipath the balancing could be done even in a fine granularity (e.g. =20= per packet) so that, - Different treatment (e.g. regarding QoS) could be provided per = =20 packet/flow, relaying traffic to a better provider (likely to have a =20 higher pricing) and charging more money to the customers. - The latter may enable pricing and services competition. - Egress traffic engineering could be decoupled from the routing = =20 advertisement, forwarding to an upstream provider or another should be =20= transparent to downstream customer ASes if they all the paths are =20 advertised beforehand. - Congestion control may be more flexible for ISPs. Thinking of future architectures, the case of multipath-aware =20 transport protocols would let some or full control of the path =20 selection to final hosts. It is not likely that ISPs go for this, but =20= theoretically failure detection, failure recovery and better =20 congestion control should be possible in this scenario, since end-=20 hosts can measure end-to-end performance easily. Jose M. Camacho, jcamacho@it.uc3m.es, www.uc3m.es +34916248795 El 11/05/2011, a las 0:36, Sampo Syreeni escribi=F3: > On 2011-05-10, marcelo bagnulo braun wrote: > >> What about doing some work in multi-path routing in the inter-=20 >> domain? i.e. enabling a router to use multiple paths with potential =20= >> different characteristics to forward packets across domains. Would =20= >> people find this topic interesting? > > I'd guess they would, since the idea is so old and also =20 > underexploited. But does it bring in real extra value? I.e. does =20 > anybody know whether multipath routing could significantly increase =20= > the total utilization of the routing fabric, either now or under =20 > some theoretically founded future situation? > > If nobody knows, a preliminary study could be IRTF material. > --=20 > Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front > +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Wed May 11 16:06:19 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF39E08D9 for ; Wed, 11 May 2011 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEswP9yH-aqL for ; Wed, 11 May 2011 16:06:19 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id 22A13E0696 for ; Wed, 11 May 2011 16:06:19 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta07.emeryville.ca.mail.comcast.net with comcast id iP5p1g0021zF43QA7P6JBp; Wed, 11 May 2011 23:06:18 +0000 Received: from [10.155.35.171] ([128.107.239.234]) by omta24.emeryville.ca.mail.comcast.net with comcast id iP641g02T547xYo8kP67Cu; Wed, 11 May 2011 23:06:14 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4DC90101.50403@it.uc3m.es> Date: Wed, 11 May 2011 16:06:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1084) Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 23:06:19 -0000 On May 10, 2011, at 2:10 AM, marcelo bagnulo braun wrote: > What about doing some work in multi-path routing in the inter-domain? > i.e. enabling a router to use multiple paths with potential different = characteristics to forward packets across domains. > Would people find this topic interesting? It looks like there are a number of people who are at least somewhat = interested in this topic. To move this topic forward, it would be very good to have a very clear = statement of what this would (and would not) involve as research goals, = and the specific researchers who are interested in contributing to this = effort. Obviously, much of this topic might involve direct protocol = modifications or mechanism proposals. These would be inappropriate as = research goals, as these would be overlapping with the work that the = IETF is chartered to perform. Answering architectural questions would = be appropriate, IMHO. Folks writing topic proposals might do so with an eye on the current RRG = charter. Any eventual topics will necessarily become part of our = rechartering effort. Tony From marcelo@it.uc3m.es Wed May 11 22:26:46 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354A0E06A6 for ; Wed, 11 May 2011 22:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2eF8ffiJj54 for ; Wed, 11 May 2011 22:26:45 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 40B1AE0689 for ; Wed, 11 May 2011 22:26:44 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (216.219-78-194.adsl-static.isp.belgacom.be [194.78.219.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 85E79704064; Thu, 12 May 2011 07:26:37 +0200 (CEST) Message-ID: <4DCB6F88.1080807@it.uc3m.es> Date: Thu, 12 May 2011 07:26:32 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tony Li References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> <69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li> In-Reply-To: <69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18130.003 Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 05:26:46 -0000 Ok, let me try to coordinate with others to produce some first draft of this probably during next week, is that ok? El 12/05/11 1:06, Tony Li escribió: > On May 10, 2011, at 2:10 AM, marcelo bagnulo braun wrote: > >> What about doing some work in multi-path routing in the inter-domain? >> i.e. enabling a router to use multiple paths with potential different characteristics to forward packets across domains. >> Would people find this topic interesting? > > It looks like there are a number of people who are at least somewhat interested in this topic. > > To move this topic forward, it would be very good to have a very clear statement of what this would (and would not) involve as research goals, and the specific researchers who are interested in contributing to this effort. Obviously, much of this topic might involve direct protocol modifications or mechanism proposals. These would be inappropriate as research goals, as these would be overlapping with the work that the IETF is chartered to perform. Answering architectural questions would be appropriate, IMHO. > > Folks writing topic proposals might do so with an eye on the current RRG charter. Any eventual topics will necessarily become part of our rechartering effort. > > Tony > > From tony.li@tony.li Wed May 11 23:53:00 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5837AE06FB for ; Wed, 11 May 2011 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUlHRSnfNmfJ for ; Wed, 11 May 2011 23:52:59 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 96286E0675 for ; Wed, 11 May 2011 23:52:59 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta04.emeryville.ca.mail.comcast.net with comcast id iWgo1g0021smiN4A4WszL5; Thu, 12 May 2011 06:52:59 +0000 Received: from [192.168.2.100] ([98.248.36.188]) by omta20.emeryville.ca.mail.comcast.net with comcast id iWsw1g00Y43ZcXW8gWsyDE; Thu, 12 May 2011 06:52:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tony Li In-Reply-To: <4DCB6F88.1080807@it.uc3m.es> Date: Wed, 11 May 2011 23:52:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81A1DDDC-8CFA-4613-BFE2-F93FD28C900A@tony.li> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> <69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li> <4DCB6F88.1080807@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1084) Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 06:53:00 -0000 That should be fine, thanks. Again, I'd like to move forward with all = proposals by the end of the month. Tony On May 11, 2011, at 10:26 PM, marcelo bagnulo braun wrote: > Ok, let me try to coordinate with others to produce some first draft = of this probably during next week, is that ok? >=20 >=20 >=20 > El 12/05/11 1:06, Tony Li escribi=F3: >> On May 10, 2011, at 2:10 AM, marcelo bagnulo braun wrote: >>=20 >>> What about doing some work in multi-path routing in the = inter-domain? >>> i.e. enabling a router to use multiple paths with potential = different characteristics to forward packets across domains. >>> Would people find this topic interesting? >>=20 >> It looks like there are a number of people who are at least somewhat = interested in this topic. >>=20 >> To move this topic forward, it would be very good to have a very = clear statement of what this would (and would not) involve as research = goals, and the specific researchers who are interested in contributing = to this effort. Obviously, much of this topic might involve direct = protocol modifications or mechanism proposals. These would be = inappropriate as research goals, as these would be overlapping with the = work that the IETF is chartered to perform. Answering architectural = questions would be appropriate, IMHO. >>=20 >> Folks writing topic proposals might do so with an eye on the current = RRG charter. Any eventual topics will necessarily become part of our = rechartering effort. >>=20 >> Tony >>=20 >>=20 >=20 From xuxh@huawei.com Thu May 12 18:20:02 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18BE07AC for ; Thu, 12 May 2011 18:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnIZohY42pXs for ; Thu, 12 May 2011 18:20:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1CCE0759 for ; Thu, 12 May 2011 18:20:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL4002EV11ATC@szxga03-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL400FL511A8X@szxga03-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL400DYK119HU@szxml04-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST) Date: Fri, 13 May 2011 09:29:14 +0800 From: Xu Xiaohu In-reply-to: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> To: 'Tony Li' , rrg@irtf.org Message-id: <001e01cc110d$2bb85710$83290530$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcwNpAXMeI4W9GDOTd6n2cjxY0HXVADYy61A References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 01:20:02 -0000 Hi Tony and all, In the past few years, RRG has done a lot of excellent research work to explore various ideas and approaches (e.g., map&encap, id/locator split = and translation...) to addressing the Internet routing scalability issue. = Today it seems that the cloud Data Center Network (DCN) and Data Center Interconnection (DCI) scenarios are facing a similar scalability = challenge (i.e., MAC forwarding table scalability issue). The demand for VM = mobility within the whole large L2 data center network or even across = geographically dispersed data centers is one major driving force of extending the L2 = domain scope larger and larger. Although the reason for the MAC forwarding table scalability issue in = the DCN/DCI scenarios is not the same as that for the Internet routing scalability issue, the ideas and approaches suitable for scaling the Internet routing system could be utilized to deal with the MAC = forwarding table scalability issue. There are already many such attempts in = reality, especially in the academic circle. VL2 , SEATTLE and MOOSE are good = examples of them. Hence I suggest we spend some time to consider whether we could utilize = our experience which was obtained from the past and ongoing Internet routing scalability solution research to address the similar scalability issue existed in the DCN/DCI scenarios, for example, we could attempt or even develop those familiar ideas or approaches mentioned above to address = the MAC table scalability issue in the DCN/DCI scenarios. Best regards, Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] = =B4=FA=B1=ED Tony Li > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C29=C8=D5 1:18 > =CA=D5=BC=FE=C8=CB: rrg@irtf.org > =D6=F7=CC=E2: [rrg] Next topic? >=20 >=20 > Hi all, >=20 > It's time to start the conversation about where the RRG is headed. Towards > that end, I'd like to open the floor for the discussion of topics. = Any _research_ > topic within the broad area of routing and addressing is appropriate. >=20 > I propose the following process: we hold this discussion this month, trying to > identify relevant topics. Each topic should have a succinct statement = of its > goals. At the end of the month, we poll to determine the interest = level in the > various topics. Those that seem to have critical mass are recommended = to > the IRTF Chair for consideration. >=20 > The default answer, if no topic has critical mass, is for the RG to go = on hiatus. >=20 > Any questions or comments on the process? >=20 > Any proposals of research topics? >=20 > The floor is open... >=20 > Tony >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From mksmith@adhost.com Thu May 12 19:03:11 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9C13001C for ; Thu, 12 May 2011 19:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axJIAP6kjZAn for ; Thu, 12 May 2011 19:03:10 -0700 (PDT) Received: from mail-in04.adhost.com (mail-in04.adhost.com [216.211.128.134]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8413001A for ; Thu, 12 May 2011 19:03:10 -0700 (PDT) Received: from AD-EXH02.adhost.lan (unknown [10.142.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail-in04.adhost.com (Postfix) with ESMTPS id 08B94614F82; Thu, 12 May 2011 19:03:09 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from AD-EXH02.adhost.lan ([fe80::1c5b:7ead:8ba3:6108]) by AD-EXH02.adhost.lan ([fe80::1c5b:7ead:8ba3:6108%11]) with mapi id 14.01.0255.000; Thu, 12 May 2011 19:03:08 -0700 From: "Michael K. Smith - Adhost" To: Xu Xiaohu , 'Tony Li' , "rrg@irtf.org" Thread-Topic: [rrg] Next topic? Thread-Index: AQHMDaP56+KffFPJZUGc782sImRbuJSKdGYA//+UH4A= Date: Fri, 13 May 2011 02:03:07 +0000 Message-ID: In-Reply-To: <001e01cc110d$2bb85710$83290530$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [67.183.9.157] Content-Type: text/plain; charset="us-ascii" Content-ID: <760163197A1E1342940F922DF45EFDD1@adhost.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 02:03:11 -0000 On 5/12/11 6:29 PM, "Xu Xiaohu" wrote: >Hi Tony and all, > >In the past few years, RRG has done a lot of excellent research work to >explore various ideas and approaches (e.g., map&encap, id/locator split >and >translation...) to addressing the Internet routing scalability issue. >Today >it seems that the cloud Data Center Network (DCN) and Data Center >Interconnection (DCI) scenarios are facing a similar scalability challenge >(i.e., MAC forwarding table scalability issue). The demand for VM mobility >within the whole large L2 data center network or even across >geographically >dispersed data centers is one major driving force of extending the L2 >domain >scope larger and larger. > >Although the reason for the MAC forwarding table scalability issue in the >DCN/DCI scenarios is not the same as that for the Internet routing >scalability issue, the ideas and approaches suitable for scaling the >Internet routing system could be utilized to deal with the MAC forwarding >table scalability issue. There are already many such attempts in reality, >especially in the academic circle. VL2 , SEATTLE and MOOSE are good >examples >of them. > >Hence I suggest we spend some time to consider whether we could utilize >our >experience which was obtained from the past and ongoing Internet routing >scalability solution research to address the similar scalability issue >existed in the DCN/DCI scenarios, for example, we could attempt or even >develop those familiar ideas or approaches mentioned above to address the >MAC table scalability issue in the DCN/DCI scenarios. > >Best regards, >Xiaohu As an adjunct to this line, there is the ARMD group in the IETF (not officially chartered AFAIK) and an associated BOF at NANOG 52 in Denver. Mike From ikob@riken.jp Thu May 12 19:53:04 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F28E06FC for ; Thu, 12 May 2011 19:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YU40pK79VDQ for ; Thu, 12 May 2011 19:53:00 -0700 (PDT) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by ietfa.amsl.com (Postfix) with ESMTP id DC502E0593 for ; Thu, 12 May 2011 19:52:59 -0700 (PDT) Received: from [172.19.31.82] (unknown [134.160.184.31]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id DEC74E4D52 for ; Fri, 13 May 2011 11:52:58 +0900 (JST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Apple Message framework v1084) From: Katsushi Kobayashi In-Reply-To: <001e01cc110d$2bb85710$83290530$@com> Date: Fri, 13 May 2011 11:52:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6C1496-FC52-47A9-ACDD-3EAA74C3B351@riken.jp> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <001e01cc110d$2bb85710$83290530$@com> To: rrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 02:59:27 -0000 Hi, I would like point out another requirement from HPC. According to DOE target of Exascale computing, the top HPC system will be comprise 100K or 1M nodes. And each node will interconnected with 2TB/s or 250GB/s BW. http://www.er.doe.gov/ascr/ascac/Meetings/Mar10/AWhite.pdf I am not sure whether the system will choose regular direct interconnection network such as 3-D torus, or irregular indirect network. DCN/DCI requirements clearly meet the later system. Even in case of direct interconnection, I believe some topology finding mechanism will be strongly required for optimal performance and for operation.=20 ---- Katsushi Kobayashi On 2011/05/13, at 10:29, Xu Xiaohu wrote: > Hi Tony and all, >=20 > In the past few years, RRG has done a lot of excellent research work = to > explore various ideas and approaches (e.g., map&encap, id/locator = split and > translation...) to addressing the Internet routing scalability issue. = Today > it seems that the cloud Data Center Network (DCN) and Data Center > Interconnection (DCI) scenarios are facing a similar scalability = challenge > (i.e., MAC forwarding table scalability issue). The demand for VM = mobility > within the whole large L2 data center network or even across = geographically > dispersed data centers is one major driving force of extending the L2 = domain > scope larger and larger. >=20 > Although the reason for the MAC forwarding table scalability issue in = the > DCN/DCI scenarios is not the same as that for the Internet routing > scalability issue, the ideas and approaches suitable for scaling the > Internet routing system could be utilized to deal with the MAC = forwarding > table scalability issue. There are already many such attempts in = reality, > especially in the academic circle. VL2 , SEATTLE and MOOSE are good = examples > of them. >=20 > Hence I suggest we spend some time to consider whether we could = utilize our > experience which was obtained from the past and ongoing Internet = routing > scalability solution research to address the similar scalability issue > existed in the DCN/DCI scenarios, for example, we could attempt or = even > develop those familiar ideas or approaches mentioned above to address = the > MAC table scalability issue in the DCN/DCI scenarios. >=20 > Best regards, > Xiaohu >=20 >=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: rrg-bounces@irtf.org = [mailto:rrg-bounces@irtf.org] =B4=FA=B1=ED Tony Li >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C29=C8=D5 1:18 >> =CA=D5=BC=FE=C8=CB: rrg@irtf.org >> =D6=F7=CC=E2: [rrg] Next topic? >>=20 >>=20 >> Hi all, >>=20 >> It's time to start the conversation about where the RRG is headed. > Towards >> that end, I'd like to open the floor for the discussion of topics. = Any > _research_ >> topic within the broad area of routing and addressing is appropriate. >>=20 >> I propose the following process: we hold this discussion this month, > trying to >> identify relevant topics. Each topic should have a succinct = statement of > its >> goals. At the end of the month, we poll to determine the interest = level > in the >> various topics. Those that seem to have critical mass are = recommended to >> the IRTF Chair for consideration. >>=20 >> The default answer, if no topic has critical mass, is for the RG to = go on > hiatus. >>=20 >> Any questions or comments on the process? >>=20 >> Any proposals of research topics? >>=20 >> The floor is open... >>=20 >> Tony >>=20 >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Thu May 12 22:13:58 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2770E0657 for ; Thu, 12 May 2011 22:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHiddRnq-sPS for ; Thu, 12 May 2011 22:13:57 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED9E0696 for ; Thu, 12 May 2011 22:13:57 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta14.emeryville.ca.mail.comcast.net with comcast id it7c1g0051smiN4AEtDwbr; Fri, 13 May 2011 05:13:56 +0000 Received: from [192.168.2.100] ([98.248.36.188]) by omta20.emeryville.ca.mail.comcast.net with comcast id itDt1g00243ZcXW8gtDuCg; Fri, 13 May 2011 05:13:55 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <8E6C1496-FC52-47A9-ACDD-3EAA74C3B351@riken.jp> Date: Thu, 12 May 2011 22:13:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0BECB0C9-3D24-4676-AEF3-96252BE7C62C@tony.li> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <001e01cc110d$2bb85710$83290530$@com> <8E6C1496-FC52-47A9-ACDD-3EAA74C3B351@riken.jp> To: Katsushi Kobayashi X-Mailer: Apple Mail (2.1084) Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 05:13:58 -0000 On May 12, 2011, at 7:52 PM, Katsushi Kobayashi wrote: > I am not sure whether the system will choose regular direct > interconnection network such as 3-D torus, or irregular indirect > network. DCN/DCI requirements clearly meet the later system. > Even in case of direct interconnection, I believe some topology > finding mechanism will be strongly required for optimal > performance and for operation.=20 Interesting. As you prepare your topic proposal, please highlight the = IP routing and addressing aspects of the research here. Thanks, Tony From pfrejborg@gmail.com Thu May 12 23:00:28 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63423E06AD for ; Thu, 12 May 2011 23:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfigrEoLgUQI for ; Thu, 12 May 2011 23:00:27 -0700 (PDT) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 49B61E0657 for ; Thu, 12 May 2011 23:00:27 -0700 (PDT) Received: by ewy1 with SMTP id 1so847605ewy.13 for ; Thu, 12 May 2011 23:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w1ietLtUvYphdGRtUwWoeWSPTTkBq95h6XqWpWiAtkA=; b=eFnRi6ZSjm5QJRwW8K/9b7Gwjdlnf4hLJdvkBbAK79Jn00CPJNGsYZ+EwW+9vFdEUp /fmPt234tTX95aOQ5Aw4o+SDRYsGj9wYMp6Cs5Ejo7bKNBzt7QIJVS4uNcxuJCjDlwQB nKt6oKEkuYYP0cUDQD6DEFD8IIp0jSiz06cfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wBcRw+q86E4hGmY6eBNQAC7xkLtXCnsnrcjM1N+K1WhIZy9BkFVQZvTMUixXyGGqkr W1vWdPKzuHeaEgA1hVD8FLEfd/5nE9FcykocH/jVXycGI7FuzjnR6eory4YZmNqFAmSq /BjZ7bjWsUefbA3fPM/rFAmh49jp2sq2sZMAw= MIME-Version: 1.0 Received: by 10.213.19.17 with SMTP id y17mr568256eba.38.1305266424110; Thu, 12 May 2011 23:00:24 -0700 (PDT) Received: by 10.213.32.7 with HTTP; Thu, 12 May 2011 23:00:24 -0700 (PDT) In-Reply-To: <001e01cc110d$2bb85710$83290530$@com> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <001e01cc110d$2bb85710$83290530$@com> Date: Fri, 13 May 2011 09:00:24 +0300 Message-ID: From: Patrick Frejborg To: Xu Xiaohu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: Tony Li , rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 06:00:28 -0000 Hi Xiaohu, this is an interesting topic and there has been other research works as well. I find it more appealing to use L3 in data centers and that is doable if the identifier/locator split is applied. Instead of finding a path from endpoint A to endpoint B the the path is established from endpoint A to service instance B. You might find these links interesting http://sns.cs.princeton.edu/projects/scaffold/ http://netseminar.stanford.edu/past_seminars/seminars/freedman-scaffold.pdf Patrick 2011/5/13 Xu Xiaohu : > Hi Tony and all, > > In the past few years, RRG has done a lot of excellent research work to > explore various ideas and approaches (e.g., map&encap, id/locator split a= nd > translation...) to addressing the Internet routing scalability issue. Tod= ay > it seems that the cloud Data Center Network (DCN) and Data Center > Interconnection (DCI) scenarios are facing a similar scalability challeng= e > (i.e., MAC forwarding table scalability issue). The demand for VM mobilit= y > within the whole large L2 data center network or even across geographical= ly > dispersed data centers is one major driving force of extending the L2 dom= ain > scope larger and larger. > > Although the reason for the MAC forwarding table scalability issue in the > DCN/DCI scenarios is not the same as that for the Internet routing > scalability issue, the ideas and approaches suitable for scaling the > Internet routing system could be utilized to deal with the MAC forwarding > table scalability issue. There are already many such attempts in reality, > especially in the academic circle. VL2 , SEATTLE and MOOSE are good examp= les > of them. > > Hence I suggest we spend some time to consider whether we could utilize o= ur > experience which was obtained from the past and ongoing Internet routing > scalability solution research to address the similar scalability issue > existed in the DCN/DCI scenarios, for example, we could attempt or even > develop those familiar ideas or approaches mentioned above to address the > MAC table scalability issue in the DCN/DCI scenarios. > > Best regards, > Xiaohu > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] = =B4=FA=B1=ED Tony Li >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C29=C8=D5 1:18 >> =CA=D5=BC=FE=C8=CB: rrg@irtf.org >> =D6=F7=CC=E2: [rrg] Next topic? >> >> >> Hi all, >> >> It's time to start the conversation about where the RRG is headed. > Towards >> that end, I'd like to open the floor for the discussion of topics. Any > _research_ >> topic within the broad area of routing and addressing is appropriate. >> >> I propose the following process: we hold this discussion this month, > trying to >> identify relevant topics. Each topic should have a succinct statement o= f > its >> goals. At the end of the month, we poll to determine the interest level > in the >> various topics. Those that seem to have critical mass are recommended t= o >> the IRTF Chair for consideration. >> >> The default answer, if no topic has critical mass, is for the RG to go o= n > hiatus. >> >> Any questions or comments on the process? >> >> Any proposals of research topics? >> >> The floor is open... >> >> Tony >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From benno@NLnetLabs.nl Mon May 16 03:18:45 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4181BE06A1 for ; Mon, 16 May 2011 03:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9zgRp1+-1iA for ; Mon, 16 May 2011 03:18:44 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1ECE069A for ; Mon, 16 May 2011 03:18:43 -0700 (PDT) Received: from aluminum.nlnetlabs.nl (aluminum.nlnetlabs.nl [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p4GAIeM9092123 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 May 2011 12:18:41 +0200 (CEST) (envelope-from benno@NLnetLabs.nl) Message-ID: <4DD0FA00.6060605@NLnetLabs.nl> Date: Mon, 16 May 2011 12:18:40 +0200 From: Benno Overeinder User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: rrg@irtf.org, marcelo bagnulo braun References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <4DC90101.50403@it.uc3m.es> <69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li> <4DCB6F88.1080807@it.uc3m.es> In-Reply-To: <4DCB6F88.1080807@it.uc3m.es> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 16 May 2011 12:18:41 +0200 (CEST) Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 10:18:45 -0000 On 5/12/11 7:26 AM, marcelo bagnulo braun wrote: > Ok, let me try to coordinate with others to produce some first draft of > this probably during next week, is that ok? > We are running some simulation experiments to get insight in the scalability (number of BGP update messages and maybe later the convergence time) and path diversity/disjointness of different multi-path routing proposals. We are trying to get an answer what the practical implications are of the deployment of multi-path routing on current Internet AS-topology (and the past topologies from 2004 onwards). If these are interesting questions to put in the draft, I am more than happy to give more details, etc. Cheers, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From HeinerHummel@aol.com Thu May 19 09:13:56 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA285E0726 for ; Thu, 19 May 2011 09:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAhzE6XXctny for ; Thu, 19 May 2011 09:13:56 -0700 (PDT) Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2254CE06D5 for ; Thu, 19 May 2011 09:13:56 -0700 (PDT) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-da01.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4JGDKO1026677 for ; Thu, 19 May 2011 12:13:20 -0400 Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v42.9.) id 9.edf.ac5ea94 (45478) for ; Thu, 19 May 2011 12:13:16 -0400 (EDT) Received: from smtprly-de02.mx.aol.com (smtprly-de02.mx.aol.com [205.188.249.169]) by cia-mc06.mx.aol.com (v129.10) with ESMTP id MAILCIAMC067-b23f4dd541878; Thu, 19 May 2011 12:13:08 -0400 Received: from webmail-m074 (webmail-m074.sim.aol.com [64.12.141.32]) by smtprly-de02.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYDE028-b23f4dd541878; Thu, 19 May 2011 12:12:55 -0400 References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com><4DC90101.50403@it.uc3m.es><69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li><4DCB6F88.1080807@it.uc3m.es> <81A1DDDC-8CFA-4613-BFE2-F93FD28C900A@tony.li> To: rrg@irtf.org Date: Thu, 19 May 2011 12:12:55 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: <81A1DDDC-8CFA-4613-BFE2-F93FD28C900A@tony.li> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDE456BF3433F4_1464_631DA_webmail-m074.sysops.aol.com" X-Mailer: AOL Webmail 33668-STANDARD Received: from 95.91.105.21 by webmail-m074.sysops.aol.com (64.12.141.32) with HTTP (WebMailUI); Thu, 19 May 2011 12:12:55 -0400 Message-Id: <8CDE456BF2AAE6C-1464-3D2F8@webmail-m074.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 16:13:56 -0000 ----------MB_8CDE456BF3433F4_1464_631DA_webmail-m074.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Proposals: 1) Discussion about alternate multicast instance identification: Historically, a multicast instance is identified by some unique (?) multic= ast address. Meanwhile there is also ssm, where the multicast instance is= identified by the sender's unicast address plus some multicast-address = from some ssm-specific range.=20 Proposal: Use a new multicast-protocol type plus the sender's unicast addr= ess. Con: Existing (deployed) multicast services have to be changed. Pro: 1 billion IPv4-addresses would be freed for unicast which is quite a= lot while facing the address depletion issue.=20 The discussion should be led by ISP folks. I think, they would know best= the costs as well as the benefits. 2) State-less multicast for about 99 % of the involved routers by means of= cascade tree multicast Example: By employing a cascade degree =3D10 about 90 % of the receivers= wouldn't even become aware of being involved in some multicast activity.A= ssuming 20 hops in average between any two nodes of the cascade tree, only= a half percent of the involved routers have be cascade tree multicast kno= wledgable. Heiner ----------MB_8CDE456BF3433F4_1464_631DA_webmail-m074.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Proposals:

1) Discussion about alternate multicast instance identification:

Historically, a multicast instance is identified by some unique (?)= multicast address. Meanwhile there is also ssm, where the multicast insta= nce is identified by the sender's unicast address plus some multicast-addr= ess  from some ssm-specific range. 

Proposal: Use a new multicast-protocol type plus the sender's unicast= address.

Con: Existing (deployed) multicast services have to be changed.
Pro: 1 billion IPv4-addresses would be freed for unicast which is qui= te a lot while facing the address depletion issue. 

The discussion should be led by ISP folks. I think, they would know= best the costs as well as the benefits.

2) State-less multicast for about 99 % of the involved routers by mea= ns of cascade tree multicast
Example: By employing a cascade degree =3D10 about 90 % of the receiv= ers wouldn't even become aware of being involved in some multicast activit= y.Assuming 20 hops in average between any two nodes of the cascade tree,= only a half percent of the involved routers have be cascade tree multicas= t knowledgable.


Heiner




 ----------MB_8CDE456BF3433F4_1464_631DA_webmail-m074.sysops.aol.com-- From ljakab@ac.upc.edu Thu May 19 09:44:36 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9AAE073D for ; Thu, 19 May 2011 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIH-lFh7-ZXi for ; Thu, 19 May 2011 09:44:36 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id D2DC1E071E for ; Thu, 19 May 2011 09:44:35 -0700 (PDT) Received: from [147.83.34.118] (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id 6E4E16B023B; Thu, 19 May 2011 18:44:31 +0200 (CEST) Message-ID: <4DD548F0.10001@ac.upc.edu> Date: Thu, 19 May 2011 18:44:32 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: heinerhummel@aol.com References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com><4DC90101.50403@it.uc3m.es><69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li><4DCB6F88.1080807@it.uc3m.es> <81A1DDDC-8CFA-4613-BFE2-F93FD28C900A@tony.li> <8CDE456BF2AAE6C-1464-3D2F8@webmail-m074.sysops.aol.com> In-Reply-To: <8CDE456BF2AAE6C-1464-3D2F8@webmail-m074.sysops.aol.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 16:44:36 -0000 Hi Heiner, On 05/19/11 18:12, heinerhummel@aol.com wrote: > > Proposals: > > 1) Discussion about alternate multicast instance identification: > > Historically, a multicast instance is identified by some unique (?) > multicast address. Meanwhile there is also ssm, where the multicast > instance is identified by the sender's unicast address plus some > multicast-address from some ssm-specific range. > > Proposal: Use a new multicast-protocol type plus the sender's unicast > address. > > Con: Existing (deployed) multicast services have to be changed. > Pro: 1 billion IPv4-addresses would be freed for unicast which is > quite a lot while facing the address depletion issue. > > The discussion should be led by ISP folks. I think, they would know > best the costs as well as the benefits. This proposal came up a few times on the North American Network Operators' Group (NANOG) mailing list, where the ISP folks hang out. I think the main concern is that "Class D" (and E, the experimental block) is hardcoded into most router's software, and forcing everyone to upgrade is just not feasible. Granted, a lot of IPv4 addresses would be freed this way, but migrating to IPv6 should be a better long term strategy. The amount of time/energy needed to coordinate a change like this would be better spent for IPv6 migration. -Loránd Jakab > > 2) State-less multicast for about 99 % of the involved routers by > means of cascade tree multicast > Example: By employing a cascade degree =10 about 90 % of the receivers > wouldn't even become aware of being involved in some multicast > activity.Assuming 20 hops in average between any two nodes of the > cascade tree, only a half percent of the involved routers have be > cascade tree multicast knowledgable. > > > Heiner > > > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From HeinerHummel@aol.com Thu May 19 15:15:33 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5CE06A2 for ; Thu, 19 May 2011 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NFmXEkmdRwj for ; Thu, 19 May 2011 15:15:32 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 36734E068B for ; Thu, 19 May 2011 15:15:32 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4JMFFT8005974; Thu, 19 May 2011 18:15:15 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v42.9.) id 6.caa.6ae40564 (55721); Thu, 19 May 2011 18:15:11 -0400 (EDT) Received: from smtprly-me02.mx.aol.com (smtprly-me02.mx.aol.com [64.12.95.103]) by cia-md02.mx.aol.com (v129.10) with ESMTP id MAILCIAMD024-b2ca4dd5966729; Thu, 19 May 2011 18:15:10 -0400 Received: from webmail-m085 (webmail-m085.sim.aol.com [64.12.224.197]) by smtprly-me02.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYME024-b2ca4dd5966729; Thu, 19 May 2011 18:15:03 -0400 References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com><4DC90101.50403@it.uc3m.es><69F152CB-2FAF-4569-B0BF-1F97BB5A845E@tony.li><4DCB6F88.1080807@it.uc3m.es> <81A1DDDC-8CFA-4613-BFE2-F93FD28C900A@tony.li> <8CDE456BF2AAE6C-1464-3D2F8@webmail-m074.sysops.aol.com> <4DD548F0.10001@ac.upc.edu> To: ljakab@ac.upc.edu Date: Thu, 19 May 2011 18:15:03 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: <4DD548F0.10001@ac.upc.edu> X-MB-Message-Source: WebUI Received: from 95.91.105.21 by webmail-m085.sysops.aol.com (64.12.224.197) with HTTP (WebMailUI); Thu, 19 May 2011 18:15:03 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDE489560AD5B6_94C_F4C9_webmail-m085.sysops.aol.com" X-Mailer: Webmail 33668-STANDARD Message-Id: <8CDE48955F0A696-94C-7B45@webmail-m085.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 22:15:33 -0000 ----------MB_8CDE489560AD5B6_94C_F4C9_webmail-m085.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Lorand, Certainly, my proposal is to find out how urgent is the IPv4-address deple= tion issue. Maybe it is not urgent and NAT will do. And looking at IPv6: IPv6 provides even more of these funny Multicast addr= esses :-(=20 You may be fancy about IPv6, not me. (I don't know whether I should be hap= py or sad about the flow label's destiny so far.) This is RRG, i.e. somehow "research for the better". IMHO there are differ= ent actions wrt p2p, p2mp, mp2p, mp2mp and anycast which should be express= ed by different protocol types. Yes, some additional information is to be= provided: In case of multicast, the sender's IPv4-address, in case of anycast some= ANYCAST-destination address (by using a separate protocol type the anyca= st addres range could be 32 bits long - more than enough). Wrt mp2p I onl= y know MPLS applications - it does not exist in IP. mp2mp isn't reflected= nowhere :-( Heiner =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Lor=C3=A1nd Jakab An: heinerhummel@aol.com Cc: rrg@irtf.org Verschickt: Do., 19. Mai. 2011, 18:44 Thema: Re: [rrg] Next topic? Hi Heiner, On 05/19/11 18:12, heinerhummel@aol.com wrote: > > Proposals: > > 1) Discussion about alternate multicast instance identification: > > Historically, a multicast instance is identified by some unique (?) > multicast address. Meanwhile there is also ssm, where the multicast > instance is identified by the sender's unicast address plus some > multicast-address from some ssm-specific range.=20 > > Proposal: Use a new multicast-protocol type plus the sender's unicast > address. > > Con: Existing (deployed) multicast services have to be changed. > Pro: 1 billion IPv4-addresses would be freed for unicast which is > quite a lot while facing the address depletion issue.=20 > > The discussion should be led by ISP folks. I think, they would know > best the costs as well as the benefits. This proposal came up a few times on the North American Network Operators' Group (NANOG) mailing list, where the ISP folks hang out. I think the main concern is that "Class D" (and E, the experimental block) is hardcoded into most router's software, and forcing everyone to upgrade is just not feasible. Granted, a lot of IPv4 addresses would be freed this way, but migrating to IPv6 should be a better long term strategy. The amount of time/energy needed to coordinate a change like this would be better spent for IPv6 migration. -Lor=C3=A1nd Jakab > > 2) State-less multicast for about 99 % of the involved routers by > means of cascade tree multicast > Example: By employing a cascade degree =3D10 about 90 % of the receivers > wouldn't even become aware of being involved in some multicast > activity.Assuming 20 hops in average between any two nodes of the > cascade tree, only a half percent of the involved routers have be > cascade tree multicast knowledgable. > > > Heiner > > > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg =20 ----------MB_8CDE489560AD5B6_94C_F4C9_webmail-m085.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Lorand,

Certainly, my proposal is to find out how urgent is the IPv4-address= depletion issue. Maybe it is not urgent and NAT will do.
And looking at IPv6: IPv6 provides even more of these funny Multicast= addresses :-( 
You may be fancy about IPv6, not me. (I don't know whether I should= be happy or sad about the flow label's destiny so far.)


This is RRG, i.e. somehow "research for the better". IMHO there are= different actions wrt p2p, p2mp, mp2p, mp2mp and anycast which should be= expressed by different protocol types. Yes, some additional information= is to be provided:
In case of multicast, the sender's IPv4-address, in case of anycast= some ANYCAST-destination address (by using a separate protocol type  = ;the anycast addres range could be 32 bits long - more than enough). Wrt=  mp2p I only know MPLS applications - it does not exist in IP. mp2mp= isn't reflected nowhere :-(


Heiner





 
----= -Urspr=C3=BCngliche Mitteilung-----
Von: Lor=C3=A1nd Jakab <ljakab@ac.upc.edu>
An: heinerhummel@aol.com
Cc: rrg@irtf.org
Verschickt: Do., 19. Mai. 2011, 18:44
Thema: Re: [rrg] Next topic?

Hi Heiner,

On 05/19/11 18:12, heinerhummel@ao=
l.com wrote:
>
> Proposals:
>
> 1) Discussion about alternate multicast instance identification:
>
> Historically, a multicast instance is identified by some unique (?)
> multicast address. Meanwhile there is also ssm, where the multicast
> instance is identified by the sender's unicast address plus some
> multicast-address  from some ssm-specific range.=20
>
> Proposal: Use a new multicast-protocol type plus the sender's unicast
> address.
>
> Con: Existing (deployed) multicast services have to be changed.
> Pro: 1 billion IPv4-addresses would be freed for unicast which is
> quite a lot while facing the address depletion issue.=20
>
> The discussion should be led by ISP folks. I think, they would know
> best the costs as well as the benefits.

This proposal came up a few times on the North American Network
Operators' Group (NANOG) mailing list, where the ISP folks hang out. I
think the main concern is that "Class D" (and E, the experimental block)
is hardcoded into most router's software, and forcing everyone to
upgrade is just not feasible. Granted, a lot of IPv4 addresses would be
freed this way, but migrating to IPv6 should be a better long term
strategy. The amount of time/energy needed to coordinate a change like
this would be better spent for IPv6 migration.

-Lor=C3=A1nd Jakab

>
> 2) State-less multicast for about 99 % of the involved routers by
> means of cascade tree multicast
> Example: By employing a cascade degree =3D10 about 90 % of the receiv=
ers
> wouldn't even become aware of being involved in some multicast
> activity.Assuming 20 hops in average between any two nodes of the
> cascade tree, only a half percent of the involved routers have be
> cascade tree multicast knowledgable.
>
>
> Heiner
>
>
>
>
>
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
----------MB_8CDE489560AD5B6_94C_F4C9_webmail-m085.sysops.aol.com-- From xuxh@huawei.com Thu May 19 21:16:25 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7797EE0659 for ; Thu, 19 May 2011 21:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MANGLED_SAVELE=2.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqo4F10iEw0B for ; Thu, 19 May 2011 21:16:24 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CFF79E0651 for ; Thu, 19 May 2011 21:16:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLH00GEM7PMV0@szxga04-in.huawei.com> for rrg@irtf.org; Fri, 20 May 2011 12:12:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLH0056H7PM0W@szxga04-in.huawei.com> for rrg@irtf.org; Fri, 20 May 2011 12:12:58 +0800 (CST) Received: from x41208c ([10.110.98.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLH003197PMOL@szxml04-in.huawei.com> for rrg@irtf.org; Fri, 20 May 2011 12:12:58 +0800 (CST) Date: Fri, 20 May 2011 12:22:26 +0800 From: Xu Xiaohu To: darlewis@cisco.com Message-id: <003701cc16a5$86918380$93b48a80$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wLgzZrg2TnJ4dDxjwNmz9Q)" Content-language: zh-cn Thread-index: AcwWpYY+ujSNUPQMR561qxszLwlm0A== Cc: 'RRG' Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 04:16:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wLgzZrg2TnJ4dDxjwNmz9Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable =20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Darrel Lewis [mailto:darlewis@cisco.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C213=C8=D5 23:02 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: Darrel Lewis > =D6=F7=CC=E2: Re: [rrg] Next topic? >=20 >=20 > On May 12, 2011, at 6:29 PM, Xu Xiaohu wrote: >=20 > > Hi Tony and all, > > > > In the past few years, RRG has done a lot of excellent research work = > > to explore various ideas and approaches (e.g., map&encap, id/locator = > > split and > > translation...) to addressing the Internet routing scalability=20 > > issue. Today it seems that the cloud Data Center Network (DCN) and=20 > > Data Center Interconnection (DCI) scenarios are facing a similar=20 > > scalability challenge (i.e., MAC forwarding table scalability=20 > > issue). The demand for VM mobility within the whole large L2 data=20 > > center network or even across geographically dispersed data centers=20 > > is one major driving force of extending the L2 domain scope larger = and larger. > > > > Although the reason for the MAC forwarding table scalability issue=20 > > in the DCN/DCI scenarios is not the same as that for the Internet=20 > > routing scalability issue, >=20 > Why do you say this? MAC addresses are exactly like PI IP addresses=20 > architecturally! =20 Sorry for late response. Yes, your point is correct from this special aspect:). The reason that I mentioned includes both the external reason = (e. g., VM mobility v.s. multi-homing, traffic-engineering and PI address = usage) and internal reason (flat address v.s. overloading of IP address = semantics). =20 > That is, they are not aggregatable, and the namespace appears flat to=20 > the routing system. =20 Correct. =20 > > the ideas and approaches suitable for scaling the Internet routing=20 > > system could be utilized to deal with the MAC forwarding table=20 > > scalability issue. >=20 > This is because its the same problem :-) >=20 > > There are already many such attempts in reality, especially in the=20 > > academic circle. VL2 , SEATTLE and MOOSE are good > examples > > of them. >=20 > There are only 2 ways to skin this cat, either translation and=20 > encapsulation, and they can either on the host or on the network. =20 Agree. However, since the application scenarios have some differences = (e.g., site networks could be configured with a default IP route in the = Internet routing scenario while data center sites could not be configured with a default MAC route in the DCI scenario...), it would better to = investigate whether the approaches we used before for scaling the Internet routing system could be reused or even simplified to deal with the similar scalability issue existed in the DCN/DCI scenarios. =20 Best regards, Xiaohu=20 =20 > > Hence I suggest we spend some time to consider whether we could=20 > > utilize > our > > experience which was obtained from the past and ongoing Internet=20 > > routing scalability solution research to address the similar=20 > > scalability issue existed in the DCN/DCI scenarios, for example, we=20 > > could attempt or even develop those familiar ideas or approaches=20 > > mentioned above to address the MAC table scalability issue in the DCN/DCI scenarios. > > > > Best regards, > > Xiaohu > > > > > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: rrg-bounces@irtf.org = [mailto:rrg-bounces@irtf.org] =B4=FA=B1=ED Tony Li > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C29=C8=D5 1:18 > >> =CA=D5=BC=FE=C8=CB: rrg@irtf.org > >> =D6=F7=CC=E2: [rrg] Next topic? > >> > >> > >> Hi all, > >> > >> It's time to start the conversation about where the RRG is headed. > > Towards > >> that end, I'd like to open the floor for the discussion of topics. = > >> Any > > _research_ > >> topic within the broad area of routing and addressing is = appropriate. > >> > >> I propose the following process: we hold this discussion this=20 > >> month, > > trying to > >> identify relevant topics. Each topic should have a succinct=20 > >> statement of > > its > >> goals. At the end of the month, we poll to determine the interest=20 > >> level > > in the > >> various topics. Those that seem to have critical mass are=20 > >> recommended to the IRTF Chair for consideration. > >> > >> The default answer, if no topic has critical mass, is for the RG to = > >> go on > > hiatus. > >> > >> Any questions or comments on the process? > >> > >> Any proposals of research topics? > >> > >> The floor is open... > >> > >> Tony > >> > >> _______________________________________________ > >> rrg mailing list > >> rrg@irtf.org > >> http://www.irtf.org/mailman/listinfo/rrg > > > > _______________________________________________ > > rrg mailing list > > rrg@irtf.org > > http://www.irtf.org/mailman/listinfo/rrg =20 --Boundary_(ID_wLgzZrg2TnJ4dDxjwNmz9Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: Darrel Lewis = [mailto:darlewis@cisco.com]

> =B7=A2=CB=CD=CA=B1=BC=E4: = 2011=C4=EA5=D4=C213=C8=D5 = 23:02

> =CA=D5=BC=FE=C8=CB: Xu = Xiaohu

> =B3=AD=CB=CD: Darrel = Lewis

> =D6=F7=CC=E2: Re: [rrg] Next = topic?

>

>

> On May 12, 2011, at 6:29 = PM, Xu Xiaohu wrote:

>

> > Hi Tony and = all,

> = >

> > In the past few = years, RRG has done a lot of excellent research work

> > to explore various = ideas and approaches (e.g., map&encap, id/locator

> > split = and

> > translation...) to = addressing the Internet routing scalability

> > issue. Today it = seems that the cloud Data Center Network (DCN) and

> > Data Center = Interconnection (DCI) scenarios are facing a similar

> > scalability = challenge (i.e., MAC forwarding table scalability

> > issue). The demand = for VM mobility within the whole large L2 data

> > center network or = even across geographically dispersed data centers

> > is one major = driving force of extending the L2 domain scope larger and larger.

> = >

> > Although the reason = for the MAC forwarding table scalability issue

> > in the DCN/DCI = scenarios is not the same as that for the Internet

> > routing scalability = issue,

>

> Why do you say = this?  MAC addresses are exactly like PI IP addresses

> = architecturally!

 

Sorry for late response. Yes, = your point is correct from this special aspect:).  The reason that I mentioned includes both the external reason (e.g., VM mobility v.s. multi-homing, traffic-engineering and PI address usage) and internal reason (flat = address v.s. overloading of IP address semantics).

 

> That is, they are not = aggregatable, and the namespace appears flat to

> the routing = system.

 

Correct.

 

> > the ideas and = approaches suitable for scaling the Internet routing

> > system could be = utilized to deal with the MAC forwarding table

> > scalability = issue.

>

> This is because its the = same problem :-)

>

> > There are already = many such attempts in reality, especially in the

> > academic circle. = VL2 , SEATTLE and MOOSE are good

> = examples

> > of = them.

>

> There are only 2 ways to = skin this cat, either translation and

> encapsulation, and they = can either on the host or on the network.

 

Agree. However, since the = application scenarios have some differences (e.g., site networks could be configured = with a default IP route in the Internet routing scenario while data center = sites could not be configured with a default MAC route in the DCI scenario...), it = would better to investigate whether the approaches we used before for scaling = the Internet routing system could be reused or even simplified to deal with = the similar scalability issue existed in the DCN/DCI = scenarios.

 

Best = regards,

Xiaohu

 

> > Hence I suggest we = spend some time to consider whether we could

> > = utilize

> = our

> > experience which = was obtained from the past and ongoing Internet

> > routing scalability = solution research to address the similar

> > scalability issue = existed in the DCN/DCI scenarios, for example, we

> > could attempt or = even develop those familiar ideas or approaches

> > mentioned above to = address the MAC table scalability issue in the DCN/DCI = scenarios.

> = >

> > Best = regards,

> > = Xiaohu

> = >

> = >

> >> = -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> >> =B7=A2=BC=FE=C8=CB: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] =B4=FA=B1=ED Tony Li

> >> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C29=C8=D5 1:18

> >> =CA=D5=BC=FE=C8=CB: rrg@irtf.org

> >> =D6=F7=CC=E2: [rrg] Next topic?

> = >>

> = >>

> >> Hi = all,

> = >>

> >> It's time to = start the conversation about where the RRG is headed.

> > = Towards

> >> that end, I'd = like to open the floor for the discussion of topics. 

> >> = Any

> > = _research_

> >> topic within = the broad area of routing and addressing is appropriate.

> = >>

> >> I propose the = following process: we hold this discussion this

> >> = month,

> > trying = to

> >> identify = relevant topics.  Each topic should have a succinct

> >> statement = of

> > = its

> >> goals.  At = the end of the month, we poll to determine the interest

> >> = level

> > in = the

> >> various = topics.  Those that seem to have critical mass are

> >> recommended to = the IRTF Chair for consideration.

> = >>

> >> The default = answer, if no topic has critical mass, is for the RG to

> >> go = on

> > = hiatus.

> = >>

> >> Any questions = or comments on the process?

> = >>

> >> Any proposals = of research topics?

> = >>

> >> The floor is = open...

> = >>

> >> = Tony

> = >>

> >> _______________________________________________

> >> rrg mailing = list

> >> rrg@irtf.org

> >> http://www.irtf.org/mai= lman/listinfo/rrg

> = >

> > _______________________________________________

> > rrg mailing = list

> > rrg@irtf.org

> > http://www.irtf.org/mai= lman/listinfo/rrg

 

--Boundary_(ID_wLgzZrg2TnJ4dDxjwNmz9Q)-- From pedroa.aranda@tid.es Thu May 19 22:48:59 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F17BE0686 for ; Thu, 19 May 2011 22:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YszB0NP2kva for ; Thu, 19 May 2011 22:48:58 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 456DDE0655 for ; Thu, 19 May 2011 22:48:57 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLH00B4AC5K1M@tid.hi.inet> for rrg@irtf.org; Fri, 20 May 2011 07:48:56 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 9F.52.02885.CE9F5DD4; Fri, 20 May 2011 07:19:40 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LLH00B46C5J1M@tid.hi.inet> for rrg@irtf.org; Fri, 20 May 2011 07:48:55 +0200 (MEST) Received: from [10.95.162.93] (10.95.67.43) by htcasmad1.hi.inet (10.95.67.73) with Microsoft SMTP Server id 8.3.83.0; Fri, 20 May 2011 07:48:55 +0200 Date: Fri, 20 May 2011 07:48:55 +0200 From: =?ISO-8859-1?Q?Pedro_Andr=E9s_Aranda_Guti=E9rrez?= To: rrg@irtf.org Message-id: <4DD600C7.5080001@tid.es> Organization: =?ISO-8859-1?Q?Telef=F3nica=2C_I+D?= MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 X-AuditID: 0a5f4068-b7beeae000000b45-16-4dd5f9ec0ffb X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsXCFe/Apfvm51Vfg8sPOC0WrXjK4sDoMXnj YbYAxigum5TUnMyy1CJ9uwSujB9rV7EULBGuOLbpL1MD4yb+LkZODiEBKYn2fa/YQWwJAROJ nd2nWCBsMYkL99azdTFyAdVsZJTYe2oRE4TznVFi18t2KGcGo8TyOb1MIC0sAqoSUxfdZQax 2QTcJJZfWgQWFxaQkXh+/xDQCg4OEQEBielnTSA2i0rsu7MObBsvUOvVY41sIDa/gJHE7I9z mSDighI/Jt8Dq2EWsJY49W0lM4StLfHk3QVWkJGiAiUS/XsFJzAKzkLSMQtJxywkHQsYmVcx ihUnFWWmZ5TkJmbmpBsY6mVk6mXmpZZsYoQEZ8YOxuU7VQ4xCnAwKvHw/oi56ivEmlhWXJl7 iFGSg0lJlNf8P1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO9hYEwI8aYkVlalFuXDpGQ4OJQk eA+AtAkWpaanVqRl5gBjECbNxMEJ0s4D1P4epIa3uCAxtzgzHSJ/ilGVo+He7wOMQix5+Xmp UuK8T0GKBECKMkrz4Oa8YhQHOliY9x5IlgeYROAmvAIazgQ0XHb/FZDhJYkIKakGRtucG2Zn 5fu3z7ncJlFoK7oodtHn30kqFVtXnmW/9yhngtOW56ycfCnTHjGYsjQ8ll7hxn1Tvzn//+EO J8veI4dnTNdb4e9dNM/0zbsP1SZ/ZKZYclUtvuhzcpWM9G7G1wIGr7S4YqZPPmC9I01qU9RJ 2xa3bw/MNuTff5ElYut88urjJSIFT5VYijMSDbWYi4oTATzPAuHfAgAA Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paag@tid.es List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 05:48:59 -0000 > Date: Thu, 19 May 2011 18:15:03 -0400 > From: heinerhummel@aol.com > To: ljakab@ac.upc.edu > Cc: rrg@irtf.org > Subject: Re: [rrg] Next topic? > Message-ID: <8CDE48955F0A696-94C-7B45@webmail-m085.sysops.aol.com> > Content-Type: text/plain; charset=3D"utf-8" > > Hi Lorand, > > > Certainly, my proposal is to find out how urgent is the IPv4-address depl= etion issue. > Maybe it is not urgent and NAT will do. DISCLAIMER: all opinions in this email are mine and do not necessarily reflect those of my employer Hi Heiner, all, I'm sorry to hear this "NAT will do". NAT does at home/SOHO environments. NAT may do at the office/branch/company environment. NAT may even do at the current low traffic profile mobile devices. But NAT will *certainly* not do when installed in the network. The problems: 1) I can open ports @ my home router, because I have all 65536 ports under my control. But in a NATxyz environment, I will be restricted and I will most probably not get the 'right' ports (i.e. 0-1023) assigned. 2) Overlooking that, you are putting boxes into the network which are concentrating traffic of a lot of people and they are single points of failure in the sense that if one dies, it will most probably not passed unnoticed by the users. 3) We have to think that the number of customers will grow and it is certain that the traffic per user will _not_ diminish. Any NAT solution means putting very specialise boxes in a sort of black hole. When traffic takes up, we will need to throw in NAT after NAT after NAT. As you see, neither users (and be it just the 'port opening' issue) nor operators will be well served with a NAT solution. Just my 2 cents,/PA -- Pedro A. Aranda Guti=E9rrez Telef=F3nica I+D Technology Specialist Network Virtualisation mailto: paag@tid.es C/Don Ram=F3n de la Cruz,84 Tlf: +34-913 128 819 E-28006 Madrid "Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden" Georg Kreisler http://www.mendeley.com/profiles/pedro-a-aranda-gutierrez Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From tli@cisco.com Sat May 21 00:26:56 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A61E0697 for ; Sat, 21 May 2011 00:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKfmhU9WT8Sz for ; Sat, 21 May 2011 00:26:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 01412E0655 for ; Sat, 21 May 2011 00:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tli@cisco.com; l=876; q=dns/txt; s=iport; t=1305962816; x=1307172416; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=K5ja9dEluasfsv9Fj9rxbE9ortW+j9D6kWacUWUJPrw=; b=gn6eTGv9WIA/IV1KAj39XbJ6YwdLHJ4nC73Fke5x2n/JI47jWiGl9k39 9quMc63ytaFzsVDpprTwQusFYBpm7/TNuY+jeAspcyi14JXGAUd/bnVUV zFIu81kh9P1vG4IWF+6xHYT7RQ+r4QheAlVqGOHcb0ERFVqoS74ZQrEhf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOVo102Q/khLgWdsb2JhbACYI416FAEBFiYmiHCcZ51xgxSDBQSQEY53 X-IronPort-AV: E=Sophos;i="4.65,245,1304294400"; d="scan'208";a="89850048" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 May 2011 07:26:54 +0000 Received: from dhcp-10-55-95-17.cisco.com (dhcp-10-55-95-17.cisco.com [10.55.95.17]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4L7QskR019485 for ; Sat, 21 May 2011 07:26:54 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tony Li In-Reply-To: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> Date: Sat, 21 May 2011 09:26:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45581ACF-25A3-42DA-ABEE-A97948900616@cisco.com> References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> To: rrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 07:26:57 -0000 On May 8, 2011, at 7:18 PM, Tony Li wrote: > I propose the following process: we hold this discussion this month, = trying to identify relevant topics. Each topic should have a succinct = statement of its goals. At the end of the month, we poll to determine = the interest level in the various topics. Those that seem to have = critical mass are recommended to the IRTF Chair for consideration. Hi all, It's now the 21st. I'd like to call on folks who are seriously = proposing topics to produce their statements. So far, we have one. =20 Something that is analogous to the current RRG charter would be most = helpful. As some topics do seem to be gaining traction, it would also be very = helpful if each statement could include a list of researchers who would = be participating, along with their research affiliations. Thanks all, Tony From ikob@riken.jp Mon May 23 01:04:18 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C1E0720 for ; Mon, 23 May 2011 01:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.03 X-Spam-Level: ** X-Spam-Status: No, score=2.03 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jodFxthIhCef for ; Mon, 23 May 2011 01:04:17 -0700 (PDT) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by ietfa.amsl.com (Postfix) with ESMTP id A1616E06F7 for ; Mon, 23 May 2011 01:04:16 -0700 (PDT) Received: from [172.19.31.79] (unknown [134.160.184.31]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 4FD83E5CCF; Mon, 23 May 2011 17:04:12 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Katsushi Kobayashi In-Reply-To: <0BECB0C9-3D24-4676-AEF3-96252BE7C62C@tony.li> Date: Mon, 23 May 2011 17:04:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com> <001e01cc110d$2bb85710$83290530$@com> <8E6C1496-FC52-47A9-ACDD-3EAA74C3B351@riken.jp> <0BECB0C9-3D24-4676-AEF3-96252BE7C62C@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1084) Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 08:04:18 -0000 Hi, Sorry for late response and not to fit an RRG charter. I believe the host number scalability issue in HPC network are not different from DCN/DCI. HPC has a roadmap including some the number of hosts to be connected, while the requirements of future DCN/DCI is not clear. If L2 can be resolve the issues alone, it is not an IETF/IRTF issue. If we need some support for ARP/DHCP presented as SEATTLE, EtherProxy, IRTF should do. HPC network also shares with DCN/DCI in the routing on large number switches. RBridge and other link-state based L2 routing can help. However, HPC network topology should be free from "backbone", since HPC network topology and traffic have highly symmetrical. I think many people agrees with the host number scalability issue, since many research challenges are ongoing and industries may support = it. The later routing issue is only my own idea, and I cannot find any research paper discussing it other than ATM PNNI.=20 So, I don't insist that RRG should pick it. ---- Katsushi Kobayashi On 2011/05/13, at 14:13, Tony Li wrote: >=20 > On May 12, 2011, at 7:52 PM, Katsushi Kobayashi wrote: >=20 >> I am not sure whether the system will choose regular direct >> interconnection network such as 3-D torus, or irregular indirect >> network. DCN/DCI requirements clearly meet the later system. >> Even in case of direct interconnection, I believe some topology >> finding mechanism will be strongly required for optimal >> performance and for operation.=20 >=20 >=20 > Interesting. As you prepare your topic proposal, please highlight the = IP routing and addressing aspects of the research here. >=20 > Thanks, > Tony >=20 From HeinerHummel@aol.com Tue May 24 00:53:21 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09457E06D4 for ; Tue, 24 May 2011 00:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqFg8iiDjP1h for ; Tue, 24 May 2011 00:53:20 -0700 (PDT) Received: from imr-da05.mx.aol.com (imr-da05.mx.aol.com [205.188.105.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA48E0675 for ; Tue, 24 May 2011 00:53:20 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4O7rA4t025370; Tue, 24 May 2011 03:53:10 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v42.9.) id j.1014.701105a (44671); Tue, 24 May 2011 03:53:09 -0400 (EDT) Received: from magic-d20.mail.aol.com (magic-d20.mail.aol.com [172.19.155.136]) by cia-mc02.mx.aol.com (v129.10) with ESMTP id MAILCIAMC022-ae7f4ddb63e54; Tue, 24 May 2011 03:53:09 -0400 From: HeinerHummel@aol.com Message-ID: <3a298.4aec9ebe.3b0cbde5@aol.com> Date: Tue, 24 May 2011 03:53:09 EDT To: ikob@riken.jp, tony.li@tony.li MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_3a298.4aec9ebe.3b0cbde5_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 95.91.105.21 X-AOL-SENDER: HeinerHummel@aol.com Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:53:21 -0000 --part1_3a298.4aec9ebe.3b0cbde5_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 23.05.2011 10:04:24 Westeurop=E4ische Sommerzeit schrei= bt =20 ikob@riken.jp: I think many people agrees with the host number scalability issue, since many research challenges are ongoing and industries may support it. The later routing issue is only my own idea, and I cannot find any research paper discussing it other than ATM PNNI.=20 ikop, ATM PNNI did try Topology Aggregation, but it was done the wrong way. I = =20 know for sure because I was part of the PNNI working group. Heiner --part1_3a298.4aec9ebe.3b0cbde5_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <= FONT id=3Drole_document color=3D#000000 size=3D2 face=3DArial>
In einer eMail vom 23.05.2011 10:04:24 Westeurop=E4ische Sommerzeit= schreibt=20 ikob@riken.jp:
I think=20 many people agrees with the host number scalability issue,
since many= =20 research challenges are ongoing and industries may support it.
The la= ter=20 routing issue is only my own idea, and I cannot find any
research pap= er=20 discussing it other than ATM PNNI.
ikop,
ATM PNNI did try Topology Aggregation, but it was done the wrong way.= I=20 know for sure because I was part of the PNNI working group.
Heiner
--part1_3a298.4aec9ebe.3b0cbde5_boundary-- From HeinerHummel@aol.com Tue May 24 01:01:21 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F9E071F for ; Tue, 24 May 2011 01:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjVRBVlzEbE3 for ; Tue, 24 May 2011 01:01:21 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB8E071E for ; Tue, 24 May 2011 01:01:20 -0700 (PDT) Received: from imo-ma02.mx.aol.com (imo-ma02.mx.aol.com [64.12.78.137]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4O81FMp027730 for ; Tue, 24 May 2011 04:01:15 -0400 Received: from HeinerHummel@aol.com by imo-ma02.mx.aol.com (mail_out_v42.9.) id 9.cc4.760b8962 (45455) for ; Tue, 24 May 2011 04:01:12 -0400 (EDT) Received: from magic-m22.mail.aol.com (magic-m22.mail.aol.com [172.20.22.195]) by cia-mc06.mx.aol.com (v129.10) with ESMTP id MAILCIAMC061-b18f4ddb65c82eb; Tue, 24 May 2011 04:01:12 -0400 From: HeinerHummel@aol.com Message-ID: <4327.955a488.3b0cbfc8@aol.com> Date: Tue, 24 May 2011 04:01:12 EDT To: rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_4327.955a488.3b0cbfc8_boundary" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 95.91.105.21 X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:01:21 -0000 --part1_4327.955a488.3b0cbfc8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have a newbie question concerning inter-domain multipath: What happens with the TTL counter when packets are received/sent by some EBGP router at some ISP-to-ISP border? Is it re-initialized or not/never ? Heiner --part1_4327.955a488.3b0cbfc8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I have a newbie question concerning inter-domain multipath:
 
What happens with the TTL counter when packets are received/sent by= some=20 EBGP router at some ISP-to-ISP border? Is it re-initialized or not/ne= ver=20 ?
 
Heiner
--part1_4327.955a488.3b0cbfc8_boundary-- From scott.brim@gmail.com Tue May 24 04:58:05 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E14E0655 for ; Tue, 24 May 2011 04:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBVtfsrxImWV for ; Tue, 24 May 2011 04:58:04 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7818E068D for ; Tue, 24 May 2011 04:58:04 -0700 (PDT) Received: by iyj12 with SMTP id 12so7874050iyj.13 for ; Tue, 24 May 2011 04:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=0ZFkR7s4nQI8Z7imrV5jgw89Sb7clFns8v7ljCM5K1s=; b=jahzLbxwGrZjX1VK2Ncqq/EsEY1l1gMpXRx5fkWDRvEN8QOliVbH9l2Zx7L/kobBf5 +LeVLvO4kx2BP1AMyqaTaVWyyeZ4cXCP4cimRyhrxNZHb1KbF++CWCQ06fAl/Ady+Sic g47pyyeJiy1hoNh3Poc6CvdeGz1n90XPv8o0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ahGLtqQt2crBu+ICQTpNsDw69xZ+oF4bHXWt2iBIsBWAqMVuQA3bFBbu+X04EJiR+y zTlJ8XGbUgkE501AYGfLzJAf9KWDpYWlV7NJbboCDAiG8qRUJ6QI6oWmnY3dp9DvKp0g BEVX4FDr0agbRRJjwmVPeH1nJQZdNmyY98C6I= MIME-Version: 1.0 Received: by 10.42.243.8 with SMTP id lk8mr7204018icb.310.1306238284156; Tue, 24 May 2011 04:58:04 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 04:58:04 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 04:58:04 -0700 (PDT) Date: Tue, 24 May 2011 07:58:04 -0400 Message-ID: From: Scott Brim To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=90e6ba614ad2eb50ac04a4044c47 Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:58:05 -0000 --90e6ba614ad2eb50ac04a4044c47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marcelo, Hannu and all, clearly it's interesting. Would you pre-distribute routing information or have one or more mapping request phases? How do we deal with tradeoffs between state maintenance and reliability? Do you want to do this in routing or in some other signaling? Consider NUTS= S and the failed attempt at the EME RG. That has a policy based discovery phase that seems very related. Scott On May 10, 2011 5:35 AM, "marcelo bagnulo braun" wrote= : > Hi, > > What about doing some work in multi-path routing in the inter-domain? > i.e. enabling a router to use multiple paths with potential different > characteristics to forward packets across domains. > Would people find this topic interesting? > > regards, marcelo > > > > El 08/05/11 19:18, Tony Li escribi=F3: >> Hi all, >> >> It's time to start the conversation about where the RRG is headed. Towards that end, I'd like to open the floor for the discussion of topics. Any _research_ topic within the broad area of routing and addressing is appropriate. >> >> I propose the following process: we hold this discussion this month, trying to identify relevant topics. Each topic should have a succinct statement of its goals. At the end of the month, we poll to determine the interest level in the various topics. Those that seem to have critical mass are recommended to the IRTF Chair for consideration. >> >> The default answer, if no topic has critical mass, is for the RG to go o= n hiatus. >> >> Any questions or comments on the process? >> >> Any proposals of research topics? >> >> The floor is open... >> >> Tony >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >> > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg --90e6ba614ad2eb50ac04a4044c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Marcelo, Hannu and all, clearly it's interesting. Would you pre-dist= ribute routing information or have one or more mapping request phases? How = do we deal with tradeoffs between state maintenance and reliability?=A0

Do you want to do this in routing or in some other signaling? Consider N= UTSS and the failed attempt at the EME RG. That has a policy based discover= y phase that seems very related.

Scott

On May 10, 2011 5:35 AM, "marcelo bagnulo b= raun" <marc= elo@it.uc3m.es> wrote:
> Hi,
>
= > What about doing some work in multi-path routing in the inter-domain?<= br> > i.e. enabling a router to use multiple paths with potential different =
> characteristics to forward packets across domains.
> Would p= eople find this topic interesting?
>
> regards, marcelo
>
>
>
> El 08/05/11 19:18, Tony Li escribi=F3:
&= gt;> Hi all,
>>
>> It's time to start the conversa= tion about where the RRG is headed. Towards that end, I'd like to open= the floor for the discussion of topics. Any _research_ topic within the b= road area of routing and addressing is appropriate.
>>
>> I propose the following process: we hold this discussi= on this month, trying to identify relevant topics. Each topic should have = a succinct statement of its goals. At the end of the month, we poll to det= ermine the interest level in the various topics. Those that seem to have c= ritical mass are recommended to the IRTF Chair for consideration.
>>
>> The default answer, if no topic has critical mass, is = for the RG to go on hiatus.
>>
>> Any questions or commen= ts on the process?
>>
>> Any proposals of research topics= ?
>>
>> The floor is open...
>>
>> Tony
&= gt;>
>> _______________________________________________
>= > rrg mailing list
>> rrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/rrg
>>
>
&= gt; _______________________________________________
> rrg mailing lis= t
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
--90e6ba614ad2eb50ac04a4044c47-- From scott.brim@gmail.com Tue May 24 05:02:17 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB27FE073A for ; Tue, 24 May 2011 05:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ygOVhJ7q9wg for ; Tue, 24 May 2011 05:02:16 -0700 (PDT) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C6764E06C7 for ; Tue, 24 May 2011 05:02:16 -0700 (PDT) Received: by iwn33 with SMTP id 33so8602359iwn.13 for ; Tue, 24 May 2011 05:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bEzcldAtq7qpyZRGSEn2/cSGhfD0CIZkjudTo31Lqos=; b=CRM2LrFL11vLgKRPNHHuhRTG2SVXewC2J7y9LQZKfu0zZy1b852V3Jv4E5dnp9I0qa iBpHg/MKV8cEQJKe+dFVRdRN1BjL65VUfhcexSFDbXXD8ll4tjMZ3kt8/bZ0gdYKxWVp V49hTv4aH/t8DH6WSERDADBhmCIiQKMMTIpWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kMLv28vWw1BmzqMhcLIwGW23rQxrJKp1pT7J6+0FdSChx+VRIV07dLYKu/TU80RAUw B+kCeDLEcOpKo4/GBsnEsHNPFhJhjkBXKhu/eWT2FQi6ZKkreHHRS3z06Tbzyla6OlwM Uk0hCkv6ir7+2ANvWb+sktUmvyODkLPaCIHsY= MIME-Version: 1.0 Received: by 10.42.94.138 with SMTP id b10mr311079icn.511.1306238536415; Tue, 24 May 2011 05:02:16 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 05:02:16 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 05:02:16 -0700 (PDT) In-Reply-To: <4327.955a488.3b0cbfc8@aol.com> References: <4327.955a488.3b0cbfc8@aol.com> Date: Tue, 24 May 2011 08:02:16 -0400 Message-ID: From: Scott Brim To: HeinerHummel@aol.com Content-Type: multipart/alternative; boundary=20cf30363f97f479fc04a4045b6a Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 12:02:17 -0000 --20cf30363f97f479fc04a4045b6a Content-Type: text/plain; charset=ISO-8859-1 TTL is a data plane OAM mechanism, unrelated to routing. When packets are forwarded, forwarding doesn't know about domain boundaries. If TTL is needed at all, it needs to be continuous. On May 24, 2011 4:01 AM, wrote: > I have a newbie question concerning inter-domain multipath: > > What happens with the TTL counter when packets are received/sent by some > EBGP router at some ISP-to-ISP border? Is it re-initialized or not/never ? > > Heiner --20cf30363f97f479fc04a4045b6a Content-Type: text/html; charset=ISO-8859-1

TTL is a data plane OAM mechanism, unrelated to routing. When packets are forwarded, forwarding doesn't know about domain boundaries. If TTL is needed at all, it needs to be continuous.

On May 24, 2011 4:01 AM, <HeinerHummel@aol.com> wrote:
> I have a newbie question concerning inter-domain multipath:
>
> What happens with the TTL counter when packets are received/sent by some
> EBGP router at some ISP-to-ISP border? Is it re-initialized or not/never ?
>
> Heiner
--20cf30363f97f479fc04a4045b6a-- From scott.brim@gmail.com Tue May 24 05:19:35 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC3BE068D for ; Tue, 24 May 2011 05:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBAw761xUbC8 for ; Tue, 24 May 2011 05:19:35 -0700 (PDT) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB22E067C for ; Tue, 24 May 2011 05:19:35 -0700 (PDT) Received: by iwn33 with SMTP id 33so8621534iwn.13 for ; Tue, 24 May 2011 05:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uu2Ty0yyr5NLOAPF954euQjOUqcwFaJpnXKngzXAqZM=; b=MMagdZGM4KwkHRPV3icy5O2S30RANN4cqBowJZQl1kTyY6vEf+TzPyfQ0uw7Rx7Z3I N2AwUq0kQRp6oxk0d09RyWnDmz9fiSyykJ2Kkm/lc2OE/cJsJjqoA1/xCIcCHd2U7hfQ Oj9UD92ch5/KTZJbRPxxDJ3fecm8q4fba15p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hu3vrfXZnHKQsOXYAE9lBv9qjJHgDpcUKRF7wNtwnfZXXMBIF8Ihuw3s5TP5ua510R gJEGG10k3JuqaNfZDxdD4c7hWaK7OG/BnK9A0Twu4qU+fmlwoLWEUVsOJB4kqwn01z1v ESNYEBri9+ez45LAPhmHgD5YJh+sNaLklnXZ4= MIME-Version: 1.0 Received: by 10.42.243.8 with SMTP id lk8mr7228613icb.310.1306239574856; Tue, 24 May 2011 05:19:34 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 05:19:34 -0700 (PDT) Received: by 10.231.19.130 with HTTP; Tue, 24 May 2011 05:19:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2011 08:19:34 -0400 Message-ID: From: Scott Brim To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=90e6ba614ad2d9d30104a4049975 Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 12:19:35 -0000 --90e6ba614ad2d9d30104a4049975 Content-Type: text/plain; charset=ISO-8859-1 Wrt multipath routing I'm invoking the end to end argument. Routing provides information on availability of paths. How many different path possibilities will you maintain state for? The applications will always want finer granularity in describing what they want than some lower layer tool like routing will provide. --90e6ba614ad2d9d30104a4049975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Wrt multipath routing I'm invoking the end to end argument. Routing = provides information on availability of paths. How many different path poss= ibilities will you maintain state for? The applications will always want fi= ner granularity in describing what they want than some lower layer tool lik= e routing will provide.

--90e6ba614ad2d9d30104a4049975-- From jmh@joelhalpern.com Tue May 24 07:00:35 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F5DE0754 for ; Tue, 24 May 2011 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH6lwpXT+wSV for ; Tue, 24 May 2011 07:00:35 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 57558E0752 for ; Tue, 24 May 2011 07:00:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3336D4300FE; Tue, 24 May 2011 07:00:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id E138A4300FA; Tue, 24 May 2011 07:00:34 -0700 (PDT) Message-ID: <4DDBBA01.2010706@joelhalpern.com> Date: Tue, 24 May 2011 10:00:33 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: HeinerHummel@aol.com References: <3a298.4aec9ebe.3b0cbde5@aol.com> In-Reply-To: <3a298.4aec9ebe.3b0cbde5@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:00:36 -0000 Heiner, I have mostly been ignoring your over-the-top assertions about your solution and about other solutions. However, Having also been there, I would have to disagree with yoru description of PNNI topology aggregation. THere is no evidence that it is "the wrong way." That is your personal opinion. Networks of the scale that would have given evidence on the topic were never constructed. Due, frankly, to IP and MPLS being better tools with lower complexity than ATM for the overall problem space. You are welcome to your opinion about the likely correctness of what the WG adopted. But please do not confuse that opinion with verified fact (as in "know for sure.") Yours, Joel On 5/24/2011 3:53 AM, HeinerHummel@aol.com wrote: > In einer eMail vom 23.05.2011 10:04:24 Westeuropäische Sommerzeit > schreibt ikob@riken.jp: > > I think many people agrees with the host number scalability issue, > since many research challenges are ongoing and industries may > support it. > The later routing issue is only my own idea, and I cannot find any > research paper discussing it other than ATM PNNI. > > ikop, > ATM PNNI did try Topology Aggregation, but it was done the wrong way. I > know for sure because I was part of the PNNI working group. > Heiner > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From HeinerHummel@aol.com Tue May 24 10:58:30 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606CDE0791 for ; Tue, 24 May 2011 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Ua1PN2a1G4 for ; Tue, 24 May 2011 10:58:29 -0700 (PDT) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4301CE079C for ; Tue, 24 May 2011 10:58:29 -0700 (PDT) Received: from imo-da02.mx.aol.com (imo-da02.mx.aol.com [205.188.169.200]) by imr-ma05.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4OHw5p2014070; Tue, 24 May 2011 13:58:05 -0400 Received: from HeinerHummel@aol.com by imo-da02.mx.aol.com (mail_out_v42.9.) id t.e74.146cce66 (43905); Tue, 24 May 2011 13:58:00 -0400 (EDT) Received: from smtprly-de01.mx.aol.com (smtprly-de01.mx.aol.com [205.188.249.168]) by cia-dc07.mx.aol.com (v129.10) with ESMTP id MAILCIADC072-b2304ddbf1a31e7; Tue, 24 May 2011 13:58:00 -0400 Received: from webmail-m002 (webmail-m002.sim.aol.com [64.12.101.84]) by smtprly-de01.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYDE015-b2304ddbf1a31e7; Tue, 24 May 2011 13:57:56 -0400 References: <3a298.4aec9ebe.3b0cbde5@aol.com> <4DDBBA01.2010706@joelhalpern.com> To: jmh@joelhalpern.com Date: Tue, 24 May 2011 13:57:55 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: <4DDBBA01.2010706@joelhalpern.com> X-MB-Message-Source: WebUI Received: from 95.91.105.21 by webmail-m002.sysops.aol.com (64.12.101.84) with HTTP (WebMailUI); Tue, 24 May 2011 13:57:55 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDE8533E144C6D_1628_15217_webmail-m002.sysops.aol.com" X-Mailer: AOL Webmail 33708-STANDARD Message-Id: <8CDE8533E0D2844-1628-CDC1@webmail-m002.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:58:30 -0000 ----------MB_8CDE8533E144C6D_1628_15217_webmail-m002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Joel, there are several aspects that let me criticize the PNNI topology aggregat= ion based on my present knowledge: We aggregated the border-to-border physical links (based on the Aggrgation= Token which was invented by G.Swallow due to my own contribution) and not the network by skimming its topology for a view from the far. The Complex Node Representation wasn't satisfactory at all.=20 I guess those who came up with the (bad) STRETCH factor had in mind hierar= chical routing a la PNNI. =20 I pointed out several times what I called Istanbul effect. That poor prope= rty applies to PNNI for sure.=20 Related though not part of the topology aggregation is its address summari= zation: DCC, ICD, E.164. Even 3 address families. A lot of prefix building= work, which is the main part of the current and so-called scalability pro= blem. As I have demonstrated: Prefix building isn't needed at all. The really good thing about PNNI was - from my personal point of view- to= see and experience the courage to go for implementing such a hierarchy= at all. It makes me go for some better one, though. Heiner=20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Joel M. Halpern An: HeinerHummel@aol.com Cc: rrg@irtf.org Verschickt: Di., 24. Mai. 2011, 16:00 Thema: Re: [rrg] Next topic? Heiner,=20 I have mostly been ignoring your over-the-top assertions about your so= lution and about other solutions. However, Having also been there, I would= have to disagree with yoru description of PNNI topology aggregation.=20 THere is no evidence that it is "the wrong way." That is your personal op= inion.=20 Networks of the scale that would have given evidence on the topic were nev= er constructed. Due, frankly, to IP and MPLS being better tools with lowe= r complexity than ATM for the overall problem space.=20 =20 You are welcome to your opinion about the likely correctness of what the= WG adopted. But please do not confuse that opinion with verified fact (a= s in "know for sure.")=20 =20 Yours,=20 Joel=20 =20 On 5/24/2011 3:53 AM, HeinerHummel@aol.com wrote:=20 > In einer eMail vom 23.05.2011 10:04:24 Westeurop=C3=A4ische Sommerzeit= =20 > schreibt ikob@riken.jp:=20 >=20 > I think many people agrees with the host number scalability issue,= =20 > since many research challenges are ongoing and industries may=20 > support it.=20 > The later routing issue is only my own idea, and I cannot find any= =20 > research paper discussing it other than ATM PNNI.=20 >=20 > ikop,=20 > ATM PNNI did try Topology Aggregation, but it was done the wrong way. I= =20 > know for sure because I was part of the PNNI working group.=20 > Heiner=20 >=20 >=20 >=20 > _______________________________________________=20 > rrg mailing list=20 > rrg@irtf.org=20 > http://www.irtf.org/mailman/listinfo/rrg=20 =20 ----------MB_8CDE8533E144C6D_1628_15217_webmail-m002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Joel,
there are several aspects that let me criticize the PNNI topology agg= regation based on my present knowledge:

We aggregated the border-to-border physical links (based on the Aggrg= ation Token which was invented by G.Swallow due to my own contribution)
and not the network by skimming its topology for a view from the far.=
The Complex Node Representation wasn't satisfactory at all. 
I guess those who came up with the (bad) STRETCH factor had in mind= hierarchical routing a la PNNI.
 
I pointed out several times what I called Istanbul effect. That poor= property applies to PNNI for sure. 

Related though not part of the topology aggregation is its address summari= zation: DCC, ICD, E.164. Even 3 address families. A lot of prefix building= work, which is the main part of the current and so-called scalability pro= blem. As I have demonstrated: Prefix building isn't needed at all.

The really good thing about PNNI was - from my personal point of view= - to see and experience  the courage to go for implementing such a hi= erarchy at all. It makes me go for some better one, though.

Heiner 


----= -Urspr=C3=BCngliche Mitteilung-----
Von: Joel M. Halpern <jmh@joelhalpern.com>
An: HeinerHummel@aol.com
Cc: rrg@irtf.org
Verschickt: Di., 24. Mai. 2011, 16:00
Thema: Re: [rrg] Next topic?

Heiner, 
  I have mostly been ignoring your over-the-top assertions about yo= ur=20 solution and about other solutions. However, Having also been there, I=20 would have to disagree with yoru description of PNNI topology aggregation.=  
THere is no evidence that it is "the wrong way." That is your personal=20 opinion. 
Networks of the scale that would have given evidence on the topic were=20 never constructed. Due, frankly, to IP and MPLS being better tools with= =20 lower complexity than ATM for the overall problem space. 
 
You are welcome to your opinion about the likely correctness of what the= =20 WG adopted. But please do not confuse that opinion with verified fact=20 (as in "know for sure.") 
 
Yours, 
Joel 
 
On 5/24/2011 3:53 AM, HeinerHummel= @aol.com wrote: 
> In einer eMail vom 23.05.2011 10:04:24 Westeurop=C3=A4ische Sommerzei= t 
> schreibt ikob@riken.jp:  > 
> I think many people agrees with the host number scalability issue= , 
> since many research challenges are ongoing and industries may&nbs= p;
> support it. 
> The later routing issue is only my own idea, and I cannot find an= y 
> research paper discussing it other than ATM PNNI. 
> 
> ikop, 
> ATM PNNI did try Topology Aggregation, but it was done the wrong way.= I 
> know for sure because I was part of the PNNI working group. 
> Heiner 
> 
> 
> 
> _______________________________________________ 
> rrg mailing list 
> rrg@irtf.org 
> http://www.irtf.org/mailman/listinfo/rrg 
 ----------MB_8CDE8533E144C6D_1628_15217_webmail-m002.sysops.aol.com-- From HeinerHummel@aol.com Tue May 24 11:08:17 2011 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5963BE0791 for ; Tue, 24 May 2011 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-oIkej8TRaD for ; Tue, 24 May 2011 11:08:16 -0700 (PDT) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by ietfa.amsl.com (Postfix) with ESMTP id B5001E078D for ; Tue, 24 May 2011 11:08:16 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id p4OI7o8Q014050; Tue, 24 May 2011 14:07:51 -0400 Received: from HeinerHummel@aol.com by imo-ma01.mx.aol.com (mail_out_v42.9.) id o.105e.717d9c8 (43957); Tue, 24 May 2011 14:07:46 -0400 (EDT) Received: from smtprly-dc01.mx.aol.com (smtprly-dc01.mx.aol.com [205.188.170.1]) by cia-dd01.mx.aol.com (v129.10) with ESMTP id MAILCIADD016-d2e94ddbf3ee265; Tue, 24 May 2011 14:07:46 -0400 Received: from webmail-m002 (webmail-m002.sim.aol.com [64.12.101.84]) by smtprly-dc01.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYDC018-d2e94ddbf3ee265; Tue, 24 May 2011 14:07:42 -0400 References: <4327.955a488.3b0cbfc8@aol.com> To: scott.brim@gmail.com Date: Tue, 24 May 2011 14:07:42 -0400 X-AOL-IP: 95.91.105.21 In-Reply-To: X-MB-Message-Source: WebUI Received: from 95.91.105.21 by webmail-m002.sysops.aol.com (64.12.101.84) with HTTP (WebMailUI); Tue, 24 May 2011 14:07:42 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CDE8549C263B9D_1628_15716_webmail-m002.sysops.aol.com" X-Mailer: AOL Webmail 33708-STANDARD Message-Id: <8CDE8549C1A54AE-1628-D0C7@webmail-m002.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Cc: rrg@irtf.org Subject: Re: [rrg] Next topic? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 18:08:17 -0000 ----------MB_8CDE8549C263B9D_1628_15716_webmail-m002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thank you, Scott. I was not sure whether the TTL is re-initiated at the IS= P boundaries or not. Good so, that there is no such re-initialization. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Scott Brim An: HeinerHummel@aol.com Cc: rrg@irtf.org Verschickt: Di., 24. Mai. 2011, 14:02 Thema: Re: [rrg] Next topic? TTL is a data plane OAM mechanism, unrelated to routing. When packets are= forwarded, forwarding doesn't know about domain boundaries. If TTL is nee= ded at all, it needs to be continuous.=20 On May 24, 2011 4:01 AM, wrote: > I have a newbie question concerning inter-domain multipath: > =20 > What happens with the TTL counter when packets are received/sent by some= =20 > EBGP router at some ISP-to-ISP border? Is it re-initialized or not/never= ? > =20 > Heiner =20 ----------MB_8CDE8549C263B9D_1628_15716_webmail-m002.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Thank you, Scott. I was no= t sure whether the TTL is re-initiated at the ISP boundaries or not. Good= so,  that there is no such re-initialization.
Heiner




----= -Urspr=C3=BCngliche Mitteilung-----
Von: Scott Brim <scott.brim@gmail.com>
An: HeinerHummel@aol.com
Cc: rrg@irtf.org
Verschickt: Di., 24. Mai. 2011, 14:02
Thema: Re: [rrg] Next topic?

TTL is a data plane OAM mechanism, unrelated to routing. When packets= are forwarded, forwarding doesn't know about domain boundaries. If TTL is= needed at all, it needs to be continuous.
On May 24, 2011 4:01 AM, <HeinerHummel@aol.com> wrote:
> I have a newbie question concerning inter-domain multipath:<= br> >
> What happens with the TTL counter when packets are received/sent by= some
> EBGP router at some ISP-to-ISP border? Is it re-initialized or not/ne= ver ?
>
> Heiner
 ----------MB_8CDE8549C263B9D_1628_15716_webmail-m002.sysops.aol.com--