From tony.li@tony.li Thu Apr 2 17:14:17 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16913A691C for ; Thu, 2 Apr 2009 17:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R467LLOAcNzZ for ; Thu, 2 Apr 2009 17:14:16 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 0B9223A68D1 for ; Thu, 2 Apr 2009 17:14:15 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id abG01b0031GXsucABoFJ7k; Fri, 03 Apr 2009 00:15:18 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id aoFB1b0083L8a8Q8ToFJhy; Fri, 03 Apr 2009 00:15:18 +0000 Message-ID: <49D5144C.7020904@tony.li> Date: Thu, 02 Apr 2009 12:38:52 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:14:17 -0000 Hi all, Thank you all for the highly spirited debate and my apologies for being unable to contribute. Other high priority matters have been in the foreground. I've read the entire debate so far and am struck by the fact that we made a change in the 2nd pass and early in the thread and I don't think everyone picked up on the importance of the distinction. Specifically, it's vital to understand that a locator and identifier have semantics that are only relevant at a particular layer. Furthermore, talking about identifiers and locators in absolute terms is not constructive; they are necessarily relative terms. Remember that both identifiers and locators start off as simply tokens. Names that we assign to things. We assign them semantic values that happen to matter at a particular layer. When regarded outside of that layer, those names then are simply opaque. For a better example, let's stop arguing about Ethernet. We have to operate with many link layers and our terminology must reasonably apply to all of them. Let's look at what happens with IP over X.25. An X.25 address is a long string of bits and within the X.25 network, if administered in a sane fashion, the address is hierarchically assigned and nicely structured. However, from the perspective of layer 3, it is wholly opaque. Just a token, nothing more. It has no semantics _at layer 3_. Similarly, from the perspective of layer 2, the IP address is neither locator nor identifier. It's just payload bits. The key point here is that the semantics of a namespace is only relative to the layer where it is applicable. The rest of the time, it's just opaque bits. As another example, let's look at the FQDN. At the application layer, it's clear that it's a practical identifier. We map it through DNS to get an IP address that gives us a network layer identifier and locator. However, at the network layer, the FQDN itself is nothing but a string. So, it's all relative. Putting this all together, here's pass 3. Again, if I missed something or have misunderstood, please feel free to bring it up. The goal here is to reach rough consensus on these definitions and we're definitely close. Regards, Tony --------------------------------------------------------------------------- locator A locator is a name that has topological sensitivity at a given layer and changes if the point of attachment at that layer changes. By default, a locator refers to layer 3. It is also possible to have locators at other layers. Locators may have other properties, such as their scope (local or global (default)) and their lifetime (ephemeral or permanent (default)). identifier An identifier is the name of an object at a given layer; identifiers have no topological sensitivity, and do not have to change, even if the object changes its point(s) of attachment within the network topology. Identifiers may have other properties, such as the scope of their uniqueness (local or global (default)), the probability of their uniqueness (statistical or absolute (default)), and their lifetime (ephemeral or permanent (default)). address An address is a name that is used as both an interface locator and an endpoint identifier. From brian.e.carpenter@gmail.com Thu Apr 2 18:55:38 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C3B3A6C5A for ; Thu, 2 Apr 2009 18:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXuz+PGDMI1d for ; Thu, 2 Apr 2009 18:55:37 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 4D1EE3A6C30 for ; Thu, 2 Apr 2009 18:55:37 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l24so442118waf.23 for ; Thu, 02 Apr 2009 18:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Cv/X6bKHcWwK54UZPCiqrzL5T9Od9Gsis5ahX7gijXg=; b=HTYuQOQKOJBiAmKC/SqMpmxMh75XTiEPsFsFLGDry7v4XVBjhHDpfRoAQ1WPqn9sUb CS8o/pboV8GT8XXR5RUtfW8UFK6YsXuQxg5h0mPsgzMQBs17mXwB75pRJ+8BISYL4LZs eI62ImHD2wbL7/e8bvV7QelZ2HOFZQXc+kAlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GgtcRDR50IHpHuKk+uxpErnlh0a0Nncmv+Rpk3LRTFI/LhGZ/PQ3LyulVbJwQgxIyk fIh8sknM2ZoqVBbYS7VbNe/ituePHYz7Ljmmv6r+2pxpCDnkpLJrWbvFs//aXNVi/CD+ ApHfXUmKQAZtfZQ7dRZTdZ1zfYdYT0ITM6Em0= Received: by 10.114.125.18 with SMTP id x18mr293752wac.220.1238723799290; Thu, 02 Apr 2009 18:56:39 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n40sm1695134wag.48.2009.04.02.18.56.37 (version=SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 18:56:38 -0700 (PDT) Message-ID: <49D56D04.9020604@gmail.com> Date: Fri, 03 Apr 2009 14:57:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Scott Brim , rrg@irtf.org References: <20090330162718.2385F6BE5E7@mercury.lcs.mit.edu> <20090330165932.GC40388@cisco.com> In-Reply-To: <20090330165932.GC40388@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [rrg] Non-Groundhog Day Moment [Re: Terminology, 2nd pass] X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 01:55:38 -0000 On 2009-03-31 05:59, Scott Brim wrote: > Excerpts from Dino Farinacci on Mon, Mar 30, 2009 09:31:25AM -0700: >> I think we need to keep all this terminology stuff simple. And not >> have too many terms. What comes out of this group will pro-market or >> negative-market locator/ID separation. And you don't want people to >> react "this locator/ID separation stuff is more trouble then it is >> worth". > > For me it's about the meaning of 'locator/identifier separation', and > mainly in endpoints. The essential point is to get identification > functions to stop using data that might have to change when topology > changes. Thankyou! This is a great insight. I think we're seeing that all these addressy-locatory-identifiery labels are a bit slippery and can change their nature according to context and usage. But the function that's using them needs to use the most stable label that has the correct semantics for the specific use. And if it fails, it's always necessary to go up a level and try again. In primitive terms, in today's world: if a MAC address fails, ARP again if an IP address fails, DNS again if an FQDN fails, Google again ;-) In an ID/LOC split world: if a MAC address fails, ARP again if an IP-locator fails, map again if an IP-identifier fails, DNS again if an FQDN fails, Google again ;-) Brian From dow.street@linquest.com Thu Apr 2 19:42:43 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95ED28C279 for ; Thu, 2 Apr 2009 19:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5beSV5PVsdlY for ; Thu, 2 Apr 2009 19:42:42 -0700 (PDT) Received: from smtp175.sat.emailsrvr.com (smtp175.sat.emailsrvr.com [66.216.121.175]) by core3.amsl.com (Postfix) with ESMTP id 21DF728C280 for ; Thu, 2 Apr 2009 19:42:42 -0700 (PDT) Received: from relay27.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay27.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 551891B403A; Thu, 2 Apr 2009 22:43:43 -0400 (EDT) Received: by relay27.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id F096F1B401F; Thu, 2 Apr 2009 22:43:42 -0400 (EDT) Message-Id: <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> From: Dow Street To: Tony Li In-Reply-To: <49D5144C.7020904@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 19:43:41 -0700 References: <49D5144C.7020904@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 02:42:43 -0000 On Apr 2, 2009, at 12:38 PM, Tony Li wrote: > > Hi all, > > Thank you all for the highly spirited debate and my apologies for > being unable to contribute. Other high priority matters have been > in the foreground. > > I've read the entire debate so far and am struck by the fact that we > made a change in the 2nd pass and early in the thread and I don't > think everyone picked up on the importance of the distinction. > Specifically, it's vital to understand that a locator and identifier > have semantics that are only relevant at a particular layer. > Furthermore, talking about identifiers and locators in absolute > terms is not constructive; they are necessarily relative terms. Agree the definitions are relative. I don't think "layer" alone is quite the right way to frame scope, though it is one way to frame it. > Remember that both identifiers and locators start off as simply > tokens. Names that we assign to things. We assign them semantic > values that happen to matter at a particular layer. When regarded > outside of that layer, those names then are simply opaque. Mostly agree - I would say outside of a particular scope, where being of a different "layer" is an example. > For a better example, let's stop arguing about Ethernet. We have to > operate with many link layers and our terminology must reasonably > apply to all of them. Let's look at what happens with IP over X. > 25. An X.25 address is a long string of bits and within the X.25 > network, if administered in a sane fashion, the address is > hierarchically assigned and nicely structured. However, from the > perspective of layer 3, it is wholly opaque. Just a token, nothing > more. It has no semantics _at layer 3_. Similarly, from the > perspective of layer 2, the IP address is neither locator nor > identifier. It's just payload bits. I think some of us want these definitions to make sense in a general and consistent manner across the various parts of the overall architecture. Agree that if we call certain things out of bounds for this discussion, and that may make it easier. > The key point here is that the semantics of a namespace is only > relative to the layer where it is applicable. The rest of the time, > it's just opaque bits. Mostly agree - same note as above. > As another example, let's look at the FQDN. At the application > layer, it's clear that it's a practical identifier. We map it > through DNS to get an IP address that gives us a network layer > identifier and locator. However, at the network layer, the FQDN > itself is nothing but a string. > > So, it's all relative. > > Putting this all together, here's pass 3. Again, if I missed > something or have misunderstood, please feel free to bring it up. > The goal here is to reach rough consensus on these definitions and > we're definitely close. > > Regards, > Tony > > --------------------------------------------------------------------------- > > locator A locator is a name that has topological sensitivity at a > given layer and changes if the point of attachment at that > layer changes. By default, a locator refers to layer 3. > It is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). It is this "point of attachment at that layer" phrase that is still problematic. If a host disconnects from one place on an ethernet segment and connects to another, it can still be reachable without changing it's IP address. Are you defining this as not changing the point of attachment (in terms of layer 3)? Also, to say that that a locator changes when the point of attachment changes depends on the nature of the routing system. The locator could stay the same, and there could be a change to the routing state instead. So there are some "relative topological scope" types of considerations in "this locator-ness" check, but the definition above does not capture those. R, Dow From tony.li@tony.li Fri Apr 3 00:54:51 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D433A688B for ; Fri, 3 Apr 2009 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSEUpgp8JaX7 for ; Fri, 3 Apr 2009 00:54:50 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id A5B2B3A65A6 for ; Fri, 3 Apr 2009 00:54:50 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id avv61b0010vp7WLA2vvtus; Fri, 03 Apr 2009 07:55:53 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id avvs1b0093L8a8Q8Rvvtg4; Fri, 03 Apr 2009 07:55:53 +0000 Message-ID: <49D5C0D8.8050204@tony.li> Date: Fri, 03 Apr 2009 00:55:04 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> In-Reply-To: <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 07:54:51 -0000 Hi Dow, >> locator A locator is a name that has topological sensitivity at a >> given layer and changes if the point of attachment at that >> layer changes. By default, a locator refers to layer 3. >> It is also possible to have locators at other layers. >> Locators may have other properties, such as their scope >> (local or global (default)) and their lifetime (ephemeral >> or permanent (default)). > > It is this "point of attachment at that layer" phrase that is still > problematic. If a host disconnects from one place on an ethernet > segment and connects to another, it can still be reachable without > changing it's IP address. Are you defining this as not changing the > point of attachment (in terms of layer 3)? _Exactly_. If you change ports on your local Ethernet switch, then you've only changed the L2 topology, and done nothing at all at layer 3. > Also, to say that that a locator changes when the point of attachment > changes depends on the nature of the routing system. The locator could > stay the same, and there could be a change to the routing state > instead. So there are some "relative topological scope" types of > considerations in "this locator-ness" check, but the definition above > does not capture those. I'd claim that by definition, that token then isn't a locator. It sounds again like a forwarding system that's doing flat routing on an identifier. I think that this is mostly a matter of semantics. Since our concern is scalability, I don't think that flat routing is really all that interesting of a case anyway. Tony From luigi@net.t-labs.tu-berlin.de Fri Apr 3 00:55:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27163A68DB for ; Fri, 3 Apr 2009 00:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX5LgpOfaBIt for ; Fri, 3 Apr 2009 00:55:44 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id D7EDC3A65A6 for ; Fri, 3 Apr 2009 00:55:43 -0700 (PDT) Received: from dyn109.net.t-labs.tu-berlin.de (dyn109.net.t-labs.tu-berlin.de [130.149.220.109]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 39EB7700D6F9; Fri, 3 Apr 2009 09:56:45 +0200 (CEST) Message-Id: <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Tony Li In-Reply-To: <49D5144C.7020904@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 09:56:44 +0200 References: <49D5144C.7020904@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 07:55:44 -0000 Hi, I am pretty happy with the definition of locator and identifier, yet.. On Apr 2, 2009, at 21:38 , Tony Li wrote: > > address An address is a name that is used as both an interface > locator and an endpoint identifier. > May be I missed something, but what is an "interface locator"? Wouldn't be better to simplify the definition? We have defined what an "identifier" is and what a "locator" is, so IMHO an address is just a name that can be used as locator or identifier. Luigi > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Fri Apr 3 01:06:56 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2D03A6941 for ; Fri, 3 Apr 2009 01:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX1Q7dyMKlwW for ; Fri, 3 Apr 2009 01:06:55 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id BF0E53A65A6 for ; Fri, 3 Apr 2009 01:06:55 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id aw7j1b0031GXsucABw7zEs; Fri, 03 Apr 2009 08:07:59 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id aw7x1b00A3L8a8Q8Tw7yQP; Fri, 03 Apr 2009 08:07:58 +0000 Message-ID: <49D5C3AC.7080502@tony.li> Date: Fri, 03 Apr 2009 01:07:08 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Iannone References: <49D5144C.7020904@tony.li> <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> In-Reply-To: <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 08:06:56 -0000 Hi Luigi, Luigi Iannone wrote: >> address An address is a name that is used as both an interface >> locator and an endpoint identifier. > > May be I missed something, but what is an "interface locator"? Just what it sounds like: a locator for a specific interface. This would be distinct from, for example, a system locator, endpoint locator, or stack locator. See the discussion that I had with Noel, as he's the one who proposed this. Tony From luigi@net.t-labs.tu-berlin.de Fri Apr 3 01:37:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1D43A68E3 for ; Fri, 3 Apr 2009 01:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX8fqJyYnA32 for ; Fri, 3 Apr 2009 01:37:16 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 2583F3A6859 for ; Fri, 3 Apr 2009 01:37:16 -0700 (PDT) Received: from dyn109.net.t-labs.tu-berlin.de (dyn109.net.t-labs.tu-berlin.de [130.149.220.109]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id C0FB6700D6F9; Fri, 3 Apr 2009 10:38:17 +0200 (CEST) Message-Id: <3B0D710F-4931-43B6-983A-C1A30AB3E471@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Tony Li In-Reply-To: <49D5C3AC.7080502@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 10:38:17 +0200 References: <49D5144C.7020904@tony.li> <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> <49D5C3AC.7080502@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 08:37:17 -0000 On Apr 3, 2009, at 10:07 , Tony Li wrote: > > Hi Luigi, > > Luigi Iannone wrote: >>> address An address is a name that is used as both an interface >>> locator and an endpoint identifier. >> May be I missed something, but what is an "interface locator"? > > > Just what it sounds like: a locator for a specific interface. This > would be distinct from, for example, a system locator, endpoint > locator, or stack locator. > IMHO sounds a bit strange that we define identifiers and locators and then we use the latter to locate interfaces.... I was thinking that a "locator" locates "identifier", if an identifier is associated to an interface, then it is correct, but I feel that somehow current definition introduces a constrain. > See the discussion that I had with Noel, as he's the one who > proposed this. Thanks, I will get a closer look to that discussion. Luigi > > > Tony > > From xleonzhao@gmail.com Fri Apr 3 07:22:43 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC263A6E28 for ; Fri, 3 Apr 2009 07:22:43 -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_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnDfdYRCe8Vp for ; Fri, 3 Apr 2009 07:22:42 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id B6CDD3A68FF for ; Fri, 3 Apr 2009 07:22:42 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so860173qwb.7 for ; Fri, 03 Apr 2009 07:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VFKi8HUzbRTsw8NLFrYW5ltNOpH26m2QCbGI9iWx4AY=; b=eUPneDLb0tfngc1tkLritr1Xb0/HDg3+2mO1xPaU3WiIkBtVCn7qBHIto1udvsVGJg JvKKB2ZYc8TtLeYUpY2NH7a4BW2uAgO6oJPE3Ow5DzypsWZAOj1TWDlwRgVvqe1TJHHm 0XiC4OxqqQjSqIFM3bDw55h/lWhSxA6t1lx/w= 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=gdp+9YajQgvthJjBuC5IpEdtRH3DULLfcmdy0qSQ1kJnfv7SZ2kqYrrtQcyE8H4A8j pPbKHxnC7etKhYVsRHg0mgMoyY5XliVO5sEXijyNyFAQFQIFP31gx7zKO58YGsA6vaX/ a6evyCIjMZUZ8lyOaKybhq48T4/LRTlz3N6XA= MIME-Version: 1.0 Received: by 10.224.67.4 with SMTP id p4mr1393066qai.266.1238768625081; Fri, 03 Apr 2009 07:23:45 -0700 (PDT) In-Reply-To: <49D5C3AC.7080502@tony.li> References: <49D5144C.7020904@tony.li> <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> <49D5C3AC.7080502@tony.li> Date: Fri, 3 Apr 2009 10:23:45 -0400 Message-ID: <4e913c5d0904030723r461f812fj8112145c92b0e5ae@mail.gmail.com> From: Xiaoliang Zhao To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:22:43 -0000 Hi All, Given historically "address" refers to both locator and identifier, which may cause some confusion in this new context. How about call "address" as "a binary implementation of a locator or an identifier"? thanks, x.zhao On Fri, Apr 3, 2009 at 4:07 AM, Tony Li wrote: > > Hi Luigi, > > Luigi Iannone wrote: >>> >>> address =A0 =A0An address is a name that is used as both an interface >>> =A0 =A0 =A0 locator and an endpoint identifier. >> >> May be I missed something, but what is an "interface locator"? > > > Just what it sounds like: a locator for a specific interface. =A0This wou= ld be > distinct from, for example, a system locator, endpoint locator, =A0or sta= ck > locator. > > See the discussion that I had with Noel, as he's the one who proposed thi= s. > > Tony > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From swb@employees.org Fri Apr 3 08:21:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172863A6987 for ; Fri, 3 Apr 2009 08:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoMPr3sMhpxI for ; Fri, 3 Apr 2009 08:21:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1266B28C140 for ; Fri, 3 Apr 2009 08:21:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="40886426" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2009 15:22:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n33FM4e5019926; Fri, 3 Apr 2009 11:22:04 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33FM3lY023386; Fri, 3 Apr 2009 15:22:04 GMT Date: Fri, 3 Apr 2009 11:21:55 -0400 From: Scott Brim To: Tony Li Message-ID: <20090403152155.GA83404@cisco.com> Mail-Followup-To: Scott Brim , Tony Li , rrg@irtf.org References: <49D5144C.7020904@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D5144C.7020904@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:21:03 -0000 Excerpts from Tony Li on Thu, Apr 02, 2009 12:38:52PM -0700: > The key point here is that the semantics of a namespace is only > relative to the layer where it is applicable. The rest of the > time, it's just opaque bits. Yes and also, even within the scope of a namespace a particular name might not be usable at a particular time or place, and it will be "just opaque bits" there. > Putting this all together, here's pass 3. Again, if I missed > something or have misunderstood, please feel free to bring it up. > The goal here is to reach rough consensus on these definitions and > we're definitely close. > --------------------------------------------------------------------------- > > locator A locator is a name that has topological sensitivity at a > given layer and changes if the point of attachment at that > layer changes. I see how "at that layer" neatly takes care of the "might not change" problem. Now that we have the ideas worked out, this first sentence could actually be reduced to A locator names a point of attachment at a given layer. "names a point of attachment" implies that the name changes if the point of attachment changes, and that in turn implies that the name is topology-sensitive. We could make those statements explicit but we don't need to. If we make them explicit, "topological sensitivity" needs tightening up. A locator itself is not topologically-sensitive. It does not change. Rather, an endpoint's association with a point of attachment changes, so the association between the endpoint and point of attachment name ("locator") changes. A locator does not have topological sensitivity, the endpoint+locator association is. So I wouldn't mind keeping things explicit but I suggest something like: A locator names a point of attachment at a given layer. If an endpoint changes its points of attachment at that layer, associations between the endpoint and locators will change. > By default, a locator refers to layer 3. > It is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). Good > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. Identifiers may > have other properties, such as the scope of their > uniqueness (local or global (default)), the probability of > their uniqueness (statistical or absolute (default)), and > their lifetime (ephemeral or permanent (default)). Good > address An address is a name that is used as both an interface > locator and an endpoint identifier. Hmm ... this brings in "interface" and "endpoint". I suggest: An address is a name that is used both as an IP-layer locator and an IP-layer endpoint identifier. From swb@employees.org Fri Apr 3 08:25:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3A928C284 for ; Fri, 3 Apr 2009 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CoNVzQ0mwjh for ; Fri, 3 Apr 2009 08:25:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 419D928C274 for ; Fri, 3 Apr 2009 08:25:26 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2009 15:26:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33FQOHI019292; Fri, 3 Apr 2009 11:26:24 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n33FQNM2025646; Fri, 3 Apr 2009 15:26:24 GMT Date: Fri, 3 Apr 2009 11:26:22 -0400 From: Scott Brim To: Brian E Carpenter Message-ID: <20090403152622.GA82453@cisco.com> Mail-Followup-To: Scott Brim , Brian E Carpenter , rrg@irtf.org References: <20090330162718.2385F6BE5E7@mercury.lcs.mit.edu> <20090330165932.GC40388@cisco.com> <49D56D04.9020604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D56D04.9020604@gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Non-Groundhog Day Moment [Re: Terminology, 2nd pass] X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:25:34 -0000 Excerpts from Brian E Carpenter on Fri, Apr 03, 2009 02:57:24PM +1300: > On 2009-03-31 05:59, Scott Brim wrote: > > > Excerpts from Dino Farinacci on Mon, Mar 30, 2009 09:31:25AM -0700: > >> I think we need to keep all this terminology stuff simple. And not > >> have too many terms. What comes out of this group will pro-market or > >> negative-market locator/ID separation. And you don't want people to > >> react "this locator/ID separation stuff is more trouble then it is > >> worth". > > > > For me it's about the meaning of 'locator/identifier separation', and > > mainly in endpoints. The essential point is to get identification > > functions to stop using data that might have to change when topology > > changes. > > Thankyou! This is a great insight. I think we're seeing that all > these addressy-locatory-identifiery labels are a bit slippery and > can change their nature according to context and usage. But the function > that's using them needs to use the most stable label that has the correct > semantics for the specific use. And if it fails, it's always necessary to > go up a level and try again. > > In primitive terms, in today's world: > > if a MAC address fails, ARP again > if an IP address fails, DNS again > if an FQDN fails, Google again ;-) > > In an ID/LOC split world: > > if a MAC address fails, ARP again > if an IP-locator fails, map again > if an IP-identifier fails, DNS again > if an FQDN fails, Google again ;-) > > Brian All true. And if I need to give you a referral, I might include the chain of fallbacks I would take if the "primary" name I give you doesn't work. From luigi@net.t-labs.tu-berlin.de Fri Apr 3 08:33:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A483A683F for ; Fri, 3 Apr 2009 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuvfR5NU8U3Q for ; Fri, 3 Apr 2009 08:33:12 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 726A13A67BD for ; Fri, 3 Apr 2009 08:32:50 -0700 (PDT) Received: from dyn109.net.t-labs.tu-berlin.de (dyn109.net.t-labs.tu-berlin.de [130.149.220.109]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 886CC700DBBA; Fri, 3 Apr 2009 17:33:52 +0200 (CEST) Message-Id: From: Luigi Iannone To: Scott Brim In-Reply-To: <20090403152155.GA83404@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 17:33:51 +0200 References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:33:13 -0000 On Apr 3, 2009, at 17:21 , Scott Brim wrote: > > >> address An address is a name that is used as both an interface >> locator and an endpoint identifier. > > Hmm ... this brings in "interface" and "endpoint". I suggest: > > An address is a name that is used both as an IP-layer locator and an > IP-layer endpoint identifier. Sounds much better to me. Luigi > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From HeinerHummel@aol.com Fri Apr 3 09:42:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5BB3A6C34 for ; Fri, 3 Apr 2009 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.513 X-Spam-Level: * X-Spam-Status: No, score=1.513 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Olct5vY2tVEg for ; Fri, 3 Apr 2009 09:42:03 -0700 (PDT) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by core3.amsl.com (Postfix) with ESMTP id DBA6D3A6A07 for ; Fri, 3 Apr 2009 09:42:02 -0700 (PDT) Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v39.1.) id e.d38.46d71640 (39954); Fri, 3 Apr 2009 12:42:53 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 3 Apr 2009 12:42:53 EDT To: luigi@net.t-labs.tu-berlin.de, swb@employees.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1238776973" X-Mailer: 9.0 SE for Windows sub 5021 Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:42:03 -0000 -------------------------------1238776973 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 location may follow addressing. Addressing may follow location. Choose one. =20 Heiner =20 =20 =20 In einer eMail vom 03.04.2009 17:34:34 Westeurop=E4ische Normalzeit schreibt= =20 luigi@net.t-labs.tu-berlin.de: On Apr 3, 2009, at 17:21 , Scott Brim wrote: > > >> address An address is a name that is used as both an interface >> locator and an endpoint identifier. > > Hmm ... this brings in "interface" and "endpoint". I suggest: > > An address is a name that is used both as an IP-layer locator and an > IP-layer endpoint identifier. Sounds much better to me. Luigi > _______________________________________________ > 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 -------------------------------1238776973 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
location may follow addressing. Addressing may follow location. Choose=20 one.
 
Heiner
 
 
 
In einer eMail vom 03.04.2009 17:34:34 Westeurop=E4ische Normalzeit sch= reibt=20 luigi@net.t-labs.tu-berlin.de:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Apr=20 3, 2009, at 17:21 , Scott Brim wrote:

>
>
>>=20 address    An address is a name that is used as both an=20 interface
>>        locator and an endpoint=20 identifier.
>
> Hmm ... this brings in "interface" and=20 "endpoint".  I suggest:
>
>  An address is a name th= at=20 is used both as an IP-layer locator and an
>  IP-layer endpoint= =20 identifier.

Sounds much better to me.

Luigi



&= gt;=20 _______________________________________________
> rrg mailing=20 list
> rrg@irtf.org
>=20 http://www.irtf.org/mailman/listinfo/rrg

__________________________= _____________________
rrg=20 mailing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1238776973-- From wherrin@gmail.com Fri Apr 3 10:04:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F8728C118 for ; Fri, 3 Apr 2009 10:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ylRJtJxF+R8 for ; Fri, 3 Apr 2009 10:04:17 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 9B80828C17A for ; Fri, 3 Apr 2009 10:03:24 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so827105yxj.37 for ; Fri, 03 Apr 2009 10:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=UTT/r+ySY9UOlV2Z88UoZ/7iXxqgb6YgBYeeJKr6KSY=; b=PxpiUTkwEhiE/bVyif4YBm4rMft3J/AZfS+Snz1sION4ldMmWo/LabcAb2eJle27cz HQLNvp5EqoC4eYpv8VPQPaWt3h20fOl1If//arEeiaQY0fPIvIFbCMfNMFMuakRmoA2G RHe64rglK4ksWLouopdSbb85Uq9zilDGbiGUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=pZ+71ov0JfqdYaOvccxH3TPaZiexGbDuT52MEHxaFr6hdVwUpTurfWG7LvMxOdI0sB TqEFaq7oi2EJkkFM+VokFRG5+5c3HElgdOY6KgFqyahtRt9hG6Eo2DElozkmfSLkk76a G4xqATQNTqO1dAfYDPZYpUrTWP6KuFlR3Ua8A= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.133.1 with SMTP id g1mr3233014and.46.1238778266903; Fri, 03 Apr 2009 10:04:26 -0700 (PDT) In-Reply-To: <20090403152155.GA83404@cisco.com> References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> Date: Fri, 3 Apr 2009 13:04:26 -0400 X-Google-Sender-Auth: fe5f0486ec3c02a4 Message-ID: <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> From: William Herrin To: Scott Brim , rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:04:18 -0000 On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim wrote: > =A0A locator names a point of attachment at a given layer. =A0If an > =A0endpoint changes its points of attachment at that layer, > =A0associations between the endpoint and locators will change. Hi Scott, I like this a lot better. It's still missing something though. LISP's LOC is definately a kind of locator but it doesn't change when I move one of my servers from one internal LAN to another internal LAN and assign it an address from a different subnet. I've changed my layer-3 attachment but the locator, which is also layer-3, doesn't change. Maybe something more like: A locator names a point of attachment within the scope of the network topology for which the locator is used. If an endpoint changes its points of attachment within that scope, associations between the endpoint and locators will change. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dow.street@linquest.com Fri Apr 3 10:50:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3693A68A3 for ; Fri, 3 Apr 2009 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf+hC277U0T6 for ; Fri, 3 Apr 2009 10:50:39 -0700 (PDT) Received: from smtp135.sat.emailsrvr.com (smtp135.sat.emailsrvr.com [66.216.121.135]) by core3.amsl.com (Postfix) with ESMTP id 5029F3A686D for ; Fri, 3 Apr 2009 10:50:39 -0700 (PDT) Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 95325C7F8C; Fri, 3 Apr 2009 13:51:41 -0400 (EDT) Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 4641ECC10C; Fri, 3 Apr 2009 13:51:41 -0400 (EDT) Message-Id: From: Dow Street To: Tony Li In-Reply-To: <49D5C0D8.8050204@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 10:51:40 -0700 References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> <49D5C0D8.8050204@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:50:40 -0000 On Apr 3, 2009, at 12:55 AM, Tony Li wrote: > > Hi Dow, > >>> locator A locator is a name that has topological sensitivity at a >>> given layer and changes if the point of attachment at that >>> layer changes. By default, a locator refers to layer 3. >>> It is also possible to have locators at other layers. >>> Locators may have other properties, such as their scope >>> (local or global (default)) and their lifetime (ephemeral >>> or permanent (default)). >> It is this "point of attachment at that layer" phrase that is still >> problematic. If a host disconnects from one place on an ethernet >> segment and connects to another, it can still be reachable without >> changing it's IP address. Are you defining this as not changing >> the point of attachment (in terms of layer 3)? > > > _Exactly_. If you change ports on your local Ethernet switch, then > you've only changed the L2 topology, and done nothing at all at > layer 3. I am ok defining things this way. To ensure we're on the same page, this means that only the network part of an IP address (from the perspective of the host) can ever be considered a locator, right? Also, since the mask that is in effect (for forwarding) at various points in the topology differs, then the part of the IP address that we can call a locator also differs at various points in the topology. > >> Also, to say that that a locator changes when the point of >> attachment changes depends on the nature of the routing system. >> The locator could stay the same, and there could be a change to the >> routing state instead. So there are some "relative topological >> scope" types of considerations in "this locator-ness" check, but >> the definition above does not capture those. > > > I'd claim that by definition, that token then isn't a locator. It > sounds again like a forwarding system that's doing flat routing on > an identifier. I think I agree - this is related to the comment above. > I think that this is mostly a matter of semantics. Since our > concern is scalability, I don't think that flat routing is really > all that interesting of a case anyway. I am trying to get at this property of "relative flatness" of various names and/or parts of the IP address at different points of the topology, even if we are only talking about familiar, aggregation based approaches to scalability. In other words, if we say that: (a) on an ethernet segment (that maps to only a single prefix in the IP routing system), only the network part of the IP address of connected hosts is considered to be a (L3?) locator, then (b) a similar property exists closer to the "middle" of the topology/ routing system if aggregation is used. In (b), more specific prefixes "hidden behind" the aggregate are topologically flat from the perspective of processes that are only aware of the less-specific, aggregate mask. I think maybe you are accounting for all of this relative-ness with the phrase "attachment point at that layer"? R, Dow From swb@employees.org Fri Apr 3 11:03:22 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED01C3A6452 for ; Fri, 3 Apr 2009 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaX40lxHJuLV for ; Fri, 3 Apr 2009 11:03:22 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 240613A6811 for ; Fri, 3 Apr 2009 11:03:22 -0700 (PDT) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 18:04:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33I4Ovr030168; Fri, 3 Apr 2009 14:04:24 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33I4OAL017827; Fri, 3 Apr 2009 18:04:24 GMT Date: Fri, 3 Apr 2009 14:04:22 -0400 From: Scott Brim To: William Herrin Message-ID: <20090403180422.GA88072@cisco.com> Mail-Followup-To: Scott Brim , William Herrin , rrg@irtf.org References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:03:23 -0000 Excerpts from William Herrin on Fri, Apr 03, 2009 01:04:26PM -0400: > On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim > wrote: > >  A locator names a point of attachment at a given layer.  If an > >  endpoint changes its points of attachment at that layer, > >  associations between the endpoint and locators will change. > > Hi Scott, > > I like this a lot better. > > It's still missing something though. LISP's LOC is definately a kind > of locator but it doesn't change when I move one of my servers from > one internal LAN to another internal LAN and assign it an address > from a different subnet. I've changed my layer-3 attachment but the > locator, which is also layer-3, doesn't change. > > Maybe something more like: > > A locator names a point of attachment within the scope of the > network topology for which the locator is used. If an endpoint > changes its points of attachment within that scope, associations > between the endpoint and locators will change. I'm having trouble deciding what that means, and I'm enthusiastically trying, so I'm sure others will have even more trouble. :-p A LISP RLOC names a point of attachment point for an ETR, and IP forwarding in the core uses it as a locator to determine how to forward the packet to that PoA. Once the packet is delivered, the ETR strips off the LISP header, exposes the header underneath, and uses the destination address in that as a locator (which names an interface on the destination). That all fits within the definition at the top. There are two "endpoints" in the sense of the definition: the ETR and the ultimate destination. LISP says: "Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs." It doesn't say that an RLOC names a point of attachment for the ultimate endpoint, just for delivery of the LISP-encapsulated packet. IMHO the association between an RLOC and an ultimate delivery point of attachment is in the LISP encaps/decaps functions, and doesn't have to be covered by the definition. OK? Scott From swb@employees.org Fri Apr 3 11:31:33 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D633A69B9 for ; Fri, 3 Apr 2009 11:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coNdl6dKHNS7 for ; Fri, 3 Apr 2009 11:31:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1A0603A694C for ; Fri, 3 Apr 2009 11:31:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,320,1235952000"; d="scan'208";a="150126059" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 03 Apr 2009 18:31:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n33IVYBb012839 for ; Fri, 3 Apr 2009 14:31:34 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n33IVY6x027876 for ; Fri, 3 Apr 2009 18:31:34 GMT Date: Fri, 3 Apr 2009 14:31:30 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090403183130.GK82453@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> <49D5C0D8.8050204@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:31:33 -0000 Excerpts from Dow Street on Fri, Apr 03, 2009 10:51:40AM -0700: > On Apr 3, 2009, at 12:55 AM, Tony Li wrote: >>>> locator A locator is a name that has topological sensitivity at a >>>> given layer and changes if the point of attachment at that >>>> layer changes. By default, a locator refers to layer 3. >>>> It is also possible to have locators at other layers. >>>> Locators may have other properties, such as their scope >>>> (local or global (default)) and their lifetime (ephemeral >>>> or permanent (default)). >>> It is this "point of attachment at that layer" phrase that is still >>> problematic. If a host disconnects from one place on an ethernet >>> segment and connects to another, it can still be reachable without >>> changing it's IP address. Are you defining this as not changing the >>> point of attachment (in terms of layer 3)? >> >> _Exactly_. If you change ports on your local Ethernet switch, then >> you've only changed the L2 topology, and done nothing at all at layer >> 3. > > I am ok defining things this way. To ensure we're on the same page, > this means that only the network part of an IP address (from the > perspective of the host) can ever be considered a locator, right? > > Also, since the mask that is in effect (for forwarding) at various > points in the topology differs, then the part of the IP address that we > can call a locator also differs at various points in the topology. Ok now we get into the sticky business of locators versus forwarding directives, which we haven't explored and don't have to yet. IMHO a locator names a point of attachment ... but more or less information can be used for forwarding a packet at various points along a path. > I am trying to get at this property of "relative flatness" of > various names and/or parts of the IP address at different points of > the topology, even if we are only talking about familiar, > aggregation based approaches to scalability. > > In other words, if we say that: > > (a) on an ethernet segment (that maps to only a single prefix in the > IP routing system), only the network part of the IP address of > connected hosts is considered to be a (L3?) locator, then (b) a > similar property exists closer to the "middle" of the topology/ > routing system if aggregation is used. > > In (b), more specific prefixes "hidden behind" the aggregate are > topologically flat from the perspective of processes that are only > aware of the less-specific, aggregate mask. > > I think maybe you are accounting for all of this relative-ness with > the phrase "attachment point at that layer"? The relative flatness thing is cool, but you're both right IMHO. At a particular "layer" (whatever that is), points of attachment have unique names, but that's independent of routing and topology, which can impose various degrees of hierarchy on the PoAs. Scott From wherrin@gmail.com Fri Apr 3 11:45:57 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D0428C2AE for ; Fri, 3 Apr 2009 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NttoNYpDS2ki for ; Fri, 3 Apr 2009 11:45:56 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 256B028C2B1 for ; Fri, 3 Apr 2009 11:45:56 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so860945ywh.37 for ; Fri, 03 Apr 2009 11:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=54REQj5EPJaEWNogOqlerhCaZu3THAE/Fj0w5uAR/ZQ=; b=BvmXvTglx7ZqCISOqqHZeAj9gNO8E43Fm4a20JtlaglH3ZgJJ8b7IZVjQrdC23Zg2I NTqzOLL/KzOrrYCl/8Oe4tMVUmgP7IsosnpAD78C0Bh5LbhNih8VyH6WNgwZpoHyUD1e mBvyEm7IDsuNSKsKyzvgw/7eA7Bz2IBP+Qc9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=AD+3YtScAEClrcsD/CB4DjjzIX5QUBRMoHeDhcxxVQfMqhpQShhuAhu7wZs3X3Si9S GOHu1U3QQFwV8vuEGYPVqdw8xieehg5IQa5q+1YD0j83gJZH+6bFfqD7C7Xi2dDjn9RM NeUi8+9aGnEGOiEtrpXu6dvdWXO8M/woJtExc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.132.4 with SMTP id f4mr3462047and.16.1238784418450; Fri, 03 Apr 2009 11:46:58 -0700 (PDT) In-Reply-To: <20090403180422.GA88072@cisco.com> References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> <20090403180422.GA88072@cisco.com> Date: Fri, 3 Apr 2009 14:46:55 -0400 X-Google-Sender-Auth: c426059ba16260b1 Message-ID: <3c3e3fca0904031146k23b799bfi83b62a967a6bd3b9@mail.gmail.com> From: William Herrin To: Scott Brim , rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:45:57 -0000 On Fri, Apr 3, 2009 at 2:04 PM, Scott Brim wrote: > Excerpts from William Herrin on Fri, Apr 03, 2009 01:04:26PM -0400: >> On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim >> wrote: >> > =A0A locator names a point of attachment at a given layer. =A0If an >> > =A0endpoint changes its points of attachment at that layer, >> > =A0associations between the endpoint and locators will change. > >> A locator names a point of attachment within the scope of the >> network topology for which the locator is used. If an endpoint >> changes its points of attachment within that scope, =A0associations >> between the endpoint and locators will change. > > I'm having trouble deciding what that means, and I'm enthusiastically > trying, so I'm sure others will have even more trouble. :-p' Hi Scott, Your version sets the scope at the network layer boundary. The locator changes with my attachment at the layer boundary. But that's not right. The scope is arbitrary. Protocol and design-dependent= . For example, I send a packet to 1.2.3.4 using a loose source route via 5.6.7.8. 5.6.7.8 is a locator. 5.6.7.8 serves as 1.2.3.4's point of attachment to the larger network. Once my packet gets to one of the routers which accepts packets to 5.6.7.8, the 5.6.7.8 locator loses scope and delivery proceeds based on the 1.2.3.4 address. But there's no layer change. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From christian.vogt@ericsson.com Fri Apr 3 15:58:14 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76E33A684B for ; Fri, 3 Apr 2009 15:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atwoW92e2v1s for ; Fri, 3 Apr 2009 15:58:13 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 727BA3A6905 for ; Fri, 3 Apr 2009 15:57:57 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n33N7XuP021736; Fri, 3 Apr 2009 18:07:35 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 17:58:57 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 17:58:56 -0500 Message-Id: From: Christian Vogt To: Routing Research Group Mailing List In-Reply-To: <49D5144C.7020904@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 15:59:00 -0700 References: <49D5144C.7020904@tony.li> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Apr 2009 22:58:56.0704 (UTC) FILETIME=[C4936400:01C9B4AF] Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:58:14 -0000 On Apr 2, 2009, Tony Li wrote: > locator A locator is a name that has topological sensitivity at a > given layer and changes if the point of attachment at that > layer changes. [...] > > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. [...] Hi Folks - Since "topological sensitivity" is key to distinguishing identifiers and locators in these definition, I believe we should be more specific with respect to what we mean by it. Much of the previous discussion was, IMHO, due to people having different understandings, as exemplified by the discussion on whether MAC addresses are identifiers or locators. In particular, "topological sensitivity" could be defined as either or both of the following: (1) as the property of being used in path selection. (2) as the property of encoding a path, strictly or loosely. If we use definition (1), the categorization of a name as identifier or locator depends on the use of the name. Overloading, e.g., can turn an identifier into a locator. On the other hand, if we use definition (2), the categorization of a name is independent of the use of the name. The earlier discussion between Tony and Dino on whether MAC addresses are identifiers or locators exemplifies the need for more specificity of what we mean by topologial sensitivity. Dino argued that a MAC address has topological sensitivity, and hence is a locator, because MAC addresses are used for path selection in switches. He is absolutely correct if we define topolocial sensitivity as in (1) and consider switched Ethernet. Tony argued that MAC addresses should be considered identifiers because they were originally not used for path selection. He is absolutely correct if we use definition (2), or if we use definition (1) and consider traditional, non-switched Ethernet. To avoid misunderstandings, I would hence suggest defining "topological sensitivity" -- either as a separate definition, or by making existing definitions more specific. Personally, I am in favor of definition (2) because it provides terminology that remains stable independent of usage and overloading. Obviously, other folks' mileage may vary. - Christian From swb@employees.org Fri Apr 3 18:45:26 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DB33A69B9 for ; Fri, 3 Apr 2009 18:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mko1LFhlfQO for ; Fri, 3 Apr 2009 18:45:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 436ED3A69B0 for ; Fri, 3 Apr 2009 18:45:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,322,1235952000"; d="scan'208";a="40962413" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2009 01:46:27 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n341kR8d023452 for ; Fri, 3 Apr 2009 21:46:27 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n341kRka028995 for ; Sat, 4 Apr 2009 01:46:27 GMT Date: Fri, 3 Apr 2009 21:46:20 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090404014620.GA97317@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> <20090403180422.GA88072@cisco.com> <3c3e3fca0904031146k23b799bfi83b62a967a6bd3b9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c3e3fca0904031146k23b799bfi83b62a967a6bd3b9@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 01:45:26 -0000 Excerpts from William Herrin on Fri, Apr 03, 2009 02:46:55PM -0400: > >> On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim > >> wrote: > >> >  A locator names a point of attachment at a given layer.  If an > >> >  endpoint changes its points of attachment at that layer, > >> >  associations between the endpoint and locators will change. > Hi Scott, > > Your version sets the scope at the network layer boundary. The > locator changes with my attachment at the layer boundary. > > But that's not right. The scope is arbitrary. Protocol and > design-dependent. > > For example, I send a packet to 1.2.3.4 using a loose source route > via 5.6.7.8. 5.6.7.8 is a locator. 5.6.7.8 serves as 1.2.3.4's point > of attachment to the larger network. > > Once my packet gets to one of the routers which accepts packets to > 5.6.7.8, the 5.6.7.8 locator loses scope and delivery proceeds based > on the 1.2.3.4 address. But there's no layer change. There are three things that may need naming. In order of increasing generality: 1. A point of attachment, aka "PoA", for the ultimate destination (at a given layer). 2. A "waypoint" which is on the path to the ultimate destination. This may be considered by some to include #1. 3. Anything that is used to make a next_hop forwarding decision, including other parts of packet headers, policy, whatever. This may be considered by some to include #2. We're stuck with "locator" as naming one of these. I was trying to apply it to #1. I think that Bill is applying it to #2. Bill? I would include "logical" PoAs such as anycast addresses in #2. Because LISP is an encapsulation, I would include LISP RLOCs in #1, not #2. I don't know what to call #3 except "input to forwarding functions". "Forwarding directive" came out of NewArch -- see . It seems to overlap our concepts of stackID and locator -- that's something to think about. But the big question is: which of these three do you think is the best match for the way the rest of the I* is using "locator"? Scott From tony.li@tony.li Fri Apr 3 20:51:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567C43A68EF for ; Fri, 3 Apr 2009 20:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nbz1klLnHrW for ; Fri, 3 Apr 2009 20:51:05 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 9692C3A67EF for ; Fri, 3 Apr 2009 20:51:05 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id bCJl1b0040mlR8UA8Fs9Mw; Sat, 04 Apr 2009 03:52:09 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id bFry1b00E3L8a8Q8XFs9WG; Sat, 04 Apr 2009 03:52:09 +0000 Message-ID: <49D6344A.9060909@tony.li> Date: Fri, 03 Apr 2009 09:07:38 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Luigi Iannone References: <49D5144C.7020904@tony.li> <15ED2F65-93A5-4990-97E8-BD6BD278AF1E@net.t-labs.tu-berlin.de> <49D5C3AC.7080502@tony.li> <3B0D710F-4931-43B6-983A-C1A30AB3E471@net.t-labs.tu-berlin.de> In-Reply-To: <3B0D710F-4931-43B6-983A-C1A30AB3E471@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:51:06 -0000 Hi Luigi, > IMHO sounds a bit strange that we define identifiers and locators and > then we use the latter to locate interfaces.... > I was thinking that a "locator" locates "identifier", if an identifier > is associated to an interface, then it is correct, but I feel that > somehow current definition introduces a constrain. Actually tying locator to identifier directly in that way would be a constraint. And we already have cases where the locator is associated with a subnet and the identifier is a stack. Obviously, there needs to be some mechanism between the two, but if that exists, who are we to complain? Tony From tony.li@tony.li Fri Apr 3 20:51:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CA73A67EF for ; Fri, 3 Apr 2009 20:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE2TIJsn-dhi for ; Fri, 3 Apr 2009 20:51:05 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id A6DEF3A68AB for ; Fri, 3 Apr 2009 20:51:05 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id bCHu1b0050FhH24A9Fs9fy; Sat, 04 Apr 2009 03:52:09 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id bFs11b0013L8a8Q8UFs9Eh; Sat, 04 Apr 2009 03:52:09 +0000 Message-ID: <49D64C60.2030804@tony.li> Date: Fri, 03 Apr 2009 10:50:24 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Brim , Tony Li , rrg@irtf.org References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> In-Reply-To: <20090403152155.GA83404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 03:51:06 -0000 Hi Scott, > Now that we have the ideas worked out, this first sentence could > actually be reduced to > > A locator names a point of attachment at a given layer. > > "names a point of attachment" implies that the name changes if the > point of attachment changes, and that in turn implies that the name is > topology-sensitive. We could make those statements explicit but we > don't need to. I think we need to be more explicit as I don't think everyone will make that same implication, so I lean towards what you have below. > If we make them explicit, "topological sensitivity" needs tightening > up. A locator itself is not topologically-sensitive. It does not > change. Rather, an endpoint's association with a point of attachment > changes, so the association between the endpoint and point of > attachment name ("locator") changes. A locator does not have > topological sensitivity, the endpoint+locator association is. > > So I wouldn't mind keeping things explicit but I suggest something > like: > > A locator names a point of attachment at a given layer. If an > endpoint changes its points of attachment at that layer, > associations between the endpoint and locators will change. Ok, I morphed it slightly: A locator is a name for a point of attachment within the topology at a given layer. Objects that change their point of attachment(s) will need to change their associated locator(s). Tony From tony.li@tony.li Fri Apr 3 21:49:17 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660C93A687F for ; Fri, 3 Apr 2009 21:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdNl+Qk6317V for ; Fri, 3 Apr 2009 21:49:11 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id E34FC3A685E for ; Fri, 3 Apr 2009 21:49:10 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id bEQh1b0030EPchoABGqEKW; Sat, 04 Apr 2009 04:50:14 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id bGqD1b00K3L8a8Q8MGqEpk; Sat, 04 Apr 2009 04:50:14 +0000 Message-ID: <49D6E6ED.2080108@tony.li> Date: Fri, 03 Apr 2009 21:49:49 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Brim , rrg@irtf.org References: <49D5144C.7020904@tony.li> <20090403152155.GA83404@cisco.com> <3c3e3fca0904031004o6366e40cibd40244a16f8eb82@mail.gmail.com> <20090403180422.GA88072@cisco.com> <3c3e3fca0904031146k23b799bfi83b62a967a6bd3b9@mail.gmail.com> <20090404014620.GA97317@cisco.com> In-Reply-To: <20090404014620.GA97317@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 04:49:17 -0000 Hi Scott, Bill, >>>> On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim >>>> wrote: >>>>> A locator names a point of attachment at a given layer. If an >>>>> endpoint changes its points of attachment at that layer, >>>>> associations between the endpoint and locators will change. > >> Your version sets the scope at the network layer boundary. The >> locator changes with my attachment at the layer boundary. Disagree. It's only one point on the topology. And it's not necessarily the network layer. And there's not even necessarily one 'network' layer even. >> For example, I send a packet to 1.2.3.4 using a loose source route >> via 5.6.7.8. 5.6.7.8 is a locator. 5.6.7.8 serves as 1.2.3.4's point >> of attachment to the larger network. >> >> Once my packet gets to one of the routers which accepts packets to >> 5.6.7.8, the 5.6.7.8 locator loses scope and delivery proceeds based >> on the 1.2.3.4 address. But there's no layer change. That depends entirely on whether you have one namespace or two. Note that you can do either. If it truly is a loose source route, then you have a single namespace. One test is whether or not you can send data directly to 1.2.3.4. If so, then it is also within your layer. If, instead, 1.2.3.4 is at another layer, then it's another namespace entirely. If we take this back to LISP, the implication here is that RLOCs and EIDs are two entirely separate namespaces. Each of them is arguably an address. > There are three things that may need naming. In order of increasing > generality: > > 1. A point of attachment, aka "PoA", for the ultimate destination > (at a given layer). > > 2. A "waypoint" which is on the path to the ultimate destination. > This may be considered by some to include #1. > > 3. Anything that is used to make a next_hop forwarding decision, > including other parts of packet headers, policy, whatever. This > may be considered by some to include #2. > > We're stuck with "locator" as naming one of these. I was trying to > apply it to #1. I think that Bill is applying it to #2. Bill? > > I would include "logical" PoAs such as anycast addresses in #2. > Because LISP is an encapsulation, I would include LISP RLOCs in #1, > not #2. > > I don't know what to call #3 except "input to forwarding functions". > > "Forwarding directive" came out of NewArch -- see > . It seems to > overlap our concepts of stackID and locator -- that's something to > think about. > > But the big question is: which of these three do you think is the best > match for the way the rest of the I* is using "locator"? I don't think that's the real question. Our job isn't to articulate common usage; it's to define what the terminology should be. I've got a real problem with including #3 because that can be just about anything. You want to forward based on port numbers? No problem. You want to forward on ToS bits? Doable. In that context _EVERYTHING_ is a locator. Some of this is even shipping code. (Cisco PBR, my apologies) As such, this is a pretty useless definition. Every field in a packet and every bit anywhere on the network qualifies. I'm not seeing any distinction between #1 and #2 either. Both are effectively points in the topology. Differentiating between destinations and waypoints seems to me to be more about the forwarding mechanism than about the namespace itself. Tony From tony.li@tony.li Fri Apr 3 22:09:17 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9D83A686E for ; Fri, 3 Apr 2009 22:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoT9-z2sYaFR for ; Fri, 3 Apr 2009 22:09:16 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 291603A685E for ; Fri, 3 Apr 2009 22:09:16 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id bGQX1b0040b6N64ABHALqA; Sat, 04 Apr 2009 05:10:20 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id bHAK1b0013L8a8Q8PHALv6; Sat, 04 Apr 2009 05:10:20 +0000 Message-ID: <49D6EBA2.8070908@tony.li> Date: Fri, 03 Apr 2009 22:09:54 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> <49D5C0D8.8050204@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 05:09:17 -0000 Hi Dow, > I am ok defining things this way. To ensure we're on the same page, > this means that only the network part of an IP address (from the > perspective of the host) can ever be considered a locator, right? I think we're aligned, but there are some nits that happen here because the IP address again this overloaded use of both locator and identifier. To demonstrate a nit: what's the network part of the IPv4 address? I have a prefix 192.168.1/24 that points to a particular Ethernet. I also have a host 192.168.1.100 that is NOT on that Ethernet. I establish host routes everywhere I need access to this host. I'd claim that 192.168.1.100/32 is both a locator and identifier. Such is the way of semantic confusion. > Also, since the mask that is in effect (for forwarding) at various > points in the topology differs, then the part of the IP address that we > can call a locator also differs at various points in the topology. Similarly, I'd make the slightly different distinction that you simply can't say what part of an IPv4 address is a locator without full information about the particular point of attachment. Note that whatever bits are relevant to the locator do NOT change over time or the point where they are examined. The fact that the observer has incomplete and insufficient information doesn't change the real semantics of the bits. Note that this is more clear in other proposals (e.g., GSE) where the locator is a fixed number of bits. > In other words, if we say that: > > (a) on an ethernet segment (that maps to only a single prefix in the IP > routing system), only the network part of the IP address of connected > hosts is considered to be a (L3?) locator, then > (b) a similar property exists closer to the "middle" of the > topology/routing system if aggregation is used. > > In (b), more specific prefixes "hidden behind" the aggregate are > topologically flat from the perspective of processes that are only aware > of the less-specific, aggregate mask. Thus, I disagree with this, as with the above. Aggregation in the routing system is (and should always be) independent of the semantics of the namespace. I think we want to be very careful here, because we don't want to define a locator namespace and accidentally have prefixes ending up in packet headers. > I think maybe you are accounting for all of this relative-ness with the > phrase "attachment point at that layer"? Some, but not as much as you're thinking. I'm really trying to use the simplest definition of PoA, such that you have to transition to another layer to make forwarding progress. Tony From dow.street@linquest.com Sat Apr 4 00:29:56 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033193A68EF for ; Sat, 4 Apr 2009 00:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3nQhzEpr0LT for ; Sat, 4 Apr 2009 00:29:55 -0700 (PDT) Received: from smtp135.sat.emailsrvr.com (smtp135.sat.emailsrvr.com [66.216.121.135]) by core3.amsl.com (Postfix) with ESMTP id 15A7F3A6768 for ; Sat, 4 Apr 2009 00:29:54 -0700 (PDT) Received: from relay3.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay3.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 38663C7334; Sat, 4 Apr 2009 03:30:58 -0400 (EDT) Received: by relay3.relay.sat.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id ADBBAC7369; Sat, 4 Apr 2009 03:30:57 -0400 (EDT) Message-Id: From: Dow Street To: Tony Li In-Reply-To: <49D6EBA2.8070908@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 4 Apr 2009 00:30:48 -0700 References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> <49D5C0D8.8050204@tony.li> <49D6EBA2.8070908@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 07:29:56 -0000 On Apr 3, 2009, at 10:09 PM, Tony Li wrote: > > Hi Dow, > >> I am ok defining things this way. To ensure we're on the same >> page, this means that only the network part of an IP address (from >> the perspective of the host) can ever be considered a locator, right? > > > I think we're aligned, but there are some nits that happen here > because the IP address again this overloaded use of both locator and > identifier. > > To demonstrate a nit: what's the network part of the IPv4 address? > I have a prefix 192.168.1/24 that points to a particular Ethernet. > I also have a host 192.168.1.100 that is NOT on that Ethernet. I > establish host routes everywhere I need access to this host. I'd > claim that 192.168.1.100/32 is both a locator and identifier. > > Such is the way of semantic confusion. Agree (I think). I would claim that all 24 bits of 192.168.1.100 could be considered to contain location information, but other hosts attached on the 192.168.1/24 segment would only have 24 "locator bits". However, I think this means that it is the combination of the (physical) point of attachment, and how that point is described in the routing system, that fully define location. If the topology were a perfect binary tree, and nodes were addressed in a manner that perfectly matched this tree, then you wouldn't need additional information in the routing system. Since the topology is not a tree, the address semantics (even in the best case of address allocation) can only approximately describe topological location - it takes the information in the routing system to complete the mapping of address to topology. >> Also, since the mask that is in effect (for forwarding) at various >> points in the topology differs, then the part of the IP address >> that we can call a locator also differs at various points in the >> topology. > > > Similarly, I'd make the slightly different distinction that you > simply can't say what part of an IPv4 address is a locator without > full information about the particular point of attachment. Note > that whatever bits are relevant to the locator do NOT change over > time or the point where they are examined. The fact that the > observer has incomplete and insufficient information doesn't change > the real semantics of the bits. I am ok with this, but would you then say that the semantics of LPM are an integral part of encoding location information in the IP address? (and subsequently, IP addresses were not locators prior to CIDR?) > > Note that this is more clear in other proposals (e.g., GSE) where > the locator is a fixed number of bits. > > >> In other words, if we say that: >> (a) on an ethernet segment (that maps to only a single prefix in >> the IP routing system), only the network part of the IP address of >> connected hosts is considered to be a (L3?) locator, then >> (b) a similar property exists closer to the "middle" of the >> topology/routing system if aggregation is used. >> In (b), more specific prefixes "hidden behind" the aggregate are >> topologically flat from the perspective of processes that are only >> aware of the less-specific, aggregate mask. > > > Thus, I disagree with this, as with the above. Aggregation in the > routing system is (and should always be) independent of the > semantics of the namespace. I think I agree from a definition perspective - that is - we can make use of proximity semantics in the address space even if there is no aggregation in the routing system. However, from an engineering perspective, the only reason to employ such semantics in the address is if you plan to aggregate (somewhere/somehow), right? R, Dow From tony.li@tony.li Sat Apr 4 01:15:25 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E483A69AF for ; Sat, 4 Apr 2009 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8ULwL0oEVuf for ; Sat, 4 Apr 2009 01:15:24 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id B57C83A6996 for ; Sat, 4 Apr 2009 01:15:24 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id bLG61b0010cQ2SLAALGVLi; Sat, 04 Apr 2009 08:16:29 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id bLGT1b0093L8a8Q8WLGUBl; Sat, 04 Apr 2009 08:16:28 +0000 Message-ID: <49D71738.4020206@tony.li> Date: Sat, 04 Apr 2009 01:15:52 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49D5144C.7020904@tony.li> <52128189-4EFB-4611-BC0C-43195CA1AA35@linquest.com> <49D5C0D8.8050204@tony.li> <49D6EBA2.8070908@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 08:15:25 -0000 > I am ok with this, but would you then say that the semantics of LPM are > an integral part of encoding location information in the IP address? > (and subsequently, IP addresses were not locators prior to CIDR?) Well, strictly speaking, LPM predates CIDR. Yes, for an IP address LPM (and the full routing table) is definitely part of what encodes location. > I think I agree from a definition perspective - that is - we can make > use of proximity semantics in the address space even if there is no > aggregation in the routing system. However, from an engineering > perspective, the only reason to employ such semantics in the address is > if you plan to aggregate (somewhere/somehow), right? The clear purpose of hierarchy is to achieve scalability through abstraction. Tony From wherrin@gmail.com Sat Apr 4 08:19:53 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC273A688D for ; Sat, 4 Apr 2009 08:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6koKYVwLeJcY for ; Sat, 4 Apr 2009 08:19:52 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 708523A67A4 for ; Sat, 4 Apr 2009 08:19:52 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so1017550anc.37 for ; Sat, 04 Apr 2009 08:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cWT4p4kFjmL8JJrBcEycnZqhNuVMBxerFoB8wzU861w=; b=DbgA7YZewo2LHoGiofgrQPAVQnNyYuAGPmZr7xpnapyV+fG+zyuOCl39+g8emisWMI KvIEN6UHbrZZiN+Kg2qepKbqlJTQfBDT72eqpsRnI1oTYSu8BoLp1c3IGmeBR5py+sbs lRqSx/Uti+oF+CZy6zpm9w0s1yNb1pCNTUtGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=S9a1+VmYTFBxUj1DSa92W/PIUAo04wI7z8QrsUSAekj0HCk0nXJ6vLoHPP3XZTkwUW qmLWmCkqJCuNoVIzi+dB/JvOjIahC7KC8xZf2wWujRIZ2Mr51Suv4bKaj/BD/XTIeOwO teFT9tsRydzAtNJ0srwml0Z5PCxo3FA/gxqUw= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.45.5 with SMTP id s5mr660265ans.26.1238858455792; Sat, 04 Apr 2009 08:20:55 -0700 (PDT) Date: Sat, 4 Apr 2009 11:20:55 -0400 X-Google-Sender-Auth: 1a6ccb506e4a0fe3 Message-ID: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> From: William Herrin To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 15:19:54 -0000 Briefly: Identifier: Any element in the ongoing communication between a user and a network service he uses which is statically bound to the function of correlating the communication's data packets with the communication as a whole. Address: Any element in a network packet used to calculate the packet's next hop. An address might or might not be used to construct an identifier as well. Locator: An address which is not used to construct an identifier. A locator is only used to calculate the packet's next hop. Identifier Definition: Any element in the ongoing communication between a user and and a network service he uses which is statically bound to the function of correlating the communication's data packets with the communication as a whole. Notes: The RRG observes that an identifier must remain unique within the scope of its use and must persist unchanged over the duration of its use. If not unique, packets may be correlated with the wrong communication. If changed, the user or his computer may not determine the new identifier in a timely manner. Examples: * The Web URL that the person uses to access cnn.com every day going back years and years, would prevent the user from tuning in to CNN and would cause all of his news-scraper programs to fail. * The DNS host name used by the Web URL which if changed would force the URL to change. * The user's login name at the New York Times, used to track the user's activity and build a usage profile which if changed would cause the NYT to lose its prior knowledge about the individual. * The session cookie used to correlate multiple http accesses with a particular user login which if changed would require the user to log in and re-identify himself again. * The TCP transport ID composed of two IP addresses and two port numbers, used to correlate individual IP packets with the TCP connection which if changed would cause the TCP connection to time out and fail. * The IP address which if changed would force the transport ID to change. * The IP address contained within the Web URL which if changed would force the URL to change. * The IP address statically locked by the web browser to the DNS hostname in the Web URL via "DNS Pinning," which if changed would require the URL to change or the browser to restart in order to negate the DNS Pinning. * The MAC address in an IPv6 packet used to construct the IP address which if changed would force the TCP transport ID to change. Address Definition: Any element in a network packet used to calculate the packet's next hop. An address might or might not be used to construct an identifier as well. Examples: * The IP address used both for packet forwarding and as a component of the TCP transport ID. Locator Definition: An address which is not used to construct an identifier. A locator is only used to calculate the packet's next hop. Notes: The RRG observes that when a host or network attaches to the Internet and adopts the use of locators and addresses already contained by the system to which it attached, this new attachment induces no additional routing state on the Internet. However, when the attaching network requires locators or addresses not already contained by the system to which it attached, knowledge about that attachment must be propagated throughout the routing system. Examples: * The MAC address in an IPv4 ethernet packet used to switch packets from one switch port to another within a LAN. * The MPLS label used to route packets to the correct exit router within an AS. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmh@joelhalpern.com Sat Apr 4 08:44:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABE23A6A04 for ; Sat, 4 Apr 2009 08:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrQyQ4eZXVF3 for ; Sat, 4 Apr 2009 08:44:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D95EA3A6888 for ; Sat, 4 Apr 2009 08:44:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F20854303D1; Sat, 4 Apr 2009 08:45:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6CE204303CB; Sat, 4 Apr 2009 08:45:15 -0700 (PDT) Message-ID: <49D78086.8040601@joelhalpern.com> Date: Sat, 04 Apr 2009 11:45:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> In-Reply-To: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 15:44:12 -0000 That is a very specific kind of identifier. It sounds to me like the definition of session identifier. Scott and I have been known to discuss whether that is the only identifier the protocol needs. But it is certainly not the only identifier that the architecture needs to be able to discuss. Yours, Joel William Herrin wrote: > Briefly: > > Identifier: Any element in the ongoing communication between a user > and a network service he uses which is statically bound to the > function of correlating the communication's data packets with the > communication as a whole. From jnc@mercury.lcs.mit.edu Sat Apr 4 08:49:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC823A6A30 for ; Sat, 4 Apr 2009 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLJeVj67RDCW for ; Sat, 4 Apr 2009 08:49:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A7F623A6A27 for ; Sat, 4 Apr 2009 08:49:46 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6E0D26BE570; Sat, 4 Apr 2009 11:50:49 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 11:50:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 15:49:47 -0000 > From: William Herrin > Address: Any element in a network packet used to calculate the packet's > next hop. That would make an MPLS tag an "address". Somehow I don't think so. (Not to mention the TOS field, if anyone is still using TOS-dependent routing.) In general, I think we're at a point of diminishing returns on discussing terminology. Existing terms (identifier, address, locator) are particularly problematic as they already have meanings in most people's minds, and changing them is nearly impossible. Just give it up. If we really need a name for some particular crisp definition (such as the one above), pick a new word/phrase, don't try and morph an existing word. Noel From jnc@mercury.lcs.mit.edu Sat Apr 4 09:10:57 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018023A6A31 for ; Sat, 4 Apr 2009 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xZvHeGTU2sJ for ; Sat, 4 Apr 2009 09:10:56 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 40F3D3A688D for ; Sat, 4 Apr 2009 09:10:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C18BB6BE572; Sat, 4 Apr 2009 12:11:59 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090404161159.C18BB6BE572@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 12:11:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:10:57 -0000 > From: Christian Vogt > In particular, "topological sensitivity" could be defined as either or > both of the following: > (1) as the property of being used in path selection. > (2) as the property of encoding a path, strictly or loosely. I don't really like the second, because although paths may be given in terms of a series of locators, locators also are used in other ways. To use a real-world example, the real-world 'locator': 123 High Street, Bigtown, Green County, Outer Luvania just names a particular _place_ - and says _nothing_ about _any_ paths to it (although one would usually expect all paths to it to eventually travel along High Street, etc). In general, my real-world analogue for 'locator' (at least, in terms of their _functionality) is 'street address' - and so, when thinking about properties of locators, I tend to use street addresses as a mental model. I would suggest we could all benefit from doing the same. Noel From jnc@mercury.lcs.mit.edu Sat Apr 4 09:34:49 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455BA3A67B0 for ; Sat, 4 Apr 2009 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxp6cbh3qbI1 for ; Sat, 4 Apr 2009 09:34:48 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 26B3D3A6826 for ; Sat, 4 Apr 2009 09:34:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D04C26BE584; Sat, 4 Apr 2009 12:35:50 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 12:35:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:34:49 -0000 > From: Tony Li > Our job isn't to articulate common usage; it's to define what the > terminology should be. I disagree, because in my experience, trying to re-define terms which are already in common use is a non-starter. So the best we can do for the Big Three (address, locator, identifier) is to come up with definitions which reasonly match what they mean to _most_ people now, and hope that the outliers eventually give up on their idiosyncratic personal definitions, and start using the one most people have. For the Big Three, I think your version of Sat, 28 Mar 2009 20:44:11 (perhaps very subtle tweaked) is about as good as we can get. Note that the definitions for those three will have to be a little 'loose', because if you make them _more_ specific, you will start to loose people from the "_most_ people" pot above. If we need terms for very specific things, we need to pick new words. In particular, the concept of 'field(s) in the header which a packet switch looks at to pick the next hop' is a concept which, AFAIK, does _not_ have a well-known term - and there's a perfect place for some new terminology. > Differentiating between destinations and waypoints seems to me to be > more about the forwarding mechanism than about the namespace itself. Exactly. To me, a location in the network connectivity graph is just.. a location in the network connectivity graph. (Which leads to 'locator: name of a location in the network connectivity graph' - perhaps you could put that in as an alternative definition.) Note also (in light of some other comments here that I don't have time to reply to in detail) that in general, the 'name of the location' is only actually _used_ at the internetwork level (for getting user traffic to the named location). It may seem that higher-level entities _also_ have locations; e.g. if you have a application which is running in a stack has only a single interface, that application also 'sort of' has a location. _However_, as soon as you say that a higher-level thing can be reached through more than one place in the network (or 'attached to more than one place in the network') - which is what multi-homing is - then the thing no longer has 'a' location. So either i) higher-level things can have more than one 'location' at a time (which is a slightly counter-intuitive property of 'location of a thing', for non-quantum-mechanicians), or ii) higher-level things do not in fact actually have locations - we just have the illusion that they do, in simple cases. Noel From HeinerHummel@aol.com Sat Apr 4 11:33:17 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7463A67D1 for ; Sat, 4 Apr 2009 11:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWmT+zw8Upne for ; Sat, 4 Apr 2009 11:33:16 -0700 (PDT) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by core3.amsl.com (Postfix) with ESMTP id 471833A6765 for ; Sat, 4 Apr 2009 11:33:15 -0700 (PDT) Received: from HeinerHummel@aol.com by imo-d05.mx.aol.com (mail_out_v39.1.) id 9.caa.41e12f7c (39952); Sat, 4 Apr 2009 14:34:11 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 4 Apr 2009 14:34:11 EDT To: jnc@mercury.lcs.mit.edu, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1238870051" X-Mailer: 9.0 SE for Windows sub 5021 Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 18:33:17 -0000 -------------------------------1238870051 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Yes, this is finally a real-world example. It may address/locate/identify =20 some particular letter box among a bin of such letter boxes, e.g. if you add= an =20 additional bin number in front of 123 High Street. The delivery service ends there. No matter who (which person) picks it up =20 from there.With all such letter boxes being nodes of the postal delivery =20 network, that network is thousand times bigger than the DFZ-core of the int= ernet,=20 and will never have a scalability problem. =20 Just wordsmithing, morphing, etc. does not bring out a good solution. Each =20 solution may create its own terms like sender/receiver or initiator/respond= er=20 or source/destination or ITR/ETR....and may introduce them up front. =20 Heiner =20 =20 =20 =20 In einer eMail vom 04.04.2009 18:12:10 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: To use a real-world example, the real-world 'locator': 123 High Street,=20 Bigtown, Green County, Outer Luvania just names a particular _place_ - and says _nothing_ about _any_ paths to i= t (although one would usually expect all paths to it to eventually travel alo= ng High Street, etc). In general, my real-world analogue for 'locator' (at least, in terms of =20 their _functionality) is 'street address' - and so, when thinking about propertie= s of locators, I tend to use street addresses as a mental model. I would=20 suggest we could all benefit from doing the same. Noel _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1238870051 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, this is finally a real-world example. It may address/locate/identi= fy=20 some particular letter box among a bin of such letter boxes, e.g. if you add= an=20 additional bin number in front of 123 High Street.
The delivery service ends there. No matter who (which person) picks it=20= up=20 from there.With all such letter boxes being nodes of the postal delivery=20 network, that network is thousand times bigger than the DFZ-core of the=20 internet, and will never have a scalability problem.
 
Just wordsmithing, morphing, etc. does not bring out a good solution. E= ach=20 solution may create its own terms like sender/receiver or=20 initiator/responder or source/destination or  ITR/ETR....and may introd= uce=20 them up front.
 
Heiner
 
 
 
 
In einer eMail vom 04.04.2009 18:12:10 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>To use a=20 real-world example, the real-world 'locator':

    123 Hig= h=20 Street,
    Bigtown,
    Green County,
 = ;=20   Outer Luvania

just names a particular _place_ - and says=20 _nothing_ about _any_ paths to it
(although one would usually expect al= l=20 paths to it to eventually travel along
High Street, etc).

In=20 general, my real-world analogue for 'locator' (at least, in terms of=20 their
_functionality) is 'street address' - and so, when thinking about= =20 properties
of locators, I tend to use street addresses as a mental mode= l. I=20 would suggest
we could all benefit from doing the same.

 =20   Noel
_______________________________________________
rrg mail= ing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1238870051-- From wherrin@gmail.com Sat Apr 4 15:24:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879743A6951 for ; Sat, 4 Apr 2009 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjSQAJccXhfO for ; Sat, 4 Apr 2009 15:24:07 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 7121A3A684B for ; Sat, 4 Apr 2009 15:24:07 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so1085750anc.37 for ; Sat, 04 Apr 2009 15:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dm0zmAUojOoRY/cXI6sW4ruHpIQQoRaIKDizXglNXi4=; b=TCTevv4qKQhMvrcaGLu81rnOF7pa6XKMy+sfWAmGoLzFeKokLBAMJ+ErJ9RzR4H21T oo5LlFiiyE6BOEmelJwZY+ntWEq2ZAyDMMCD8g50ttV1XWJpFqSb8+ZZ0HsQWFibGJeW 9KzUAs5T7XYpyzCkip/ToIqUcti834YaRHFtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Lpl990y1Zh8eouT3ee8ctub9ODa7+2XXMTcL20B83W8txiS/B5YxcCAkVSXpf7CLp/ ZoYYCwj2BxPM7LnHmKrP/7t0zOGzokmLlBU94lTZUu7ZeZ0W7oxggmRR/nMBuqOLweX9 vg0FmQ60xSsOD4SfL5YvhmhCpgvYEoeD8oBP8= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.14.10 with SMTP id 10mr4103273ann.119.1238883911292; Sat, 04 Apr 2009 15:25:11 -0700 (PDT) In-Reply-To: <49D78086.8040601@joelhalpern.com> References: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> <49D78086.8040601@joelhalpern.com> Date: Sat, 4 Apr 2009 18:25:11 -0400 X-Google-Sender-Auth: 2f7a60a5d44d2b6f Message-ID: <3c3e3fca0904041525p6e5f1503w14ff1e730ac5f50c@mail.gmail.com> From: William Herrin To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 22:24:08 -0000 On Sat, Apr 4, 2009 at 11:45 AM, Joel M. Halpern wrot= e: > William Herrin wrote: >> Identifier: Any element in the ongoing communication between a user >> and a network service he uses which is statically bound to the >> function of correlating the communication's data packets with the >> communication as a whole. > That is a very specific kind of identifier. =A0It sounds to me like the > definition of session identifier. Joel, Either I didn't describe it well enough or you read it too narrowly. It's any element at all that's incorporated into that correlation process with a static binding. It's the session ID that incorporates multiple transports into a session but its also the transport ID that incorporates the packets into each transport as well as the components (srcip, dstip, srcport, dstport) from which the transport ID is constructed. Not only that, it's the login that correlates multiple sessions into an account. If it's statically incorporated into that correlation process in any way then it's an ID. In the most general sense, an identity correlates a set of smaller entities into the single larger entity which contains them. If you think that's wrong, poke a hole in it. Give me one counter-example of an identifier which does not function as a correlator. If I can't either explain how it's used as a correlator or explain why it's not an identifier then I'll have to find a new theory. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Sat Apr 4 15:24:10 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C546C3A69B1 for ; Sat, 4 Apr 2009 15:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUjp9NVe5TA2 for ; Sat, 4 Apr 2009 15:24:10 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id F23963A68ED for ; Sat, 4 Apr 2009 15:24:09 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so1085750anc.37 for ; Sat, 04 Apr 2009 15:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pbuXWUxpRM4oK2j2pbqTCJJHNlkImDCe72KOIS71tz4=; b=nyR9qM5a4o0SGuBGnJ+0AJCYCpUnaHPTRYGunU9NdHzCAKTTDKdlm0mxfi6aQpMRAB wMTUGSwov1YvCHfq3n6ANaK3Th0KmRIfHM0WlGkqJvUzoceuVkquXiU17SNcnJKrG1LB te3jrvyvsfS9B2cveY3Opadm4ZCp0trXZrG44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L+i8Je7khf7jv25U6fegXcNKzn28f/qAS+UJl6JO2IQUawBOFT6ndiPDFWg/FQnN93 w/AwE3jn6+PAamKxQAMau3/Ib0QS4qT38VqsKvVSVr3Bi7U6vTq4OwetEF8POhEMRfrX PbPObaPjzhJRo2j6QC1+rDpGy8zQMOViyZu1U= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.134.10 with SMTP id h10mr5422562and.31.1238883914093; Sat, 04 Apr 2009 15:25:14 -0700 (PDT) In-Reply-To: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 18:25:14 -0400 X-Google-Sender-Auth: be295a75a078a028 Message-ID: <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> From: William Herrin To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 22:24:10 -0000 On Sat, Apr 4, 2009 at 11:50 AM, Noel Chiappa wro= te: > =A0 =A0> From: William Herrin > > =A0 =A0> Address: Any element in a network packet used to calculate the p= acket's > =A0 =A0> next hop. > > That would make an MPLS tag an "address". Somehow I don't think so. Why not? What characteristics of what you think of as an address are missing from the typical use of an MPLS tag? > (Not to > mention the TOS field, if anyone is still using TOS-dependent routing.) Was TOS ever used in the dynamic part of a routing protocol? If TOS is used in the forwarding decision within a particular scope then it is part of an address within that scope. If that scope happens to be a static route on a single piece of equipment (or a static nudge to a dynamic route) then it's well outside the RRG's area of interest. The same goes for Linux Virtual Server (LVS) which routes packets based on the TCP transport ID. The TCP transport ID is an address within that scope, but the scope is limited to a single server cluster. > If we really need a name for some particular crisp definition (such as th= e > one above), pick a new word/phrase, don't try and morph an existing word. If the chair is amenable to that idea, so am I. At the moment I'm endeavoring to remove the fuzz from the existing terms as the chair requested. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Sat Apr 4 16:23:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E333A6994 for ; Sat, 4 Apr 2009 16:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vIHFhz3nRdm for ; Sat, 4 Apr 2009 16:23:40 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 90FFA3A67B6 for ; Sat, 4 Apr 2009 16:23:40 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id bZKP1b00C0FhH24A1bQBQV; Sat, 04 Apr 2009 23:24:11 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id bbQj1b00U3L8a8Q8UbQltR; Sat, 04 Apr 2009 23:24:45 +0000 Message-ID: <49D7EC26.3020008@tony.li> Date: Sat, 04 Apr 2009 16:24:22 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: William Herrin References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> In-Reply-To: <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 23:23:41 -0000 Hi Bill, >> > Address: Any element in a network packet used to calculate the packet's >> > next hop. >> >> That would make an MPLS tag an "address". Somehow I don't think so. > > Why not? What characteristics of what you think of as an address are > missing from the typical use of an MPLS tag? Well, for one thing, an MPLS label is relative. Label value X is only meaningful pairwise between a pair of routers along the path. The same value X between any different pair of routers will imply a separate LSP and thus a different path entirely. >> (Not to >> mention the TOS field, if anyone is still using TOS-dependent routing.) > > Was TOS ever used in the dynamic part of a routing protocol? Yes. OSPF used to have TOS support. >> If we really need a name for some particular crisp definition (such as the >> one above), pick a new word/phrase, don't try and morph an existing word. > > If the chair is amenable to that idea, so am I. At the moment I'm > endeavoring to remove the fuzz from the existing terms as the chair > requested. Normally, I would love that idea. However, our specific request is that we define the terms locator and identifier. Regards, Tony From wherrin@gmail.com Sat Apr 4 16:40:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9183A6829 for ; Sat, 4 Apr 2009 16:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAGnpLoNZ20J for ; Sat, 4 Apr 2009 16:40:06 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id B2BE83A67B6 for ; Sat, 4 Apr 2009 16:40:06 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so1170295yxj.37 for ; Sat, 04 Apr 2009 16:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/BIonErn7b76WXN/ze8gvn2Hy09KTtqSATNnmixT9sU=; b=nzgGfHvYOQHzz0EIDwJJ0mPjIqbQDtPqF7PuPnmdhCxVxSk70lEC5Il0P4jxcvauCg hiKeY0fURHstblli47eOMlAAyjwQpEsq++NgLe8kRiJPZOfGk4HHJVvW2/wexjtdHMTg /6Iyq0OQC9bQ4wb562x7YJh1V/5VcWk/JbJDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aYQXNEF+zJxIZlwyENSTpbO0oSFyxLpESBV9zY/MSxD+wMZrqzFCsYamxFjvAle6Ju U14Dknrhk2+UJ/ezff/xe/tx2SJ0O86GI5ySGGuyH8khmPl1nW/wu8nR/0r1sMA7O250 /NnrA2ANLAfOnf7NlaAkIGuzedFM/NlO0KsRU= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.43.14 with SMTP id q14mr1400507anq.56.1238888469634; Sat, 04 Apr 2009 16:41:09 -0700 (PDT) In-Reply-To: <49D7EC26.3020008@tony.li> References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> <49D7EC26.3020008@tony.li> Date: Sat, 4 Apr 2009 19:41:09 -0400 X-Google-Sender-Auth: 96ccbf1610220166 Message-ID: <3c3e3fca0904041641t2026d764v396ad250227c6ff4@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 23:40:08 -0000 On Sat, Apr 4, 2009 at 7:24 PM, Tony Li wrote: >>> That would make an MPLS tag an "address". Somehow I don't think so. >> >> Why not? What characteristics of what you think of as an address are >> missing from the typical use of an MPLS tag? > > Well, for one thing, an MPLS label is relative. =A0Label value X is only > meaningful pairwise between a pair of routers along the path. =A0The same > value X between any different pair of routers will imply a separate LSP a= nd > thus a different path entirely. Tony, Maybe I misunderstand how MPLS is used with respect to Internet routing. Please correct: As I understand it, an IPv4 packet arrives at [A], an MPLS encoding router. The router looks up the destination in its routing table and determines that [B], a border router to another system, should deal with the packet next. So, [A] tags the packet with "555" which means "send to router B," and then passes the packet router C which appears to currently have the shortest path to [B]. Router C knows that tag 555 means pass the packet to [B], so it sends it to router D which appears to currently have the shortest path to [B]. Rinse and repeat until it gets to [B] which knows that it owns tag 555 which means decapsulate the packet back to IPv4 and route it using the BGP table. In that use case, tag 555 is most certainly a locator within the scope of the MPLS system. I'll concede that MPLS tags are general purpose and can be programmed with other functions besides that of a locator. In theory, you could define an MPLS tag to mean "beep the speaker and then pop the stack." In practice, MPLS is used to define locators with an AS-interior scope so that only the AS border routers need to carry the BGP table and make BGP routing decisions. Or have I misrepresented how MPLS is being used as it pertains to Internet routing? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Sat Apr 4 17:03:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323AD3A6829 for ; Sat, 4 Apr 2009 17:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNPBUiIcbs5R for ; Sat, 4 Apr 2009 17:03:20 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 668CB3A6814 for ; Sat, 4 Apr 2009 17:03:20 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id bZaw1b0050cQ2SLA7c4RKK; Sun, 05 Apr 2009 00:04:25 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id bc4P1b00H3L8a8Q8Wc4Q9f; Sun, 05 Apr 2009 00:04:25 +0000 Message-ID: <49D7F56F.5050906@tony.li> Date: Sat, 04 Apr 2009 17:03:59 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: William Herrin References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> <49D7EC26.3020008@tony.li> <3c3e3fca0904041641t2026d764v396ad250227c6ff4@mail.gmail.com> In-Reply-To: <3c3e3fca0904041641t2026d764v396ad250227c6ff4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:03:21 -0000 Hi Bill, > Maybe I misunderstand how MPLS is used with respect to Internet > routing. Please correct: > > As I understand it, an IPv4 packet arrives at [A], an MPLS encoding > router. The router looks up the destination in its routing table and > determines that [B], a border router to another system, should deal > with the packet next. So, [A] tags the packet with "555" which means > "send to router B," and then passes the packet router C which appears > to currently have the shortest path to [B]. Router C knows that tag > 555 means pass the packet to [B], so it sends it to router D which > appears to currently have the shortest path to [B]. Rinse and repeat > until it gets to [B] which knows that it owns tag 555 which means > decapsulate the packet back to IPv4 and route it using the BGP table. > > In that use case, tag 555 is most certainly a locator within the scope > of the MPLS system. Even in the simplest cases, the label value is almost always allocated on a hop-by-hop basis. Thus, 555 is only valid for a single hop and the router that receives this will SWAP it for another value. The only cases where 555 itself would act as a true locator would be if someone is doing global label allocation, and that's very rare, AFAIK. There are many, many more complicated uses, especially using TE, that would also argue that a label itself is nothing but an index into a computed path. The only time you'd have an object that truly would seem to "name a point of attachment" is during signaling, when the RSVP Explicit Route Object (ERO) would contain the full path. Note that this is somewhat different than how we think of a locator, as normally we consider a locator to be an absolute name of a location, not the relative path to a location. Tony From jnc@mercury.lcs.mit.edu Sat Apr 4 17:35:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A7B3A69DF for ; Sat, 4 Apr 2009 17:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx88Gl8ry4v0 for ; Sat, 4 Apr 2009 17:35:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B26503A69A9 for ; Sat, 4 Apr 2009 17:35:46 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AF6346BE588; Sat, 4 Apr 2009 20:36:49 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090405003649.AF6346BE588@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 20:36:49 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:35:47 -0000 > From: William Herrin >> That would make an MPLS tag an "address". Somehow I don't think so. > Why not? What characteristics of what you think of as an address are > missing from the typical use of an MPLS tag? Um, because to me, an address, like its real-world prototype, says _where_ you are, in some way that anyone can grok, independent of either who they, where they are, or how they get to that destination. (Yes, NAT complicates the issue for IPv4 addresses.) An MPLS tag identifies (at best) a particular path. It identifies a particular destination only as a _side-effect_ (the same way that my land-line phone number identifies my street address as a side-effect). > From: Tony Li >>> If we really need a name for some particular crisp definition ... >>> ... pick a new word/phrase, don't try and morph an existing word. >> If the chair is amenable to that idea, so am I. > Normally, I would love that idea. However, our specific request is that > we define the terms locator and identifier. I don't see a conflict here. We can define locator and identifier, as requested - and on our own, for our own use, we can define a term to mean 'field(s) in the packet used to make next-hop forwarding decisions' - along with terms for any other meanings that seem useful to have terms for, meanings _other_ than the defined meanings for address, locator and identifier. Noel From wherrin@gmail.com Sat Apr 4 17:42:50 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4F03A6903 for ; Sat, 4 Apr 2009 17:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLxTkK9LlHHH for ; Sat, 4 Apr 2009 17:42:49 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 060373A67E7 for ; Sat, 4 Apr 2009 17:42:48 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so1109453anc.37 for ; Sat, 04 Apr 2009 17:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fS+NNl3Pd7VVTuqWfS10wfBIgq4+DwIDXGd+yuU99Vs=; b=n+MflV27wrVNjzvBfDuMWglabNYcd7yZAepViyUbqA7Z9pdOr9oE3bhnijWAGcLN/u qWtVJbzP7MP5v218b48WKsfBy1WVSi70lnHxt1XTynpZgOdUmJ4I4viiqfu9Fdbfq+2m v4H0kkHAhFMHwICi7GCXgkRV8wKBARGO9O20c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nbIwEVcGjscqN3GEFVrxKpnhyC7Mgcs2mHdEssxEYd2fEJRX6H3r/nPId7RLWXJOCs FPLANRofl2sunYJQf/w44BDURpjTcRWZe2LFEz6WZdia+uAiH0JrBMpc5sZcosj9y0O3 kvg0gbRehHLz9LfhkdaURqWodTbW8effLjBQM= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.14.10 with SMTP id 10mr4187362ann.119.1238892232947; Sat, 04 Apr 2009 17:43:52 -0700 (PDT) In-Reply-To: <49D7F56F.5050906@tony.li> References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> <49D7EC26.3020008@tony.li> <3c3e3fca0904041641t2026d764v396ad250227c6ff4@mail.gmail.com> <49D7F56F.5050906@tony.li> Date: Sat, 4 Apr 2009 20:43:52 -0400 X-Google-Sender-Auth: 223a22578142f3f3 Message-ID: <3c3e3fca0904041743v56561cd8je4551fcffa563499@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:42:50 -0000 On Sat, Apr 4, 2009 at 8:03 PM, Tony Li wrote: >> In that use case, tag 555 is most certainly a locator within the scope >> of the MPLS system. > > Even in the simplest cases, the label value is almost always allocated on= a > hop-by-hop basis. =A0Thus, 555 is only valid for a single hop and the rou= ter > that receives this will SWAP it for another value. Hi Tony, Like a frame relay DLCI. Got it now. I still argue that it's a locator under the locator definition I used. Remember, I didn't define "locator" as point of attachment here. I defined it as a type of address not used to construct an identifier while I defined an address as an element used to determine the packet's next hop. Nothing in my definition of address or locator precludes translation, even on a hop by hop basis. Translation is only obstructed in the identifier where it might interfere with the persistence requirement. >=A0Note that this is somewhat different > than how we think of a locator, as normally we consider a locator to be a= n > absolute name of a location, not the relative path to a location. Yeah, I get that. I'm suggesting that how we've been thinking about locators and identifiers is not quite right. The error was revealed by our attempt here to give them more precise definitions. They're eluding our attempts at rigor. Regards, Bill --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Sat Apr 4 17:58:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDAC3A689F for ; Sat, 4 Apr 2009 17:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxS9a5DFBLsu for ; Sat, 4 Apr 2009 17:58:29 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 0E1503A67B6 for ; Sat, 4 Apr 2009 17:58:28 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so1182445yxj.37 for ; Sat, 04 Apr 2009 17:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=HZ7EDG4PLbYLG+H1W66MFhxidZVLpCnWwbt7fV/M2Yw=; b=hOG8SOHA+Z6oob77cY0ZsXEXwCEOHzba+9VFJKMD6PfYQ4igTrqlIEB1dahoob0B/b MO9MyePp+usEilGRpoL/EZbSy63i912djtzO0C8w6j1ev0uMNwmBXE4APohVky/7cj/b LgtGKji+DtegQgl6WjBK7gxJKqhQGHJr6f6iU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j+qrXZtdTP/p7mAmXfsEVuYL4mf/JBFwxWUGwNdOxtZapuTyKskfjze+zp2UTjkaSS eRXiPlV7PErL2rK+3aXowJMm9m5rBcmIsCy2/Q69fRPWNiK1mI2GmpLfbGlnhpIGBkEs 55p8slj/RBGHTZmIAM33Uw8IfiVPNvvQukXIU= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.134.10 with SMTP id h10mr5515812and.31.1238893172662; Sat, 04 Apr 2009 17:59:32 -0700 (PDT) In-Reply-To: <20090405003649.AF6346BE588@mercury.lcs.mit.edu> References: <20090405003649.AF6346BE588@mercury.lcs.mit.edu> Date: Sat, 4 Apr 2009 20:59:32 -0400 X-Google-Sender-Auth: 095a6cfc3e0e8e46 Message-ID: <3c3e3fca0904041759i5bb559e3rf3e54d7d98bb315f@mail.gmail.com> From: William Herrin To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:58:30 -0000 On Sat, Apr 4, 2009 at 8:36 PM, Noel Chiappa wrot= e: > =A0 =A0> From: William Herrin > =A0 =A0>> That would make an MPLS tag an "address". Somehow I don't think= so > =A0 =A0> Why not? What characteristics of what you think of as an address= are > =A0 =A0> missing from the typical use of an MPLS tag? > > Um, because to me, an address, like its real-world prototype, says _where= _ > you are, in some way that anyone can grok, independent of either who they= , > where they are, or how they get to that destination. (Yes, NAT complicate= s > the issue for IPv4 addresses.) Hi Noel, You can send mail to my mother via the postal address: General Delivery Dora, MO That address probably fails to reveal that she lives just north of Kitty Hawk NC. Defining address in terms of where you are, whether geographically or topologically, offers a very slippery definition. It's hard to give it any kind of rigor in the face of anycast, multicast and load balancing. > =A0 =A0> Normally, I would love that idea. However, our specific request = is that > =A0 =A0> we define the terms locator and identifier. > > I don't see a conflict here. I'd like to a see a definition of locator and identifier which is rigorous and consistent both with our theoretical constructs and with existing network protocols. Giving the community a sloppy definition of identifier and locator would diminish us. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Sat Apr 4 20:52:20 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBE83A6A65 for ; Sat, 4 Apr 2009 20:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVCNk3R3Aj0E for ; Sat, 4 Apr 2009 20:52:19 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 4B1DC3A68C1 for ; Sat, 4 Apr 2009 20:52:19 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id bfRe1b0010lTkoCA6ftQx4; Sun, 05 Apr 2009 03:53:24 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id bftN1b00E3L8a8Q8QftPzn; Sun, 05 Apr 2009 03:53:24 +0000 Message-ID: <49D82B0E.5010106@tony.li> Date: Sat, 04 Apr 2009 20:52:46 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: William Herrin References: <20090404155049.6E0D26BE570@mercury.lcs.mit.edu> <3c3e3fca0904041525l55a8e0d8n973555c369ea8274@mail.gmail.com> <49D7EC26.3020008@tony.li> <3c3e3fca0904041641t2026d764v396ad250227c6ff4@mail.gmail.com> <49D7F56F.5050906@tony.li> <3c3e3fca0904041743v56561cd8je4551fcffa563499@mail.gmail.com> In-Reply-To: <3c3e3fca0904041743v56561cd8je4551fcffa563499@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 03:52:20 -0000 Hi Bill, > Like a frame relay DLCI. Got it now. Exactly. > I still argue that it's a locator under the locator definition I used. > Remember, I didn't define "locator" as point of attachment here. I > defined it as a type of address not used to construct an identifier > while I defined an address as an element used to determine the > packet's next hop. > > Nothing in my definition of address or locator precludes translation, > even on a hop by hop basis. Translation is only obstructed in the > identifier where it might interfere with the persistence requirement. I agree that translation is not that big a deal as long as it isn't happening due to a namespace boundary or scope boundary (e.g., NAT). However, I'm still not ready to roll labels, VCI, DLCI, and X.25 paths (and for that matter, the Atomic link layer path) into our definition of 'locator'. I'd much prefer to take the opportunity to distinguish those and use something like 'path' to describe those. > Yeah, I get that. I'm suggesting that how we've been thinking about > locators and identifiers is not quite right. The error was revealed by > our attempt here to give them more precise definitions. They're > eluding our attempts at rigor. Ok, enlightenment is most welcome. ;-) Must be accompanied by alternate text tho. Cheers, Tony From brian.e.carpenter@gmail.com Sun Apr 5 19:23:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D053A67D6 for ; Sun, 5 Apr 2009 19:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57CEqTIcxchb for ; Sun, 5 Apr 2009 19:23:03 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id BD75A3A67EE for ; Sun, 5 Apr 2009 19:22:52 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l24so942812waf.23 for ; Sun, 05 Apr 2009 19:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RO9TCRQEDg1qM3rkLfX0vF0k3ilpeJYgJpCFSfrmDoE=; b=FarS6ifTSMC7BJilV0IEbCxbZVAVGabokOD5oi25rTj5o4b4HkjjIc85D34JPpk3V1 3bUKHHwy3owYKcQmifDTfkhhBoXPiewQUoAlhZCj5ih6OhVZWc+MVnQU0DRBN75gM0Hm NyjbJnR/gxs3klzIeFA5XQ3blIZ3PHScV9dfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=a5J0Ltfr5Xgk46kAbYyOsQDHTSWneD5RIF80oWRO77ijn6gQUQfhMxeqg7owz65pMD fY1Nv5m1V+SL4gR3FIxS6339eN5aRTm7wrWCahk5D7ImUDuSsjZrM/UBI4K1+8tGrkbL +AVWNJB4v9anJi6uKJvFZU5X3RVRrk9FZ0wz8= Received: by 10.114.59.1 with SMTP id h1mr1996197waa.87.1238984638196; Sun, 05 Apr 2009 19:23:58 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l30sm4946834waf.69.2009.04.05.19.23.56 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 19:23:57 -0700 (PDT) Message-ID: <49D967B1.3080108@gmail.com> Date: Mon, 06 Apr 2009 14:23:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> In-Reply-To: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 02:23:04 -0000 On 2009-04-05 04:35, Noel Chiappa wrote: ... > 'locator: name of a location in the network connectivity graph' Oh. Finally a version that appears to be logically complete and unambiguous. Thanks. Brian From jnc@mercury.lcs.mit.edu Mon Apr 6 07:39:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774C33A6C94 for ; Mon, 6 Apr 2009 07:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8fKivztZl94 for ; Mon, 6 Apr 2009 07:39:13 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id AF5CF3A6C6C for ; Mon, 6 Apr 2009 07:39:10 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 86A0C6BE56B; Mon, 6 Apr 2009 10:40:15 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090406144015.86A0C6BE56B@mercury.lcs.mit.edu> Date: Mon, 6 Apr 2009 10:40:15 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 14:39:19 -0000 > From: Brian E Carpenter >> 'locator: name of a location in the network connectivity graph' > a version that appears to be logically complete and unambiguous. Did you want to expand it to include the ability to name chunks of the network, too? I.e. 'name of either i) a location in the network connectivity graph, or ii) a contiguous portion of the network'? For routing purposes, one usually has to name areas of the network... Noel From jnc@mercury.lcs.mit.edu Mon Apr 6 10:46:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776153A6D08 for ; Mon, 6 Apr 2009 10:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvumEYBA2vbU for ; Mon, 6 Apr 2009 10:46:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7FAD13A6C81 for ; Mon, 6 Apr 2009 10:46:39 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 413726BE570; Mon, 6 Apr 2009 13:47:44 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090406174744.413726BE570@mercury.lcs.mit.edu> Date: Mon, 6 Apr 2009 13:47:44 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: [rrg] Some ancient history... X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:46:40 -0000 In researching a message to the Internet-History mailing list, I came across an interesting piece of old history. Note the definition of "forwarding selector"! Noel -------- Date: Mon, 16 Aug 93 23:09:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9308170309.AA07638@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Terminology problems This mailing list is having severe terminology conflicts over the term "address". One person uses it in a message, assuming *their* personal definition, and someone else reads the message using a *different* personal definition, and hey presto, instant miscommunication (on the world's most powerful communication network, sigh :-). I suggest we either a) agree on one meaning to solve this, or b) stop using the term altogether. Lets not argue interminably over terminology: if, at the end of 48 hours, we don't achieve a), I will adopt b), and basically ignore all message with the term "address" in them. Here are a list of suggested terms and definitions: "address" - The structured name of an attachment point to the network. The structure is used by the routing to make its (difficult :-) job a little easier. I believe it is an inescapable truth, (and have so argued at length :-) that things which have related addresses must be topologically related, or else the routing will break down, but let's leave that for a bit. The address might or might not appear in all packets (see "f-selector"). "interface name", "i-name" - Alternative name for the above, if we don't agree to call it an "address". "forwarding selector", "f-selector" - The field in the packets which the routers look at to decide where to send the packet next. In X.25, the f-selector si the VC-ID, in IPv4, the 'destination IP address'. "host identifier", "h-id" - A name (*not* an ASCII string), probably globally unique, for a host; the current IPv4 'address' has this as one of its current functions. (Much the same as an EID, for those who understand that term.) Will the normally quiet "listeners" out there *please* speak up, if this set of terms is to your liking? If I have missed any possible meaning which is currently attached to the term 'address' by anyone, or anyone sees a use for some other term, send it in. I also suggest everyone read RFC-1498, but Saltzer, *without delay*, if you have not already done so. It provide a very clear, and *essential*, framework for all discussions of object naming in networks. From brian.e.carpenter@gmail.com Mon Apr 6 14:40:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E415F3A67E3 for ; Mon, 6 Apr 2009 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK+I7Z65Otyq for ; Mon, 6 Apr 2009 14:40:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 39F053A6866 for ; Mon, 6 Apr 2009 14:40:34 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g9so2203660rvb.7 for ; Mon, 06 Apr 2009 14:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=s414w1NvAfuRStxijuxb/cAr2/xMo0Wx7YDgf4an2GA=; b=hfKczZnuTMF3xOVJWCB8zV4quPK2SIZr6ZVYf0uNxewTWR2yyddZyB+3226AHrLTpu OF6oAhilaQ/Ya2koiVACKBvoa1BHJgNwXDwlgGmFKQw31885ATX6b7ni40dvFWlHkal3 DznQ5AXPSf/JasSu3UDKEcRzskLvqBHApiSNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=QHvTquyyP3BeBE6U/M+yTondCVKtn7tlLq90tAYKPBeUCUbjL3MXRmkzIzVASHWyYy 1CckRRdFyoism7xJAfEF0UVVIboMRLQzyII10y6ORMqGVw7H/JsSCMbu0m87ubAcf9O1 VAySoYhsuO6g2MbT0CC8JQwbPRslmmyXO2WQY= Received: by 10.141.196.8 with SMTP id y8mr1576881rvp.101.1239054100293; Mon, 06 Apr 2009 14:41:40 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id g22sm19772133rvb.23.2009.04.06.14.41.38 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 14:41:39 -0700 (PDT) Message-ID: <49DA770E.6050308@gmail.com> Date: Tue, 07 Apr 2009 09:41:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20090406144015.86A0C6BE56B@mercury.lcs.mit.edu> In-Reply-To: <20090406144015.86A0C6BE56B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 21:40:35 -0000 On 2009-04-07 02:40, Noel Chiappa wrote: > > From: Brian E Carpenter > > >> 'locator: name of a location in the network connectivity graph' > > > a version that appears to be logically complete and unambiguous. > > Did you want to expand it to include the ability to name chunks of the > network, too? > > I.e. 'name of either i) a location in the network connectivity graph, or ii) > a contiguous portion of the network'? > > For routing purposes, one usually has to name areas of the network... I could argue, given that the Internet is a network of networks, that your definition already covers this recursively. Then, we can argue for some time whether an AS# is a locator ;-) Brian From tony.li@tony.li Tue Apr 7 20:52:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C283A6E37 for ; Tue, 7 Apr 2009 20:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhWIAMbqzp8A for ; Tue, 7 Apr 2009 20:52:08 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id C47A63A6A27 for ; Tue, 7 Apr 2009 20:52:08 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id cdl31b0090lTkoCA9rtGS7; Wed, 08 Apr 2009 03:53:16 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id crtE1b00J3L8a8Q8QrtF9F; Wed, 08 Apr 2009 03:53:16 +0000 Message-ID: <49DC1F92.7000408@tony.li> Date: Tue, 07 Apr 2009 20:52:50 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 03:52:09 -0000 Hi all, As the conversation has died down, I'm going to guess that we've converged. The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99 Please vote for or against these definitions: locator A locator is a name for a point of attachment within the topology at a given layer. Objects that change their point of attachment(s) will need to change their associated locator(s). By default, a locator refers to layer 3. It is also possible to have locators at other layers. Locators may have other properties, such as their scope (local or global (default)) and their lifetime (ephemeral or permanent (default)). identifier An identifier is the name of an object at a given layer; identifiers have no topological sensitivity, and do not have to change, even if the object changes its point(s) of attachment within the network topology. Identifiers may have other properties, such as the scope of their uniqueness (local or global (default)), the probability of their uniqueness (statistical or absolute (default)), and their lifetime (ephemeral or permanent (default)). address An address is a name that is used as both an interface locator and an endpoint identifier. Tony From jmh@joelhalpern.com Tue Apr 7 21:10:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA443A6A27 for ; Tue, 7 Apr 2009 21:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwoaod04AVtp for ; Tue, 7 Apr 2009 21:10:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 960F93A68A5 for ; Tue, 7 Apr 2009 21:10:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D0CF143043E; Tue, 7 Apr 2009 21:11:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3885643043A; Tue, 7 Apr 2009 21:11:13 -0700 (PDT) Message-ID: <49DC23DE.2060206@joelhalpern.com> Date: Wed, 08 Apr 2009 00:11:10 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> In-Reply-To: <49DC1F92.7000408@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 04:10:08 -0000 Close enough for me. Joel Tony Li wrote: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: > http://doodle.com/9sybb8dmk5phvp99 > > Please vote for or against these definitions: > > locator A locator is a name for a point of attachment within the > topology at a given layer. Objects that change their point > of attachment(s) will need to change their associated > locator(s). By default, a locator refers to layer 3. It > is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). > > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. Identifiers may > have other properties, such as the scope of their > uniqueness (local or global (default)), the probability of > their uniqueness (statistical or absolute (default)), and > their lifetime (ephemeral or permanent (default)). > > address An address is a name that is used as both an interface > locator and an endpoint identifier. > > > > Tony > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From menth@informatik.uni-wuerzburg.de Wed Apr 8 00:10:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8FD3A6E4A for ; Wed, 8 Apr 2009 00:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdf2wU0kA1H4 for ; Wed, 8 Apr 2009 00:10:18 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 422BE3A6E49 for ; Wed, 8 Apr 2009 00:10:17 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 99A801990F5; Wed, 8 Apr 2009 09:11:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8C9E31990E9; Wed, 8 Apr 2009 09:11:23 +0200 (CEST) Received: from [78.51.146.90] (f051146090.adsl.alicedsl.de [78.51.146.90]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5290E1990D5; Wed, 8 Apr 2009 09:11:23 +0200 (CEST) Message-ID: <49DC4E1C.1040905@informatik.uni-wuerzburg.de> Date: Wed, 08 Apr 2009 09:11:24 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> In-Reply-To: <49DC1F92.7000408@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 07:10:19 -0000 Hi Tony, I haven't followed all the discussions. What I am missing is the definition of an endpoint identifier. Is it the name of a device attached at a certain location, i.e. an ephemeral identifier for that box (not interface) because it can be replaced by others and so that name is not permanent? That's just a guess and an extrapolation from its use in LISP according to my understanding. But it's not given in the text. Apart from that, the definitions seem clear to me. Regards, Michael Tony Li schrieb: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: > http://doodle.com/9sybb8dmk5phvp99 > > Please vote for or against these definitions: > > locator A locator is a name for a point of attachment within the > topology at a given layer. Objects that change their point > of attachment(s) will need to change their associated > locator(s). By default, a locator refers to layer 3. It > is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). > > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. Identifiers may > have other properties, such as the scope of their > uniqueness (local or global (default)), the probability of > their uniqueness (statistical or absolute (default)), and > their lifetime (ephemeral or permanent (default)). > > address An address is a name that is used as both an interface > locator and an endpoint identifier. > > > > Tony > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From kafle@nict.go.jp Wed Apr 8 00:26:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E716A3A6873 for ; Wed, 8 Apr 2009 00:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6W549iu5jOV for ; Wed, 8 Apr 2009 00:26:48 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 4C13A3A6767 for ; Wed, 8 Apr 2009 00:26:46 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n387Rqh9020496 for ; Wed, 8 Apr 2009 16:27:52 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n387RqoI017872 for ; Wed, 8 Apr 2009 16:27:52 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n387RqQs017869 for ; Wed, 8 Apr 2009 16:27:52 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 0FC832C1FF for ; Wed, 8 Apr 2009 16:27:52 +0900 (JST) Received: from kaflenote2 (ssh.nict.go.jp [133.243.3.49]) by mail3.nict.go.jp (NiCT Mail) with ESMTP id 0988E4D6C for ; Wed, 8 Apr 2009 16:27:52 +0900 (JST) From: "Ved Kafle" To: References: <49DC1F92.7000408@tony.li> Date: Wed, 8 Apr 2009 16:27:49 +0900 Message-ID: <5EA9BC5226A34B6DA5A51B89AF39220E@kaflenote2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49DC1F92.7000408@tony.li> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acm3/ZMk+c/9igydQbymOzfMpRhIQgAG/44w Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 07:26:49 -0000 How about slightly modifying the definition of address to indicate that an address is, by default, a locator? It can be treated as an identitier when it goes into network protocols of layer 4 and above. Ved Kafle -----Original Message----- From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of Tony Li Sent: Wednesday, April 08, 2009 12:53 PM To: rrg@irtf.org Subject: [rrg] Consensus check: terminology Hi all, As the conversation has died down, I'm going to guess that we've converged. The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99 Please vote for or against these definitions: locator A locator is a name for a point of attachment within the topology at a given layer. Objects that change their point of attachment(s) will need to change their associated locator(s). By default, a locator refers to layer 3. It is also possible to have locators at other layers. Locators may have other properties, such as their scope (local or global (default)) and their lifetime (ephemeral or permanent (default)). identifier An identifier is the name of an object at a given layer; identifiers have no topological sensitivity, and do not have to change, even if the object changes its point(s) of attachment within the network topology. Identifiers may have other properties, such as the scope of their uniqueness (local or global (default)), the probability of their uniqueness (statistical or absolute (default)), and their lifetime (ephemeral or permanent (default)). address An address is a name that is used as both an interface locator and an endpoint identifier. Tony _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Wed Apr 8 01:14:28 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DD93A6A46 for ; Wed, 8 Apr 2009 01:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-oSQowj5tJw for ; Wed, 8 Apr 2009 01:14:27 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 97EDF3A69A7 for ; Wed, 8 Apr 2009 01:14:27 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id cwBi1b0040x6nqcABwFbfH; Wed, 08 Apr 2009 08:15:35 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id cwFZ1b0073L8a8Q8YwFal3; Wed, 08 Apr 2009 08:15:35 +0000 Message-ID: <49DC5CFF.6060302@tony.li> Date: Wed, 08 Apr 2009 01:14:55 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <49DC1F92.7000408@tony.li> <49DC4E1C.1040905@informatik.uni-wuerzburg.de> In-Reply-To: <49DC4E1C.1040905@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:14:28 -0000 Michael Menth wrote: > Hi Tony, > > I haven't followed all the discussions. What I am missing is the > definition of an endpoint identifier. Is it the name of a device > attached at a certain location, i.e. an ephemeral identifier for that > box (not interface) because it can be replaced by others and so that > name is not permanent? That's just a guess and an extrapolation from its > use in LISP according to my understanding. But it's not given in the text. > > Apart from that, the definitions seem clear to me. Hi Michael, Along the way, we decided to separate the properties from the objects. Thus, in defining an 'identifier', we're defining entire classes of namespaces. Our agreement is that the object can then be attached independently of this. Thus, one can have an endpoint identifier, an interface identifier, a stack identifier, etc. Regards, Tony From tony.li@tony.li Wed Apr 8 01:15:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3967E3A6A46 for ; Wed, 8 Apr 2009 01:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPfRaVYIOPxR for ; Wed, 8 Apr 2009 01:15:40 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 563D53A67E6 for ; Wed, 8 Apr 2009 01:15:40 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id cwG71b0010FhH24A5wGoJE; Wed, 08 Apr 2009 08:16:48 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id cwGm1b0013L8a8Q8UwGn8l; Wed, 08 Apr 2009 08:16:48 +0000 Message-ID: <49DC5D48.5010409@tony.li> Date: Wed, 08 Apr 2009 01:16:08 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ved Kafle References: <49DC1F92.7000408@tony.li> <5EA9BC5226A34B6DA5A51B89AF39220E@kaflenote2> In-Reply-To: <5EA9BC5226A34B6DA5A51B89AF39220E@kaflenote2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:15:41 -0000 Ved Kafle wrote: > How about slightly modifying the definition of address to indicate that an > address is, by default, a locator? It can be treated as an identitier when > it goes into network protocols of layer 4 and above. Hi Ved, I think we already have that. > address An address is a name that is used as both an interface > locator and an endpoint identifier. Thus, an address is both a locator and identifier. Tony From menth@informatik.uni-wuerzburg.de Wed Apr 8 01:46:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC183A696C for ; Wed, 8 Apr 2009 01:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moxmzjDXXWtW for ; Wed, 8 Apr 2009 01:46:18 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 511F83A63EC for ; Wed, 8 Apr 2009 01:46:18 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5702019910A; Wed, 8 Apr 2009 10:47:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4B21A199102; Wed, 8 Apr 2009 10:47:23 +0200 (CEST) Received: from [78.51.146.90] (f051146090.adsl.alicedsl.de [78.51.146.90]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 15227A0676; Wed, 8 Apr 2009 10:47:23 +0200 (CEST) Message-ID: <49DC649C.1020900@informatik.uni-wuerzburg.de> Date: Wed, 08 Apr 2009 10:47:24 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> <49DC4E1C.1040905@informatik.uni-wuerzburg.de> <49DC5CFF.6060302@tony.li> In-Reply-To: <49DC5CFF.6060302@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:46:19 -0000 Hi Tony, this does not really answer my question. Let me rephrase it: what is an endpoint? Regards, Michael Tony Li schrieb: > Michael Menth wrote: >> Hi Tony, >> >> I haven't followed all the discussions. What I am missing is the >> definition of an endpoint identifier. Is it the name of a device >> attached at a certain location, i.e. an ephemeral identifier for that >> box (not interface) because it can be replaced by others and so that >> name is not permanent? That's just a guess and an extrapolation from >> its use in LISP according to my understanding. But it's not given in >> the text. >> >> Apart from that, the definitions seem clear to me. > > > Hi Michael, > > Along the way, we decided to separate the properties from the objects. > Thus, in defining an 'identifier', we're defining entire classes of > namespaces. Our agreement is that the object can then be attached > independently of this. Thus, one can have an endpoint identifier, an > interface identifier, a stack identifier, etc. > > Regards, > Tony -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From swb@employees.org Wed Apr 8 04:02:46 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E9B3A6E67 for ; Wed, 8 Apr 2009 04:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AtLggNt3KLc for ; Wed, 8 Apr 2009 04:02:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B57623A6A3B for ; Wed, 8 Apr 2009 04:02:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,344,1235952000"; d="scan'208";a="41270043" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2009 11:03:44 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n38B3h8b014930; Wed, 8 Apr 2009 07:03:43 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n38B3hx5015233; Wed, 8 Apr 2009 11:03:43 GMT Date: Wed, 8 Apr 2009 07:03:43 -0400 From: Scott Brim To: Tony Li Message-ID: <20090408110343.GG507@cisco.com> Mail-Followup-To: Scott Brim , Tony Li , rrg@irtf.org References: <49DC1F92.7000408@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DC1F92.7000408@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:02:46 -0000 Excerpts from Tony Li on Tue, Apr 07, 2009 08:52:50PM -0700: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: > http://doodle.com/9sybb8dmk5phvp99 Ouch. I had to go do my day job for a couple of days. I'll be back soon. Please don't close this. From bless@tm.uka.de Wed Apr 8 04:20:36 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93133A68DA for ; Wed, 8 Apr 2009 04:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqMbKVskXQ6e for ; Wed, 8 Apr 2009 04:20:36 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id CA9773A6B0F for ; Wed, 8 Apr 2009 04:20:35 -0700 (PDT) Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1LrVqc-0005Jt-Bl; Wed, 08 Apr 2009 13:21:41 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 144CF2FC015; Wed, 8 Apr 2009 13:21:38 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id E187210083; Wed, 8 Apr 2009 13:21:37 +0200 (CEST) Message-ID: <49DC88C1.5020405@tm.uka.de> Date: Wed, 08 Apr 2009 13:21:37 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <49DC1F92.7000408@tony.li> <49DC4E1C.1040905@informatik.uni-wuerzburg.de> <49DC5CFF.6060302@tony.li> <49DC649C.1020900@informatik.uni-wuerzburg.de> In-Reply-To: <49DC649C.1020900@informatik.uni-wuerzburg.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:20:36 -0000 Hi Michael, Michael Menth wrote: > this does not really answer my question. Let me rephrase it: what is an > endpoint? What the term endpoint denotes depends on which level/layer you are looking at: do you mean "host/end-system endpoint" or "transport connection endpoint" or "application endpoint" etc.? In case you mean an identifier for a "host" (which could be virtual BTW), the given identifier definition applies, too. I don't see anything special there. It's sure that also some locators/addresses will lead to the "host" (or its interfaces/stacks) in order to deliver data to it. Regards, Roland From menth@informatik.uni-wuerzburg.de Wed Apr 8 04:27:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E692A3A6B20 for ; Wed, 8 Apr 2009 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQsbkub0iHE9 for ; Wed, 8 Apr 2009 04:27:08 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id E1BD53A6B13 for ; Wed, 8 Apr 2009 04:27:07 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5D957A07C3; Wed, 8 Apr 2009 13:28:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 503D1A07BC; Wed, 8 Apr 2009 13:28:14 +0200 (CEST) Received: from [78.51.146.90] (f051146090.adsl.alicedsl.de [78.51.146.90]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 16F5DA07B1; Wed, 8 Apr 2009 13:28:14 +0200 (CEST) Message-ID: <49DC8A4E.6060900@informatik.uni-wuerzburg.de> Date: Wed, 08 Apr 2009 13:28:14 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Roland Bless References: <49DC1F92.7000408@tony.li> <49DC4E1C.1040905@informatik.uni-wuerzburg.de> <49DC5CFF.6060302@tony.li> <49DC649C.1020900@informatik.uni-wuerzburg.de> <49DC88C1.5020405@tm.uka.de> In-Reply-To: <49DC88C1.5020405@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:27:09 -0000 Hi Roland, apparently an endpoint can be multiple things. Therefore, I suggest to add a defintion for an endpoint. It sounds like a name of a source or target in communication on some layer. Examples would be helpful. Regards, Michael Roland Bless schrieb: > Hi Michael, > > Michael Menth wrote: > >> this does not really answer my question. Let me rephrase it: what is an >> endpoint? >> > > What the term endpoint denotes depends on which level/layer you are > looking at: do you mean "host/end-system endpoint" or > "transport connection endpoint" or "application endpoint" etc.? > In case you mean an identifier for a "host" (which could be virtual > BTW), the given identifier definition applies, too. I don't see anything > special there. It's sure that also some locators/addresses will > lead to the "host" (or its interfaces/stacks) in order to deliver > data to it. > > Regards, > Roland > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From wherrin@gmail.com Wed Apr 8 07:27:28 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EBA3A69C4 for ; Wed, 8 Apr 2009 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lh9DyQMCsV8 for ; Wed, 8 Apr 2009 07:27:27 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 5F4613A67FA for ; Wed, 8 Apr 2009 07:27:27 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so87434anc.37 for ; Wed, 08 Apr 2009 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=WRGElSOUKt7DC1HBEyfX8sMMPj/nWpyIiBbT9gpMjis=; b=PfRWx0Gnrzg6TK5nHhLcjFD7lnuYGEBFHRQpNFtfaxqMpknIH6kSn/zkRnGqeMOBPo A2/9L4JdkFrEvg9zPBNzS1KS+Lek/+nnC4UAOTlPZv5c2oEzo8YqwE7OuwnlaSrDGPji d0KRIIS01npDPtgdn6ZDH7D6weSu8SV7T3MgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SYHp84Z21PJD+a7ngIcub5EhBGGJgN0Sd4CZWMub4qxcACYiOOdXhy+cqbwSneWzEG OMNUX+237r1BgT4hE/ITVFqYoEta9XPlyrpo3aHk1BmV81uYtbVdHSoJYUnwhtljGWbn RqwfLWs6iWkHhj1Q4HWsRvRNAveH7M9LYXDD4= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.11.14 with SMTP id 14mr3116150ank.88.1239200914028; Wed, 08 Apr 2009 07:28:34 -0700 (PDT) In-Reply-To: <49DC1F92.7000408@tony.li> References: <49DC1F92.7000408@tony.li> Date: Wed, 8 Apr 2009 10:28:33 -0400 X-Google-Sender-Auth: f7a86420c95d1bb2 Message-ID: <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:27:28 -0000 On Tue, Apr 7, 2009 at 11:52 PM, Tony Li wrote: > As the conversation has died down, I'm going to guess that we've converge= d. > =A0The consensus check can be found here: http://doodle.com/9sybb8dmk5phv= p99 Tony, Looks like I get to play lonely voice of dissent: these definitions don't provide me with a useful language to talk about routing. With these definitions adopted, I would need to strip the words from most of the documents I've produced as they simply don't fit. In addition, the definition of address is demonstrably wrong. > address =A0 =A0An address is a name that is used as both an interface > =A0 =A0 =A0 =A0 =A0 locator and an endpoint identifier. Counterexample #1: RFC1918 IP addresses used inside a LAN consisting of a personal computer, an ethernet hub and a NAT device. The IP address in this example contains no locator semantics whatsoever, at least not as you've defined a locator. Counterexample #2: The IP address of an anycasted DNS service. The IP address neither identifies an endpoint nor locates a particular interface's points of attachment to the network. Instead it identifies a service and specifies multiple locations via which that service can be obtained. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dow.street@linquest.com Wed Apr 8 08:15:37 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDC13A68DA for ; Wed, 8 Apr 2009 08:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSsX9zGer+zt for ; Wed, 8 Apr 2009 08:15:36 -0700 (PDT) Received: from smtp115.iad.emailsrvr.com (smtp115.iad.emailsrvr.com [207.97.245.115]) by core3.amsl.com (Postfix) with ESMTP id 951F83A69B7 for ; Wed, 8 Apr 2009 08:15:36 -0700 (PDT) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8F9E51B4061; Wed, 8 Apr 2009 11:16:43 -0400 (EDT) Received: by relay31.relay.iad.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 229E71B4025; Wed, 8 Apr 2009 11:16:43 -0400 (EDT) Message-Id: <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> From: Dow Street To: Tony Li In-Reply-To: <49DC1F92.7000408@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 08:16:40 -0700 References: <49DC1F92.7000408@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:15:37 -0000 On Apr 7, 2009, at 8:52 PM, Tony Li wrote: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: http://doodle.com/9sybb8dmk5phvp99 > > Please vote for or against these definitions: > > locator A locator is a name for a point of attachment within the > topology at a given layer. Objects that change their point > of attachment(s) will need to change their associated > locator(s). By default, a locator refers to layer 3. It > is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). Also tied up with day job stuff recently... I don't think this one is quite there yet since it doesn't directly address the question of how (a) namespace semantics and (b) the associated routing system are involved in characterizing the name of an attachment point as a locator (or not). I think some of this relation is implied in the language above, but it is still fuzzy... Using the postal example, 123 High Street, Bigtown, Green County, Outer Luvania We would agree (I think) that if an object / person moved next door, and still wanted to be reachable, it would need to use a different locator (say, 125 High Street). However, what if larger sections of the geography itself move - perhaps today Green County is beside Blue County, but tomorrow it is next to Red County. Some of the location information is stored outside the locator itself - in a map of some sort. This map could be a static reference that all components of the system are aware of through outside means (e.g. a traditional geographic map), or it could be a dynamic map (e.g. the current system state of a routing system). Depending on the nature of the "change to the point of attachment", and the characteristics of the system geography and map of that geography, the (i) locator name may need to change or the (ii) map itself may need to change. R, Dow From lear@cisco.com Wed Apr 8 08:43:53 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D59B3A6A32 for ; Wed, 8 Apr 2009 08:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.688 X-Spam-Level: X-Spam-Status: No, score=-9.688 tagged_above=-999 required=5 tests=[AWL=0.911, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg79deFcLSax for ; Wed, 8 Apr 2009 08:43:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0ACA33A68FE for ; Wed, 8 Apr 2009 08:43:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,345,1235952000"; d="scan'208";a="37776716" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2009 15:44:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n38FiwkW007258; Wed, 8 Apr 2009 17:44:58 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp6540.cisco.com [10.61.89.139]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n38Fival023272; Wed, 8 Apr 2009 15:44:58 GMT Message-ID: <49DCC679.5030801@cisco.com> Date: Wed, 08 Apr 2009 17:44:57 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090408 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> In-Reply-To: <49DC1F92.7000408@tony.li> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2241; t=1239205498; x=1240069498; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Consensus=20check=3A=20terminol ogy |Sender:=20; bh=YkxluxV4Puw6LsYJ//pXUqb0Oa1xXepkkQj5RRXH9bs=; b=dDVnSIkbj98/McsjD2zK9iIG3u73EA275sqi1vqyQKQ52MjztVmHKtodfn um7zKqBWX7LMEqt1Ja1E/eVH/J/PZd2hOgMisCFwokr2E5YVR9EUWGfbWKYv PnPK6KB+K4; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:43:53 -0000 I'm sorry for not paying attention for a while, Tony, but I think we can improve on the wording by reducing it. On 4/8/09 5:52 AM, Tony Li wrote: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: > http://doodle.com/9sybb8dmk5phvp99 > > Please vote for or against these definitions: > > locator A locator is a name for a point of attachment within the > topology at a given layer. Objects that change their point > of attachment(s) will need to change their associated > locator(s). By default, a locator refers to layer 3. It > is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). I propose generic definitions and then applying them in specific cases. Hence... A locator is a value or string that specifies location of an object within a physical or logical topology. > > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. Identifiers may > have other properties, such as the scope of their > uniqueness (local or global (default)), the probability of > their uniqueness (statistical or absolute (default)), and > their lifetime (ephemeral or permanent (default)). An identifier is a value or string that references a specific object or group of objects. The discussion of lifetime is relevant in the context of binding an identity to various properties. Some properties are permanent, and some are ephemeral. I will probably always have the same blood type, but my location changes. In the case of a host, its name may stay the same, perhaps even its distinguished name, but its private and public keys may or may not change, even when its address does change. In this discussion please keep in mind both host names and how GSLBs tend to work. Eliot From jnc@mercury.lcs.mit.edu Wed Apr 8 09:14:37 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1235A3A6B36 for ; Wed, 8 Apr 2009 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ5PpjPULscE for ; Wed, 8 Apr 2009 09:14:36 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5C8493A6B20 for ; Wed, 8 Apr 2009 09:14:36 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6E3F56BE56B; Wed, 8 Apr 2009 12:15:42 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> Date: Wed, 8 Apr 2009 12:15:42 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:14:37 -0000 > From: William Herrin > these definitions don't provide me with a useful language to talk about > routing. I agree - but the solution is not to warp these terms into meanings useful to routing; rather, define some _more_ terms which are useful for that. > In addition, the definition of address is demonstrably wrong. > ... > Counterexample #2: The IP address of an anycasted DNS service. True. So change the definition to be "a name that is usually used", and in the expanded text, mention that multicast, anycast, etc don't fit within that last part of that definition. There is simply no way to produce a definition which both i) completely and accurately describes all the uses to which an IPvN address is currently put, and ii) is short and crisp. Noel From jnc@mercury.lcs.mit.edu Wed Apr 8 09:37:49 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E065628C10A for ; Wed, 8 Apr 2009 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oax7Zr0Iu6aY for ; Wed, 8 Apr 2009 09:37:49 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 253373A6B58 for ; Wed, 8 Apr 2009 09:37:49 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 168516BE56B; Wed, 8 Apr 2009 12:38:56 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090408163856.168516BE56B@mercury.lcs.mit.edu> Date: Wed, 8 Apr 2009 12:38:56 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:37:50 -0000 {Found in an editor buffer - sorry if this is a bit late.} > From: William Herrin > I'm suggesting that how we've been thinking about locators and > identifiers is not quite right. The error was revealed by our attempt > here to give them more precise definitions. They're eluding our > attempts at rigor. The problem is not that past thinking was lacking in rigor. (Please note that the _original_ published definition of 'locator' was _extremely_ rigorous - it meant a hierarchically structured name for a map node.) The problem, _in part_, is that the terms, _over time_, have come to have somewhat different meanings to different people. Hence my prior comment: >> the best we can do for the Big Three (address, locator, identifier) is >> to come up with definitions which reasonly match what they mean to >> _most_ people now, and hope that the outliers eventually give up on >> their idiosyncratic personal definitions ... >> ... Note that the definitions for those three will have to be a little >> 'loose', because if you make them _more_ specific, you will start to >> loose people from the "_most_ people" pot above. (I said 'in part' because _some_ people probably aren't thinking about this rigorously.) But the point remains that much as you and I might want rigor, that attempt will inevitably do a Titanic when faced with actual usage in a wide community. > Defining address in terms of where you are .. topologically [is not > very plausible] The term 'address', perhaps, for the reasons you give below (although I would claim this doesn't apply to 'locator'). > ... offers a very slippery definition. It's hard to give it any kind of > rigor in the face of anycast, multicast and load balancing. Not to mention its use at the transport layer to name the entity at the other end of a reliable end-end connection.... But you are absolutely right - 'address' is probably irretrievably broken. The best we can do, probably, is say something akin to 'as used in deployed IPv4', and then list its uses there. Noel From bless@tm.uka.de Wed Apr 8 13:05:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E573A6B54 for ; Wed, 8 Apr 2009 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmhOGUpYw+wF for ; Wed, 8 Apr 2009 13:05:17 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 38D603A69EB for ; Wed, 8 Apr 2009 13:05:17 -0700 (PDT) Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Lre2N-0005h5-L0; Wed, 08 Apr 2009 22:06:22 +0200 Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 61AB12FC018; Wed, 8 Apr 2009 22:06:19 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 0543610083; Wed, 8 Apr 2009 22:06:18 +0200 (CEST) Message-ID: <49DD03BA.8020605@tm.uka.de> Date: Wed, 08 Apr 2009 22:06:18 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: William Herrin References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> In-Reply-To: <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:05:18 -0000 Hi Bill, William Herrin wrote: > In addition, the definition of address is demonstrably wrong. > > >> address An address is a name that is used as both an interface >> locator and an endpoint identifier. > > Counterexample #1: RFC1918 IP addresses used inside a LAN consisting > of a personal computer, an ethernet hub and a NAT device. The IP > address in this example contains no locator semantics whatsoever, at > least not as you've defined a locator. I disagree. The IP address is used to locate the component's interface within the subnet. The resolution protocol is ARP in this case as it "locates" the interface belonging to the particular IP address. So first it is checked whether the destination is in the same subnet (to me this is also related to finding the location) and if it is the case, ARP "locates" the particular interface. > Counterexample #2: The IP address of an anycasted DNS service. The IP > address neither identifies an endpoint nor locates a particular > interface's points of attachment to the network. Instead it identifies > a service and specifies multiple locations via which that service can > be obtained. Correct, but I don't think that this is really a counterexample: The Anycast address identifies _an_ endpoint (though not a particular/specific one) that hosts the DNS service. Anycast routing will locate _an_ interface belonging to such an endpoint. Regards, Roland From wherrin@gmail.com Wed Apr 8 13:58:43 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D633A68F4 for ; Wed, 8 Apr 2009 13:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bP+WMMJ2cgc for ; Wed, 8 Apr 2009 13:58:42 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id A3B783A687D for ; Wed, 8 Apr 2009 13:58:42 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so228736ywh.37 for ; Wed, 08 Apr 2009 13:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=VWux1sv9IK2c4/PJeo2o+l8aiN/EJ0vYFk0uLlGRDXU=; b=YngfGI8kEfC2R1b2VMmvyM4Nklt3KLR9FDZKV8BXgI2wI7Yqb0xMEe+tSiS12WSqKI w0vufqTxciI2Y+FaruJf0HzcBlBsy4+BUxvuBBpDm863b0dUnuANtSpC/59pdyHNzUG8 0VNzSM5OWeMELYIRsaqvxLOykFWlgu4YLX7vE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LZn3EFMMKQ8U4yhORF51bf8qWKDy3pmOgt6RJlqL9vbzhZe916O3E0VHVURrzMk2tK Kd0sf+0conP0ijCybGkSMSmb78pKDs0xgjUOsyriIoeT5zhKssJQrTxB3lqoGdoKKBNc th9ej+GtT9MGCiLu/yN57RblNkpoJXm1XoSB0= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.14.2 with SMTP id 2mr3955952ann.38.1239224389312; Wed, 08 Apr 2009 13:59:49 -0700 (PDT) In-Reply-To: <49DD03BA.8020605@tm.uka.de> References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> Date: Wed, 8 Apr 2009 16:59:46 -0400 X-Google-Sender-Auth: b1bd4763b4335e33 Message-ID: <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> From: William Herrin To: Roland Bless Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:58:44 -0000 On Wed, Apr 8, 2009 at 4:06 PM, Roland Bless wrote: >> Counterexample #2: The IP address of an anycasted DNS service. The IP >> address neither identifies an endpoint nor locates a particular >> interface's points of attachment to the network. Instead it identifies >> a service and specifies multiple locations via which that service can >> be obtained. > > Correct, but I don't think that this is really a counterexample: > The Anycast address identifies _an_ endpoint (though not a > particular/specific one) that hosts the DNS service. Hi Roland, Nice try, but "an" is synonymous with "one" and "one endpoint" doesn't mean "a more or less random choice among the many endpoints eligible to respond." Even if it did, packets may be routed to different servers on a packet by packet basis depending on the metric and whether per-packet load sharing is enabled. The address can hardly be an endpoint identifier if a different endpoint is selected for every single packet. > Anycast > routing will locate _an_ interface belonging to such an endpoint. Nope. The anycast DNS servers are configured with unicast IP addresses on their network interfaces. The anycast address is assigned as a local machine alias, reachable only by packets that get routed to the machine through one of its unicast interfaces. Counter-example #3: Describe for me, if you will, the locator and endpoint identifier semantics associated with 127.0.0.1. Counter-example #4: At home, I duck bandwidth limits on my ISP's usenet server by configuring my Linux router to apply NAT and spread the source address for outbound requests to TCP port 119 among all of my static IP addresses on a connection by connection basis. It does this both for source IPs used by machines are tasked to other purposes and for IP addresses which are not assigned to any machine. In all of those cases, the NAT machine functions as a normal router and packet-filtering firewall in for packets except for the specific ones where the exterior TCP port is 119. It does not mangle or translate any other packets. In this configuration, the source IP address has no endpoint identifier semantics whatsoever, with Tony's definition or any other. The TCP connection ID looks a lot like an identifier but the source IP address by itself has only locator semantics, and then only until the entry into my network after which packets with an external port of 119 go one way and the other packets go one of a number of different directions. What was it Hamlet said? More things on heaven and earth? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmh@joelhalpern.com Wed Apr 8 19:55:45 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E638E3A695C for ; Wed, 8 Apr 2009 19:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BSnjINLY-uQ for ; Wed, 8 Apr 2009 19:55:45 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 25BDE3A6781 for ; Wed, 8 Apr 2009 19:55:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 14F9343031B; Wed, 8 Apr 2009 19:56:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 19ADD4302DD; Wed, 8 Apr 2009 19:56:51 -0700 (PDT) Message-ID: <49DD63F0.1030102@joelhalpern.com> Date: Wed, 08 Apr 2009 22:56:48 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> In-Reply-To: <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 02:55:46 -0000 The last analysis I saw is that anycast is in some sense a fiction. That is, it is not meaningful to describe an anycast IP "address" as an address according to any of the useful definitions of address. Rather, it is a name for a collection of things. We have merely overloaded the routing system so as to route on that particular kind of name. Yours, Joel William Herrin wrote: > On Wed, Apr 8, 2009 at 4:06 PM, Roland Bless wrote: >>> Counterexample #2: The IP address of an anycasted DNS service. The IP >>> address neither identifies an endpoint nor locates a particular >>> interface's points of attachment to the network. Instead it identifies >>> a service and specifies multiple locations via which that service can >>> be obtained. >> Correct, but I don't think that this is really a counterexample: >> The Anycast address identifies _an_ endpoint (though not a >> particular/specific one) that hosts the DNS service. > > Hi Roland, > > Nice try, but "an" is synonymous with "one" and "one endpoint" doesn't > mean "a more or less random choice among the many endpoints eligible > to respond." > > Even if it did, packets may be routed to different servers on a packet > by packet basis depending on the metric and whether per-packet load > sharing is enabled. The address can hardly be an endpoint identifier > if a different endpoint is selected for every single packet. > >> Anycast >> routing will locate _an_ interface belonging to such an endpoint. > > Nope. The anycast DNS servers are configured with unicast IP addresses > on their network interfaces. The anycast address is assigned as a > local machine alias, reachable only by packets that get routed to the > machine through one of its unicast interfaces. > > > Counter-example #3: > > Describe for me, if you will, the locator and endpoint identifier > semantics associated with 127.0.0.1. > > > Counter-example #4: > > At home, I duck bandwidth limits on my ISP's usenet server by > configuring my Linux router to apply NAT and spread the source address > for outbound requests to TCP port 119 among all of my static IP > addresses on a connection by connection basis. It does this both for > source IPs used by machines are tasked to other purposes and for IP > addresses which are not assigned to any machine. > > In all of those cases, the NAT machine functions as a normal router > and packet-filtering firewall in for packets except for the specific > ones where the exterior TCP port is 119. It does not mangle or > translate any other packets. > > In this configuration, the source IP address has no endpoint > identifier semantics whatsoever, with Tony's definition or any other. > The TCP connection ID looks a lot like an identifier but the source IP > address by itself has only locator semantics, and then only until the > entry into my network after which packets with an external port of 119 > go one way and the other packets go one of a number of different > directions. > > > What was it Hamlet said? More things on heaven and earth? > > > Regards, > Bill Herrin > > From tony.li@tony.li Wed Apr 8 20:38:14 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4413A6A32 for ; Wed, 8 Apr 2009 20:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrUv1o0mx9W2 for ; Wed, 8 Apr 2009 20:38:14 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id F0A063A6781 for ; Wed, 8 Apr 2009 20:38:13 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id dCHQ1b00F0x6nqcA4FfNfH; Thu, 09 Apr 2009 03:39:22 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id dFfM1b0023L8a8Q8YFfMdF; Thu, 09 Apr 2009 03:39:22 +0000 Message-ID: <49DD6DD2.3060105@tony.li> Date: Wed, 08 Apr 2009 20:38:58 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 03:38:15 -0000 I'd like to point out to the folks that want to continue the discussion that the consensus check under way is not dependent on the ongoing (and welcome) discussion. If you do wish to continue the discussion in any binding way, please vote against the current proposal. Many folks who appear adamant against the current proposals have not yet voted. Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 The poll closes at Tue, 14 Apr 2009 20:52:50 -0700 (one week from when initiated). Now, back to the fray! Regards, Tony From tony.li@tony.li Wed Apr 8 21:13:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012403A6A02 for ; Wed, 8 Apr 2009 21:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UPxBJTJUVYT for ; Wed, 8 Apr 2009 21:13:22 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 3AD703A696F for ; Wed, 8 Apr 2009 21:13:22 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id dCHQ1b00y0mlR8UA5GEWfc; Thu, 09 Apr 2009 04:14:30 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id dGEU1b00M3L8a8Q8XGEWhY; Thu, 09 Apr 2009 04:14:30 +0000 Message-ID: <49DD760B.7090100@tony.li> Date: Wed, 08 Apr 2009 21:14:03 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> In-Reply-To: <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:13:23 -0000 Hi Dow, > I don't think this one [locator] is quite there yet since it doesn't directly > address the question of how (a) namespace semantics and (b) the > associated routing system are involved in characterizing the name of an > attachment point as a locator (or not). I think some of this relation > is implied in the language above, but it is still fuzzy... The definition of locator isn't supposed to involve the specific routing system and it's not meant to specify or constrain the path in the general case. Locators are supposed to define 'where' something is, not 'how to get there'. > Using the postal example, > > 123 High Street, > Bigtown, > Green County, > Outer Luvania > > We would agree (I think) that if an object / person moved next door, and > still wanted to be reachable, it would need to use a different locator > (say, 125 High Street). However, what if larger sections of the > geography itself move - perhaps today Green County is beside Blue > County, but tomorrow it is next to Red County. Well, it's then the job of routing to compute that path. Certainly, you wouldn't want a situation where every node on the network would have to recompute its locator every time there was a topology change. Tony From tony.li@tony.li Wed Apr 8 21:24:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0603A6911 for ; Wed, 8 Apr 2009 21:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTkzp+TxCx+K for ; Wed, 8 Apr 2009 21:24:16 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 41C603A68D0 for ; Wed, 8 Apr 2009 21:24:16 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id dCHU1b00E0lTkoCAFGRQH4; Thu, 09 Apr 2009 04:25:24 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id dGRP1b00D3L8a8Q8QGRQyQ; Thu, 09 Apr 2009 04:25:24 +0000 Message-ID: <49DD789A.5010803@tony.li> Date: Wed, 08 Apr 2009 21:24:58 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Noel Chiappa References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> In-Reply-To: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:24:17 -0000 Noel Chiappa wrote: > There is simply no way to produce a definition which both i) completely and > accurately describes all the uses to which an IPvN address is currently put, > and ii) is short and crisp. So true. And it would seem that i) is a clear indication of the amount of overloading that we've applied to the IPv4 namespace. Tony From dino@cisco.com Wed Apr 8 21:45:50 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524A33A68B1 for ; Wed, 8 Apr 2009 21:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lop2-UjrOapf for ; Wed, 8 Apr 2009 21:45:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5AD9B3A6911 for ; Wed, 8 Apr 2009 21:45:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,158,1238976000"; d="scan'208";a="169072473" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Apr 2009 04:46:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n394kvIH010217; Wed, 8 Apr 2009 21:46:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n394kvGh022325; Thu, 9 Apr 2009 04:46:57 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 21:46:57 -0700 Received: from [192.168.1.3] ([10.21.127.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 21:46:56 -0700 Message-Id: <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> From: Dino Farinacci To: Tony Li In-Reply-To: <49DD789A.5010803@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 8 Apr 2009 21:47:01 -0700 References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 09 Apr 2009 04:46:56.0785 (UTC) FILETIME=[3623A810:01C9B8CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=798; t=1239252417; x=1240116417; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Consensus=20check=3A=20terminol ogy |Sender:=20; bh=+aCvtFLsTZBCWO5LHHsja8TzlGFSZw/Qx/xVM+FIKo4=; b=YMIjsZTQRV0ReGOKamdUi8PA26KsyUbzo/hbn0LnHJq9kcTRe+9Uk4BU8w B9Npnw75N8E57JnZVbLqRMU/mWWrlPXaGcYDx9Vy/FSILPNxbDvM8VkwyUMa dv6/5ylN2J; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:45:50 -0000 > Noel Chiappa wrote: > >> There is simply no way to produce a definition which both i) >> completely and >> accurately describes all the uses to which an IPvN address is >> currently put, >> and ii) is short and crisp. > > > So true. And it would seem that i) is a clear indication of the > amount of overloading that we've applied to the IPv4 namespace. Is a group address a locator or ID? For LISP, it is considered an EID since it doesn't map to topology and when a host moves around and stays joined to the group, the group address doesn't change. So it is close to your definition of "Identifier". Dino > > > Tony > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From dino@cisco.com Wed Apr 8 21:46:54 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5CA3A6BA1 for ; Wed, 8 Apr 2009 21:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daklHtxMFizx for ; Wed, 8 Apr 2009 21:46:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 14D1F3A6911 for ; Wed, 8 Apr 2009 21:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,158,1238976000"; d="scan'208";a="282957001" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2009 04:48:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n394m0BX018914; Wed, 8 Apr 2009 21:48:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n394m031026597; Thu, 9 Apr 2009 04:48:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 21:48:00 -0700 Received: from [192.168.1.3] ([10.21.127.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 21:48:00 -0700 Message-Id: <79204767-6298-4360-94BB-782A0B17DBE5@cisco.com> From: Dino Farinacci To: Dino Farinacci In-Reply-To: <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 8 Apr 2009 21:48:04 -0700 References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 09 Apr 2009 04:48:00.0378 (UTC) FILETIME=[5C0B2DA0:01C9B8CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1022; t=1239252480; x=1240116480; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Consensus=20check=3A=20terminol ogy |Sender:=20; bh=9HGPtRdCWyN/aUtixhR6XzhZdUSFHkPOMHAnzzCWvZA=; b=vrn62E6mjE7qz4guBIGhGygU9kGkLjabZapOmJ29rXdE+QBwFs0BLVdroy dI7BHc5thLdkutZi55uVqnfkUF3XS3MKw1iLThmnbEq98Y180sVXzm+n+deZ Yc0JkShvun; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:46:54 -0000 >> Noel Chiappa wrote: >> >>> There is simply no way to produce a definition which both i) >>> completely and >>> accurately describes all the uses to which an IPvN address is >>> currently put, >>> and ii) is short and crisp. >> >> >> So true. And it would seem that i) is a clear indication of the >> amount of overloading that we've applied to the IPv4 namespace. > > Is a group address a locator or ID? > > For LISP, it is considered an EID since it doesn't map to topology > and when a host moves around and stays joined to the group, the > group address doesn't change. So it is close to your definition of > "Identifier". I have a typo above. Please s/EID/ID. Dino > > > Dino > >> >> >> 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 tony.li@tony.li Wed Apr 8 22:07:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7E83A6E70 for ; Wed, 8 Apr 2009 22:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skYXUC8Ly-rb for ; Wed, 8 Apr 2009 22:07:08 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 331D13A6BEA for ; Wed, 8 Apr 2009 22:05:58 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id dCHQ1b00E0x6nqcA4H76KC; Thu, 09 Apr 2009 05:07:06 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id dH751b0053L8a8Q8YH765q; Thu, 09 Apr 2009 05:07:06 +0000 Message-ID: <49DD825D.4030303@tony.li> Date: Wed, 08 Apr 2009 22:06:37 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> <79204767-6298-4360-94BB-782A0B17DBE5@cisco.com> In-Reply-To: <79204767-6298-4360-94BB-782A0B17DBE5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:07:09 -0000 >>> So true. And it would seem that i) is a clear indication of the >>> amount of overloading that we've applied to the IPv4 namespace. >> >> Is a group address a locator or ID? >> >> For LISP, it is considered an EID since it doesn't map to topology and >> when a host moves around and stays joined to the group, the group >> address doesn't change. So it is close to your definition of >> "Identifier". > > I have a typo above. Please s/EID/ID. I'd concur with identifier. Is there some issue with that? Tony From dino@cisco.com Wed Apr 8 22:08:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75D73A6911 for ; Wed, 8 Apr 2009 22:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IufpLm8B0+9C for ; Wed, 8 Apr 2009 22:08:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E4B043A68A5 for ; Wed, 8 Apr 2009 22:08:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,159,1238976000"; d="scan'208";a="282963819" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2009 05:09:47 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3959lde006541; Wed, 8 Apr 2009 22:09:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3959l9w005961; Thu, 9 Apr 2009 05:09:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 22:09:47 -0700 Received: from [192.168.1.3] ([10.21.127.179]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 22:09:47 -0700 Message-Id: <3BDEDDDE-D5B7-452D-9B48-7A6B6B773494@cisco.com> From: Dino Farinacci To: Tony Li In-Reply-To: <49DD825D.4030303@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 8 Apr 2009 22:09:52 -0700 References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> <79204767-6298-4360-94BB-782A0B17DBE5@cisco.com> <49DD825D.4030303@tony.li> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 09 Apr 2009 05:09:47.0295 (UTC) FILETIME=[6706E2F0:01C9B8D1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=904; t=1239253787; x=1240117787; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Consensus=20check=3A=20terminol ogy |Sender:=20; bh=Yi5ZyljlrrOAZqeZXmjjwoDW95TBIGwPYweZBnKYHmA=; b=IkXuLtcVRFQ771epsBS7Ud23t4la6wxLk/wR5+WOIertmNhqGx/qUi51ag b/60KQ+2+fK5fdplhoMlH0lcRWlaSsSc0Q/pdZU9XBzsOEpJUddxs2MncHsX +vJWDmbo1X; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:08:40 -0000 >>>> So true. And it would seem that i) is a clear indication of the >>>> amount of overloading that we've applied to the IPv4 namespace. >>> >>> Is a group address a locator or ID? >>> >>> For LISP, it is considered an EID since it doesn't map to topology >>> and when a host moves around and stays joined to the group, the >>> group address doesn't change. So it is close to your definition of >>> "Identifier". >> I have a typo above. Please s/EID/ID. > > I'd concur with identifier. Is there some issue with that? Just wondering if you should include a group address in your definition. Up until now, I think everyone is thinking about unicast- type addresses. And also, to bring up the point Joel made, an anycast address is also known as a way to use (or abuse) a unicast address. Rather than having a formal definition and encoding (like IPv6 does). Dino From dow.street@linquest.com Wed Apr 8 22:10:46 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCB23A68A5 for ; Wed, 8 Apr 2009 22:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrHvYqKLBZsw for ; Wed, 8 Apr 2009 22:10:45 -0700 (PDT) Received: from smtp125.iad.emailsrvr.com (smtp125.iad.emailsrvr.com [207.97.245.125]) by core3.amsl.com (Postfix) with ESMTP id A903B3A6911 for ; Wed, 8 Apr 2009 22:10:45 -0700 (PDT) Received: from relay22.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay22.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 7A4121B4045; Thu, 9 Apr 2009 01:11:52 -0400 (EDT) Received: by relay22.relay.iad.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 296971B4005; Thu, 9 Apr 2009 01:11:52 -0400 (EDT) Message-Id: <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> From: Dow Street To: Tony Li In-Reply-To: <49DD760B.7090100@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 22:11:50 -0700 References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:10:47 -0000 On Apr 8, 2009, at 9:14 PM, Tony Li wrote: > > Hi Dow, > >> I don't think this one [locator] is quite there yet since it >> doesn't directly address the question of how (a) namespace >> semantics and (b) the associated routing system are involved in >> characterizing the name of an attachment point as a locator (or >> not). I think some of this relation is implied in the language >> above, but it is still fuzzy... > > > The definition of locator isn't supposed to involve the specific > routing system and it's not meant to specify or constrain the path > in the general case. Locators are supposed to define 'where' > something is, not 'how to get there'. But if the "where" name does not encode *any* information about "how to get there", then it doesn't really have any location semantics, right? From tony.li@tony.li Wed Apr 8 22:18:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179AE3A680E for ; Wed, 8 Apr 2009 22:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sksrNrGo+vQh for ; Wed, 8 Apr 2009 22:18:47 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 397183A68B1 for ; Wed, 8 Apr 2009 22:18:47 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id dCHQ1b00M16AWCUACHKvEM; Thu, 09 Apr 2009 05:19:55 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id dHKu1b00A3L8a8Q8SHKveD; Thu, 09 Apr 2009 05:19:55 +0000 Message-ID: <49DD855D.4070203@tony.li> Date: Wed, 08 Apr 2009 22:19:25 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dino Farinacci References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> <79204767-6298-4360-94BB-782A0B17DBE5@cisco.com> <49DD825D.4030303@tony.li> <3BDEDDDE-D5B7-452D-9B48-7A6B6B773494@cisco.com> In-Reply-To: <3BDEDDDE-D5B7-452D-9B48-7A6B6B773494@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:18:48 -0000 > Just wondering if you should include a group address in your definition. > Up until now, I think everyone is thinking about unicast-type addresses. Not necessary, I think, as our charter is to define these terms for abstract discussions, not document current (ab)uses. I think we're in agreement that 'group address' is actually only a result of the overloading of 'group identifiers' onto a true 'address space'. > And also, to bring up the point Joel made, an anycast address is also > known as a way to use (or abuse) a unicast address. Rather than having a > formal definition and encoding (like IPv6 does). Agreed. Just another overloading... Tony From dow.street@linquest.com Wed Apr 8 22:30:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9769B3A6B18 for ; Wed, 8 Apr 2009 22:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgL+4XCvqxtJ for ; Wed, 8 Apr 2009 22:30:39 -0700 (PDT) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by core3.amsl.com (Postfix) with ESMTP id D953B3A6878 for ; Wed, 8 Apr 2009 22:30:39 -0700 (PDT) Received: from relay10.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.dfw.mlsrvr.com (SMTP Server) with ESMTPS id 224CF95DB0D; Thu, 9 Apr 2009 01:31:47 -0400 (EDT) Received: by relay10.relay.dfw.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id D3CC795DB08; Thu, 9 Apr 2009 01:31:46 -0400 (EDT) Message-Id: From: Dow Street To: Tony Li In-Reply-To: <49DD760B.7090100@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 22:31:42 -0700 References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 05:30:40 -0000 On Apr 8, 2009, at 9:14 PM, Tony Li wrote: >> Using the postal example, >> 123 High Street, >> Bigtown, >> Green County, >> Outer Luvania >> We would agree (I think) that if an object / person moved next >> door, and still wanted to be reachable, it would need to use a >> different locator (say, 125 High Street). However, what if larger >> sections of the geography itself move - perhaps today Green County >> is beside Blue County, but tomorrow it is next to Red County. > > > Well, it's then the job of routing to compute that path. Certainly, > you wouldn't want a situation where every node on the network would > have to recompute its locator every time there was a topology change. Maybe we can close the terminology gap here by defining a few different kinds of topology change. Then I think the latest locator definition might make sense if the "topology change" phrase in that definition referred to only some of these kinds of changes, but not all. In other words, I'm not sure if we have a different understanding of the properties in play, or if our understanding is reasonably similar and it is just the words that are causing the confusion. R, Dow From dow.street@linquest.com Thu Apr 9 00:06:32 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AEE3A6EAC for ; Thu, 9 Apr 2009 00:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jELhXhJBTcCI for ; Thu, 9 Apr 2009 00:06:31 -0700 (PDT) Received: from smtp165.iad.emailsrvr.com (smtp165.iad.emailsrvr.com [207.97.245.165]) by core3.amsl.com (Postfix) with ESMTP id 90E803A6BF0 for ; Thu, 9 Apr 2009 00:06:31 -0700 (PDT) Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 75B901B402B for ; Thu, 9 Apr 2009 03:07:37 -0400 (EDT) Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 25C751B4005 for ; Thu, 9 Apr 2009 03:07:37 -0400 (EDT) Message-Id: <0430712D-C8C6-4E4E-9EC9-7D5F8765935B@linquest.com> From: Dow Street To: rrg@irtf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 00:07:35 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [rrg] starting from the abstract... X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 07:06:32 -0000 At the risk of making things even more confused...it seems we have at least the following things that we are trying to talk about: 1. landscape - an object or system with a notion of distance 2. a point on a landscape 3. a name for a point on a landscape 4. an object that is attached to a point on the landscape 5. a name for an object that is attached to a point on a landscape 6. a map of a landscape describing which points are named what 7. a name for a section of a landscape (i.e., a collection of points on a landscape) In the current system (I think) we have a physical topology (landscape A) and the IP topology (landscape B). There is an implicit map for landscape B - i.e. for the names of points in landscape B. This implicit map is captured in the proximity semantics of the IP address - that is, by default, locations with names that are numerically close to each other are assumed to be topologically close to each other in the IP landscape. This same property allows us to name sections of the IP landscape, where the section name is implicitly related to the names of the points comprising that section. There is an explicit map (the routing system state) that relates locations in landscape B to locations in landscape A. This explicit map (I think) also sometimes overrides the implicit map in landscape B. If an object attached to landscape A with a name in landscape B changes location in landscape A, either the explicit map relating A to B must change, or the object's name in B must change to (or retain) a name in B that (i) conforms to the implicit map for landscape B and (ii) does not violate the current relation of A to B. Ok - going to sleep... From tony.li@tony.li Thu Apr 9 01:00:28 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DB53A6A6E for ; Thu, 9 Apr 2009 01:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVGJiGsR9EMs for ; Thu, 9 Apr 2009 01:00:27 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 7A8263A6A05 for ; Thu, 9 Apr 2009 01:00:27 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id dKsz1b0020b6N64A7L1cg8; Thu, 09 Apr 2009 08:01:36 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id dL1a1b0053L8a8Q8PL1blc; Thu, 09 Apr 2009 08:01:35 +0000 Message-ID: <49DDA5CD.7010200@tony.li> Date: Thu, 09 Apr 2009 00:37:49 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> In-Reply-To: <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:00:28 -0000 Dow Street wrote: > But if the "where" name does not encode *any* information about "how to > get there", then it doesn't really have any location semantics, right? Does our mail address of 123 High Street, Bigtown, Green County, Outer Luvania Tell us *any* information about how to get there? Seems to have a lot of location semantics tho, yes? Tony From philip.eardley@bt.com Thu Apr 9 02:47:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8419F3A67B1 for ; Thu, 9 Apr 2009 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-jzK1lIIDsq for ; Thu, 9 Apr 2009 02:47:04 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 8C4563A6A4D for ; Thu, 9 Apr 2009 02:45:38 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 10:46:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Apr 2009 10:46:44 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7B05@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <49CFF596.2080307@tony.li> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Comments on draft-irtf-rrg-recommendation-01 Thread-Index: AcmwvXi4nJG9U0NuSXaNp0fYfAAqYwIN9HeQ From: To: X-OriginalArrivalTime: 09 Apr 2009 09:46:45.0349 (UTC) FILETIME=[1828B150:01C9B8F8] Cc: rrg@irtf.org Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:47:05 -0000 Couple of follow-ups in line, sorry for the delay. Best wishes phil { -----Original Message----- { From: Tony Li [mailto:tony.li@tony.li] { Sent: 29 March 2009 23:27 { To: Eardley,PL,Philip,CXR9 R { Cc: rrg@irtf.org { Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 {=20 {=20 { Hi Phil, {=20 { Thanks for the comments. {=20 { philip.eardley@bt.com wrote: { > the S3.3 Herrin taxonomy highly compresses a lot of options. i can { > understand the reason for trying to do it very succinctly, however a { > couple of things might help without decompressing it: [1] some { > figures to illustrate differences schematically [2] an appendix with { > some mapping of 'well known rrg protocols' to particular options - ? {=20 {=20 { I'd welcome the figures. Please note that we're confined to ASCII art { here, so they will require some careful crafting. Sorry. {=20 { I'm trying to stay away from citing the particular proposals, as this { will then easily degenerate into arguments about how each proposal in { turn is not properly represented. {=20 {=20 { > i disagree with Criticism 1 of strategy E (let economics suppress { > growth). you say that it needs a central authority system whereby { > money is transferreed from ISPs announcing prefixes to ISPs running { > core routers. i think that only pairwise interactions are needed ie { > just between 2 ISPs that are connected. so ISP-provider charges its { > ISP-customer for prefix announcements, this can depend on how { > aggregated teh prefix is. the same thing can be done at higher levels { > of the hierarachy. the decision whether to charge like this can all { > be done independently for every ISP pair. in fact you could argue { > that this is already being done today to some extent. [1] route flap { > damping limits how often ISP accepts route announcements. you could { > view this an economics: no charge if within RFD limit; infinite { > charge if over RFD limit. [2] ISP can select who gets PI addresses, { > depending on value /payment from customer. {=20 {=20 { Well, if it only took pairwise charging to make this happen, then it { would seem likely that some ISP would have been willing to start doing { this in a significant way and then these costs would have been passed { down to the consumer. Similarly, if some ISP could start doing this, { then its competitors would also have to move in this direction and { charging would also have become ubiquitous. {=20 { Instead what we see is that ISPs accept all routes from any of their { customers simply to protect their bandwidth revenue. Thus, to instill { any feedback mechanism, there's going to need to some centralized { authority that can effectively force a non-zero cost on prefix injection. {=20 { Note also that this can't be done by a small group of ISPs due to { anti-trust issues. [phil] I don't agree with this. just because pairwise charging hasn't happened yet, doesn't mean it couldn't happen. While prefix announcement /routing messages can be supported (because system scales well enough) then there is limited incentive to do it. ISPs get money from transporting data. If isps hit scaling limit that affected their ability to transport data & thereby gain money, then charging for routing msgs would be an option. In any case, RFC & slecting who's allowed PI addresses are already proxies for charging for prefix announcements, so in fact a crude version of strategy E is already being followed.=20 {=20 {=20 { > something on the lines of the second criticism seems ok, although { > "giving up a solution that genuinely enables users" seems rather { > provocative /vague [sorry, no text suggestion at the moment] {=20 {=20 { Granted. I'd welcome alternate word-smithing. [phil] something like: Strategy E does not seek to make the routing protocol more scalable, rather the limited 'capacity' is allocated according to willingness to pay.=20 {=20 {=20 { > In the conclusions i dont understand what you mean by : { > { > "Further, variants of Strategy B (Section 3.3.2 { > { > ) that require manual locator assignment are similarly unacceptable, { > as are solutions that do not significantly change existing host { > behavior, such as Strategy D (Section 3.3.4 { > { > ), Strategy E (Section 3.3.5 { > { > ), Strategy F (Section 3.3.6 { > { > ), and Strategy G (Section 3.3.7 { > { > )." this says that a solution is only accepatble only if it { > significantly changes host behaviour. i presume you mean the { > opposite. however Strategy E (economics) & F (do nothing) seem to { > have no impact on host behaviour either. {=20 {=20 { The point that I'm trying to make here is that we want to avoid manual { renumbering. This basically means that we have to automate renumbering { or obviates the need for it. {=20 { Let me try to word-smith that: {=20 { Further, variants of Strategy B (Section 3.3.2) that require manual { locator assignment are similarly unacceptable, as are other solutions { that require manual locator assignment, such as Strategy D (Section { 3.3.4), Strategy E (Section 3.3.5), Strategy F (Section 3.3.6), and { Strategy G (Section 3.3.7). [phil] my point was the strategy e & f don't seem to say anything about manual locator assignment. Since neither of them develop a new RRG protocol, they kind of self-exclude themselves from developing an RRG protocol(?) {=20 {=20 { Better? {=20 { Regards, { Tony From philip.eardley@bt.com Thu Apr 9 02:47:39 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E9B3A6C02 for ; Thu, 9 Apr 2009 02:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_20=-0.74, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EghdTKWOt+51 for ; Thu, 9 Apr 2009 02:47:38 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id EF8013A6EB2 for ; Thu, 9 Apr 2009 02:47:34 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 10:48:41 +0100 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: Thu, 9 Apr 2009 10:48:40 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7B06@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <3c3e3fca0903291938v1d5363acvfffff1411c73ac7d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Comments on draft-irtf-rrg-recommendation-01 Thread-Index: Acmw4JMvbrI08R4SRHK0x1Wf+IuEZwIFZhAw From: To: X-OriginalArrivalTime: 09 Apr 2009 09:48:41.0175 (UTC) FILETIME=[5D325670:01C9B8F8] Cc: rrg@irtf.org Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:47:39 -0000 Couple of follow-ups in line, sorry for the delay. Best wishes phil { -----Original Message----- { From: wherrin@gmail.com [mailto:wherrin@gmail.com] On Behalf Of = William { Herrin { Sent: 30 March 2009 03:38 { To: Eardley,PL,Philip,CXR9 R { Cc: rrg@irtf.org { Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 {=20 { On 3/26/09, philip.eardley@bt.com wrote: { > i disagree with Criticism 1 of strategy E (let economics suppress { growth). { > you say that it needs a central authority system whereby money is { > transferreed from ISPs announcing prefixes to ISPs running core { > routers. i think that only pairwise interactions are needed ie just { > between 2 ISPs that are connected. {=20 { Hi Philip, {=20 { You'd have to negotiate with too many different parties to carry your { prefixes. Having your ISP negotiate with it's neighbors such that it's { neighbors will carry the negotiations forward to their neighbors { yields precisely the system we have today, which brings us full circle { to the problem we're trying to solve. [phil] I don't think it's necessary to " carry the negotiations = forward". Negotiating with your neighbours is enough - they then = negotiate with their neighbours and so on. After all, when I buy apples = I have a contract with the greengrocer or supermarket; the greengrocer = has a contract with a wholesaler; the wholesaler has a contract with the = farmer. No need for me to negotiate with farmer or clearinghouses. I = don't see why it would have to be different in the rrg case. {=20 { On the other hand, it doesn't require a central authority, only a { central clearinghouse in which all participation is optional and the { participants set the rules of their own participation. I posited such { a system in a moderate amount of detail on the NANOG list some time { last year. Basically, you go to the clearinghouse and post your rates { for various types of carriage of routing slots. Then you search { everybody else's posted rates according to the criteria that you need { in order to get the connectivity you want, and for each of the route { announcements you make, you instruct the clearinghouse that you are { purchasing the package of ISPs and rates that you specified in the { search. {=20 { Let me ground that with an example: I have 199.33.224.0/23 multihomed { on the Internet. It's for my hobbies. Today that consumes a routing { slot on every backbone router on the Internet. Maybe it's enough to { authorize Verizon Business to announce 199.0.0.0/8 and then for me to { make arrangements with Verizon Business, each ISP in the AS chain from { me to Verizon Business and all ISPs who do business within the { mid-atlantic states to carry my /23 route. That's still hundreds of { entities, far too many to contact and negotiate with by hand. But with { a clearinghouse to facilitate the negotiation and payment process, I { could have full Internet connectivity while consuming routing slots in { less than a thousand organizations instead of some thirty thousand { worldwide. That would lower the real-world impact from the more than { $6k per slot per year today to maybe a couple hundred dollars -- which { I could easily afford to pay. {=20 {=20 { > something on the lines of the second criticism seems ok, although { >"giving up a solution that genuinely enables users" seems rather { > provocative /vague [sorry, no text suggestion at the moment] {=20 { The long version of that statement went something like this: {=20 { If we're resource-constrained so that we can really only have a few { hundred thousand routing slots in the Internet then the Domino's Pizza { franchise down the street can't be multihomed with two ISPs. There { just aren't enough routing slots to give them away. Over time, the { scarcity of those routing slots will make them more and more valuable { to the point where I can't afford to keep my basement multihomed { either. {=20 { This does not empower me as an individual; quite the opposite, I'm { obstructed from consuming the resource for something as trite as my { personal hobbies. [phil] maybe we have a philosophical difference here. it seems to me a = good architectural goal for a protocol to allow costs to be allocated to = those that cause them, without having to distort/break the protocol; = enabling a party to do what it wants for free regardless of its impact = on other parties seems to me a poor goal - or at least it is likely that = (once the impact is economically significant) the architecture will get = distorted somehow. {=20 { Regards, { Bill Herrin {=20 {=20 { -- { William D. Herrin ................ = herrin@dirtside.com=A0=A0bill@herrin.us { 3005 Crane Dr. ...................... Web: { Falls Church, VA 22042-3004 From dow.street@linquest.com Thu Apr 9 06:52:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C82A3A6C57 for ; Thu, 9 Apr 2009 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Mzj77rD1tZ for ; Thu, 9 Apr 2009 06:52:05 -0700 (PDT) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by core3.amsl.com (Postfix) with ESMTP id A9FB428C124 for ; Thu, 9 Apr 2009 06:50:59 -0700 (PDT) Received: from relay10.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.dfw.mlsrvr.com (SMTP Server) with ESMTPS id 2425B95DB12; Thu, 9 Apr 2009 09:52:07 -0400 (EDT) Received: by relay10.relay.dfw.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id C228A95DB0D; Thu, 9 Apr 2009 09:52:06 -0400 (EDT) Message-Id: From: Dow Street To: Tony Li In-Reply-To: <49DDA5CD.7010200@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 06:52:03 -0700 References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> <49DDA5CD.7010200@tony.li> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:52:06 -0000 Tony, Thanks for the comments. More below... On Apr 9, 2009, at 12:37 AM, Tony Li wrote: > Dow Street wrote: >> But if the "where" name does not encode *any* information about >> "how to get there", then it doesn't really have any location >> semantics, right? > > > Does our mail address of > > 123 High Street, > Bigtown, > Green County, > Outer Luvania > > Tell us *any* information about how to get there? I think you can say there is a often a continuity convention in names for sections of geographic landscapes. That is, someplace in Green county is generally reachable from another place in Green country without having to exit Green county. This is, of course, not always the case (e.g. Alaska). There is also an implied hierarchy in the set of names for map sections in this address, e.g. Bigtown is "in" Green County. Based on these conventions, and given the name of the location, one might say you could derive a loose path from your present location in the landscape to the point named by this locator, even without an full / explicit map. "First get to Outer Luvania, then find Green County, etc.." I think this information constitutes some notion of "how to get there". However, we may not want to call it a "path", but more of a "plan for a path" that does not become an actual path until we add a road sign that says "Bigtown over there". If this (path) is what you are defining as information on "how to get there", then I think we are in sync conceptually. > Seems to have a lot of location semantics tho, yes? I would say it does. Specifically those semantics are: - the (country, county, city, state, street, number) hierarchy of names (where each level of names in the hierarchy is flat wrt to the names of the others) - the numerical, proximity semantics of the street number R, Dow From wherrin@gmail.com Thu Apr 9 07:12:58 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599703A6C59 for ; Thu, 9 Apr 2009 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdKiBMXz1oGs for ; Thu, 9 Apr 2009 07:12:57 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 6B98E3A6B86 for ; Thu, 9 Apr 2009 07:12:57 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so452321yxj.37 for ; Thu, 09 Apr 2009 07:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=JRD2JoljIPN4N9Dnx1B+7Rk8ku6BIiyr+sTJEBfGLUk=; b=DgX1Dm9/BINMIRqT6Uc/09yMU68JdKjKLwn3SknFTU2rqbLF4MeMu54icTEch82Cbe 01RxNUtQa67CK8F1ais7mgPqUVzgDFq2+PWOQJ6sYwyM8OwpGRnCMvtwzzE8Halk7wGB xAeQ2ZHLWv+ru+pxgRvgAabo1n0C0859h/Jqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ui+Z1Cn3ZNN9ZgtP3wbU8uggf9YQPIRsGSXeAj6oDTqEANYz7XxjtyVA1l/Ef6hswa vcXanHmAUugNRGPmvxv9LhjC7muPPqb4C6QeT1eTbefVUkXVoe1x9BbHfxbMQbm1qCTD MGEQB8n/73ihba0EqyX59Let4+smFhsHIH5Lc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.101.69.6 with SMTP id w6mr264884ank.22.1239286444930; Thu, 09 Apr 2009 07:14:04 -0700 (PDT) In-Reply-To: <49DD63F0.1030102@joelhalpern.com> References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> <49DD63F0.1030102@joelhalpern.com> Date: Thu, 9 Apr 2009 10:14:04 -0400 X-Google-Sender-Auth: 7483e3613c6eb6ea Message-ID: <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> From: William Herrin To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:12:58 -0000 On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern wrote: > The last analysis I saw is that anycast is in some sense a fiction. That is, > it is not meaningful to describe an anycast IP "address" as an address > according to any of the useful definitions of address. > Rather, it is a name for a collection of things. > We have merely overloaded the routing system so as to route on that > particular kind of name. Joel, So you see an abnormality here, not a pattern in the evolution of routing? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jnc@mercury.lcs.mit.edu Thu Apr 9 07:20:24 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153A03A6C57 for ; Thu, 9 Apr 2009 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsLTkc80Q71L for ; Thu, 9 Apr 2009 07:20:23 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 601F33A6BC9 for ; Thu, 9 Apr 2009 07:20:23 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6CC456BE556; Thu, 9 Apr 2009 10:21:30 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090409142130.6CC456BE556@mercury.lcs.mit.edu> Date: Thu, 9 Apr 2009 10:21:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:20:24 -0000 > From: William Herrin > So you see an abnormality here, not a pattern in the evolution of > routing? To paraphrase Saltzer ("[The confusion over terminology] also stems from trying to discuss the issues with too few well-defined concepts at hand."), I see architectural kludgery stemming from trying to do things with too few well-designed mechanisms at hand. In other words, when the only tool you've got is a hammer... Noel From jmh@joelhalpern.com Thu Apr 9 07:21:36 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEC73A6C6E for ; Thu, 9 Apr 2009 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C68QfKSNVzy7 for ; Thu, 9 Apr 2009 07:21:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BAACA3A6C97 for ; Thu, 9 Apr 2009 07:21:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0817343027B; Thu, 9 Apr 2009 07:22:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 61E95430276; Thu, 9 Apr 2009 07:22:40 -0700 (PDT) Message-ID: <49DE04AC.1070606@joelhalpern.com> Date: Thu, 09 Apr 2009 10:22:36 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> <49DD63F0.1030102@joelhalpern.com> <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> In-Reply-To: <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 14:21:36 -0000 What I see is a hack that would be ineffective in a system that actually drove serious aggregation. If we really drove prefixes to aggregatability, then only those few exceptions which were highly unusual could use the equivalent of IPv4 Anycast. (Note, this is different from IPv6 anycast which, as I understand, is more like naming a portion of the map, rather than trying to name an arbitrary set of scattered end-nodes.) So yes, I think anycast as captured by IPv4 treatment (like anycast DNS) is an abnormality, not a useful direction. If we want to make that service a first class citizen, we will have to do so very differently, and recognize the costs as with multicast. Yours, Joel William Herrin wrote: > On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern wrote: >> The last analysis I saw is that anycast is in some sense a fiction. That is, >> it is not meaningful to describe an anycast IP "address" as an address >> according to any of the useful definitions of address. >> Rather, it is a name for a collection of things. >> We have merely overloaded the routing system so as to route on that >> particular kind of name. > > Joel, > > So you see an abnormality here, not a pattern in the evolution of routing? > > Regards, > Bill Herrin > > From wherrin@gmail.com Thu Apr 9 08:22:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2190D3A6D70 for ; Thu, 9 Apr 2009 08:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjwD6eb6tIoQ for ; Thu, 9 Apr 2009 08:22:47 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id E4B293A6902 for ; Thu, 9 Apr 2009 08:22:46 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so476867ywh.37 for ; Thu, 09 Apr 2009 08:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=S9FJ4DxwwF0AftlfoHbTFb471gpNn3yL9qC68bIv/B4=; b=gV7oJO5z5Hp2YzNmX5ZtG92dXrb+0YX8dpIrTED7gdGYFNFotCVT2S6A/dRsoXhFrV Czm8/+/3IiT0m9k7p2Vat+oOTiURWY0jgx6GgTjzZe5uMY6XHoDe3gPSQOPB0QTCvTXq ltwms9x6F0yaPdFQOaLeBCO5uO9QFJlfzsfOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gDiIjNlx/GtkxK3lwjC3w57vPcC6wtYTLDCr9tpTjuujx6Whi0slnLRzY2XD8pzMMp 4uDJKBB8gXm+FUDXx+piRBmMm7z1xQHgENGFySDYVfOVwJnbKLigP3lCatlS8dqIGfJW FB/G3uaEb9kpkH4566nbs5fb6AJJl70w2/Btc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.216.12 with SMTP id o12mr390175ang.46.1239290634645; Thu, 09 Apr 2009 08:23:54 -0700 (PDT) In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7B06@E03MVB1-UKBR.domain1.systemhost.net> References: <3c3e3fca0903291938v1d5363acvfffff1411c73ac7d@mail.gmail.com> <4A916DBC72536E419A0BD955EDECEDEC04AD7B06@E03MVB1-UKBR.domain1.systemhost.net> Date: Thu, 9 Apr 2009 11:23:54 -0400 X-Google-Sender-Auth: a5aa9cd12af1c91e Message-ID: <3c3e3fca0904090823t4f4f215bo1fcf7b4851365e39@mail.gmail.com> From: William Herrin To: philip.eardley@bt.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 15:22:48 -0000 On Thu, Apr 9, 2009 at 5:48 AM, wrote: > { You'd have to negotiate with too many different parties to carry your > { prefixes. Having your ISP negotiate with it's neighbors such that it's > { neighbors will carry the negotiations forward to their neighbors > { yields precisely the system we have today, which brings us full circle > { to the problem we're trying to solve. > > [phil] I don't think it's necessary to " carry the negotiations forward".= Negotiating with your neighbours is enough - they then negotiate with thei= r neighbours and so on. After all, when I buy apples I have a contract with= the greengrocer or supermarket; the greengrocer has a contract with a whol= esaler; the wholesaler has a contract with the farmer. Hi Phil, If you've inserted a subtlety here, it escapes me. You've described the status quo in which experience shows that the result is all DFZ routes are carried by all DFZ routers. > { This does not empower me as an individual; quite the opposite, I'm > { obstructed from consuming the resource for something as trite as my > { personal hobbies. > > [phil] maybe we have a philosophical difference here. it seems to me a go= od architectural goal for a protocol to allow costs to be allocated to thos= e that cause them, without having to distort/break the protocol. Agreed in principle. One fly in the ointment is that there is no source provider from which the cost can flow. If I want a particular kind of apple, the costs flow from the grower of that apple out through however many middlemen and transport processes it takes to get that apple to me. Costs in Internet transport are radically different; they flow from a loose cabal of middlemen (the tier 1 backbones) out towards both the suppliers and the consumers. We've found a mechanism that more or less successfully assigns bandwidth costs in this economic architecture (transit and peering) but what mechanism could assign the cost of routing slots? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Thu Apr 9 09:18:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AB03A6A75 for ; Thu, 9 Apr 2009 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-HPCEQU2isC for ; Thu, 9 Apr 2009 09:18:06 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id AFC6B3A6846 for ; Thu, 9 Apr 2009 09:18:06 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id dPRF1b0060lTkoCAEUKFEB; Thu, 09 Apr 2009 16:19:15 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id dUKD1b00L3L8a8Q8QUKEiM; Thu, 09 Apr 2009 16:19:15 +0000 Message-ID: <49DE1FC1.9030003@tony.li> Date: Thu, 09 Apr 2009 09:18:09 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dow Street References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> <49DDA5CD.7010200@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:18:07 -0000 Dow Street wrote: > I think you can say there is a often a continuity convention in names > for sections of geographic landscapes. That is, someplace in Green > county is generally reachable from another place in Green country > without having to exit Green county. This is, of course, not always the > case (e.g. Alaska). There is also an implied hierarchy in the set of > names for map sections in this address, e.g. Bigtown is "in" Green > County. Based on these conventions, and given the name of the location, > one might say you could derive a loose path from your present location > in the landscape to the point named by this locator, even without an > full / explicit map. "First get to Outer Luvania, then find Green > County, etc.." I think this information constitutes some notion of > "how to get there". That's certainly one possible path, but it may well not be optimal. What you're really pointing out here is that in a hierarchical locator system, that following the path via aggregates itself becomes a candidate path, *if* you can tell where the aggregates are. However, to do that you again need the information held in the routing subsystem. There are trivial examples where the candidate path implied by such routing are suboptimal, and where "cold-potato" routing is optimal. Imagine the case where all of the roads in Green County are very, very poorly maintained and full of potholes that make you drive slowly (i.e., high metric). The optimal path is to stay outside of Green County until you get to the point outside of the county that is closest to the destination. > However, we may not want to call it a "path", but > more of a "plan for a path" that does not become an actual path until we > add a road sign that says "Bigtown over there". If this (path) is what > you are defining as information on "how to get there", then I think we > are in sync conceptually. Agreed. Tony From wherrin@gmail.com Thu Apr 9 09:49:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0749F3A6A00 for ; Thu, 9 Apr 2009 09:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n34z0QoODwNG for ; Thu, 9 Apr 2009 09:49:38 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id A76593A6902 for ; Thu, 9 Apr 2009 09:49:38 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so508306yxj.37 for ; Thu, 09 Apr 2009 09:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=aDopPy5wJwvZOYq7ES7CR3j7OLhlFcl6YFNDBUxX7+g=; b=Yn9/wy3Mggvg7+BshMitKxmqiYSNyE34053x7oxUPxi61qdy8PQTcq4Z/pqf7YY9V9 qucI1/ZmSPZYZj4GeFILIxlORpTp76HnQRLfOaGHfp437EWcNT2WyDBRoTK6ORMNQ5kG xkTKjz81OUOvtfOu8tIzE//fhBwIndwY8gfkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dTSFXlfHIW3om0+LjoTBVUU8GmZirMl1jUAgeyzsWByAnIoadmZVpf19kKI+yiSKy/ jtlkC2bBGPr0YMU7hL+m8oRIfVe1valOVmt4ibYIERp1oceGhXNBsB7vtnlRRkTpGMcp tHSmhLoEoP+aZapM+qihBfFOCf8l6X6EZe+FY= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.166.10 with SMTP id o10mr539190ane.53.1239295846347; Thu, 09 Apr 2009 09:50:46 -0700 (PDT) In-Reply-To: <49DE04AC.1070606@joelhalpern.com> References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> <49DD63F0.1030102@joelhalpern.com> <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> <49DE04AC.1070606@joelhalpern.com> Date: Thu, 9 Apr 2009 12:50:46 -0400 X-Google-Sender-Auth: 073b0ce9916a635f Message-ID: <3c3e3fca0904090950w6efbf730t5b51fa661100bcb5@mail.gmail.com> From: William Herrin To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:49:40 -0000 On Thu, Apr 9, 2009 at 10:22 AM, Joel M. Halpern wrote: > William Herrin wrote: >> On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern >> wrote: >>> The last analysis I saw is that anycast is in some sense a fiction. >> So you see an abnormality here, not a pattern in the evolution of routing? > What I see is a hack that would be ineffective in a system that actually > drove serious aggregation. Joel, Okay, well, I see an evolutionary pattern in the routing architecture. I see a set of core services, like map resolution, where causing the first packet to reach any one of the many eligible and available respondents represents a significant efficiency gain for the overall Internet architecture versus a unicast timeout and retry cycle which continues until an available respondent is found. And I see more of it in our future. Frankly, I'm surprised no one has published an RFC describing an "anycast DNS resolver address" that can be statically configured in TCP/IP network stacks with the expectation that it'll reach the nearest operational DNS resovler. It would greatly simplify client configuration and would make maintenance downtime on the primary resolver much less disruptive. If its practical for anycast to be an integral part of unicast routing then it's likely to be suboptimal or even destructive to architect it as a peer to unicast routing. I also foresee a combined anycast/multicast address where a host sends a multicast packet to a single unknown respondent on the LAN, the local router keeps track of whether there is a respondent on the LAN, and if there isn't then the router takes the multicast packet and forwards it unicast to the nearest respondent that has introduced a route into the system. With the combined address, a host could perform a map lookup to an architecurally defined destination (zero configuration) by emitting a single packet on the LAN with the expectation that barring packet loss it'll reach a system capable of fulfilling the map lookup. A minor tweak would solve the noise on the LAN by having the host subsequently use the respondent's unicast IP address until there's a timeout. But I 'spose that's an ineffective hack too, yes? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmh@joelhalpern.com Thu Apr 9 12:33:42 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B77B3A6C34 for ; Thu, 9 Apr 2009 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cvgmLFGhZAJ for ; Thu, 9 Apr 2009 12:33:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 48EFF3A6CA4 for ; Thu, 9 Apr 2009 12:33:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ACA16430360; Thu, 9 Apr 2009 12:34:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id E162E430336; Thu, 9 Apr 2009 12:34:48 -0700 (PDT) Message-ID: <49DE4DD4.5090106@joelhalpern.com> Date: Thu, 09 Apr 2009 15:34:44 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> <49DD63F0.1030102@joelhalpern.com> <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> <49DE04AC.1070606@joelhalpern.com> <3c3e3fca0904090950w6efbf730t5b51fa661100bcb5@mail.gmail.com> In-Reply-To: <3c3e3fca0904090950w6efbf730t5b51fa661100bcb5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 19:33:42 -0000 Let me turn this about. If the "anycast" we are talking about is something that must be used only by a few specialized services that are intended to optimize certain network behaviors, then it is a hack. Maybe a useful hack, but still a hack. Conversely, if we are expecting to allow anycast for any distribution of services, then it had better not be in the core routing system. Such anycast "addresses" do not name a location. Hence they are inherently non-aggregateable. They need to go through a mapping system of some sort before we ask packet forwarding to handle them. (Yes, there are architectures where routing does not require "where", such as compact routing. But until we know how to make such systems actually work I will not assert that even they can handle this sort of anycast.) Yours, Joel William Herrin wrote: > On Thu, Apr 9, 2009 at 10:22 AM, Joel M. Halpern wrote: >> William Herrin wrote: >>> On Wed, Apr 8, 2009 at 10:56 PM, Joel M. Halpern >>> wrote: >>>> The last analysis I saw is that anycast is in some sense a fiction. >>> So you see an abnormality here, not a pattern in the evolution of routing? >> What I see is a hack that would be ineffective in a system that actually >> drove serious aggregation. > > Joel, > > Okay, well, I see an evolutionary pattern in the routing architecture. > > I see a set of core services, like map resolution, where causing the > first packet to reach any one of the many eligible and available > respondents represents a significant efficiency gain for the overall > Internet architecture versus a unicast timeout and retry cycle which > continues until an available respondent is found. > > And I see more of it in our future. Frankly, I'm surprised no one has > published an RFC describing an "anycast DNS resolver address" that can > be statically configured in TCP/IP network stacks with the expectation > that it'll reach the nearest operational DNS resovler. It would > greatly simplify client configuration and would make maintenance > downtime on the primary resolver much less disruptive. > > If its practical for anycast to be an integral part of unicast routing > then it's likely to be suboptimal or even destructive to architect it > as a peer to unicast routing. > > I also foresee a combined anycast/multicast address where a host sends > a multicast packet to a single unknown respondent on the LAN, the > local router keeps track of whether there is a respondent on the LAN, > and if there isn't then the router takes the multicast packet and > forwards it unicast to the nearest respondent that has introduced a > route into the system. > > With the combined address, a host could perform a map lookup to an > architecurally defined destination (zero configuration) by emitting a > single packet on the LAN with the expectation that barring packet loss > it'll reach a system capable of fulfilling the map lookup. A minor > tweak would solve the noise on the LAN by having the host subsequently > use the respondent's unicast IP address until there's a timeout. > > But I 'spose that's an ineffective hack too, yes? > > Regards, > Bill Herrin > From wherrin@gmail.com Thu Apr 9 13:14:29 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0D13A6CFB for ; Thu, 9 Apr 2009 13:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTeqBnG0j8ng for ; Thu, 9 Apr 2009 13:14:28 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 6F3443A67FF for ; Thu, 9 Apr 2009 13:14:28 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so560037anc.37 for ; Thu, 09 Apr 2009 13:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=CzHAGKe9qBetK6pP8VJJwRLCzuE5n9oTRnnfDWfdzTI=; b=TNWACHXCB/w+4lyu9bhRh7b1Pn4oTN11LItw/OQ8SKWsAnM3+59gzDdmhUfBaGAhSG 69KnUeEui510uBbuxI26/MSP0XA1fYh1W6+FuCVv+skGziJVJl/B66dvQy0m4efU9jU/ 3WwJxYBCUwM05Bm4Tp74umKvAdDoB92oeNpr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QGbWyJhQPae6FFXrLNV9kZjO5QVgMTjXUjhG/0tl72VsWWMLJtuBry2D5bA7ncOz8S TxEnXmvNjEb7rBKNCFzG3jdcKTUkYWaRzJpOMawSDumS63NiDJQsggzo5c/aTuK3ySjb a6aFpKj/8Xn8hV8mwi/xwJ6NVePSQfHrpewWs= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.105.9 with SMTP id d9mr828654anc.142.1239308134044; Thu, 09 Apr 2009 13:15:34 -0700 (PDT) In-Reply-To: <49DE4DD4.5090106@joelhalpern.com> References: <49DC1F92.7000408@tony.li> <3c3e3fca0904080728j4c69a633n7254b118e4478f9a@mail.gmail.com> <49DD03BA.8020605@tm.uka.de> <3c3e3fca0904081359s2fe62cc0t6c74b51a1aee1fe7@mail.gmail.com> <49DD63F0.1030102@joelhalpern.com> <3c3e3fca0904090714i699ae1aes8dac3797a4ddfc82@mail.gmail.com> <49DE04AC.1070606@joelhalpern.com> <3c3e3fca0904090950w6efbf730t5b51fa661100bcb5@mail.gmail.com> <49DE4DD4.5090106@joelhalpern.com> Date: Thu, 9 Apr 2009 16:15:33 -0400 X-Google-Sender-Auth: b55770332fa00f83 Message-ID: <3c3e3fca0904091315p6f3a74c2pea28f211e87ae4d0@mail.gmail.com> From: William Herrin To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:14:29 -0000 On Thu, Apr 9, 2009 at 3:34 PM, Joel M. Halpern wrote: > Conversely, if we are expecting to allow anycast for any distribution of > services, then it had better not be in the core routing system. Joel, That's a pretty harsh view for something that's steadily becoming the defacto standard for the DNS roots, standard for the TLD roots and forms part of the technological underpinning of Neustar's UltraDNS service among others. Regards, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swb@employees.org Thu Apr 9 13:16:55 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49933A6407 for ; Thu, 9 Apr 2009 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgeQyWU6u9JE for ; Thu, 9 Apr 2009 13:16:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BEFF53A6CD0 for ; Thu, 9 Apr 2009 13:15:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,162,1238976000"; d="scan'208";a="41398882" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2009 20:16:46 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n39KGkSI009422; Thu, 9 Apr 2009 16:16:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n39KGjSt018236; Thu, 9 Apr 2009 20:16:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:16:46 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:16:45 -0400 Message-ID: <49DE57AC.4060005@employees.org> Date: Thu, 09 Apr 2009 16:16:44 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dow Street References: <0430712D-C8C6-4E4E-9EC9-7D5F8765935B@linquest.com> In-Reply-To: <0430712D-C8C6-4E4E-9EC9-7D5F8765935B@linquest.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 20:16:45.0455 (UTC) FILETIME=[1AC721F0:01C9B950] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] starting from the abstract... X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:16:55 -0000 Starting my replies with this thread ... Dow Street allegedly wrote on 04 09 2009 3:07 AM: > At the risk of making things even more confused...it seems we have at > least the following things that we are trying to talk about: > > 1. landscape - an object or system with a notion of distance > > 2. a point on a landscape > > 3. a name for a point on a landscape > > 4. an object that is attached to a point on the landscape > > 5. a name for an object that is attached to a point on a landscape > > 6. a map of a landscape describing which points are named what > > 7. a name for a section of a landscape (i.e., a collection of points on > a landscape) I like this list. It is a superset of the one I sent out. However, in addition, you need a name for "a thing that forwarding uses", for example Noel's forwarding selector: a "field in the packets which the routers look at to decide where to send the packet next". Something can "name a location" (i.e. point of attachment) but not be present in the packet as the packet crosses the Internet. Even if it is present a forwarder might not use it in deciding how to forward the packet. I think we can all agree now that the term 'locator' is terribly confusing. A sensor senses, a resistor resists ... but a 'locator' does not locate, rather it is a name that may or may not be used by a function that actually does locate. But we're stuck with it. Now let's be sure to limit how 'locator' is used so that it is actually useful. It names an attachment point (not an endpoint). From swb@employees.org Thu Apr 9 13:47:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3993A6B59 for ; Thu, 9 Apr 2009 13:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDfw1YS64XPA for ; Thu, 9 Apr 2009 13:47:43 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 70E833A68D2 for ; Thu, 9 Apr 2009 13:47:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,163,1238976000"; d="scan'208";a="41477467" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2009 20:48:51 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n39Kmp5E024974; Thu, 9 Apr 2009 16:48:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n39KmpYV021627; Thu, 9 Apr 2009 20:48:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:48:51 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:48:50 -0400 Message-ID: <49DE5F31.6000405@employees.org> Date: Thu, 09 Apr 2009 16:48:49 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> <7C84CE35-F364-470F-96CD-653487E11401@linquest.com> <49DD760B.7090100@tony.li> <1ED455CD-7AF0-4A33-A69F-5E7F9DCC1160@linquest.com> <49DDA5CD.7010200@tony.li> In-Reply-To: <49DDA5CD.7010200@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 20:48:50.0320 (UTC) FILETIME=[96163900:01C9B954] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:47:44 -0000 Tony Li allegedly wrote on 04 09 2009 3:37 AM: > Dow Street wrote: >> But if the "where" name does not encode *any* information about "how >> to get there", then it doesn't really have any location semantics, right? > > > Does our mail address of > > 123 High Street, > Bigtown, > Green County, > Outer Luvania > > Tell us *any* information about how to get there? > > Seems to have a lot of location semantics tho, yes? > > Tony There are many bits of "where" information which are not allocated to specific edge attachment points. We can name them, but for now the most important thing is that NOT ALL bits of 'where' information are 'locators'. Locators should be restricted to being names allocated to specific edge attachment points and should not include group addresses or any other abstractions. However, just because a piece of 'where' information is not a locator doesn't mean it has to be an identifier either. > "forwarding selector", "f-selector" - The field in the packets which the > routers look at to decide where to send the packet next. In X.25, > the f-selector si the VC-ID, in IPv4, the 'destination IP address'. Actually since this is the new millennium, a forwarder can a number of forwarding selectors, not just one. From swb@employees.org Thu Apr 9 13:54:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5023A6843 for ; Thu, 9 Apr 2009 13:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVh3SN7PP+sR for ; Thu, 9 Apr 2009 13:54:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7011A3A67B0 for ; Thu, 9 Apr 2009 13:54:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,163,1238976000"; d="scan'208";a="283475225" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Apr 2009 20:55:11 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n39KtBFH021206; Thu, 9 Apr 2009 13:55:11 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n39KtAZs006773; Thu, 9 Apr 2009 20:55:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:55:10 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 16:55:09 -0400 Message-ID: <49DE60AD.9040801@employees.org> Date: Thu, 09 Apr 2009 16:55:09 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dino Farinacci References: <20090408161542.6E3F56BE56B@mercury.lcs.mit.edu> <49DD789A.5010803@tony.li> <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> In-Reply-To: <52ABC549-1FFF-46E8-B5C8-1FB2A1AEFD3A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 20:55:09.0912 (UTC) FILETIME=[78575D80:01C9B955] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:54:04 -0000 Dino Farinacci allegedly wrote on 04 09 2009 12:47 AM: >> Noel Chiappa wrote: >> >>> There is simply no way to produce a definition which both i) >>> completely and >>> accurately describes all the uses to which an IPvN address is >>> currently put, >>> and ii) is short and crisp. >> >> >> So true. And it would seem that i) is a clear indication of the >> amount of overloading that we've applied to the IPv4 namespace. > > Is a group address a locator or ID? > > For LISP, it is considered an EID since it doesn't map to topology and > when a host moves around and stays joined to the group, the group > address doesn't change. So it is close to your definition of "Identifier". > > Dino Are you talking about multicast group addresses? They are a perfect example of a forwarding selector. At each hop, forwarding uses them to decide on a next-hop, but they do not name a particular point of attachment. Just because they are not 'locators' doesn't mean they are identifiers. What was it Noel said about trying to fit everything into too few names? From swb@employees.org Thu Apr 9 14:08:10 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDD33A68A3 for ; Thu, 9 Apr 2009 14:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gpg7Cft5D4G for ; Thu, 9 Apr 2009 14:08:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 050123A684A for ; Thu, 9 Apr 2009 14:08:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,163,1238976000"; d="scan'208";a="41407600" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2009 21:09:16 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n39L9Ggr012890; Thu, 9 Apr 2009 17:09:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n39L9GcM029112; Thu, 9 Apr 2009 21:09:16 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 17:09:16 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 17:09:15 -0400 Message-ID: <49DE63FB.6070106@employees.org> Date: Thu, 09 Apr 2009 17:09:15 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Li References: <49DC1F92.7000408@tony.li> In-Reply-To: <49DC1F92.7000408@tony.li> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 21:09:15.0981 (UTC) FILETIME=[70A33FD0:01C9B957] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 21:08:10 -0000 Tony Li allegedly wrote on 04 07 2009 11:52 PM: > > Hi all, > > As the conversation has died down, I'm going to guess that we've > converged. The consensus check can be found here: > http://doodle.com/9sybb8dmk5phvp99 > > Please vote for or against these definitions: I voted against ... > locator A locator is a name for a point of attachment within the > topology at a given layer. Objects that change their point > of attachment(s) will need to change their associated > locator(s). By default, a locator refers to layer 3. It > is also possible to have locators at other layers. > Locators may have other properties, such as their scope > (local or global (default)) and their lifetime (ephemeral > or permanent (default)). This works for me except for anycast. The problem is that if you have an anycast address you might not _need_ to change it if you move to a different point of attachment, and since that particular point of attachment might not have any other name associated with it, IMHO within a single network, anycast _does_ name a particular point of attachment. So I'm back to the suggestion I made before you included "at a given layer": a locator is a name for a point of attachment, and if an object moves its associated locator(s) might not change but it cannot assume that they will not. Perhaps the text could say "may have to change" or "cannot be expected not to change". > identifier An identifier is the name of an object at a given layer; > identifiers have no topological sensitivity, and do not > have to change, even if the object changes its point(s) of > attachment within the network topology. Identifiers may > have other properties, such as the scope of their > uniqueness (local or global (default)), the probability of > their uniqueness (statistical or absolute (default)), and > their lifetime (ephemeral or permanent (default)). wfm > address An address is a name that is used as both an interface > locator and an endpoint identifier. wfm Scott From swb@employees.org Thu Apr 9 16:42:02 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC053A6B76 for ; Thu, 9 Apr 2009 16:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE1I7jFupwhr for ; Thu, 9 Apr 2009 16:42:02 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1B9633A6A2F for ; Thu, 9 Apr 2009 16:42:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,163,1238976000"; d="scan'208";a="71344592" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2009 23:43:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n39NhAxA008676; Thu, 9 Apr 2009 16:43:10 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n39NhA4Z011520; Thu, 9 Apr 2009 23:43:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 19:43:09 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 19:43:09 -0400 Message-ID: <49DE880C.7020704@employees.org> Date: Thu, 09 Apr 2009 19:43:08 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> In-Reply-To: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 23:43:09.0212 (UTC) FILETIME=[F0127DC0:01C9B96C] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:42:02 -0000 William Herrin allegedly wrote on 04 04 2009 11:20 AM: > Briefly: > > Identifier: Any element in the ongoing communication between a user > and a network service he uses which is statically bound to the > function of correlating the communication's data packets with the > communication as a whole. We use identifiers for - discovery - authentication - session control - referral 3/4 of these are outside of an "ongoing communication". > Address: Any element in a network packet used to calculate the > packet's next hop. An address might or might not be used to construct > an identifier as well. There are many elements in a packet that are used to calculate the next-hop. You really don't want to try to generalize "address" to cover everything including SIP options and (as others have said) MPLS labels. > Locator: An address which is not used to construct an identifier. A > locator is only used to calculate the packet's next hop. (1) There's no way "locator" is going to be a negative definition. (2) See other discussion about why Packet Forwarding is a separation issue from Point Of Attachment Naming (what locators are for). Scott From wherrin@gmail.com Thu Apr 9 17:07:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6537C3A6BB6 for ; Thu, 9 Apr 2009 17:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jryxjgzV2H4E for ; Thu, 9 Apr 2009 17:07:06 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 59E463A6CEF for ; Thu, 9 Apr 2009 17:07:06 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so639925ywh.37 for ; Thu, 09 Apr 2009 17:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=q7W4Jj8ZKArSkDZTw3XjKVnQ6H8a1fxXQcOx3DkLl0g=; b=Xjw+qiPUI8yAmnsThqaI6k0da+jGVPVv+1e/5WLeCD6OmQFvYsVU7KR0cpWLRLKY/n agJo4YVcLaeyHET4ETan5e8Af23yWZZKqi3LJWAESharSyV4XFx8/edgBk6js5rDA/Rp CmjBw7pQ76A8RuNYxtXkOAFYq/kpzs05AnDes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=R1nCmVRCMw+yKl2Vhlv6FuBu42sCD4hfPbCnma4b7Oqv1mMgjj7N82/qL42rDH2jQN XX9iiavk3ImS+rHaWIQvyXuSUCZNVSYETwalDR3F3DySkYxgFI/vK/g16S1fc+kkZRfn iaTt1ma9EY/gy5IIE4hYwLj956fDT8r0Pra1c= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.166.10 with SMTP id o10mr1372392ane.53.1239322094372; Thu, 09 Apr 2009 17:08:14 -0700 (PDT) In-Reply-To: <49DE880C.7020704@employees.org> References: <3c3e3fca0904040820n40de17fcic90cfa4aa17b4c10@mail.gmail.com> <49DE880C.7020704@employees.org> Date: Thu, 9 Apr 2009 20:08:14 -0400 X-Google-Sender-Auth: e49b09be14ae0ae3 Message-ID: <3c3e3fca0904091708o1a720b34mb76ffa7d1fe9e460@mail.gmail.com> From: William Herrin To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] definitions - alternate view X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:07:07 -0000 On Thu, Apr 9, 2009 at 7:43 PM, Scott Brim wrote: > William Herrin allegedly wrote on 04 04 2009 11:20 AM: >> Identifier: Any element in the ongoing communication between a user >> and a network service he uses which is statically bound to the >> function of correlating the communication's data packets with the >> communication as a whole. > > We use identifiers for > > =A0- discovery > =A0- authentication > =A0- session control > =A0- referral > > 3/4 of these are outside of an "ongoing communication". Hi Scott, If you take the plain-english meanings of the two words (instead of implicitly adding "session" to the end) you'll find that it stretches to cover all four cases. If I chat with you today, and I chat with you tomorrow, and I chat with you again next week, that's an ongoing communication. I discover your current location, possibly by going somewhere I know you frequent, asking "Have you seen Scott?" and being referred to someone else who might know. We confirm each others' identity by sight and begin a chat session tied together by the audio characteristics of our respective voices. Nevertheless, I relent. "Identifier," as we've used it here on the group, has at least two rather distinct meanings that deserve to be treated separately. We do ourselves a disservice by trying to either combine them or exorcise one or the other. Referent - these are your discovery and referral elements. They're used in the process of connecting the user to the resource he seeks. Correlator - your session and authentication elements. They're used to collect the packets and connections and sessions into a larger scope. We've been calling both of these things identifiers but they don't really have much in common. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jnc@mercury.lcs.mit.edu Thu Apr 9 17:17:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5099F3A6B2E for ; Thu, 9 Apr 2009 17:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxxmXmsxt1ko for ; Thu, 9 Apr 2009 17:17:08 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 90F363A69E9 for ; Thu, 9 Apr 2009 17:17:08 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 18A276BE5C3; Thu, 9 Apr 2009 20:18:14 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> Date: Thu, 9 Apr 2009 20:18:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:17:09 -0000 > From: William Herrin > If its practical for anycast to be an integral part of unicast routing > then it's likely to be suboptimal or even destructive to architect it > as a peer to unicast routing. Anycast 'addresses' are service names. What we are doing, then, is using the routing to route to service names. This might be seen as good in the short term, but this kind of mixing of fundamentally different functions in one mechanism is exactly the kind of thing that, in the long run, can be a problem. For one thing, it's a truism of system architecture that as a system gets larger, mechanisms that are used to do two different things don't scale well. For another, it makes the resulting system more rigid, less adaptable, etc, etc. Noel From jnc@mercury.lcs.mit.edu Thu Apr 9 17:54:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1EC3A6D04 for ; Thu, 9 Apr 2009 17:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHJJFWu6wnqs for ; Thu, 9 Apr 2009 17:54:06 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 4799F3A6CCB for ; Thu, 9 Apr 2009 17:54:06 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 794586BE5C5; Thu, 9 Apr 2009 20:55:13 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090410005513.794586BE5C5@mercury.lcs.mit.edu> Date: Thu, 9 Apr 2009 20:55:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 00:54:07 -0000 > From: Dino Farinacci > Is a group address a locator or ID? Well, as you point out, it has more of the characteristics of an identifier. But really it's a 'group name', with quite different semantics from a 'host identifier' - in IPv4 it just happens to live in the same namespace, but it names a very different kind of thing. Noel From swb@employees.org Thu Apr 9 18:22:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A219528C107 for ; Thu, 9 Apr 2009 18:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnvepCCH5GWy for ; Thu, 9 Apr 2009 18:22:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9C3EF28C119 for ; Thu, 9 Apr 2009 18:22:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,164,1238976000"; d="scan'208";a="41503374" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2009 01:23:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3A1NCAG016114; Thu, 9 Apr 2009 21:23:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3A1NC7a005328; Fri, 10 Apr 2009 01:23:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 21:23:12 -0400 Received: from sbrim-mbp.local ([10.86.242.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 21:23:11 -0400 Message-ID: <49DE9F7E.80500@employees.org> Date: Thu, 09 Apr 2009 21:23:10 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> In-Reply-To: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2009 01:23:11.0857 (UTC) FILETIME=[E9ED6E10:01C9B97A] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:22:05 -0000 Noel Chiappa allegedly wrote on 04 09 2009 8:18 PM: > > From: William Herrin > > > If its practical for anycast to be an integral part of unicast routing > > then it's likely to be suboptimal or even destructive to architect it > > as a peer to unicast routing. > > Anycast 'addresses' are service names. What we are doing, then, is using the > routing to route to service names. Assuming you are right that anycast addresses are service names (see below) you are using service names as forwarding selectors. We do that with deep packet inspection too for example. > This might be seen as good in the short term, but this kind of mixing of > fundamentally different functions in one mechanism is exactly the kind of > thing that, in the long run, can be a problem. It is not mixing different functions. There is a big difference between what forwarding uses and point of attachment names. Forwarding can use anything, and does (not all of it in the packets). Granted it is placing the service name in a field where one traditionally finds addresses, but no actual functions are mixed. Forwarding does what it always does. The service names cleverly look like addresses. But all that assumes anycast addresses are "service names". I want to get back to the question of whether anycast addresses are locators. Joel and I had a short phone call, and here's the example I used: - Suppose I have a little network and I advertise a route to it on the Internet. Are the names for points of attachment of the nodes on my network locators? Yes (I hope you say). - Now suppose Joel accidentally misconfigures a few things and ends up configuring exactly the same prefix for his little network, and advertising a route to it. I haven't changed anything. Are the names for the points of attachment on my network still locators, or are they just "service names"? Joel suggested that the architecture shouldn't have to handle misconfigurations, but it's deeper than that. Someone making a mistake does not change the essential nature of things in the architecture. A suggestion for a fundamental principle: If an architectural component is fundamental, what someone does with it doesn't change what it is. So I ask you: if I had locators to start with, why wouldn't I still have locators after someone else claims to have them as well? If the answer is that I still do, how is that different from anycast? Scott From jmh@joelhalpern.com Thu Apr 9 18:42:33 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC523A69ED for ; Thu, 9 Apr 2009 18:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmwN-cnHOGgu for ; Thu, 9 Apr 2009 18:42:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4BC0A3A67D7 for ; Thu, 9 Apr 2009 18:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D37E3430457; Thu, 9 Apr 2009 18:43:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7462E430461; Thu, 9 Apr 2009 18:43:39 -0700 (PDT) Message-ID: <49DEA446.9020007@joelhalpern.com> Date: Thu, 09 Apr 2009 21:43:34 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim References: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> <49DE9F7E.80500@employees.org> In-Reply-To: <49DE9F7E.80500@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 01:42:33 -0000 Considered as an architectural locator, in your example of accidental misconfiguration, the locator is still a locator. In fact, it is still your locator, locating your interfaces. However, due to misconfiguration, the system no longer knows that in all places. That is very different from something which is actually located in multiple places. Joel Scott Brim wrote: > Noel Chiappa allegedly wrote on 04 09 2009 8:18 PM: >> > From: William Herrin >> >> > If its practical for anycast to be an integral part of unicast routing >> > then it's likely to be suboptimal or even destructive to architect it >> > as a peer to unicast routing. >> >> Anycast 'addresses' are service names. What we are doing, then, is using the >> routing to route to service names. > > Assuming you are right that anycast addresses are service names (see > below) you are using service names as forwarding selectors. We do that > with deep packet inspection too for example. > >> This might be seen as good in the short term, but this kind of mixing of >> fundamentally different functions in one mechanism is exactly the kind of >> thing that, in the long run, can be a problem. > > It is not mixing different functions. There is a big difference between > what forwarding uses and point of attachment names. Forwarding can use > anything, and does (not all of it in the packets). Granted it is > placing the service name in a field where one traditionally finds > addresses, but no actual functions are mixed. Forwarding does what it > always does. The service names cleverly look like addresses. > > But all that assumes anycast addresses are "service names". I want to > get back to the question of whether anycast addresses are locators. > Joel and I had a short phone call, and here's the example I used: > > - Suppose I have a little network and I advertise a route to it on the > Internet. Are the names for points of attachment of the nodes on my > network locators? Yes (I hope you say). > > - Now suppose Joel accidentally misconfigures a few things and ends up > configuring exactly the same prefix for his little network, and > advertising a route to it. I haven't changed anything. Are the names > for the points of attachment on my network still locators, or are they > just "service names"? > > Joel suggested that the architecture shouldn't have to handle > misconfigurations, but it's deeper than that. Someone making a mistake > does not change the essential nature of things in the architecture. A > suggestion for a fundamental principle: If an architectural component is > fundamental, what someone does with it doesn't change what it is. > > So I ask you: if I had locators to start with, why wouldn't I still have > locators after someone else claims to have them as well? If the answer > is that I still do, how is that different from anycast? > > Scott > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From rja@extremenetworks.com Fri Apr 10 07:55:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4453A69C6 for ; Fri, 10 Apr 2009 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJxkB8j7YMuK for ; Fri, 10 Apr 2009 07:55:30 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 045EB3A67DD for ; Fri, 10 Apr 2009 07:55:29 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHW00FHQ4620QF2@vms173017.mailsrvcs.net> for rrg@irtf.org; Fri, 10 Apr 2009 09:56:30 -0500 (CDT) Message-id: <75C3DFFD-67FE-47DC-848B-6C73A9BA1982@extremenetworks.com> From: RJ Atkinson To: IRTF Routing RG Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 10:56:26 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [rrg] Terminology: Multicasting X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 14:55:30 -0000 It seems to me that for multicasting a similar kind of semantic overloading is currently common. As for the unicast world, I don't think such semantic overloading is helpful. It seems to me that relative to multicasting, there are at least 2 different objects that matter: 1) A Multicast Group Identifier, which is topology independent, and just gives a name for the group. 2) A Rendezvous Point useful for that Multicast Group. I imagine this is topology-dependent, and aggregatable, as it is naming the location of an RP (i.e. from the perspective of the unicast world). Some folks might suggest that (2) is a kind of "Forwarding Directive" or "Forwarding Hint", but it seems to me that the thing really needed is the location of a RP for a given destination multicast group. Yours, Ran From rja@extremenetworks.com Fri Apr 10 07:56:38 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21ADE3A6DF5 for ; Fri, 10 Apr 2009 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MJKmI+LVptV for ; Fri, 10 Apr 2009 07:56:37 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 126F13A6DF8 for ; Fri, 10 Apr 2009 07:55:50 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHW00FHQ4620QF2@vms173017.mailsrvcs.net> for rrg@irtf.org; Fri, 10 Apr 2009 09:56:58 -0500 (CDT) Message-id: From: RJ Atkinson To: IRTF Routing RG Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 10:56:58 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [rrg] Anycasting X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 14:56:38 -0000 +1 for what Joel H has been saying in the last day or two. Ran From dino@cisco.com Fri Apr 10 12:46:25 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A533A697A for ; Fri, 10 Apr 2009 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVlxFCH1truc for ; Fri, 10 Apr 2009 12:46:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 772B93A6BD4 for ; Fri, 10 Apr 2009 12:46:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,169,1238976000"; d="scan'208";a="284062261" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2009 19:47:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3AJlLV1004000; Fri, 10 Apr 2009 12:47:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3AJlLP1017515; Fri, 10 Apr 2009 19:47:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 12:47:21 -0700 Received: from [192.168.5.216] ([10.21.118.4]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 12:47:20 -0700 Message-Id: <44FAB7A3-CDB6-4D0C-A13D-1E4169E66785@cisco.com> From: Dino Farinacci To: RJ Atkinson In-Reply-To: <75C3DFFD-67FE-47DC-848B-6C73A9BA1982@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Fri, 10 Apr 2009 09:11:03 -0700 References: <75C3DFFD-67FE-47DC-848B-6C73A9BA1982@extremenetworks.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 10 Apr 2009 19:47:20.0854 (UTC) FILETIME=[29682360:01C9BA15] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1170; t=1239392841; x=1240256841; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Terminology=3A=20Multicasting |Sender:=20; bh=Baagtjleq8j4B3jKHRjrQUrQu7WbomqqLGRBgqu1qRA=; b=St3zt7VkkfVOtV/3dhMLK+Ruap3ZV9EB7M08DjqeN02D8xk0iYFszne69P aP+ies46CjDz2gFZv/S+v2Mg/ysev0siBxFd9f84B5QB3f2GHsWHRZZZrRW2 4AAO/RWq9m; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IRTF Routing RG Subject: Re: [rrg] Terminology: Multicasting X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:46:25 -0000 > It seems to me that for multicasting a similar > kind of semantic overloading is currently common. > As for the unicast world, I don't think such > semantic overloading is helpful. > > It seems to me that relative to multicasting, > there are at least 2 different objects that > matter: > > 1) A Multicast Group Identifier, which is topology > independent, and just gives a name for the group. > > 2) A Rendezvous Point useful for that Multicast Group. > I imagine this is topology-dependent, and aggregatable, > as it is naming the location of an RP (i.e. from the > perspective of the unicast world). > > Some folks might suggest that (2) is a kind of "Forwarding > Directive" or "Forwarding Hint", but it seems to me that > the thing really needed is the location of a RP for a > given destination multicast group. As well as a source address for a source-based distribution trees. Check out one set of definitions in draft-farinacci-lisp- multicast-01.txt. Dino > > > Yours, > > Ran > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From tony.li@tony.li Sat Apr 11 16:36:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30843A6AAD for ; Sat, 11 Apr 2009 16:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su8-qpzMq6wf for ; Sat, 11 Apr 2009 16:36:04 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 008593A6A38 for ; Sat, 11 Apr 2009 16:35:34 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ePQd1b00417UAYkA4Pclzx; Sat, 11 Apr 2009 23:36:45 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id ePcj1b00F3L8a8Q8ZPck81; Sat, 11 Apr 2009 23:36:45 +0000 Message-ID: <49E12972.6020707@tony.li> Date: Sat, 11 Apr 2009 16:36:18 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Brim References: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> <49DE9F7E.80500@employees.org> In-Reply-To: <49DE9F7E.80500@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 23:36:05 -0000 [Catching up...] >> This might be seen as good in the short term, but this kind of mixing of >> fundamentally different functions in one mechanism is exactly the kind of >> thing that, in the long run, can be a problem. > > It is not mixing different functions. There is a big difference between > what forwarding uses and point of attachment names. Forwarding can use > anything, and does (not all of it in the packets). Granted it is > placing the service name in a field where one traditionally finds > addresses, but no actual functions are mixed. Forwarding does what it > always does. The service names cleverly look like addresses. I don't much care how cleverly it's dressed up, it's still an overloading of the token space. That's not an unthinkable direction, but it should be done consciously, with care and forethought. And regardless of much lipstick is applied, it still doesn't make the 'anycast group name' into a locator. It is simply an identifier for a group, with 'one of this set' semantics. We also use it as a forwarding selector. Similarly, the token that we use for a 'multicast group name' is an identifier for a group, with 'all of this set' semantics. Perhaps one clear way of distinguishing these is to look at the embedded topological semantics embedded in these independently of the routing protocols. For a locator, there is a specific, assigned location in the topology. For these group identifiers, _all_ of the location semantics is necessarily embedded in the routing protocol. > If an architectural component is > fundamental, what someone does with it doesn't change what it is. I like that, sort of, but it's missing something. After all, all tokens are simply bit strings. It's only in doing something with them that we assign semantics. Perhaps another way of saying this is that if you overload semantics on an object, you don't obviate the original semantics of the object. > So I ask you: if I had locators to start with, why wouldn't I still have > locators after someone else claims to have them as well? If the answer > is that I still do, how is that different from anycast? A locator points to one assigned spot in the topology. If through misconfiguration or maliciousness it is abused, then yes, it will be mapped to the wrong place, but the fact that we can say 'right' and 'wrong' makes it clear that it has a semantic assignment to a given point. Not so with anycast... Tony From irtf@tonistoev.info Sun Apr 12 02:22:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062FE3A6B18 for ; Sun, 12 Apr 2009 02:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMqUDQfzK1mz for ; Sun, 12 Apr 2009 02:22:06 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 2A2943A6960 for ; Sun, 12 Apr 2009 02:22:06 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop-2.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LsvuB-00051i-GP for rrg@irtf.org; Sun, 12 Apr 2009 12:23:11 +0300 From: Toni Stoev To: IRTF RRG Date: Sun, 12 Apr 2009 12:23:10 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904121223.10977.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 09:22:07 -0000 Hello, future world! Here is my faithful view on address/ID terminology. Term: locator Definition: name of the topological location of a node Analog: unicast address Synonym: address Term: identifier Definition: name of the network identification of a node Analog: host identifier Term: brand Definition: name of the identification of a service type Analog: well known port, anycast address Term: breed Definition: name of the identification of a session kind Analog: multicast address So, I am voting Against in Consensus Check. Toni From HeinerHummel@aol.com Tue Apr 14 12:29:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2473A6EC8 for ; Tue, 14 Apr 2009 12:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWbM-2JHaBpN for ; Tue, 14 Apr 2009 12:29:29 -0700 (PDT) Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by core3.amsl.com (Postfix) with ESMTP id 647103A6EC4 for ; Tue, 14 Apr 2009 12:29:29 -0700 (PDT) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imo-d20.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249e4e452302; Tue, 14 Apr 2009 15:30:26 -0400 Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v40_r1.5.) id l.c05.5c481b7f (39331); Tue, 14 Apr 2009 15:30:19 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 14 Apr 2009 15:30:18 EDT To: dow.street@linquest.com, tony.li@tony.li MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1239737418" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 205.188.169.201 Cc: rrg@irtf.org Subject: Re: [rrg] Consensus check: terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 19:29:30 -0000 -------------------------------1239737418 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 09.04.2009 07:32:05 Westeurop=E4ische Normalzeit schrei= bt dow.street@linquest.com: In other words, I'm not sure if we have a different understanding of the properties in play, or if our understanding is reasonably similar and it is just the words that are causing the confusion. R, Dow Lawyer #1 makes up his point. Judge: You are right ! Lawyer #2 makes up his point which completely opposes lawyer#1. Judge: You are right ! An observing lawyer#3: My honor, you cannot say "you are rigtht" to this= gentleman and also "you are right" to that other gentleman as both have opposite opinions. Judge: Your are also right ! I think all of you are right. Unfortunately there is no poll button to vote for yes AND no at the same time :-( Maybe R Dow is right: the words are causing the confusion. And also: the= definitions cannot replace a solution. Heiner -------------------------------1239737418 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 09.04.2009 07:32:05 Westeurop=E4ische Normalzeit= schreibt dow.street@linquest.com:
In other words, I'm not sure if we have a different 
understanding of th= e properties in play, or if our understanding is 
reasonably simi= lar and it is just the words that are causing the 
confusion.

R,
Dow
Lawyer #1 makes up his point.
Judge: You are right !
Lawyer #2 makes up his point which completely opposes lawyer#1.
Judge: You are right !
An observing lawyer#3: My honor, you cannot say "you are rigtht" to= this gentleman and also "you are right" to that other gentleman as both have op= posite opinions.
Judge: Your are also right !
 
I think all of you are right. Unfortunately there is no poll but= ton to vote for yes AND no at the same time :-(
 
Maybe R Dow is right: the words are causing the confusion. And also:= the definitions cannot replace a solution.
 
Heiner 
 -------------------------------1239737418-- From tony.li@tony.li Tue Apr 14 20:33:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045FC3A681A for ; Tue, 14 Apr 2009 20:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR+PL2R7qHTq for ; Tue, 14 Apr 2009 20:33:02 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 1CBB43A6767 for ; Tue, 14 Apr 2009 20:33:02 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id fcHP1b00e0FhH24A9faFZR; Wed, 15 Apr 2009 03:34:15 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id ffaD1b00F3L8a8Q8UfaENj; Wed, 15 Apr 2009 03:34:14 +0000 Message-ID: <49E555A3.80502@tony.li> Date: Tue, 14 Apr 2009 20:33:55 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tony Li References: <49DD6DD2.3060105@tony.li> In-Reply-To: <49DD6DD2.3060105@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 03:33:03 -0000 Tony Li wrote: > > I'd like to point out to the folks that want to continue the discussion > that the consensus check under way is not dependent on the ongoing (and > welcome) discussion. If you do wish to continue the discussion in any > binding way, please vote against the current proposal. Many folks who > appear adamant against the current proposals have not yet voted. > > Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 > > The poll closes at Tue, 14 Apr 2009 20:52:50 -0700 (one week from when > initiated). Hi all, The poll has now closed. The ayes have it, 10 to 4 (71%), which is reasonably clear consensus. The definitions listed are hereby adopted. Regards, Tony From tony.li@tony.li Tue Apr 14 20:51:11 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4861D3A6A43 for ; Tue, 14 Apr 2009 20:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cqg71yKt36wW for ; Tue, 14 Apr 2009 20:51:10 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 6E4003A69EB for ; Tue, 14 Apr 2009 20:51:10 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id fNjw1b0030ldTLk54fsNlQ; Wed, 15 Apr 2009 03:52:22 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA04.westchester.pa.mail.comcast.net with comcast id ffsL1b0013L8a8Q3QfsNii; Wed, 15 Apr 2009 03:52:22 +0000 Message-ID: <49E559E0.2090302@tony.li> Date: Tue, 14 Apr 2009 20:52:00 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 03:51:11 -0000 Hi all, Thank you for your help with the terminology discussion. I'd like to propose the next question: what are the necessary and sufficient properties of identifiers? We discussed this at Dagstuhl and came away with the following: - topologyâ€independent - stable, at discretion of owner - unambiguous - distinguishable (two for same object?) - facilitate sessionâ€level referrals Thoughts? Tony From wherrin@gmail.com Tue Apr 14 21:49:58 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A53A6A70 for ; Tue, 14 Apr 2009 21:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muMEkAjBGtTW for ; Tue, 14 Apr 2009 21:49:57 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id E2FE13A6A32 for ; Tue, 14 Apr 2009 21:49:56 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1990301ywh.37 for ; Tue, 14 Apr 2009 21:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=jj3zUEJkJbL8RZ+osjL77MlznrZ2pYwZEtZhmYvmeZo=; b=Tv1cks0UEnr+5YahzXFUb90qRMAYWMRYC6/Hmrdb6MQo4hdKOIwzc2Dlg61dAQGi7O 5oshm4/6Ktt7U+MUZWqwRPN+d/PhEfkM6ghGeGfdGoyiEsarVXY2Scn3wy1Jptx3cmOS qJeIHlprg36uLF2kq7/u46w4iQtkt8+LoCyWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=q5BIzzRjF32s676EvV7Pd67Nq4x/W68X0doqYNe3KC3MmDX47dr3RzmLd8+UVDDAK+ MU9/OtUBLYVDm6FcjO2t4d9KTozLi2NWsxH8d6ZXuc5qKxx+ByOoIbpqwy5Tasp3vBoO 3HrOLXDfikLPiKm/dDxOiVitB2hBA2BE5cGTY= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.5.16 with SMTP id 16mr8116541ane.8.1239771068519; Tue, 14 Apr 2009 21:51:08 -0700 (PDT) In-Reply-To: <49E555A3.80502@tony.li> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> Date: Wed, 15 Apr 2009 00:51:08 -0400 X-Google-Sender-Auth: 1f272cf39993883d Message-ID: <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:49:58 -0000 On Tue, Apr 14, 2009 at 11:33 PM, Tony Li wrote: >> Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 > > The poll has now closed. =A0The ayes have it, 10 to 4 (71%), which is > reasonably clear consensus. =A0The definitions listed are hereby adopted. 10 people would have to hum awfully loud to form a consensus among the crowd RRG draws at the meetings. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From xuxh@huawei.com Tue Apr 14 22:52:51 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B383A6B23 for ; Tue, 14 Apr 2009 22:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.387 X-Spam-Level: X-Spam-Status: No, score=0.387 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrCchjIU9K72 for ; Tue, 14 Apr 2009 22:52:51 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B643C3A697F for ; Tue, 14 Apr 2009 22:52:50 -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 <0KI4006IGODRR3@szxga04-in.huawei.com> for rrg@irtf.org; Wed, 15 Apr 2009 13:53:51 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400BX2ODQRX@szxga04-in.huawei.com> for rrg@irtf.org; Wed, 15 Apr 2009 13:53:51 +0800 (CST) Date: Wed, 15 Apr 2009 13:53:52 +0800 From: Xu Xiaohu In-reply-to: <49E559E0.2090302@tony.li> To: 'Tony Li' , rrg@irtf.org Message-id: <003e01c9bd8e$8e1dc090$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acm9fcRgQEeF6Bb1RQuHl5uvPMYR7gAECXrg Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 05:52:51 -0000 > We discussed this at Dagstuhl and came away with the following: >=20 > - topology=A9\independent > - stable, at discretion of owner > - unambiguous > - distinguishable (two for same object?) > - facilitate session=A9\level referrals Does the identifier need any structure? e.g. hierarchical information. = so as to make the ID based routing on overlay network (mapping overlay)more efficient and make the ACL more flexible. Xiaohu From tony.li@tony.li Tue Apr 14 23:10:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2D73A6B7F for ; Tue, 14 Apr 2009 23:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAzU50l-naxt for ; Tue, 14 Apr 2009 23:10:13 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id ECE733A6B5F for ; Tue, 14 Apr 2009 23:10:12 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id fhuY1b0051GXsucA1iAf2G; Wed, 15 Apr 2009 06:10:39 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id fiBQ1b0013L8a8Q8TiBRoj; Wed, 15 Apr 2009 06:11:25 +0000 Message-ID: <49E57A71.5000901@tony.li> Date: Tue, 14 Apr 2009 23:10:57 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> In-Reply-To: <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 06:10:13 -0000 William Herrin wrote: > On Tue, Apr 14, 2009 at 11:33 PM, Tony Li wrote: >>> Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 >> The poll has now closed. The ayes have it, 10 to 4 (71%), which is >> reasonably clear consensus. The definitions listed are hereby adopted. > > 10 people would have to hum awfully loud to form a consensus among the > crowd RRG draws at the meetings. Not if the rest of them were silent, which is effectively what has happened. ;-( Tony From rw@firstpr.com.au Wed Apr 15 01:07:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C951C3A6C05 for ; Wed, 15 Apr 2009 01:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoQ+YZvO2muk for ; Wed, 15 Apr 2009 01:07:06 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5F3BF3A6C0C for ; Wed, 15 Apr 2009 01:07:06 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 4C71A1759EA; Wed, 15 Apr 2009 18:08:17 +1000 (EST) Message-ID: <49E595F1.1080703@firstpr.com.au> Date: Wed, 15 Apr 2009 18:08:17 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rrg@irtf.org References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> In-Reply-To: <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 08:07:07 -0000 Short version: Lots of messages on precisely defining terms which I think do not need it. A year ago the "Summary and Analysis" documents for LISP, APT, Ivip, Six/One Router, TRRP and some others were completed - but the co-chairs have never discussed them. I stayed out of this discussion and vote because I believe the words Identifier, Locator and Address don't need and shouldn't be expected to have precise definitions - because they are frequently used in ways which depend on the conceptual framework of the author. Likewise, I think it would not be productive to try to try to make all religious leaders agree on the definition of "God" - or for psychologists to agree on the precise meaning of "The Unconscious". Not all words have such context dependent meanings. AFAIK "Namespace" only seems to have one meaning: http://www.firstpr.com.au/ip/ivip/namespace/ and I couldn't find a single debate about its meaning, or any IETF people who felt the need to define its meaning. Bill wrote, quoting Tony: >>> Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 >> The poll has now closed. The ayes have it, 10 to 4 (71%), which is >> reasonably clear consensus. The definitions listed are hereby adopted. > > 10 people would have to hum awfully loud to form a consensus among the > crowd RRG draws at the meetings. Of the ~147 messages in this discussion, the breakdown of frequency per author (18 authors) is something like this, with Tony's 33 messages first: 33 23 19 18 11 9 8 4 3 2 1 3 2 1 3 2 1 3 14 votes may indicate a lack of interest in the debate or a lack of confidence that a No would make any difference. I think the co-chairs have a difficult task getting consensus on anything, and when they do, since there is no signed-up constituency I guess it could be hard to make a decision. Opinions weighted by effort expended by the author? Anonymous votes, where a lurker's opinion counts as much as that of someone who wrote pages of thoughtful material? I think the definitions are not bad: http://www.ietf.org/mail-archive/web/rrg/current/msg04724.html but I don't see how these help us solve the scalable routing problem. This is not some mathematical problem awaiting solution via profound insights, perhaps based on semantics developed with penetrating rigour. It is a problem whose solutions are tightly bound by the need for compatibility with all existing hosts and most existing routers - and by the need to ensure immediate benefits for early adopters, since the solution will only work if it is voluntarily adopted by most end-user networks which want multihoming, portability etc. I will sit out the next debate too: "Properties of identifiers". It is a year since we (those who made detailed proposals - AKA the Charter's "candidate designs") wrote our 8 page "Summary and Analysis" documents as requested by the co-chairs. These are linked to from: http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup I just updated the Ivip one today - but it is now 17 pages, in part because it now has to cover Modified Header Forwarding: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf The co-chairs have never commented on or supported discussion of these. I think this would be an interesting and productive discussion. - Robin From lear@cisco.com Wed Apr 15 03:42:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777493A68C5 for ; Wed, 15 Apr 2009 03:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.75 X-Spam-Level: X-Spam-Status: No, score=-9.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y79xrGas40TR for ; Wed, 15 Apr 2009 03:42:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2213D3A6403 for ; Wed, 15 Apr 2009 03:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38349828" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 10:43:57 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FAhvKC016523; Wed, 15 Apr 2009 12:43:57 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4834.cisco.com [10.61.82.225]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FAhuOS025548; Wed, 15 Apr 2009 10:43:56 GMT Message-ID: <49E5BA6C.3080504@cisco.com> Date: Wed, 15 Apr 2009 12:43:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Li References: <20090410001814.18A276BE5C3@mercury.lcs.mit.edu> <49DE9F7E.80500@employees.org> <49E12972.6020707@tony.li> In-Reply-To: <49E12972.6020707@tony.li> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=785; t=1239792237; x=1240656237; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20be=20careful=20what=20you=20ask=20for=20(vaguel y=20related=20in=20a=20smelly=20kind=20of=0A=20way=20to=20Re =3A=20[rrg]=20Consensus=20check=3A=20terminology) |Sender:=20; bh=f4Xc/rY6P+g9ELmjXEzaJw2QXpe58Nm/G/J8UA+1Yik=; b=LXGwEGa1vPo4tHCtvB3ON4ODiVzrkaaiMJ8jnnY5vztuDXGF3h1NYwrcjz rn9/jHOwG8etY5bbKT4hDhZmogaj9BoX7GFVqOLXF3iaM0kKK2CzCHPEYCX8 bUrfhMsWgP; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: rrg@irtf.org, Noel Chiappa Subject: [rrg] be careful what you ask for (vaguely related in a smelly kind of way to Re: Consensus check: terminology) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 10:42:48 -0000 Not really relevant to your main point, but... On 4/12/09 1:36 AM, Tony Li wrote: > I don't much care how cleverly it's dressed up, it's still an > overloading of the token space. That's not an unthinkable direction, > but it should be done consciously, with care and forethought. Just a historical note on this point. When the NSRG considered architectural separation of identifier and locator, Steve Deering made the point that, particularly at layer 4, there are at least weak security benefits from having the transport use the IP address as part of the pseudo-checksum. What he was really saying, I think, with the benefit of some eight years of hindsight, was that there are indeed risks we must consider should we decouple things TOO much. Eliot From jmh@joelhalpern.com Wed Apr 15 07:33:58 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01203A6C41 for ; Wed, 15 Apr 2009 07:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSCocQtSpu0T for ; Wed, 15 Apr 2009 07:33:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1C1443A69CF for ; Wed, 15 Apr 2009 07:33:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A3F2A430393; Wed, 15 Apr 2009 07:35:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 166A94303D7; Wed, 15 Apr 2009 07:35:09 -0700 (PDT) Message-ID: <49E5F095.4010503@joelhalpern.com> Date: Wed, 15 Apr 2009 10:35:01 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Xu Xiaohu References: <003e01c9bd8e$8e1dc090$5e0c6f0a@china.huawei.com> In-Reply-To: <003e01c9bd8e$8e1dc090$5e0c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: rrg@irtf.org Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:33:58 -0000 As I understand it, while an identifier may, in a specific protocol proposal, have structure (hierarchical or otherwise), there are no specific structural requirements for identifiers in general. There is no general requirement that they have structure. Yours, Joel Xu Xiaohu wrote: >> We discussed this at Dagstuhl and came away with the following: >> >> - topology©\independent >> - stable, at discretion of owner >> - unambiguous >> - distinguishable (two for same object?) >> - facilitate session©\level referrals > > Does the identifier need any structure? e.g. hierarchical information. so as > to make the ID based routing on overlay network (mapping overlay)more > efficient and make the ACL more flexible. > > Xiaohu > > > > ------------------------------------------------------------------------ > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From xleonzhao@gmail.com Wed Apr 15 07:54:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F30B3A6C2E for ; Wed, 15 Apr 2009 07:54:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho5hMTK3reOK for ; Wed, 15 Apr 2009 07:54:06 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 7F7B53A697A for ; Wed, 15 Apr 2009 07:54:06 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so2068513anc.37 for ; Wed, 15 Apr 2009 07:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=THg4WD0ReqzDmgQs8EVMBF8r+/8NoPhAfWOlAQ+ao5g=; b=QUVzKrK8U9B8/Het0yd2zDiponSrblJZUnm+9zjQeEzV31NCK1G04S/8OslEBTE4H7 u/SycKMlY9rkoSni4EJ0rnoTr6dWt39wfFbe0gTV7O/8EBuLbb0U72YGOlkRZxZy1bWm lw2sJ5KcXhgYqmU6Gwgj1wd+ypwI8BF5HRV9c= 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=PVrbFIBkEGqOnq7+1Qc/yP1WgyYpLH1TjzRvRRG51252pCZhfz5cxlf5unJqPwiEfA e7OKU4lgViOif9xVUr28bO8hL2ajoFICTZkuA243OCfhCp/w6neP/uV+iBy2YiGBqh9G qRm7VAq+yLZHi0fE+vEFwRdyR+g46MzassPmo= MIME-Version: 1.0 Received: by 10.100.45.9 with SMTP id s9mr492023ans.133.1239807318395; Wed, 15 Apr 2009 07:55:18 -0700 (PDT) In-Reply-To: <49E595F1.1080703@firstpr.com.au> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E595F1.1080703@firstpr.com.au> Date: Wed, 15 Apr 2009 10:55:17 -0400 Message-ID: <4e913c5d0904150755s337be9f8t90b42e66d84daf3d@mail.gmail.com> From: Xiaoliang Zhao To: Robin Whittle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:54:07 -0000 > It is a problem whose solutions are tightly bound by the need for > compatibility with all existing hosts and most existing routers - and > by the need to ensure immediate benefits for early adopters, since > the solution will only work if it is voluntarily adopted by most > end-user networks which want multihoming, portability etc. > I would consensus on this one. Best, ---- Xiaoliang (Leon) Zhao Sr. Network Engineer Public IP Global Network Engineering Verizon Business From pesherb@yahoo.com Wed Apr 15 08:09:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6BC28C19F for ; Wed, 15 Apr 2009 08:09:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvB3cKczGBqx for ; Wed, 15 Apr 2009 08:09:39 -0700 (PDT) Received: from web59202.mail.re1.yahoo.com (web59202.mail.re1.yahoo.com [66.196.101.28]) by core3.amsl.com (Postfix) with SMTP id BF10D28C178 for ; Wed, 15 Apr 2009 08:09:39 -0700 (PDT) Received: (qmail 45320 invoked by uid 60001); 15 Apr 2009 15:10:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239808251; bh=7HL2f8Ewk8Dm9u4RzVUXlbjW8Wr9qkbatjn+CWUlavM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hrxzm6gYdZa7juG4381ecfYaJB8gvl/sajpDlZ6zdcXml7IQecJCSnubxMtPj2ikvFZU953elK59uXlMMyCXnl0CCHOBWquT/5SUs3/iIWvnNvQEihTM53T4tvXiwvOgn5tssYoo0hyXApcPPSociLEIYEN6l/SBxM6/MIFoTSU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=a1IytQP0eMj/T3/BQz6vjZV3wetwbOtPO944brq19OP1ZPwHTimSWw3z522RLsBQbRTX8Q2Eh2HEl9JW/Suvg/DUBLfizPnOic3/pxHzMI6oGIPCRut0etsfvlWPMX+2y4wNmElSA/njkeMEgk7JlrsmTw/Fb+lGx2stZk7mCxI=; Message-ID: <610292.43536.qm@web59202.mail.re1.yahoo.com> X-YMail-OSG: qaBbKZ4VM1kNLSIVAibj3r1sajAOoMU.0RgF25gixsjrpBZVVu2XGl8e1jA8IGvJJRtcegsEQ999UmIJMImcNrJDb7Vk5vVmlZpCG7f2jeexgxidGAhm3560312gVgwn2lKUU9ZFVdpIgsNaggVpGPbrKjGrNjBDdPu0RZy_KQsInfbFoZUPX5K4SbYSUu.guKcWh4FKwJerCGpPjItc_9MVNO0T6ILMH0THgVvz9JABqBjZndkOmBN7wheg3DnPu6XnAgRjFpGBICFVkMsaEBMkgniaM6FQm8no0HGlu.lF5rR91Gqb1XwK Received: from [99.227.138.137] by web59202.mail.re1.yahoo.com via HTTP; Wed, 15 Apr 2009 08:10:51 PDT X-Mailer: YahooMailWebService/0.7.289.1 Date: Wed, 15 Apr 2009 08:10:51 -0700 (PDT) From: Peter Sherbin To: rrg@irtf.org, Tony Li In-Reply-To: <49E559E0.2090302@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pesherb@yahoo.com List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:09:40 -0000 > necessary and sufficient properties of identifiers? - generated, distributed, managed by whom / how? - private property of the owner? - if permanent lifetime, what happens if the object dies? Thanks, Peter --- On Tue, 4/14/09, Tony Li wrote: > From: Tony Li > Subject: [rrg] Next topic: properties of identifiers > To: rrg@irtf.org > Date: Tuesday, April 14, 2009, 11:52 PM > Hi all, >=20 > Thank you for your help with the terminology discussion.=20 > I'd like to propose the next question: what are the > necessary and sufficient properties of identifiers? >=20 > We discussed this at Dagstuhl and came away with the > following: >=20 > - topology=E2=80=90independent > - stable, at discretion of owner > - unambiguous > - distinguishable (two for same object?) > - facilitate session=E2=80=90level referrals >=20 > Thoughts? >=20 > Tony >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg=0A=0A=0A From wherrin@gmail.com Wed Apr 15 08:55:11 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129463A6B3F for ; Wed, 15 Apr 2009 08:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le00WEIyaOcp for ; Wed, 15 Apr 2009 08:55:09 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 6B9083A6B0F for ; Wed, 15 Apr 2009 08:55:09 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so2140570yxj.37 for ; Wed, 15 Apr 2009 08:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=PXQNAnNd4328dGQv2u5dIq9oYBBWRdpOYs/Ci4dBS2M=; b=jzW0oC1ilavQGBj7oIlDyxnvM+45ZWHAE3RrOKsYpcEcPPFWVZtDyWdSJ3oMzn7I5J hBKIFdHkj7Esu6SYCG7WQXnNmiuIRaxOEFsKlcNXQH3kKCDWYXgxK5UTUa/CDg3SVacz CmSW6rz6ye7gkAFFwQxqt4MdDQChdhYHnhYtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dR5658fYR8M01lA8bkhr9gIZBkXzy2jM36edY2NrXtUftSeWwiZHyvi9xAPDMAIJRE hKpOYRDSoVbBOOGu2B6T9rzvR7PFoOsrz7Iazh62niRrcFbqtLQ2Gs5awjXhlKHelrdV 4zEj++AAmDY7YTDLInmkGqJNWQ3QqizgKAV4w= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.178.9 with SMTP id a9mr647496anf.9.1239810981035; Wed, 15 Apr 2009 08:56:21 -0700 (PDT) In-Reply-To: <49E57A71.5000901@tony.li> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> Date: Wed, 15 Apr 2009 11:56:19 -0400 X-Google-Sender-Auth: 18d8aa7b88df3798 Message-ID: <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:55:11 -0000 On Wed, Apr 15, 2009 at 2:10 AM, Tony Li wrote: > William Herrin wrote: >> On Tue, Apr 14, 2009 at 11:33 PM, Tony Li wrote: >>>> Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 >>> >>> The poll has now closed. =A0The ayes have it, 10 to 4 (71%), which is >>> reasonably clear consensus. =A0The definitions listed are hereby adopte= d. >> >> 10 people would have to hum awfully loud to form a consensus among the >> crowd RRG draws at the meetings. > > Not if the rest of them were silent, which is effectively what has happen= ed. Hi Tony, Had only two people responded and both said "yes", you'd know better than to call it a consensus. I'm not sure why 14 respondents including dissent should suggest a different conclusion. A consensus check is not a vote. Consensus is an affirmative finding, not a balance between affirmative and negative. Unlike a vote, there are three possible outcomes: consensus for, consensus against and no consensus. For a weak consensus (or "rough consensus" if you prefer the IETF parlance) you're looking for one of two situations: Situation A: 1. The stakeholders are present 2. A simple majority join the consensus. 3. No more than a single-digit-percentage join the dissent Situation B: 1. The stakeholders are present 2. A significant minority join the consensus. 3. No dissent. If the meeting attendance is any guide, 14 respondents is not a majority of the RRG. Further, there was nearly 30% dissent. Your methodology was in error. By failing to consider the stakeholders present but non-responsive, you pre-eliminated the possibility of "no consensus," requiring respondents to either vote for or against the particular definition. That's not a consensus; that's a vote. Corrected for non-response, the proper conclusion from your data is: No consensus. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dow.street@linquest.com Wed Apr 15 09:17:45 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AF23A6A14 for ; Wed, 15 Apr 2009 09:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNulcflHp7UP for ; Wed, 15 Apr 2009 09:17:44 -0700 (PDT) Received: from smtp155.iad.emailsrvr.com (smtp155.iad.emailsrvr.com [207.97.245.155]) by core3.amsl.com (Postfix) with ESMTP id 287B33A694A for ; Wed, 15 Apr 2009 09:17:44 -0700 (PDT) Received: from relay15.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 2DB6E1B4033; Wed, 15 Apr 2009 12:18:56 -0400 (EDT) Received: by relay15.relay.iad.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 9552C1B401C; Wed, 15 Apr 2009 12:18:50 -0400 (EDT) Message-Id: From: Dow Street To: William Herrin In-Reply-To: <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 09:18:49 -0700 References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 16:17:45 -0000 I did not personally vote before the poll closed, but if forced to chose I would probably have said "nea". I partly didn't vote because I do not think agreeing to, or perhaps divining, the "pure" definition for "locator" moves us very far along the path toward a solution. At the start of this discussion I did, but I don't now. There seem to be a lot of different kinds of things we want to talk about, 3 or 4 of which could reasonably map (semantically) to the term "locator". As it stands, I think the definition brought to the poll is a little too fuzzy to be useful (for reasons I have described previously), but if it is helpful for others, so be it. R, Dow On Apr 15, 2009, at 8:56 AM, William Herrin wrote: > On Wed, Apr 15, 2009 at 2:10 AM, Tony Li wrote: >> William Herrin wrote: >>> On Tue, Apr 14, 2009 at 11:33 PM, Tony Li wrote: >>>>> Again, the poll can be found here: http://doodle.com/9sybb8dmk5phvp99 >>>> >>>> The poll has now closed. The ayes have it, 10 to 4 (71%), which is >>>> reasonably clear consensus. The definitions listed are hereby >>>> adopted. >>> >>> 10 people would have to hum awfully loud to form a consensus among >>> the >>> crowd RRG draws at the meetings. >> >> Not if the rest of them were silent, which is effectively what has >> happened. > > > Hi Tony, > > Had only two people responded and both said "yes", you'd know better > than to call it a consensus. I'm not sure why 14 respondents including > dissent should suggest a different conclusion. > > A consensus check is not a vote. Consensus is an affirmative finding, > not a balance between affirmative and negative. Unlike a vote, there > are three possible outcomes: consensus for, consensus against and no > consensus. > > For a weak consensus (or "rough consensus" if you prefer the IETF > parlance) you're looking for one of two situations: > > Situation A: > 1. The stakeholders are present > 2. A simple majority join the consensus. > 3. No more than a single-digit-percentage join the dissent > > Situation B: > 1. The stakeholders are present > 2. A significant minority join the consensus. > 3. No dissent. > > > If the meeting attendance is any guide, 14 respondents is not a > majority of the RRG. Further, there was nearly 30% dissent. > > Your methodology was in error. By failing to consider the stakeholders > present but non-responsive, you pre-eliminated the possibility of "no > consensus," requiring respondents to either vote for or against the > particular definition. That's not a consensus; that's a vote. > > Corrected for non-response, the proper conclusion from your data is: > No consensus. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From swb@employees.org Wed Apr 15 11:28:02 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675CA3A6F2A for ; Wed, 15 Apr 2009 11:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de9FsUDoetQF for ; Wed, 15 Apr 2009 11:28:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5DE023A69F7 for ; Wed, 15 Apr 2009 11:28:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="41995051" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2009 18:29:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FITCOg011303 for ; Wed, 15 Apr 2009 14:29:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FITC2V017586 for ; Wed, 15 Apr 2009 18:29:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:29:12 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:29:11 -0400 Date: Wed, 15 Apr 2009 14:29:10 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090415182910.GD44356@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 18:29:12.0067 (UTC) FILETIME=[12BCC530:01C9BDF8] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:28:02 -0000 Excerpts from Noel Chiappa on Sat, Apr 04, 2009 12:35:50PM -0400: > Note also (in light of some other comments here that I don't have time to > reply to in detail) that in general, the 'name of the location' is only > actually _used_ at the internetwork level (for getting user traffic to the > named location). Clarification: it is only used _for location_ at the level at which it names a location and by functions which do forwarding. Consider MIPv6: from the point of view of a correspondent node, to start with a home address names, and only names, a point of attachment. Later on, when "route optimization" is done, the home address is also used as part of authentication and session identification. But the functions that use it in those ways are not part of IP forwarding. > It may seem that higher-level entities _also_ have locations; e.g. > if you have a application which is running in a stack has only a > single interface, that application also 'sort of' has a location. Bzzt. If you want to talk about "location" of an application, be very careful what your layers are, and your layer networks. You can talk about location of a web services server in a web services layer network. That is far above IP and IP is not involved. You can also say that to reach an application via IP you need to send IP packets to a particular IP-layer location. These two views are independent. > _However_, as soon as you say that a higher-level thing can be > reached through more than one place in the network (or 'attached to > more than one place in the network') - which is what multi-homing is > - then the thing no longer has 'a' location. Whether it has a location in its own application-level layer network is not affected by how many IP-level connections there might be. swb From dino@cisco.com Wed Apr 15 11:34:59 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BFA3A6B07 for ; Wed, 15 Apr 2009 11:34:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gve7fheH0j3s for ; Wed, 15 Apr 2009 11:34:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D23753A68E0 for ; Wed, 15 Apr 2009 11:34:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="153634979" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 18:35:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FIZqN9007127; Wed, 15 Apr 2009 11:35:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FIZqPr013519; Wed, 15 Apr 2009 18:35:52 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 11:35:52 -0700 Received: from dhcp-171-71-55-200.cisco.com ([171.71.55.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 11:35:51 -0700 Message-Id: <9D086BFD-8766-49E4-BFBA-829151977439@cisco.com> From: Dino Farinacci To: Xiaoliang Zhao In-Reply-To: <4e913c5d0904150755s337be9f8t90b42e66d84daf3d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 15 Apr 2009 11:36:00 -0700 References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E595F1.1080703@firstpr.com.au> <4e913c5d0904150755s337be9f8t90b42e66d84daf3d@mail.gmail.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 15 Apr 2009 18:35:51.0733 (UTC) FILETIME=[00F4F650:01C9BDF9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=681; t=1239820552; x=1240684552; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=0K/nATbt4qSDGX+SA/A+TEeQxJYbGDgMActsBNN9CSY=; b=T/M0dFNpDrykZvuNFCutm8y6sfpL9opr3ImlvwGWB3wbAXR3HH1LQcfW++ ma7Zun+UDByYM4vRe7zuWTTf6fsWah4N9oDDyOs9xTe39d4SADCMhvCBc1k3 sHmgZSLAt8; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rrg@irtf.org, Robin Whittle Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:34:59 -0000 >> It is a problem whose solutions are tightly bound by the need for >> compatibility with all existing hosts and most existing routers - and >> by the need to ensure immediate benefits for early adopters, since >> the solution will only work if it is voluntarily adopted by most >> end-user networks which want multihoming, portability etc. >> > I would consensus on this one. Me too. That's 3-0. Dino > > > Best, > ---- > Xiaoliang (Leon) Zhao > Sr. Network Engineer > Public IP Global Network Engineering > Verizon Business > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From swb@employees.org Wed Apr 15 11:39:36 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030F53A6B07 for ; Wed, 15 Apr 2009 11:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97AbIAbPdPn8 for ; Wed, 15 Apr 2009 11:39:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3A8553A6E37 for ; Wed, 15 Apr 2009 11:39:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="172053295" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2009 18:40:47 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FIelkj018187; Wed, 15 Apr 2009 11:40:47 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3FIek94005168; Wed, 15 Apr 2009 18:40:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:40:42 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:40:41 -0400 Date: Wed, 15 Apr 2009 14:40:37 -0400 From: Scott Brim To: Tony Li Message-ID: <20090415184037.GA47183@cisco.com> Mail-Followup-To: Scott Brim , Tony Li , rrg@irtf.org References: <49E559E0.2090302@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49E559E0.2090302@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 18:40:42.0034 (UTC) FILETIME=[ADFD6120:01C9BDF9] Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:39:36 -0000 Tony, First, there are a different uses for identifiers and each has different requirements. Before we can talk about properties for "identifiers" in general we need to separate out which particular uses we are talking about. For example, are you including discovery starting from FQDNs? Kerberos identifiers for auth/auth? Second, what is the purpose of the exercise? I suspect that every practical use case knows what properties it needs already for its various identifiers. If you look at the requirements of a specific use case the properties fall out. One possible purpose I could see (and one I was trying to get at in my slides) would be to reduce the number of identifiers we think we need. What do you have in mind? Scott Excerpts from Tony Li on Tue, Apr 14, 2009 08:52:00PM -0700: > > Hi all, > > Thank you for your help with the terminology discussion. I'd like to > propose the next question: what are the necessary and sufficient > properties of identifiers? > > We discussed this at Dagstuhl and came away with the following: > > - topologyâ€independent > - stable, at discretion of owner > - unambiguous > - distinguishable (two for same object?) > - facilitate sessionâ€level referrals > > Thoughts? > > Tony > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From swb@employees.org Wed Apr 15 11:41:31 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125E33A6A70 for ; Wed, 15 Apr 2009 11:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCxHpKqPZnXJ for ; Wed, 15 Apr 2009 11:41:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6ACDC3A68D5 for ; Wed, 15 Apr 2009 11:41:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="286866730" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2009 18:42:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FIgUNs022455; Wed, 15 Apr 2009 11:42:30 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FIgQgF021580; Wed, 15 Apr 2009 18:42:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:42:22 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 14:42:21 -0400 Date: Wed, 15 Apr 2009 14:42:13 -0400 From: Scott Brim To: Tony Li Message-ID: <20090415184213.GE44356@cisco.com> Mail-Followup-To: Scott Brim , Tony Li , rrg@irtf.org References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E555A3.80502@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 18:42:22.0299 (UTC) FILETIME=[E9C09AB0:01C9BDF9] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:41:31 -0000 Excerpts from Tony Li on Tue, Apr 14, 2009 08:33:55PM -0700: > The poll has now closed. The ayes have it, 10 to 4 (71%), which is > reasonably clear consensus. The definitions listed are hereby adopted. Could you stick them on tools or somewhere, so we don't have to search through mail to find them? From jmh@joelhalpern.com Wed Apr 15 11:47:17 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9D63A6824 for ; Wed, 15 Apr 2009 11:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-czksMHzM-9 for ; Wed, 15 Apr 2009 11:47:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B51CE3A69F7 for ; Wed, 15 Apr 2009 11:47:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 67CBC430489 for ; Wed, 15 Apr 2009 11:48:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D8D9E43044B for ; Wed, 15 Apr 2009 11:48:28 -0700 (PDT) Message-ID: <49E62BF3.20402@joelhalpern.com> Date: Wed, 15 Apr 2009 14:48:19 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rrg@irtf.org References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E595F1.1080703@firstpr.com.au> <4e913c5d0904150755s337be9f8t90b42e66d84daf3d@mail.gmail.com> <9D086BFD-8766-49E4-BFBA-829151977439@cisco.com> In-Reply-To: <9D086BFD-8766-49E4-BFBA-829151977439@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:47:17 -0000 Having gone back to figure out what "It" in the below quoted text is, I disagree. If "it" is a solution to the problems of routing scalability, reliability, robustness, etc that the rrg was chartered to work on, then I do not believe we ever agreed that compatibility with all existing hosts was a requirement. Deployability in such a way that existing hosts and existing routers can interwork with any solution, deployability such that there is value in incremental deployment, and migratability so that incremental deployment is possible are all things I would buy into. But I do not buy that we can not adopt solutions where the primary value requires changes in hosts, or in many routers over the long term. And I do not agree that getting clear terminology is irrelevant to getting to such a goal. I have frequently found it very confusing, and a hinderance to progress, to realize that the person I was talking with meant something different by the terms he was using than I meant by them. Yes, it happens. But that does not make it helpful. Getting a set of terms we can agree upon, and using them, can be very helpful. Yours, Joel Dino Farinacci wrote: >>> It is a problem whose solutions are tightly bound by the need for >>> compatibility with all existing hosts and most existing routers - and >>> by the need to ensure immediate benefits for early adopters, since >>> the solution will only work if it is voluntarily adopted by most >>> end-user networks which want multihoming, portability etc. >>> >> I would consensus on this one. > > Me too. That's 3-0. > > Dino > >> >> >> Best, >> ---- >> Xiaoliang (Leon) Zhao >> Sr. Network Engineer >> Public IP Global Network Engineering >> Verizon Business >> _______________________________________________ >> 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 rja@extremenetworks.com Wed Apr 15 12:10:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7A93A6A8C for ; Wed, 15 Apr 2009 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckoStvCR-mcq for ; Wed, 15 Apr 2009 12:10:20 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id C699E3A6B24 for ; Wed, 15 Apr 2009 12:10:20 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500075PATDE13@vms173001.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 14:11:22 -0500 (CDT) Message-id: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> From: RJ Atkinson To: IRTF Routing RG Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 15:11:17 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:10:21 -0000 Earlier Eliot Lear wrote: % Just a historical note on this point. When the NSRG considered % architectural separation of identifier and locator, Steve Deering % made the point that, particularly at layer 4, there are at least % weaksecurity benefits from having the transport use the IP address % as part of the pseudo-checksum. Eliot's history is sadly incomplete in ways that truly matter... 1) A majority of the NSRG participants present, and everyone with any security background present, clearly disagreed with Steve Deering's claim at the time, speaking as someone who participated in the entire NSRG lifetime (unlike Eliot). 2) It is likely that the *entire* IETF Security Area disagrees with the claim made above; one could confidently say that the vast majority of the IETF Security Area disagrees with that claim. Frankly, the claim is just silly. There are *zero* security benefits from having the transport-layer pseudo-header checksum include the IP address. Zip. None. Zero. Yours, Ran rja@extremenetworks.com From rja@extremenetworks.com Wed Apr 15 12:18:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D773A6C31 for ; Wed, 15 Apr 2009 12:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fz1micATQUU for ; Wed, 15 Apr 2009 12:18:46 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 746493A69BF for ; Wed, 15 Apr 2009 12:18:46 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500GLSPOV0L74@vms173005.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 14:19:48 -0500 (CDT) Message-id: <04C8BB73-23B0-48F6-BDF0-69F5DB50662B@extremenetworks.com> From: RJ Atkinson To: IRTF Routing RG Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 15:19:43 -0400 X-Mailer: Apple Mail (2.930.3) Subject: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:18:47 -0000 Earlier, Tony Li wrote: % We discussed this at Dagstuhl and came away with the following: % - topology=E2=80=90independent Yes. % - stable, at discretion of owner Stable -- yes, but not necessarily until the end of all time. However, what does "at the discretion of owner" mean above ? % - unambiguous - distinguishable (two for same object?) I don't understand the commentary above. % - facilitate session=E2=80=90level referrals An architecture is likely to have multiple identifiers, often with different identifiers at different layers of the architecture. So, while a session-layer identifier might facilitate a session-layer referral, I do not think it is a requirement that all lower-layer identifiers facilitate session-layer referrals. Yours, Ran From rja@extremenetworks.com Wed Apr 15 12:22:39 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB98F3A6C57 for ; Wed, 15 Apr 2009 12:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KycEdAd8nckC for ; Wed, 15 Apr 2009 12:22:39 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 2717D3A68D5 for ; Wed, 15 Apr 2009 12:22:39 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500HFRPVCLNW2@vms173017.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 14:23:41 -0500 (CDT) Message-id: <619BD8CE-C845-403F-A34D-3D0A0AAC840F@extremenetworks.com> From: RJ Atkinson To: IRTF Routing RG Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 15:23:36 -0400 X-Mailer: Apple Mail (2.930.3) Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:22:39 -0000 Earlier, Joel M Halpern wrote: > Having gone back to figure out what "It" in the below quoted text > is, I disagree. > > If "it" is a solution to the problems of routing scalability, > reliability, robustness, etc that the rrg was chartered to work on, > then I do not believe we ever agreed that compatibility with all > existing hosts was a requirement. > > Deployability in such a way that existing hosts and existing routers > can interwork with any solution, deployability such that there is > value in incremental deployment, and migratability so that > incremental deployment is possible are all things I would buy into. > But I do not buy that we can not adopt solutions where the primary > value requires changes in hosts, or in many routers over the long > term. > > And I do not agree that getting clear terminology is irrelevant to > getting to such a goal. I have frequently found it very confusing, > and a hinderance to progress, to realize that the person I was > talking with meant something different by the terms he was using > than I meant by them. Yes, it happens. But that does not make it > helpful. Getting a set of terms we can agree upon, and using them, > can be very helpful. +1 Ran rja@extremenetworks.com PS: This thread needs a new Subject line, but I'm not sure what it ought to be... From jzwiebel@cisco.com Wed Apr 15 12:33:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27993A6BCF for ; Wed, 15 Apr 2009 12:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfRfdj31vFah for ; Wed, 15 Apr 2009 12:33:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 47B3F3A6B07 for ; Wed, 15 Apr 2009 12:33:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="155115919" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2009 19:34:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FJYZZn006882 for ; Wed, 15 Apr 2009 12:34:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FJYZRj015010 for ; Wed, 15 Apr 2009 19:34:35 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 12:34:35 -0700 Received: from [10.0.1.4] ([10.21.118.232]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 12:34:35 -0700 Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Zwiebel Date: Wed, 15 Apr 2009 09:34:34 -1000 To: rrg RG X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 15 Apr 2009 19:34:35.0225 (UTC) FILETIME=[351F2C90:01C9BE01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=755; t=1239824075; x=1240688075; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=j49T9JWWz5bavyi4AmQ2js/hDv208PWj9zunGVF49Sw=; b=YpCkbN3+hPQpY2gu4p2eVTCR5rLI2n5yPXl0nZA21iPZe93Qd6YEqrHcDx BVGm4fwvhSd+Zl0hTe3VQvsyUr7qI+wcQ2boxIDI0ICl0cEy1G5Bw2isQ3wD jzYXKsbdkS; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: John Zwiebel Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:33:24 -0000 > Yes > >> From: Xiaoliang Zhao >> Date: April 15, 2009 7:55:17 AM PDT >> To: Robin Whittle >> Cc: rrg@irtf.org >> Subject: Re: [rrg] Point of order >> >> >>> It is a problem whose solutions are tightly bound by the need for >>> compatibility with all existing hosts and most existing routers - >>> and >>> by the need to ensure immediate benefits for early adopters, since >>> the solution will only work if it is voluntarily adopted by most >>> end-user networks which want multihoming, portability etc. >>> >>> >> I would consensus on this one. >> >> Best, >> ---- >> Xiaoliang (Leon) Zhao >> Sr. Network Engineer >> Public IP Global Network Engineering >> Verizon Business >> From swb@employees.org Wed Apr 15 12:34:42 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8B428C212 for ; Wed, 15 Apr 2009 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGAljZYqdwXb for ; Wed, 15 Apr 2009 12:34:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0D98128C21C for ; Wed, 15 Apr 2009 12:34:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="286902292" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2009 19:35:54 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3FJZrFC025455 for ; Wed, 15 Apr 2009 12:35:53 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FJZllL024705 for ; Wed, 15 Apr 2009 19:35:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 15:35:42 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 15:35:42 -0400 Date: Wed, 15 Apr 2009 15:35:36 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090415193536.GJ44356@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49E559E0.2090302@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 19:35:42.0182 (UTC) FILETIME=[5D080060:01C9BE01] Authentication-Results: sj-dkim-3; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:34:42 -0000 Excerpts from Tony Li on Tue, Apr 14, 2009 08:52:00PM -0700: > - topologyâ€independent by definition > - stable, at discretion of owner Is that a useful attribute? Is the point that they are not necessarily persistent, or that they might be persistent, or ... ? > - unambiguous Is this a statement about scope? Please clarify. > - distinguishable (two for same object?) Does "distinguishable" mean a name only names one object? I don't see why an object can't have multiple names from the same namespace. > - facilitate sessionâ€level referrals That's a statement about a requirement for identifiers used in session control. It's not a requirement for any particular identifier, e.g. it's not a requirement for FQDNs. We need to make a statement about the scope of this exercise, and what requirements it is meant to meet, before proceeding much further. From swb@employees.org Wed Apr 15 12:47:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5643A6F0D for ; Wed, 15 Apr 2009 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjGoVAWtsUHp for ; Wed, 15 Apr 2009 12:47:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E5F083A6B07 for ; Wed, 15 Apr 2009 12:47:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="41926527" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2009 19:48:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FJmWAM012584; Wed, 15 Apr 2009 15:48:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FJmWX7019689; Wed, 15 Apr 2009 19:48:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 15:48:32 -0400 Received: from cisco.com ([10.86.248.228]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 15:48:31 -0400 Date: Wed, 15 Apr 2009 15:48:29 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090415194829.GK44356@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org, Malcolm Betts References: <20090404163550.D04C26BE584@mercury.lcs.mit.edu> <20090415182910.GD44356@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090415182910.GD44356@cisco.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 15 Apr 2009 19:48:32.0099 (UTC) FILETIME=[27F00330:01C9BE03] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: Malcolm Betts Subject: Re: [rrg] Relativity & generality and Terminology, 3rd pass X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:47:21 -0000 Excerpts from Scott Brim on Wed, Apr 15, 2009 02:29:10PM -0400: > Excerpts from Noel Chiappa on Sat, Apr 04, 2009 12:35:50PM -0400: > > It may seem that higher-level entities _also_ have locations; e.g. > > if you have a application which is running in a stack has only a > > single interface, that application also 'sort of' has a location. > > Bzzt. If you want to talk about "location" of an application, be very > careful what your layers are, and your layer networks. I haven't used the term layer network in a while, and I did in this message, so I should explain it. It came out of ITU-T SG15. I'm CCing Malcolm Betts who will answer any questions :-p. A layer network may have all 7 layers of the old X.200 7-layer model. It also has its own point-of-attachment namespace, control, and management. You can stack layer networks, and/or concatenate them. Sonet/SDH is one or more layer networks. ATM is one (iirc ATM has X.200 layers 1-5). IP is a layer network. IMHO single-hop MPLS pseudowires are not a layer network, but multi-hop PWs are. That's because multi-hop PWs added a namespace for points of attachment. Web Services can form a layer network. It even has loose-source routing. swb From dow.street@linquest.com Wed Apr 15 12:49:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1058B28C256 for ; Wed, 15 Apr 2009 12:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWUzODuJhpFj for ; Wed, 15 Apr 2009 12:49:11 -0700 (PDT) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by core3.amsl.com (Postfix) with ESMTP id 48CF128C24E for ; Wed, 15 Apr 2009 12:49:11 -0700 (PDT) Received: from relay1.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay1.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id D26AE1278587; Wed, 15 Apr 2009 15:50:22 -0400 (EDT) Received: by relay1.relay.dfw.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 963BA1278585; Wed, 15 Apr 2009 15:50:22 -0400 (EDT) Message-Id: <497E8DB1-2A92-4F8E-9509-3B0D2E084088@linquest.com> From: Dow Street To: Joel M. Halpern In-Reply-To: <49E62BF3.20402@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 12:50:21 -0700 References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E595F1.1080703@firstpr.com.au> <4e913c5d0904150755s337be9f8t90b42e66d84daf3d@mail.gmail.com> <9D086BFD-8766-49E4-BFBA-829151977439@cisco.com> <49E62BF3.20402@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 19:49:12 -0000 On Apr 15, 2009, at 11:48 AM, Joel M. Halpern wrote: > And I do not agree that getting clear terminology is irrelevant to > getting to such a goal. I have frequently found it very confusing, > and a hinderance to progress, to realize that the person I was > talking with meant something different by the terms he was using > than I meant by them. Yes, it happens. But that does not make it > helpful. Getting a set of terms we can agree upon, and using them, > can be very helpful. I am not sure if your comment above was in response to mine - if so, let me clarify: - I do think getting clear and agreed upon terminology is important. - I personally do not think the polled definition of locator is clear. However, there seems to be some agreement of others that it is clear enough. - I do *not* think it is useful to argue whether (clearly defined thing A) vs (clearly defined thing B) should be called a "locator". If your comment above was not in response to mine, then disregard! R, Dow From dino@cisco.com Wed Apr 15 13:21:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FF43A6922 for ; Wed, 15 Apr 2009 13:21:06 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxlhoEejHXwf for ; Wed, 15 Apr 2009 13:21:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6CEDC3A6BC7 for ; Wed, 15 Apr 2009 13:20:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="286931069" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2009 20:21:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FKLrMT013534; Wed, 15 Apr 2009 13:21:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3FKLrjB022515; Wed, 15 Apr 2009 20:21:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 13:21:50 -0700 Received: from dhcp-171-71-55-200.cisco.com ([171.71.55.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 13:21:50 -0700 Message-Id: <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> From: Dino Farinacci To: RJ Atkinson In-Reply-To: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 15 Apr 2009 13:22:00 -0700 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 15 Apr 2009 20:21:50.0739 (UTC) FILETIME=[CF384630:01C9BE07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=366; t=1239826913; x=1240690913; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Eliot's=20note |Sender:=20; bh=zFzL/UNh0LKTG4+qkKsHciY2UQD39/EUsQY555Ud1NU=; b=iZ4N6n3mR22UHcrMbiwTIkZ+Ss8xVZD+v8aalin3NtHPP7QIJkCmqTomAA D8cnDHhtZ8Mjbt2u8KCDRxkgOdFurHledh76OOAKo48T8mzK6lbz+RaKnHWv Yth4svdBDe; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IRTF Routing RG Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:21:06 -0000 > Frankly, the claim is just silly. There are *zero* security > benefits from having the transport-layer pseudo-header checksum > include the IP address. Zip. None. Zero. I would add there are very little *other* benefits as well. Definitely not at the cost of unnecessary complexity implementors have to go through to checksum UDP messages. Dino From lear@cisco.com Wed Apr 15 13:24:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A556A3A6F3A for ; Wed, 15 Apr 2009 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.769 X-Spam-Level: X-Spam-Status: No, score=-9.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAgIxuAyaIWL for ; Wed, 15 Apr 2009 13:24:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5BF453A6E60 for ; Wed, 15 Apr 2009 13:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="38386487" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 20:25:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FKPwIq012905; Wed, 15 Apr 2009 22:25:58 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-97-15.cisco.com [10.61.97.15]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FKPvW0012679; Wed, 15 Apr 2009 20:25:58 GMT Message-ID: <49E642D5.6020304@cisco.com> Date: Wed, 15 Apr 2009 22:25:57 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shredder/3.0b3pre MIME-Version: 1.0 To: RJ Atkinson References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> In-Reply-To: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=261; t=1239827158; x=1240691158; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Eliot's=20note |Sender:=20; bh=mWimjWy4CgA6G4VLqJcBSdjnvqq3aDh983Ur/a0YPyg=; b=mFynFrgObFOILbXLnb4pJzIEYco8t4zKHEygAzH3j61Kq/aoQ1Nz+2htar QkcEgBXvhpnQOrJno8bwg6MQEYcyYFO5MAOdK6giPqrIM9SfQGi5kxGEnnbt vZxGtUWv+C; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: IRTF Routing RG Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:24:48 -0000 Regardless of what you think of Steve's point about the checksum, his underlying point was that there is a binding between transport and internet names, if ever so weak, and that if you introduce a new name you have to bind it securely between layers. From L.Wood@surrey.ac.uk Wed Apr 15 13:43:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579523A6C6C for ; Wed, 15 Apr 2009 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeOtE4EuqseH for ; Wed, 15 Apr 2009 13:43:03 -0700 (PDT) Received: from mail115.messagelabs.com (mail115.messagelabs.com [195.245.231.179]) by core3.amsl.com (Postfix) with SMTP id C8F533A6BF8 for ; Wed, 15 Apr 2009 13:43:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-115.messagelabs.com!1239828253!21179911!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 16542 invoked from network); 15 Apr 2009 20:44:13 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-115.messagelabs.com with SMTP; 15 Apr 2009 20:44:13 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 21:44:13 +0100 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_01C9BE0A.EEFB4D28" Date: Wed, 15 Apr 2009 21:39:38 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Eliot's note Thread-Index: Acm+B+66jTOEKqXLQiieAxAN53dUhAAAlzbX References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> From: To: , X-OriginalArrivalTime: 15 Apr 2009 20:44:13.0142 (UTC) FILETIME=[EF5AB760:01C9BE0A] Cc: rrg@irtf.org Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:43:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BE0A.EEFB4D28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The benefits and tradeoffs are different for IPv6, which discards header checksums, making the pseudo-header check more important for reliability reasons. Besides, shouldn't NAT be difficult? -----Original Message----- From: rrg-bounces@irtf.org on behalf of Dino Farinacci Sent: Wed 2009-04-15 21:22 To: RJ Atkinson Cc: IRTF Routing RG Subject: Re: [rrg] Eliot's note =20 > Frankly, the claim is just silly. There are *zero* security > benefits from having the transport-layer pseudo-header checksum > include the IP address. Zip. None. Zero. I would add there are very little *other* benefits as well. Definitely =20 not at the cost of unnecessary complexity implementors have to go =20 through to checksum UDP messages. Dino ------_=_NextPart_001_01C9BE0A.EEFB4D28 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rrg] Eliot's note

The benefits and tradeoffs are different for IPv6, = which discards
header checksums, making the pseudo-header check more important for
reliability reasons.

Besides, shouldn't NAT be difficult?

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: rrg-bounces@irtf.org on behalf of Dino Farinacci
Sent: Wed 2009-04-15 21:22
To: RJ Atkinson
Cc: IRTF Routing RG
Subject: Re: [rrg] Eliot's note

> Frankly, the claim is just silly.  There are *zero* = security
> benefits from having the transport-layer pseudo-header checksum
> include the IP address.  Zip.  None.  Zero.

I would add there are very little *other* benefits as well. = Definitely 
not at the cost of unnecessary complexity implementors have to = go 
through to checksum UDP messages.

Dino

------_=_NextPart_001_01C9BE0A.EEFB4D28-- From dino@cisco.com Wed Apr 15 13:57:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CF03A6BED for ; Wed, 15 Apr 2009 13:57: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4OAnLZScoiM for ; Wed, 15 Apr 2009 13:57:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1BBD13A6B21 for ; Wed, 15 Apr 2009 13:57:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="286952232" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2009 20:58:34 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3FKwYET030044; Wed, 15 Apr 2009 13:58:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FKwYer019011; Wed, 15 Apr 2009 20:58:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 13:58:34 -0700 Received: from dhcp-171-71-55-200.cisco.com ([171.71.55.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 13:58:33 -0700 Message-Id: <819BEB8B-A684-4962-9FAD-52BE10CB93C0@cisco.com> From: Dino Farinacci To: In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 15 Apr 2009 13:58:44 -0700 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 15 Apr 2009 20:58:33.0933 (UTC) FILETIME=[F06CFFD0:01C9BE0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1115; t=1239829114; x=1240693114; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Eliot's=20note |Sender:=20; bh=clz9G51Yrt6ip30KO+m+QTPYxki78g1XaIcsq/gNBpI=; b=rKZX9lYbgkdZ+cHZ87O+6lq6maJgznsvQJ5t2O7sdEg/fh5I72QjdDmPCV 8exyrvKQ5jxbQks4ex10zLSpx401/m49a7l1MMkKXoTPlC8w8VqCQb84glS1 nQufBlntSP; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rja@extremenetworks.com, rrg@irtf.org Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 20:57:35 -0000 > The benefits and tradeoffs are different for IPv6, which discards > header checksums, making the pseudo-header check more important for > reliability reasons. > Not convinced at all. If IP source or destination address bits get corrupted, a link-layer CRC will find it before the destination will ever get the packet. > Besides, shouldn't NAT be difficult? > With enough thrust, anything can fly. Doesn't mean it should. ;-) Dino > > > > > -----Original Message----- > From: rrg-bounces@irtf.org on behalf of Dino Farinacci > Sent: Wed 2009-04-15 21:22 > To: RJ Atkinson > Cc: IRTF Routing RG > Subject: Re: [rrg] Eliot's note > > > Frankly, the claim is just silly. There are *zero* security > > benefits from having the transport-layer pseudo-header checksum > > include the IP address. Zip. None. Zero. > > I would add there are very little *other* benefits as well. Definitely > not at the cost of unnecessary complexity implementors have to go > through to checksum UDP messages. > > Dino > > From rja@extremenetworks.com Wed Apr 15 14:08:53 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3604C3A6F41 for ; Wed, 15 Apr 2009 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LXALxnTLwDV for ; Wed, 15 Apr 2009 14:08:52 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 78B743A6F3C for ; Wed, 15 Apr 2009 14:08:52 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500KE3USCX2G3@vms173003.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 16:09:53 -0500 (CDT) Message-id: <9AB2114A-5F63-45C0-BBB8-F88B0B084AAC@extremenetworks.com> From: RJ Atkinson To: Eliot Lear In-reply-to: <49E642D5.6020304@cisco.com> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 17:09:48 -0400 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <49E642D5.6020304@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: IRTF Routing RG Subject: Re: [rrg] authenticating inter-layer name bindings X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:08:53 -0000 On 15 Apr 2009, at 16:25, Eliot Lear wrote: > Regardless of what you think of Steve's point about the checksum, his > underlying point was that there is a binding between transport and > internet names, if ever so weak, and that if you introduce a new name > you have to bind it securely between layers. I'll attempt a rephrase. One of the points that various security folks have made over the years (and that was made during NSRG days) is that millions of home NAT boxes (all very very low cost, with low-powered/cheap innards) have no trouble modifying that "binding" in a way that makes the binding worthless from a security (i.e. authentication) perspective. So: 1) An issue with the deployed Internet is that there is not always an easily authenticated binding between names at different layers. - DNSsec is part of the solution for this, as it will permit authentication of the bindings between IP addresses and FQDNs. - IPsec, especially AH, is another part of the solution for this. And as a corollary: 2) It is desirable to be able to authenticate bindings between related names that exist at different layers. - DNSsec is one example of how this might be done. - IPsec AH is another example of how this might be done. Cheers, Ran From rja@extremenetworks.com Wed Apr 15 14:13:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083743A6F37 for ; Wed, 15 Apr 2009 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCQ8DcTxwl5B for ; Wed, 15 Apr 2009 14:13:02 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by core3.amsl.com (Postfix) with ESMTP id 559A13A6C43 for ; Wed, 15 Apr 2009 14:13:02 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500858UZ41K73@vms173001.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 16:13:57 -0500 (CDT) Message-id: <9DBA1BFE-33F7-4C40-A6AD-027AAF019BB4@extremenetworks.com> From: RJ Atkinson To: L.Wood@surrey.ac.uk In-reply-to: <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 17:13:52 -0400 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> X-Mailer: Apple Mail (2.930.3) Cc: "rrg@irtf.org" Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:13:03 -0000 On 15 Apr 2009, at 16:39, L.Wood@surrey.ac.uk wrote: > The benefits and tradeoffs are different for IPv6, which discards > header checksums, making the pseudo-header check more important for > reliability reasons. There are still zero "security" benefits for IPv6. (For my part, I would not want to claim that there are other IPv6 benefits to including IP addresses in the pseudo-header checksum, but the crux of the original claim was an inaccurate one relating to "security".) It is still trivially easy to modify the IPv6 address, and recalculate TCP/UDP checksums to hide the modification. > Besides, shouldn't NAT be difficult? It isn't difficult now, and hasn't been for years. It is so easy that it keeps self-deploying. Yours, Ran From rja@extremenetworks.com Wed Apr 15 14:14:10 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2553A6C43 for ; Wed, 15 Apr 2009 14:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aig9q2--m18o for ; Wed, 15 Apr 2009 14:14:10 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 39A403A6C3B for ; Wed, 15 Apr 2009 14:14:10 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI500AH7V1INGM3@vms173003.mailsrvcs.net> for rrg@irtf.org; Wed, 15 Apr 2009 16:15:19 -0500 (CDT) Message-id: <2942B6ED-F2C0-411A-93EE-F688AA91D481@extremenetworks.com> From: RJ Atkinson To: Dino Farinacci In-reply-to: <819BEB8B-A684-4962-9FAD-52BE10CB93C0@cisco.com> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 17:15:17 -0400 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> <819BEB8B-A684-4962-9FAD-52BE10CB93C0@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "rrg@irtf.org RG" Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 21:14:11 -0000 On 15 Apr 2009, at 16:58, Dino Farinacci wrote: >> The benefits and tradeoffs are different for IPv6, which discards >> header checksums, making the pseudo-header check more important for >> reliability reasons. > > Not convinced at all. If IP source or destination address bits get > corrupted, a link-layer CRC will find it before the destination will > ever get the packet. And if the link checksum isn't strong enough, there will be other serious problems anyway, so a strong enough link checksum is an independent requirement... So +1 on Dino's remarks on this thread... Yours, Ran From brian.e.carpenter@gmail.com Wed Apr 15 16:06:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70ADC3A6A53 for ; Wed, 15 Apr 2009 16:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBIPRPUTXurz for ; Wed, 15 Apr 2009 16:06:04 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 1DAA83A67AC for ; Wed, 15 Apr 2009 16:05:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so115727rvb.7 for ; Wed, 15 Apr 2009 16:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wG9oyjkjvFugokX9sJQPVDD0Glie/jpLFrBvCmTI71U=; b=aQEd5cs/7bduQ4Ns8R+ZfwTce1VHIcQDPbjkKDEzxqR2ZhjUu/jyrTAFWlhwfX6lMv 0PFEQzvv09swGq1bzQKeE2AEJkrEoYrYeSWH7sSeZgxlItGbgwUkbLo54HPhOsOLQte2 ziZ7QW0MfmaOP6ERYtbrvR2Lc9lKTsvmQQD7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=OVyA474w8Zlt+nUkKyopreyIIJec4KGk0E9U4NcEFqjrlgwOV7UHkuep0deU/Te4S1 AB0861CuDccVVng1Ft13/IG3LYci9VR8wZ3l0oxB5BaUjMjMO8dwd8ii/S4elCbC5S5m UPBuGXmWciIcnT1G4R5oOoVdtdKRyFCZWLGAg= Received: by 10.114.197.10 with SMTP id u10mr334087waf.174.1239836811665; Wed, 15 Apr 2009 16:06:51 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l27sm348382waf.41.2009.04.15.16.06.49 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 16:06:51 -0700 (PDT) Message-ID: <49E66888.7080100@gmail.com> Date: Thu, 16 Apr 2009 11:06:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rja@extremenetworks.com, rrg@irtf.org Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 23:06:05 -0000 On 2009-04-16 08:39, L.Wood@surrey.ac.uk wrote: > The benefits and tradeoffs are different for IPv6, which discards > header checksums, making the pseudo-header check more important for > reliability reasons. That's unclear to me. One of the arguments for dropping the layer 3 checksum in IPv6 is that modern layer 2 solutions come with error detection. Making the layer 4 checksum compulsory strengthened that argument, of course. But I don't remember discussion of why the pseudo-header checksum is essential. In fact, when the IPNG WG was chartered in 11/94, the charter said: TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group. So it was taken for granted that we needed it. > > Besides, shouldn't NAT be difficult? Well, no. I don't like NAT because it damages end to end connectivity. If we fix things so that NAT doesn't damage connectivity, NAT ceases to be a problem. Abolishing the address component of the pseudo-header checksum would reduce the damage done by NAT. So in that sense, it would be a move in the right direction. Brian From dino@cisco.com Wed Apr 15 16:11:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEC43A6A74 for ; Wed, 15 Apr 2009 16:11:41 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpNA3SX6hPHE for ; Wed, 15 Apr 2009 16:11:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8CDAE3A67B5 for ; Wed, 15 Apr 2009 16:11:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="172186538" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2009 23:12:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FNCrX7027034; Wed, 15 Apr 2009 16:12:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3FNCqBu029126; Wed, 15 Apr 2009 23:12:52 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:12:52 -0700 Received: from dhcp-171-71-55-200.cisco.com ([171.71.55.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:12:52 -0700 Message-Id: <54AF9A3E-CCA5-4EBD-86F7-C2B6F7CFF71B@cisco.com> From: Dino Farinacci To: Brian E Carpenter In-Reply-To: <49E66888.7080100@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Wed, 15 Apr 2009 16:13:04 -0700 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> <49E66888.7080100@gmail.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 15 Apr 2009 23:12:52.0350 (UTC) FILETIME=[B39DD9E0:01C9BE1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1037; t=1239837173; x=1240701173; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Eliot's=20note |Sender:=20; bh=BiMUcs5xMeeYjjCGIkua/oVO6IOF1YiHMSTgbORrJDk=; b=NoFagbCvOLdSbRu7bzGODGNbQnel4bQt/sqTo5HfcSgqbTZa8+uFidWfeD GkX+Tx1Ph9OjtLdFCISJHilKnIKqHhuBE20Tzn7GZtOBKSiOex/G06DlMKyc gU35fxZqFUZZfUdjGPM1zf61PCKBAyKdguM5GrKDYJ9s2KhSpLvAQ=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rja@extremenetworks.com, rrg@irtf.org Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 23:11:41 -0000 > That's unclear to me. One of the arguments for dropping the layer 3 > checksum in IPv6 is that modern layer 2 solutions come with error > detection. Making the layer 4 checksum compulsory strengthened > that argument, of course. But I don't remember discussion of > why the pseudo-header checksum is essential. In fact, when the IPNG WG > was chartered in 11/94, the charter said: > > TCP/UDP: The IPng Working Group will specify the procedures for > hosts to > compute and verify TCP/UDP pseudo-headers. Any other changes to TCP > beyond making TCP work with IPng are out of scope of the working > group > and should be dealt with by a TCPng Working Group. > > So it was taken for granted that we needed it. I recall the IPng directorate wanted to make the fewest changes to the transport layers. The only changes that were required was to lengthen the address and that is what turned out. The same reason why the low-order 64-bits were not used as a socket-id for TCP for tcb lookups. Dino From brian.e.carpenter@gmail.com Wed Apr 15 16:16:57 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F453A6B57 for ; Wed, 15 Apr 2009 16:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9kTs67xuTpB for ; Wed, 15 Apr 2009 16:16:57 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 378813A6AF7 for ; Wed, 15 Apr 2009 16:16:57 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l24so60985waf.23 for ; Wed, 15 Apr 2009 16:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tPK9/MeFBhyt4Wf3aljqYNT8UY8JSfnmIyABb1eO1xA=; b=uAcIQwiM7pgqBwOUtvRhZ4hmmchZk6Xow40eG8i40Es/XOQWIAMvzEUuvmnyf8QVQZ 60h0VnJo9CGhbYUlZwIj4ezkHhBYhg0SgIqnRHxYL7JnVVVSPwDh0O38n2CNIOLDBdIl OfFfg7I7zh4C4vCCBrZtXx/N1VrDbGunKNyIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Ie3PzPoMd0guMYXTJhomkx0r1PTSD+YMA/+1Dgdsie7xyVVMJ1BAcQR1d1kudK2ok9 GZcJS7SbhAd/oad2btDI1ggH0W6BclDBUP7tSK6AMOfbIWWIIru4mwu6gquFRGJLfp77 +eeQit9df+GpazOMSnisDlEGauXahy6U9HagE= Received: by 10.114.177.1 with SMTP id z1mr346837wae.68.1239837489729; Wed, 15 Apr 2009 16:18:09 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l38sm361264waf.68.2009.04.15.16.18.08 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 16:18:09 -0700 (PDT) Message-ID: <49E66B2E.3000503@gmail.com> Date: Thu, 16 Apr 2009 11:18:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tony Li References: <49E559E0.2090302@tony.li> In-Reply-To: <49E559E0.2090302@tony.li> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 23:16:58 -0000 On 2009-04-15 15:52, Tony Li wrote: >=20 > Hi all, >=20 > Thank you for your help with the terminology discussion. I'd like to > propose the next question: what are the necessary and sufficient > properties of identifiers? >=20 > We discussed this at Dagstuhl and came away with the following: >=20 > - topology=E2=80=90independent > - stable, at discretion of owner I'd say: must have a defined lifetime, set by the owner, which may be inf= inite. > - unambiguous I'd say: must have a defined scope within which they are unique and unamb= iguous. The scope may be universal. [Now define 'universal'. It's not so easy.] > - distinguishable (two for same object?) > - facilitate session=E2=80=90level referrals Brian From rw@firstpr.com.au Wed Apr 15 19:39:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A163A6811 for ; Wed, 15 Apr 2009 19:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuQWr5GRCYf0 for ; Wed, 15 Apr 2009 19:39:42 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 9461A3A6934 for ; Wed, 15 Apr 2009 19:39:41 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 93B06175A76; Thu, 16 Apr 2009 12:40:52 +1000 (EST) Message-ID: <49E69AB5.6060409@firstpr.com.au> Date: Thu, 16 Apr 2009 12:40:53 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Zwiebel Subject: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 02:39:44 -0000 Short version: I hope many people will agree with something like: A successful solution to the routing and addressing scaling problem is tightly constrained by the need for it to be voluntarily adopted by the great majority of end-user networks of all sizes who want or need multihoming, inbound traffic engineering and/or portability of their address space between ISPs. Broadly speaking, this means that at the time of introduction: 1 - The solution must provide immediate and compelling benefits to the end-user networks who adopt it, irrespective of how many other networks have so far adopted it. 2 - Therefore, it must provide multihoming, TE and portability for the adopting networks in a manner which fully supports communications with all hosts - including all hosts in non-upgraded networks. 3 - Therefore, the solution must be compatible with all hosts (stacks and applications) and routers in non-upgraded networks. 4 - The solution must be compatible with all existing applications in the adopting networks. 5 - Although in principle, some or many host stacks could be upgraded in the adopting networks, the difficulties this presents means that a scalable routing solution will only be widely enough adopted on a voluntary basis if no such upgrades are required in order for the new system to provide compelling benefits. Firstly, there are difficulties in motivating operating system / stack programmers to add and test new facilities. Secondly there may be costs and disruption for the adopting network in upgrading the stacks. Thirdly, in many or most end-user networks, some or many hosts will not be amenable to stack upgrades due to them using operating systems which are no longer being maintained or developed. This is especially the case for devices such as printers, routers etc. which do not use one of the major operating systems. 6 - The solution must be compatible with all existing DFZ routers. (Unless it can be shown that all DFZ routers can be upgraded - such as via a software update - by the time of introduction.) [See note at end of message.] 7 - The solution must be attractive for the large number of smaller networks who currently cannot get PI space to do multihoming etc. Our goal is not just to reduce the number of DFZ routes but to enable a much larger number of end-user networks to gain multihoming, TE and portability than is currently possible. 8 - Ideally the solution will also be attractive for most or all end-user networks who currently have their own PI prefixes. This is firstly to improve scaling by attracting those larger end-user networks away from their current conventional PI address space usage and secondly to ensure that smaller networks which aspire to be bigger in the future will perceive the new kind of scalable end-user network address space as suitable for their long-term needs. 9 - Ideally the new system should not compromise security or performance compared to that of current PI or PA techniques. Any degradation in security, packet path lengths, end-to-end packet transit times, packet loss rates and general robustness etc. needs to be more than compensated for by reduced costs and/or benefits such as a more flexible and responsive multihoming restoration capability than is possible with current BGP techniques. 10 - The solution will not be widely enough adopted if it requires upgrades to the internal routers of adopting networks - except perhaps in very small networks such as SOHO where one or a few routers need upgrading anyway to perform ITR and ETR etc. functions. In the longer term - in the years and decades to come - upgrades to DFZ routers, to ISP and end-user network internal routers and to host stacks can be made without significant cost or inconvenience and may allow enhanced performance for the new system. I counted 4 people, including myself, supporting my statement about the scalable routing problem in the "Re: Point of order" thread: http://www.ietf.org/mail-archive/web/rrg/current/msg04786.html It is a problem whose solutions are tightly bound by the need for compatibility with all existing hosts and most existing routers - and by the need to ensure immediate benefits for early adopters, since the solution will only work if it is voluntarily adopted by most end-user networks which want multihoming, portability etc. Xiaoliang Zhao (4789), Dino Farinacci (4794) and John Zwiebel (4801). Joel, you are the only one so far to disagree: http://www.ietf.org/mail-archive/web/rrg/current/msg04797.html > If "it" is a solution to the problems of routing scalability, > reliability, robustness, etc that the rrg was chartered to work on, > then I do not believe we ever agreed that compatibility with all > existing hosts was a requirement. I wasn't suggesting we had all agreed to this, or that "rough consensus" on this had been achieved. The sentence I wrote was a terse version of what I believe to be true. I believe it would be a good idea to reach rough consensus on something like this, such as the new text above. > Deployability in such a way that existing hosts and existing > routers can interwork with any solution, deployability such that > there is value in incremental deployment, and migratability so that > incremental deployment is possible are all things I would buy into. I agree with this, according to my understanding of "incremental deployment" - but after much debate from 2007-11-07 to 2008-04-10 I discovered that my understanding of this term could not be defined in a few words, and was considerably more complex than the meaning several other people ascribed to this term. You contributed to the debate on 2008-03-18: http://www.ietf.org/mail-archive/web/rrg/current/msg01775.html > One small aspect that I think I am seeing here is the same words > ("incrementally deployable") being used to describe two different > concepts. I may be confused, but it looks to me like: > > Deployable incrementally without disruption: This means that a > portion of the net (host, site ISP, whatever) can deploy the system > without losing capability or connectivity. A flag day is not > necessary in order to get the system operational. > > Deployment incremental incentives: This sounds like what Robin is > asking for, and is related to a bunch of work I have seen from > folks like Dr. Odlyzko on the economic incentives that are needed > to drive deployment. It includes analysis of issues like when do > folks need positive return on new technologies to cause them to > deploy. > > They are both valid concerns. But I think they are two different > dimensions. I agree entirely. I realised that my use of the term "incrementally deployable" involved all the conditions for people being motivated to adopt it - in particular by the scalable routing solution providing real benefits for the adopters even when very few other networks have so far adopted it. I think this means the system must provide multihoming, TE and portability of address space in a way which works with all incoming packets, including those from non-upgraded networks. Brian Dickson responded to your message: http://www.ietf.org/mail-archive/web/rrg/current/msg01881.html raising 15 separate points in 4 categories, including: We should be sure the benefits are truly compelling, ideally universally so, and the costs so marginal as to be nearly negligible, before settling on a recommendation. That may mean more work for us, but it is a small price to pay. which I entirely support. You also wrote (2008-03-20): http://www.ietf.org/mail-archive/web/rrg/current/msg01848.html > I realize that there has to be a limit how far down the economic / > business analysis we go. Among other things, we need to start by > coming up with ideas, without regard to such limits. But when it > comes to deployment analysis, ignoring the question of who pays, > and why, is just not going to work. We don't need (don't want, and > can't) to mandate a business model. I would hope that a sensible > recommendation allows for multiple business models. But if we can > not even imagine one that works, then it fails. which I also entirely support. On 2008-04-02 I came up with a detailed description of the deployment requirements of a successful scalable routing solution: http://www.ietf.org/mail-archive/web/rrg/current/msg02030.html ====== "No significant barriers to widespread deployment due to initially low uptake rate, or disruption of existing practices" or: "The zero (or relatively low) critical mass criteria for ubiquitous deployment on an incremental basis without outside inducements" (10) The technology must be able to be introduced without disrupting existing practices. After some low specified level of initial deployment, ideally zero, everyone (or at least most people) who deploys the technology receives benefits (maybe net benefits in some short enough time-frame after accounting for one-off purchase and installation costs) which are not only positive, but substantial and likely to attract many other end-users to the technology. For this to be true, the benefits received must not depend much or at all on what proportion of other users have adopted the technology. Therefore, if the technology would be fundamentally attractive to many, most or all end-users once deployed by most or all end-users, it would also be attractive enough to the very first (or after some low, specified, level of adoption) to actually become widely deployed via a purely incremental means, without inducements or a major up-front deployment before any end-users gain significant benefits. ====== That's a bit of a mouthful, but it is quite a task to fully describe the constraints of upgrading the routing and addressing system of the Internet when we are relying on purely voluntary adoption by end-user networks and their ISPs. The text at the start of this message is an attempt to rewrite the sentence Xiaoliang Zhao, Dino Farinacci and John Zwiebel supported, in the hope that you and many others will support it too. You wrote: > And I do not agree that getting clear terminology is irrelevant to > getting to such a goal. I have frequently found it very confusing, > and a hinderance to progress, to realize that the person I was > talking with meant something different by the terms he was using > than I meant by them. Yes, it happens. But that does not make it > helpful. Getting a set of terms we can agree upon, and using them, > can be very helpful. Yes, but I do not want to try to define exact semantics for "incrementally deployable". I am wary of using the term at all, without explicit definition, because it apparently means different things to different folks, as indicated by the debate over a year ago: http://www.google.com/search?q=RRG+"incrementally+deployable"+site%3Awww.ietf.org+-"rrg+Discussion+Archive" - Robin Note regarding upgrading DFZ routers: If all DFZ routers (or every DFZ router between any ITR and any ETR) can be replaced or upgraded with a firmware update before the solution is deployed, then we could gain considerable benefits. There may be other benefits of this, but I am thinking of Modified Header Forwarding as an alternative to encapsulation - which would eliminate encapsulation overheads and greatly reduce ITR and ETR complexity, due to avoiding the Path MTU Discovery problems which are inherent in encapsulation: http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw http://www.firstpr.com.au/ip/ivip/ivip6/ How soon must a solution be deployed? The IPv4 DFZ routing table http://bgp.potaroo.net currently has a doubling time of about 5.3 years. I think it will be 5 years or more before we really try to deploy a scalable routing system for IPv4. IPv6 DFZ prefixes (click number for IPv6 prefix count at http://bgp.potaroo.net/v6/v6rpt.html) currently number about 855 which is 1/256 of the 219,603 for IPv4. The doubling time is between 2.7 and 4 years. Even with a doubling time of 2 years, it would take 16 years to reach the current IPv4 numbers. So I think it will be perfectly feasible to have IPv6 DFZ routers upgraded for Modified Header Forwarding in time for a scalable routing solution. From jmh@joelhalpern.com Wed Apr 15 20:17:56 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3273A6936 for ; Wed, 15 Apr 2009 20:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EusKRhM4JWV8 for ; Wed, 15 Apr 2009 20:17:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F20DA3A6887 for ; Wed, 15 Apr 2009 20:17:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E599D1C40FB4 for ; Wed, 15 Apr 2009 20:19:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6D7291C40FB3 for ; Wed, 15 Apr 2009 20:19:06 -0700 (PDT) Message-ID: <49E6A3A0.1060202@joelhalpern.com> Date: Wed, 15 Apr 2009 23:18:56 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> In-Reply-To: <49E69AB5.6060409@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:17:57 -0000 This long list of "goals" has the interesting property that each of them sounds reasonable, but each is phrased in such a way as to leave me wondering if it is intended to imply cases or interpretations with which I disagree. To use your original text as an example, "compatibility with all hosts" seems to imply that the solution can not start by modifying some of the hosts. I know that you have argued that a solution based on host modification is untenable, and this is a topic on which we have disagreed. I absolutely agree that deployment has to have value for the deployer, in a reasonable and practical deployment scenario. And the deployer must not lose the ability to talk to the rest of the world in exchagne for that value. Most of the implications I see do not quite match up with the way you chose to phrase things below. An example in the first paragraph below is that the question of what the deployment path is, and when the bulk of users see value, and what value they see, varies depending upon the solution. Nothing will be "voluntarily adopted by the great majority of ..." early in its introduction. The path to widespread adoption is tricky for any technology. Yours, Joel Robin Whittle wrote: > Short version: I hope many people will agree with something like: > > > A successful solution to the routing and addressing > scaling problem is tightly constrained by the need > for it to be voluntarily adopted by the great > majority of end-user networks of all sizes who want > or need multihoming, inbound traffic engineering > and/or portability of their address space between > ISPs. > > Broadly speaking, this means that at the time of > introduction: > > 1 - The solution must provide immediate and > compelling benefits to the end-user networks > who adopt it, irrespective of how many other > networks have so far adopted it. > > 2 - Therefore, it must provide multihoming, TE and > portability for the adopting networks in a > manner which fully supports communications with > all hosts - including all hosts in non-upgraded > networks. > > 3 - Therefore, the solution must be compatible with > all hosts (stacks and applications) and routers > in non-upgraded networks. > > 4 - The solution must be compatible with all > existing applications in the adopting networks. > > 5 - Although in principle, some or many host stacks > could be upgraded in the adopting networks, the > difficulties this presents means that a scalable > routing solution will only be widely enough > adopted on a voluntary basis if no such upgrades > are required in order for the new system to > provide compelling benefits. > > Firstly, there are difficulties in motivating > operating system / stack programmers to add and > test new facilities. Secondly there may be > costs and disruption for the adopting network in > upgrading the stacks. Thirdly, in many or most > end-user networks, some or many hosts will not > be amenable to stack upgrades due to them using > operating systems which are no longer being > maintained or developed. This is especially > the case for devices such as printers, routers > etc. which do not use one of the major operating > systems. > > 6 - The solution must be compatible with all > existing DFZ routers. (Unless it can be shown > that all DFZ routers can be upgraded - such as > via a software update - by the time of > introduction.) [See note at end of message.] > > 7 - The solution must be attractive for the large > number of smaller networks who currently cannot > get PI space to do multihoming etc. Our goal is > not just to reduce the number of DFZ routes but > to enable a much larger number of end-user > networks to gain multihoming, TE and portability > than is currently possible. > > 8 - Ideally the solution will also be attractive for > most or all end-user networks who currently have > their own PI prefixes. This is firstly to > improve scaling by attracting those larger > end-user networks away from their current > conventional PI address space usage and secondly > to ensure that smaller networks which aspire to > be bigger in the future will perceive the new > kind of scalable end-user network address space > as suitable for their long-term needs. > > 9 - Ideally the new system should not compromise > security or performance compared to that of > current PI or PA techniques. Any degradation > in security, packet path lengths, end-to-end > packet transit times, packet loss rates and > general robustness etc. needs to be more than > compensated for by reduced costs and/or benefits > such as a more flexible and responsive > multihoming restoration capability than is > possible with current BGP techniques. > > 10 - The solution will not be widely enough adopted > if it requires upgrades to the internal routers > of adopting networks - except perhaps in very > small networks such as SOHO where one or a few > routers need upgrading anyway to perform ITR and > ETR etc. functions. > > In the longer term - in the years and decades to > come - upgrades to DFZ routers, to ISP and end-user > network internal routers and to host stacks can be > made without significant cost or inconvenience and > may allow enhanced performance for the new system. > > > I counted 4 people, including myself, supporting my statement about > the scalable routing problem in the "Re: Point of order" thread: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04786.html > > It is a problem whose solutions are tightly bound by the need for > compatibility with all existing hosts and most existing routers - > and by the need to ensure immediate benefits for early adopters, > since the solution will only work if it is voluntarily adopted by > most end-user networks which want multihoming, portability etc. > > Xiaoliang Zhao (4789), Dino Farinacci (4794) and John Zwiebel (4801). > > Joel, you are the only one so far to disagree: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04797.html > >> If "it" is a solution to the problems of routing scalability, >> reliability, robustness, etc that the rrg was chartered to work on, >> then I do not believe we ever agreed that compatibility with all >> existing hosts was a requirement. > > I wasn't suggesting we had all agreed to this, or that "rough > consensus" on this had been achieved. > > The sentence I wrote was a terse version of what I believe to be > true. I believe it would be a good idea to reach rough consensus on > something like this, such as the new text above. > > >> Deployability in such a way that existing hosts and existing >> routers can interwork with any solution, deployability such that >> there is value in incremental deployment, and migratability so that >> incremental deployment is possible are all things I would buy into. > > I agree with this, according to my understanding of "incremental > deployment" - but after much debate from 2007-11-07 to 2008-04-10 I > discovered that my understanding of this term could not be defined in > a few words, and was considerably more complex than the meaning > several other people ascribed to this term. > > You contributed to the debate on 2008-03-18: > > http://www.ietf.org/mail-archive/web/rrg/current/msg01775.html > >> One small aspect that I think I am seeing here is the same words >> ("incrementally deployable") being used to describe two different >> concepts. I may be confused, but it looks to me like: >> >> Deployable incrementally without disruption: This means that a >> portion of the net (host, site ISP, whatever) can deploy the system >> without losing capability or connectivity. A flag day is not >> necessary in order to get the system operational. >> >> Deployment incremental incentives: This sounds like what Robin is >> asking for, and is related to a bunch of work I have seen from >> folks like Dr. Odlyzko on the economic incentives that are needed >> to drive deployment. It includes analysis of issues like when do >> folks need positive return on new technologies to cause them to >> deploy. >> >> They are both valid concerns. But I think they are two different >> dimensions. > > I agree entirely. I realised that my use of the term "incrementally > deployable" involved all the conditions for people being motivated > to adopt it - in particular by the scalable routing solution > providing real benefits for the adopters even when very few other > networks have so far adopted it. I think this means the system must > provide multihoming, TE and portability of address space in a way > which works with all incoming packets, including those from > non-upgraded networks. > > Brian Dickson responded to your message: > > http://www.ietf.org/mail-archive/web/rrg/current/msg01881.html > > raising 15 separate points in 4 categories, including: > > We should be sure the benefits are truly compelling, ideally > universally so, and the costs so marginal as to be nearly > negligible, before settling on a recommendation. That may > mean more work for us, but it is a small price to pay. > > which I entirely support. > > You also wrote (2008-03-20): > > http://www.ietf.org/mail-archive/web/rrg/current/msg01848.html > >> I realize that there has to be a limit how far down the economic / >> business analysis we go. Among other things, we need to start by >> coming up with ideas, without regard to such limits. But when it >> comes to deployment analysis, ignoring the question of who pays, >> and why, is just not going to work. We don't need (don't want, and >> can't) to mandate a business model. I would hope that a sensible >> recommendation allows for multiple business models. But if we can >> not even imagine one that works, then it fails. > > which I also entirely support. > > On 2008-04-02 I came up with a detailed description of the deployment > requirements of a successful scalable routing solution: > > http://www.ietf.org/mail-archive/web/rrg/current/msg02030.html > > ====== > > "No significant barriers to widespread deployment due to > initially low uptake rate, or disruption of existing > practices" > > or: "The zero (or relatively low) critical mass criteria for > ubiquitous deployment on an incremental basis without > outside inducements" > > > (10) The technology must be able to be introduced without > disrupting existing practices. After some low > specified level of initial deployment, ideally zero, > everyone (or at least most people) who deploys the > technology receives benefits (maybe net benefits in > some short enough time-frame after accounting for > one-off purchase and installation costs) which are > not only positive, but substantial and likely to > attract many other end-users to the technology. > For this to be true, the benefits received must not > depend much or at all on what proportion of other > users have adopted the technology. Therefore, if the > technology would be fundamentally attractive to many, > most or all end-users once deployed by most or all > end-users, it would also be attractive enough to the > very first (or after some low, specified, level of > adoption) to actually become widely deployed via a purely > incremental means, without inducements or a major up-front > deployment before any end-users gain significant benefits. > > ====== > > That's a bit of a mouthful, but it is quite a task to fully describe > the constraints of upgrading the routing and addressing system of the > Internet when we are relying on purely voluntary adoption by end-user > networks and their ISPs. > > > The text at the start of this message is an attempt to rewrite the > sentence Xiaoliang Zhao, Dino Farinacci and John Zwiebel supported, > in the hope that you and many others will support it too. > > You wrote: > >> And I do not agree that getting clear terminology is irrelevant to >> getting to such a goal. I have frequently found it very confusing, >> and a hinderance to progress, to realize that the person I was >> talking with meant something different by the terms he was using >> than I meant by them. Yes, it happens. But that does not make it >> helpful. Getting a set of terms we can agree upon, and using them, >> can be very helpful. > > Yes, but I do not want to try to define exact semantics for > "incrementally deployable". I am wary of using the term at all, > without explicit definition, because it apparently means different > things to different folks, as indicated by the debate over a year ago: > > http://www.google.com/search?q=RRG+"incrementally+deployable"+site%3Awww.ietf.org+-"rrg+Discussion+Archive" > > - Robin > > > Note regarding upgrading DFZ routers: > > If all DFZ routers (or every DFZ router between any ITR and > any ETR) can be replaced or upgraded with a firmware update > before the solution is deployed, then we could gain > considerable benefits. > > There may be other benefits of this, but I am thinking of > Modified Header Forwarding as an alternative to encapsulation > - which would eliminate encapsulation overheads and greatly > reduce ITR and ETR complexity, due to avoiding the Path MTU > Discovery problems which are inherent in encapsulation: > > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw > http://www.firstpr.com.au/ip/ivip/ivip6/ > > How soon must a solution be deployed? > > The IPv4 DFZ routing table http://bgp.potaroo.net currently has a > doubling time of about 5.3 years. I think it will be 5 years or > more before we really try to deploy a scalable routing system for > IPv4. > > IPv6 DFZ prefixes (click number for IPv6 prefix count at > http://bgp.potaroo.net/v6/v6rpt.html) currently number about > 855 which is 1/256 of the 219,603 for IPv4. The doubling > time is between 2.7 and 4 years. Even with a doubling time of > 2 years, it would take 16 years to reach the current IPv4 > numbers. > > So I think it will be perfectly feasible to have IPv6 DFZ > routers upgraded for Modified Header Forwarding in time > for a scalable routing solution. > > > From tony.li@tony.li Wed Apr 15 20:51:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13B73A6811 for ; Wed, 15 Apr 2009 20:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UZvb4coX+El for ; Wed, 15 Apr 2009 20:51:05 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id EBE5E3A6BDA for ; Wed, 15 Apr 2009 20:50:54 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id fuLk1b00T0b6N64AC3s8WD; Thu, 16 Apr 2009 03:52:08 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id g3s51b00D3L8a8Q8P3s5CZ; Thu, 16 Apr 2009 03:52:07 +0000 Message-ID: <49E64D15.6030903@tony.li> Date: Wed, 15 Apr 2009 14:09:41 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> In-Reply-To: <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:51:05 -0000 Hi Bill, > Had only two people responded and both said "yes", you'd know better > than to call it a consensus. I'm not sure why 14 respondents including > dissent should suggest a different conclusion. In fact, if only two people responded, I'd conclude that the rest didn't care and thus it was acceptable. Yes, that counts as rough consensus. > For a weak consensus (or "rough consensus" if you prefer the IETF > parlance) you're looking for one of two situations: > > Situation A: > 1. The stakeholders are present > 2. A simple majority join the consensus. > 3. No more than a single-digit-percentage join the dissent > > Situation B: > 1. The stakeholders are present > 2. A significant minority join the consensus. > 3. No dissent. Interesting, but that doesn't match my experience, my expectations, or my criteria. > Your methodology was in error. By failing to consider the stakeholders > present but non-responsive, you pre-eliminated the possibility of "no > consensus," requiring respondents to either vote for or against the > particular definition. That's not a consensus; that's a vote. Call it what you like. If folks don't hum, then they don't contribute to the consensus. There are currently 463 members of the RRG, based on the mailing list membership. By your criteria, we need to have input from nearly two hundred people to reach any kind of consensus. That's a guarantee of never making progress. No thank you. If folks care, they'll speak up. If they don't care, then it must not be important to them and we should move on. > Corrected for non-response, the proper conclusion from your data is: > No consensus. Thank you for your concern. I'm sorry that you feel like you've lost and that I'm being unresaonable. All I'm trying to do is to move forward. Cheers, Tony From tony.li@tony.li Wed Apr 15 20:51:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468893A6811 for ; Wed, 15 Apr 2009 20:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6Vp0wn-Fr0C for ; Wed, 15 Apr 2009 20:51:05 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id AB4BA3A6C8E for ; Wed, 15 Apr 2009 20:51:00 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id fu1p1b00G0S2fkCA53sE0u; Thu, 16 Apr 2009 03:52:14 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id g3sC1b0033L8a8Q8V3sCHr; Thu, 16 Apr 2009 03:52:13 +0000 Message-ID: <49E656E7.4060501@tony.li> Date: Wed, 15 Apr 2009 14:51:35 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04AD7B05@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7B05@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Comments on draft-irtf-rrg-recommendation-01 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:51:06 -0000 Hi Phil, Thanks for the comments. Sorry I couldn't respond sooner. > { Well, if it only took pairwise charging to make this happen, then it > { would seem likely that some ISP would have been willing to start doing > { this in a significant way and then these costs would have been passed > { down to the consumer. Similarly, if some ISP could start doing this, > { then its competitors would also have to move in this direction and > { charging would also have become ubiquitous. > { > { Instead what we see is that ISPs accept all routes from any of their > { customers simply to protect their bandwidth revenue. Thus, to instill > { any feedback mechanism, there's going to need to some centralized > { authority that can effectively force a non-zero cost on prefix > injection. > { > { Note also that this can't be done by a small group of ISPs due to > { anti-trust issues. > > [phil] I don't agree with this. just because pairwise charging hasn't > happened yet, doesn't mean it couldn't happen. Well, in some sense you're right, it could happen. However, without a clear driver and without some evidence of it moving forward, we've got no reasonable argument that it will happen. Oh, and this is after several folks have tried to get this started. I don't think we should wait for this. > While prefix announcement /routing messages can be supported (because > system scales well enough) then there is limited incentive to do it. > ISPs get money from transporting data. If isps hit scaling limit that > affected their ability to transport data & thereby gain money, then > charging for routing msgs would be an option. We've hit scalability limits repeatedly, since near the start of operations of non-NSF backed ISPs in the early 90's. It's never been sufficient motivation for any of them to try charging. > { > something on the lines of the second criticism seems ok, although > { > "giving up a solution that genuinely enables users" seems rather > { > provocative /vague [sorry, no text suggestion at the moment] > { > { > { Granted. I'd welcome alternate word-smithing. > > [phil] something like: Strategy E does not seek to make the routing > protocol more scalable, rather the limited 'capacity' is allocated > according to willingness to pay. How about just removing the entire paragraph? This is supposed to be a section on criticism, not advocacy. > { > In the conclusions i dont understand what you mean by : > { > > { > "Further, variants of Strategy B (Section 3.3.2 > { > > { 3.3.2> > { > ) that require manual locator assignment are similarly unacceptable, > { > as are solutions that do not significantly change existing host > { > behavior, such as Strategy D (Section 3.3.4 > { > > { 3.3.4> > { > ), Strategy E (Section 3.3.5 > { > > { 3.3.5> > { > ), Strategy F (Section 3.3.6 > { > > { 3.3.6> > { > ), and Strategy G (Section 3.3.7 > { > > { 3.3.7> > { > )." this says that a solution is only accepatble only if it > { > significantly changes host behaviour. i presume you mean the > { > opposite. however Strategy E (economics) & F (do nothing) seem to > { > have no impact on host behaviour either. > { > { > { The point that I'm trying to make here is that we want to avoid manual > { renumbering. This basically means that we have to automate > renumbering > { or obviates the need for it. > { > { Let me try to word-smith that: > { > { Further, variants of Strategy B (Section 3.3.2) that require manual > { locator assignment are similarly unacceptable, as are other solutions > { that require manual locator assignment, such as Strategy D (Section > { 3.3.4), Strategy E (Section 3.3.5), Strategy F (Section 3.3.6), and > { Strategy G (Section 3.3.7). > > [phil] my point was the strategy e & f don't seem to say anything about > manual locator assignment. Since neither of them develop a new RRG > protocol, they kind of self-exclude themselves from developing an RRG > protocol(?) Fair. I've removed both from that paragraph. I'll add another section on the scope of the charter and reference how those strategies aren't covered by our charter. Tony From tvest@pch.net Wed Apr 15 20:54:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576093A6A3E for ; Wed, 15 Apr 2009 20:54:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hsi7Lkqx+8I for ; Wed, 15 Apr 2009 20:54:28 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 292783A6811 for ; Wed, 15 Apr 2009 20:54:28 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA06.westchester.pa.mail.comcast.net with comcast id fuG71b00G0QuhwU563v2jy; Thu, 16 Apr 2009 03:55:02 +0000 Received: from [172.16.1.3] ([24.125.119.245]) by OMTA02.westchester.pa.mail.comcast.net with comcast id g3vg1b0055Hlxyo3N3vglx; Thu, 16 Apr 2009 03:55:41 +0000 From: Tom Vest To: Robin Whittle In-Reply-To: <49E69AB5.6060409@firstpr.com.au> References: <49E69AB5.6060409@firstpr.com.au> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 23:55:38 -0400 X-Mailer: Apple Mail (2.930.3) Cc: John Zwiebel , RRG Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:54:30 -0000 Hi Robin, FWIW I like what's here. However, if we subsequently find ourselves in a world where IPv6 remains undeployed, and (possession of) IPv4 continues to represent a critical bottleneck to nontrivial participation in the routing system, then most/all of the maxims below would seem to be largely or exclusively relevant to "incumbent" IPv4 holders. If I'm not off-base in this observation, it would have two troubling implications. First, it suggests that this particular vision of incremental deployability foregoes, if not excludes, one of the key drivers of technology change in other sectors -- i.e., the possibility of early adoption led by aspiring new entrants, in this case aspiring routing services providers. Second, while the recommendations should, if followed, increase the odds of the associated technology being widely deployed, it would still leave the fate of the technology in question to be determined absolutely by "incumbent" routing system participants. In this specific sense, a future technology that satisfies all of the requirements for "incremental deployability" might still end up getting effectively "vetoed," in the way that (some say) IPv6 has been vetoed. Before I even attempt to suggest what kind of extensions or modifications might serve to remedy this perceived "incumbent bias" I'd be very interested in hearing reactions from others... Thanks, Tom Vest On Apr 15, 2009, at 10:40 PM, Robin Whittle wrote: > Short version: I hope many people will agree with something like: > > > A successful solution to the routing and addressing > scaling problem is tightly constrained by the need > for it to be voluntarily adopted by the great > majority of end-user networks of all sizes who want > or need multihoming, inbound traffic engineering > and/or portability of their address space between > ISPs. > > Broadly speaking, this means that at the time of > introduction: > > 1 - The solution must provide immediate and > compelling benefits to the end-user networks > who adopt it, irrespective of how many other > networks have so far adopted it. > > 2 - Therefore, it must provide multihoming, TE and > portability for the adopting networks in a > manner which fully supports communications with > all hosts - including all hosts in non-upgraded > networks. > > 3 - Therefore, the solution must be compatible with > all hosts (stacks and applications) and routers > in non-upgraded networks. > > 4 - The solution must be compatible with all > existing applications in the adopting networks. > > 5 - Although in principle, some or many host stacks > could be upgraded in the adopting networks, the > difficulties this presents means that a scalable > routing solution will only be widely enough > adopted on a voluntary basis if no such upgrades > are required in order for the new system to > provide compelling benefits. > > Firstly, there are difficulties in motivating > operating system / stack programmers to add and > test new facilities. Secondly there may be > costs and disruption for the adopting network in > upgrading the stacks. Thirdly, in many or most > end-user networks, some or many hosts will not > be amenable to stack upgrades due to them using > operating systems which are no longer being > maintained or developed. This is especially > the case for devices such as printers, routers > etc. which do not use one of the major operating > systems. > > 6 - The solution must be compatible with all > existing DFZ routers. (Unless it can be shown > that all DFZ routers can be upgraded - such as > via a software update - by the time of > introduction.) [See note at end of message.] > > 7 - The solution must be attractive for the large > number of smaller networks who currently cannot > get PI space to do multihoming etc. Our goal is > not just to reduce the number of DFZ routes but > to enable a much larger number of end-user > networks to gain multihoming, TE and portability > than is currently possible. > > 8 - Ideally the solution will also be attractive for > most or all end-user networks who currently have > their own PI prefixes. This is firstly to > improve scaling by attracting those larger > end-user networks away from their current > conventional PI address space usage and secondly > to ensure that smaller networks which aspire to > be bigger in the future will perceive the new > kind of scalable end-user network address space > as suitable for their long-term needs. > > 9 - Ideally the new system should not compromise > security or performance compared to that of > current PI or PA techniques. Any degradation > in security, packet path lengths, end-to-end > packet transit times, packet loss rates and > general robustness etc. needs to be more than > compensated for by reduced costs and/or benefits > such as a more flexible and responsive > multihoming restoration capability than is > possible with current BGP techniques. > > 10 - The solution will not be widely enough adopted > if it requires upgrades to the internal routers > of adopting networks - except perhaps in very > small networks such as SOHO where one or a few > routers need upgrading anyway to perform ITR and > ETR etc. functions. > > In the longer term - in the years and decades to > come - upgrades to DFZ routers, to ISP and end-user > network internal routers and to host stacks can be > made without significant cost or inconvenience and > may allow enhanced performance for the new system. > > > I counted 4 people, including myself, supporting my statement about > the scalable routing problem in the "Re: Point of order" thread: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04786.html > > It is a problem whose solutions are tightly bound by the need for > compatibility with all existing hosts and most existing routers - > and by the need to ensure immediate benefits for early adopters, > since the solution will only work if it is voluntarily adopted by > most end-user networks which want multihoming, portability etc. > > Xiaoliang Zhao (4789), Dino Farinacci (4794) and John Zwiebel (4801). > > Joel, you are the only one so far to disagree: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04797.html > >> If "it" is a solution to the problems of routing scalability, >> reliability, robustness, etc that the rrg was chartered to work on, >> then I do not believe we ever agreed that compatibility with all >> existing hosts was a requirement. > > I wasn't suggesting we had all agreed to this, or that "rough > consensus" on this had been achieved. > > The sentence I wrote was a terse version of what I believe to be > true. I believe it would be a good idea to reach rough consensus on > something like this, such as the new text above. > > >> Deployability in such a way that existing hosts and existing >> routers can interwork with any solution, deployability such that >> there is value in incremental deployment, and migratability so that >> incremental deployment is possible are all things I would buy into. > > I agree with this, according to my understanding of "incremental > deployment" - but after much debate from 2007-11-07 to 2008-04-10 I > discovered that my understanding of this term could not be defined in > a few words, and was considerably more complex than the meaning > several other people ascribed to this term. > > You contributed to the debate on 2008-03-18: > > http://www.ietf.org/mail-archive/web/rrg/current/msg01775.html > >> One small aspect that I think I am seeing here is the same words >> ("incrementally deployable") being used to describe two different >> concepts. I may be confused, but it looks to me like: >> >> Deployable incrementally without disruption: This means that a >> portion of the net (host, site ISP, whatever) can deploy the system >> without losing capability or connectivity. A flag day is not >> necessary in order to get the system operational. >> >> Deployment incremental incentives: This sounds like what Robin is >> asking for, and is related to a bunch of work I have seen from >> folks like Dr. Odlyzko on the economic incentives that are needed >> to drive deployment. It includes analysis of issues like when do >> folks need positive return on new technologies to cause them to >> deploy. >> >> They are both valid concerns. But I think they are two different >> dimensions. > > I agree entirely. I realised that my use of the term "incrementally > deployable" involved all the conditions for people being motivated > to adopt it - in particular by the scalable routing solution > providing real benefits for the adopters even when very few other > networks have so far adopted it. I think this means the system must > provide multihoming, TE and portability of address space in a way > which works with all incoming packets, including those from > non-upgraded networks. > > Brian Dickson responded to your message: > > http://www.ietf.org/mail-archive/web/rrg/current/msg01881.html > > raising 15 separate points in 4 categories, including: > > We should be sure the benefits are truly compelling, ideally > universally so, and the costs so marginal as to be nearly > negligible, before settling on a recommendation. That may > mean more work for us, but it is a small price to pay. > > which I entirely support. > > You also wrote (2008-03-20): > > http://www.ietf.org/mail-archive/web/rrg/current/msg01848.html > >> I realize that there has to be a limit how far down the economic / >> business analysis we go. Among other things, we need to start by >> coming up with ideas, without regard to such limits. But when it >> comes to deployment analysis, ignoring the question of who pays, >> and why, is just not going to work. We don't need (don't want, and >> can't) to mandate a business model. I would hope that a sensible >> recommendation allows for multiple business models. But if we can >> not even imagine one that works, then it fails. > > which I also entirely support. > > On 2008-04-02 I came up with a detailed description of the deployment > requirements of a successful scalable routing solution: > > http://www.ietf.org/mail-archive/web/rrg/current/msg02030.html > > ====== > > "No significant barriers to widespread deployment due to > initially low uptake rate, or disruption of existing > practices" > > or: "The zero (or relatively low) critical mass criteria for > ubiquitous deployment on an incremental basis without > outside inducements" > > > (10) The technology must be able to be introduced without > disrupting existing practices. After some low > specified level of initial deployment, ideally zero, > everyone (or at least most people) who deploys the > technology receives benefits (maybe net benefits in > some short enough time-frame after accounting for > one-off purchase and installation costs) which are > not only positive, but substantial and likely to > attract many other end-users to the technology. > For this to be true, the benefits received must not > depend much or at all on what proportion of other > users have adopted the technology. Therefore, if the > technology would be fundamentally attractive to many, > most or all end-users once deployed by most or all > end-users, it would also be attractive enough to the > very first (or after some low, specified, level of > adoption) to actually become widely deployed via a purely > incremental means, without inducements or a major up-front > deployment before any end-users gain significant benefits. > > ====== > > That's a bit of a mouthful, but it is quite a task to fully describe > the constraints of upgrading the routing and addressing system of the > Internet when we are relying on purely voluntary adoption by end-user > networks and their ISPs. > > > The text at the start of this message is an attempt to rewrite the > sentence Xiaoliang Zhao, Dino Farinacci and John Zwiebel supported, > in the hope that you and many others will support it too. > > You wrote: > >> And I do not agree that getting clear terminology is irrelevant to >> getting to such a goal. I have frequently found it very confusing, >> and a hinderance to progress, to realize that the person I was >> talking with meant something different by the terms he was using >> than I meant by them. Yes, it happens. But that does not make it >> helpful. Getting a set of terms we can agree upon, and using them, >> can be very helpful. > > Yes, but I do not want to try to define exact semantics for > "incrementally deployable". I am wary of using the term at all, > without explicit definition, because it apparently means different > things to different folks, as indicated by the debate over a year ago: > > http://www.google.com/search?q=RRG+"incrementally+deployable"+site > %3Awww.ietf.org+-"rrg+Discussion+Archive" > > - Robin > > > Note regarding upgrading DFZ routers: > > If all DFZ routers (or every DFZ router between any ITR and > any ETR) can be replaced or upgraded with a firmware update > before the solution is deployed, then we could gain > considerable benefits. > > There may be other benefits of this, but I am thinking of > Modified Header Forwarding as an alternative to encapsulation > - which would eliminate encapsulation overheads and greatly > reduce ITR and ETR complexity, due to avoiding the Path MTU > Discovery problems which are inherent in encapsulation: > > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw > http://www.firstpr.com.au/ip/ivip/ivip6/ > > How soon must a solution be deployed? > > The IPv4 DFZ routing table http://bgp.potaroo.net currently has a > doubling time of about 5.3 years. I think it will be 5 years or > more before we really try to deploy a scalable routing system for > IPv4. > > IPv6 DFZ prefixes (click number for IPv6 prefix count at > http://bgp.potaroo.net/v6/v6rpt.html) currently number about > 855 which is 1/256 of the 219,603 for IPv4. The doubling > time is between 2.7 and 4 years. Even with a doubling time of > 2 years, it would take 16 years to reach the current IPv4 > numbers. > > So I think it will be perfectly feasible to have IPv6 DFZ > routers upgraded for Modified Header Forwarding in time > for a scalable routing solution. > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From rw@firstpr.com.au Wed Apr 15 21:47:33 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29773A6C7E for ; Wed, 15 Apr 2009 21:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUwjMcK1Z97h for ; Wed, 15 Apr 2009 21:47:32 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 278BD3A6BF2 for ; Wed, 15 Apr 2009 21:47:32 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 3BF8A175A9E; Thu, 16 Apr 2009 14:48:43 +1000 (EST) Message-ID: <49E6B8AC.30908@firstpr.com.au> Date: Thu, 16 Apr 2009 14:48:44 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> <49E6A3A0.1060202@joelhalpern.com> In-Reply-To: <49E6A3A0.1060202@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 04:47:33 -0000 Short version: Responding to Joel, with a change to the first paragraph. Hi Joel, You wrote: > This long list of "goals" has the interesting property that each of them > sounds reasonable, but each is phrased in such a way as to leave me > wondering if it is intended to imply cases or interpretations with which > I disagree. I am glad you think each point sounds reasonable. I am not trying to slip anything by you. Please let me know how you might disagree with possible interpretations of the various points. > To use your original text as an example, "compatibility with all hosts" > seems to imply that the solution can not start by modifying some of the > hosts. I know that you have argued that a solution based on host > modification is untenable, and this is a topic on which we have disagreed. The new text is not so absolute. All 10 points are "Broadly speaking . . ." which I intend to meaning something like "These are good general principles - and that any deviation from them would require a convincing argument". Please give an example of how a scalable routing solution could be widely adopted (or adopted at all by end-user networks in general, in the early stages) if it required some form of host changes in order for it to deliver compelling benefits for the adopting networks. For instance: 1 - Changes to host stacks or applications in other networks. (A non-starter, I think we all agree.) 2 - Changes to all applications in the adopting network. (Likewise, a non-starter, I am sure.) 3 - Changes to the some or all applications in the adopting network. 4 - Changes to stacks in some or all hosts in the adopting network. Please give examples of why such changes might be an essential element of any scalable routing solution which would be generally superior to alternative solutions which require no such changes. Please also give some examples of how particular types of end-user network might be motivated to make such changes. I am not opposed to host changes on an optional basis. For instance, Ivip has optional ITR functions in sending hosts - not behind NAT, but on ordinary ("RLOC") or Ivip-mapped micronet ("EID") addresses. My concern is about a scalable routing solution requiring host changes in some or all hosts in order for it to deliver the compelling benefits needed for widespread voluntary adoption. > I absolutely agree that deployment has to have value for the deployer, > in a reasonable and practical deployment scenario. And the deployer > must not lose the ability to talk to the rest of the world in exchagne > for that value. I think we all agree on this. > Most of the implications I see do not quite match up with the way > you chose to phrase things below. > An example in the first paragraph below is that the question of what the > deployment path is, and when the bulk of users see value, and what value > they see, varies depending upon the solution. Nothing will be > "voluntarily adopted by the great majority of ..." early in its > introduction. The path to widespread adoption is tricky for any > technology. OK - here is a version which hopefully overcomes this problem - the addition of "over a period of years". A successful solution to the routing and addressing scaling problem is tightly constrained by the need for it to be voluntarily adopted, over a period of years, by the great majority of end-user networks of all sizes who want or need multihoming, inbound traffic engineering and/or portability of their address space between ISPs. Please point out any other problems with implications you foresee and suggest any other things which could be improved. BTW, I used an invalid address Brian Dickson. I think it should be: Brian Dickson - Robin From rw@firstpr.com.au Wed Apr 15 22:21:38 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C129A3A6ABF for ; Wed, 15 Apr 2009 22:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLuDE1P+fOh1 for ; Wed, 15 Apr 2009 22:21:37 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C4DB63A68A3 for ; Wed, 15 Apr 2009 22:21:36 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 71D7E175D4C; Thu, 16 Apr 2009 15:22:48 +1000 (EST) Message-ID: <49E6C0A9.5000606@firstpr.com.au> Date: Thu, 16 Apr 2009 15:22:49 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Zwiebel Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 05:21:38 -0000 Short version: Responding to Tom Vest's concern about how the constraints on widespread adoption of a scalable routing solution seem to preclude widespread adoption of IPv6. Hi Tom, Regarding my suggested text: http://www.ietf.org/mail-archive/web/rrg/current/msg04815.html you wrote: > FWIW I like what's here. However, if we subsequently find ourselves in a > world where IPv6 remains undeployed, and (possession of) IPv4 continues > to represent a critical bottleneck to nontrivial participation in the > routing system, then most/all of the maxims below would seem to be > largely or exclusively relevant to "incumbent" IPv4 holders. I tried to describe the constraints as I saw them. The pressure to retain existing applications and stacks is extremely strong - surely too strong in the foreseeable future to allow widespread voluntary adoption of a solution which required extensive stack or application changes. I didn't refer to the possibility of adopting a completely new kind of new address space (IPv6 instead of IPv4) and the required new ISP connectivity to support it, as would be the case if the solution involved IPv6 or some other alternative to IPv4. That would be precluded by the points: 2 & 3 - Hosts with the IPv6 address only get multihoming etc. with communication with other IPv6 hosts. Because the solution presumably only provides benefits for IPv6 communications, it fails to meet this constraint that it "fully supports communications with all hosts - including all hosts in non-upgraded networks." since, during adoption, most hosts in non-upgraded networks are IPv4 hosts. 4 & 5 Most end-user networks which want multihoming do not, at present, have all their hosts and applications fully ready for IPv6. However, perhaps something needs to be added to the text to address your concern about how the scope of text seems to be within the current IPv4 situation, rather than looking beyond it. > If I'm not > off-base in this observation, it would have two troubling implications. > First, it suggests that this particular vision of incremental > deployability foregoes, if not excludes, one of the key drivers of > technology change in other sectors -- i.e., the possibility of early > adoption led by aspiring new entrants, in this case aspiring routing > services providers. I understand you are referring to IPv6 being promoted by existing or new ISPs who have a vision for IPv6 and promote its adoption. IPv6 adoption remains glacial: http://bgp.potaroo.net/v6/v6rpt.html BGP advertised Autonomous prefixes Systems IPv4 219603 25296 IPv6 855 741 I can't imagine the majority of current Internet users adopting it any time soon. Perhaps in the future it will be adopted for fixed networks in countries where IPv4 space is in too-short supply. However, I think that any such service would need IPv4 connectivity to be useful - so IPv6 addresses for the hosts is not the whole story - the hosts still need to tunnel to some IPv4 proxy server or whatever, so they can function on the IPv4 Internet. The most likely scenario I can imagine for large-scale adoption of IPv6 is in mobile networks - 3G cellphone networks and whatever they develop into. AFAIK, this has not occurred to any substantial degree yet. I agree that the constraints as I wrote them seem to preclude widespread adoption of IPv6, except perhaps in some future mobile networks where direct connectivity to IPv4 hosts is for some reason not required. I think the text reflects the reality, however unfortunate the reality is for the migration to IPv6. > Second, while the recommendations should, if > followed, increase the odds of the associated technology being widely > deployed, it would still leave the fate of the technology in question to > be determined absolutely by "incumbent" routing system participants. Since we (the RRG, the IETF etc.) have no coercive powers, I agree that the fate of a particular network is absolutely determined by those who are running and using the network. I see our task as requiring the development of a new form of address space, with all the supporting protocols and software for routers and other network elements, which will solve the scaling problem if widely deployed. Then we need to make that system so attractive that it will be widely adopted by most end-user networks which want multihoming etc. - even though they may neither know or care about the scalability problem, bloated DFZ route numbers etc. We need to show it works, that people can make money using it and generally promote it. However, only if it works really well will it be widely enough adopted to solve the routing scalability problem. > In > this specific sense, a future technology that satisfies all of the > requirements for "incremental deployability" might still end up getting > effectively "vetoed," in the way that (some say) IPv6 has been vetoed. I am trying not to ascribe any particular meaning to "incremental deployability". I don't agree that IPv6 has been "vetoed". It has been available for 10 years or more an almost no-one really wants it, for the simple reasons that it doesn't provide connectivity to the great majority of hosts and that for most people, it provides no benefit over IPv4. > Before I even attempt to suggest what kind of extensions or > modifications might serve to remedy this perceived "incumbent bias" I'd > be very interested in hearing reactions from others... I think the term "incumbent bias" implies an unreasonable resistance to change. I don't think it is unreasonable that the great majority of Internet users want and need a continuing service which enables them to communicate with every other Internet host used by other similar people. The IPv4 Internet is by far the biggest and most significant IT system which has ever existed. In a free country, there would be no demand for a service which failed to connect to even 1 or 2% of hosts. An IPv6-only service fails to connect to nearly 100% of hosts. This is no fault of IPv6 - its just that no-one has figured out how to remain IPv4 compatible while upgrading to another network. It could be done, in principle - but only by radically rewriting all applications to use a new stack. Even then, it would be a complex and error-prone business trying to retain functionality running on one or the other network exclusively, or using them both at the same time. Here is a potential addition to the text, but I think this is taking the scope of the piece beyond the constraints to adoption, and into some additional goals we might have regarding the long-term development of the Net: The above text attempts to summarise the real-world constraints on a scalable routing solution. It appears that these constraints create a very high barrier to migration of significant numbers of existing end-user networks from IPv4 to an IPv6 service, either with or without retaining their IPv4 address space. It follows that even if IPv6 had a scalable routing solution, that the barriers to mass adoption of it would remain so high as to preclude a mass migration from IPv4. Our goal is to solve the routing scaling problem in both the IPv4 and IPv6 Internets - and for the foreseeable future, the problem only manifests in the IPv4 Internet. Perhaps an additional goal of a scalable routing solution would be - by some methods yet to be determined - to facilitate adoption of an alternative to IPv4 such as IPv6 which is a more promising basis for accommodating very large numbers of individual hosts, many of which are expected to be mobile devices. Maybe something like this could be a footnote. - Robin From lars.eggert@nokia.com Thu Apr 16 00:47:48 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1953A6B4B for ; Thu, 16 Apr 2009 00:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1+sd1hh7W8L for ; Thu, 16 Apr 2009 00:47:47 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 60EA73A67C0 for ; Thu, 16 Apr 2009 00:47:46 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3G7mTOt060497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Apr 2009 10:48:55 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: rrg@irtf.org Content-Type: multipart/signed; boundary=Apple-Mail-12--432069716; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 10:48:55 +0300 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Thu, 16 Apr 2009 10:48:55 +0300 (EEST) Subject: [rrg] CFP: ACM ReArch'09 (co-located with ACM CoNEXT) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ReArch'09 TPC Co-Chairs List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 07:47:48 -0000 --Apple-Mail-12--432069716 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit ACM ReArch'09 - Re-Architecting the Internet Co-located with ACM CoNEXT 2009 Rome, Italy, December 1, 2009 http://conferences.sigcomm.org/co-next/2009/workshops/rearch Submission Deadline: August 6, 2009 Submit at: http://edas.info/newPaper.php?c=7673 Motivation The Internet architecture has been remarkably successful in allowing a planet-scale internetwork to form. However, this architecture is losing its original simplicity and transparency as new classes of applications, business models, security mechanisms, scalability enablers and operational and management requirements give rise to point solutions that extend the architecture without regards to its original design principles. Although these developments are necessary in the short term to allow the Internet to continue to operate under the present economical, technical and social conditions, in combination, they have significantly reduced the potential for longer-term evolution of the Internet architecture. This loss of flexibility is already being felt as the number of Internet nodes grows by another order of magnitude. Several substantial Future Internet initiatives are underway in Europe, the Americas and Asia, and the vendor and network operator communities are also actively discussing the limitations of the current Internet architecture as well as its potential evolution. The first solution proposals in this space have already started to be analyzed. ReArch'09 - the second instance of this workshop since its very successful debut at CONeXT 2008 - will discuss the underlying problems of the Internet architecture and protocols and debate how we might fix them in a way that regains us the original architectural simplicity and clarity of the Internet for another 30+ years. This workshop solicits original, high-quality papers that analyze and discuss ideas for a new Internet architecture, including specific improvements to current Internet protocols, especially at the internetworking, transport and application layers, new internetworking components that integrate into the existing architecture and ideas for clean-slate internetworking architectures. Topics ReArch'09 covers all aspects related to the current and future Internet architecture including, but not limited to, the following impact: * New networking paradigms * New business models * New routing architectures * New traffic engineering and congestion control mechanisms * Measurements and analyses that characterize and quantify architectural limitations * New architecture proposals and their implications for research and operations * New protocols to address specific architectural limitations * Studies of interactions between stakeholders of the Internet and the architecture itself * Design principles and interfaces to accommodate the conflicting interests of stakeholders in the architecture * Principles of evolving future architectures * Discussions on interworking with the existing Internet and deployability Papers that present interesting, fresh ideas at an early stage are more suitable for this workshop than highly polished results or incremental refinements of previous work. Submissions may include position papers that point out new directions and attempt to stimulate discussion; position papers should be clearly marked as such. Submission must be original and not already be published or submitted for publication elsewhere. The proceedings of the workshop will be published in the ACM Digital Library. Submissions Submitted papers must be at most six (6) pages long, including all figures, tables, references, appendices, etc. They must be formatted according to the standard ACM double column format *except* that *all* text must use a font size of 10 points or larger. Longer submissions will not be reviewed. The review process is single-blind. Submit papers via EDAS at http://edas.info/newPaper.php?c=7673 Submission Deadline: August 6, 2009 Notification Deadline: September 10, 2009 Camera Ready Deadline: October 1, 2009 ReArch'09: December 1, 2009 Committees Workshop Co-Chairs Lars Eggert, Nokia Research Center & TKK, Finland Tilman Wolf, University of Massachusetts, USA Technical Program Committee Bengt Ahlgren, SICS, Sweden Mark Allman, ICSI, USA Bob Briscoe, BT Group, United Kingdom Brian Carpenter, University of Auckland, New Zealand Jon Crowcroft, University of Cambridge, United Kingdom Kevin Fall, Intel Research, USA Pierre Francois, UC Louvain, Belgium James Griffioen, University of Kentucky, USA Robert Hancock, Roke Manor Research, United Kingdom Mark Handley, University College London, United Kingdom Hiroaki Harai, NICT, Japan Daniel Massey, Colorado State University, USA Martin May, Thomson Research, France Akihiro Nakao, Univeristy of Tokyo, Japan Pekka Nikander, Ericsson Research Nomadiclab, Finland Craig Partridge, BBN Technologies, USA George Rouskas, North Carolina State University, USA Peter Steenkiste, Carnegie Mellon University, USA Christian Vogt, Ericsson Research, USA Klaus Wehrle, RWTH Aachen, Germany Rolf Winter, NEC Network Labs, Germany Martina Zitterbart, University of Karlsruhe, Germany Steering Committee Marcelo Bagnulo, University Carlos III of Madrid, Spain Olivier Bonaventure, UC Louvain, Belgium Kenjiro Cho, IIJ, Japan Joe Touch, USC/ISI, USA --Apple-Mail-12--432069716 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA0MTYwNzQ4NTVaMCMGCSqGSIb3DQEJBDEWBBRL/SKnMdMFfvNp uxhjosWvjjfvbjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAXK5TkeAJ3Cs7pEJ+8BP0CaoOCQSdtL/O2qHXtixmec3US19f0g5g PczM3h8+TGBXSWdi/1jLbkWW0hegQvXnGx96AZuYPJZ/DWnEJPUbbmPltmPcS/Rd3D9daZZ99NMW 1xbGSIcluRNtR3Eg5C7WkSWewTctg8nFpbOWPaMCI64Z8WiRyEW/lQcYsg25YBHSUj2kMPawvOTu Mp2Ak7fEoOmi3Bg2xSGZUCYl5YjfVkG59Q1ssdK+m57ZbACxeNo9yU4fpj3hai9vufHuc1XruZQ1 fXEkhPfJ9ZJajKVKVyxYDTyQ8hWrUa4zfoIaoOf/88bEet037GAJs4iGFqy47gAAAAAAAA== --Apple-Mail-12--432069716-- From irtf@tonistoev.info Thu Apr 16 04:41:28 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13EE3A6885 for ; Thu, 16 Apr 2009 04:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMltAb4jvrf6 for ; Thu, 16 Apr 2009 04:41:28 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 18B8D3A6823 for ; Thu, 16 Apr 2009 04:41:27 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LuPzH-0003L0-UU for rrg@irtf.org; Thu, 16 Apr 2009 14:42:36 +0300 From: Toni Stoev Date: Thu, 16 Apr 2009 14:42:35 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline To: IRTF RRG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200904161442.35179.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Introduction X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 11:41:29 -0000 Hello, everyone. I have definite ideas on here relevant topics. I am in favor of role-based architecture. I see node identification subject as most needing and likely to yield a resolution. So, I am going to flow into that stream of discussion. Toni From wherrin@gmail.com Thu Apr 16 04:52:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBF83A684A for ; Thu, 16 Apr 2009 04:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJzFTLyreJ9T for ; Thu, 16 Apr 2009 04:52:11 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id A68023A67AE for ; Thu, 16 Apr 2009 04:52:11 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 3so260296yxj.37 for ; Thu, 16 Apr 2009 04:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fmX8ug5Yu+Kr5kX2uHTtPXA8l22HOHUg5ZhyrtXj/tk=; b=IeSv030gXkPGgLIsfpQOGd3qYG1UB0uwXfjwrFQpoV4BJeBYn4xdq1KpJoZh/7qgmP +rQn+66bjfh2IUsZBXX4cYiHcg8zr9YXl+kWx+gtPFdjywy8m0LXAX61Go9uUpjXbNpY wv2EtSAVS8ZQRBQVYnBZf1iCQZsyx57OvB/Jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DX/JtEwnlo0DPgbCw+pfob0RjX95TaaoKCT77DV0S5lG8hd5Pvu5OuFsb3V/3Nee21 spsSx4D2rxGdVS0ED75WD1F6hyZSQFo/1oBICFgWcSBVz6sF0TZTXSOqwMExR/j9y6fL SGSgm7nWFvaHtIjPtEpZPwVJ8HpTnJlnoCgfQ= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.241.13 with SMTP id o13mr1944527anh.3.1239882804331; Thu, 16 Apr 2009 04:53:24 -0700 (PDT) In-Reply-To: <49E64D15.6030903@tony.li> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> Date: Thu, 16 Apr 2009 07:53:24 -0400 X-Google-Sender-Auth: 1632241ca81e7bd5 Message-ID: <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 11:52:12 -0000 On Wed, Apr 15, 2009 at 5:09 PM, Tony Li wrote: > There are currently 463 members of the RRG, based on the > mailing list membership > If only two people responded, I'd conclude that the rest didn't > care and thus it was acceptable. =A0Yes, that counts as rough consensus. Yikes! Tony, here's what our old friend Webster has to say about consensus: consensus n. 1 an opinion held by all or most 2 general agreement, esp. in opinion The notion that because the other 461 subscribers of the list were not offended enough to respond constitutes consensus in favor defies the plain English meaning of the word consensus. Last year, I and most of the rest of the group ignored your declaration of consensus on "fix it for IPv6 first" and continued focusing solely on approaches which work for IPv4. I hope you find a better way to evaluate consensus but as it stands I'll ignore this one too. For the record, if you were paying attention, the closest to the actual consensus was roughly: On Wed, Apr 15, 2009 at 12:18 PM, Dow Street wrot= e: > I do not think agreeing to, or perhaps > divining, the "pure" definition for "locator" moves us very far along the > path toward a solution. At the start of this discussion I did, but I don'= t > now +1. Regards, Bill --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From irtf@tonistoev.info Thu Apr 16 05:49:26 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607773A67AF for ; Thu, 16 Apr 2009 05:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nA1v+hecgUF for ; Thu, 16 Apr 2009 05:49:25 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 94E5D3A6359 for ; Thu, 16 Apr 2009 05:49:25 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LuR35-0001pB-0O for rrg@irtf.org; Thu, 16 Apr 2009 15:50:35 +0300 From: Toni Stoev Date: Thu, 16 Apr 2009 15:50:34 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline To: IRTF RRG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200904161550.34274.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 12:49:26 -0000 First My opinion is that node identification has to be network centric, that is, to be constituted on network assets. Motivation for this is that the network has the necessary and sufficient resources to form and handle an identifier. Toni From rja@extremenetworks.com Thu Apr 16 06:18:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4399728C0F3 for ; Thu, 16 Apr 2009 06:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFRFCXBkNVkW for ; Thu, 16 Apr 2009 06:18:03 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id 8271B28C0F0 for ; Thu, 16 Apr 2009 06:18:03 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI700EJ93NH4G44@vms173019.mailsrvcs.net> for rrg@irtf.org; Thu, 16 Apr 2009 08:18:58 -0500 (CDT) Message-id: <2093B316-49E4-4A0D-A21E-3882C966F862@extremenetworks.com> From: RJ Atkinson To: "rrg@irtf.org RG" In-reply-to: <54AF9A3E-CCA5-4EBD-86F7-C2B6F7CFF71B@cisco.com> Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 09:18:53 -0400 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> <49E66888.7080100@gmail.com> <54AF9A3E-CCA5-4EBD-86F7-C2B6F7CFF71B@cisco.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 13:18:04 -0000 On 15 Apr 2009, at 19:13, Dino Farinacci wrote: >> That's unclear to me. One of the arguments for dropping the layer 3 >> checksum in IPv6 is that modern layer 2 solutions come with error >> detection. Making the layer 4 checksum compulsory strengthened >> that argument, of course. But I don't remember discussion of >> why the pseudo-header checksum is essential. In fact, when the IPNG >> WG >> was chartered in 11/94, the charter said: >> >> TCP/UDP: The IPng Working Group will specify the procedures for >> hosts to >> compute and verify TCP/UDP pseudo-headers. Any other changes to TCP >> beyond making TCP work with IPng are out of scope of the working >> group >> and should be dealt with by a TCPng Working Group. >> >> So it was taken for granted that we needed it. > > I recall the IPng directorate wanted to make the fewest changes to the > transport layers. The only changes that were required was to lengthen > the address and that is what turned out. > > The same reason why the low-order 64-bits were not used as a socket-id > for TCP for tcb lookups. All of the above is consistent with my recollections. More is the pity, since decoupling the IPv6 addresses from the upper-layer pseudo-header calculations would have done IPv6 users a tremendous amount of good. Mea culpa. AH for IPv6 should not have included the IPv6 Routing Prefixes either (although including the IPv6 IID would have been sensible). Ran From jmh@joelhalpern.com Thu Apr 16 08:13:39 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF523A6DA9 for ; Thu, 16 Apr 2009 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ31R5rGe9yB for ; Thu, 16 Apr 2009 08:13:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 86AE23A6CCD for ; Thu, 16 Apr 2009 08:13:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A7727430196; Thu, 16 Apr 2009 08:14:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-88.clppva.btas.verizon.net [71.161.52.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 11E0D430137; Thu, 16 Apr 2009 08:14:50 -0700 (PDT) Message-ID: <49E74B62.3020700@joelhalpern.com> Date: Thu, 16 Apr 2009 11:14:42 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> In-Reply-To: <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:13:39 -0000 Speaking only for myself, while I like solutions that help v4, I do not see a problem with solving the architectural problem only, or first, for v6. To a significant degree the architectural problems for v4 are self-limiting. And v6 is still in sufficient flux that changes are far more practical. Yours, Joel William Herrin wrote: ... > Last year, I and most of the rest of the group ignored your > declaration of consensus on "fix it for IPv6 first" and continued > focusing solely on approaches which work for IPv4. I hope you find a > better way to evaluate consensus but as it stands I'll ignore this one > too. ... From dino@cisco.com Thu Apr 16 08:41:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8B83A6F8A for ; Thu, 16 Apr 2009 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE-+EoUbrEwE for ; Thu, 16 Apr 2009 08:41:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AA0A63A6F7A for ; Thu, 16 Apr 2009 08:40:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208";a="287432465" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Apr 2009 15:42:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3GFg6S1013575; Thu, 16 Apr 2009 08:42:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3GFg637027012; Thu, 16 Apr 2009 15:42:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:42:06 -0700 Received: from [192.168.1.3] ([10.21.93.249]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:42:06 -0700 Message-Id: <17327A2B-DAEC-484F-AB61-A8A27DF72FA1@cisco.com> From: Dino Farinacci To: RJ Atkinson In-Reply-To: <2093B316-49E4-4A0D-A21E-3882C966F862@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 16 Apr 2009 08:42:05 -0700 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> <49E66888.7080100@gmail.com> <54AF9A3E-CCA5-4EBD-86F7-C2B6F7CFF71B@cisco.com> <2093B316-49E4-4A0D-A21E-3882C966F862@extremenetworks.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 16 Apr 2009 15:42:06.0134 (UTC) FILETIME=[E53A8D60:01C9BEA9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=446; t=1239896526; x=1240760526; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Eliot's=20note |Sender:=20; bh=UEXNYT4LWSxjpimOazCPdrYKNsAFMZJTVRcDd+hWRrk=; b=GbTEpdJpUwUjS/adiwNVbemXQNgnVVDTq5K8evmDxlFz7xquY9HEB+PNB7 gvmqiXOSea6RGwz3uvMTcYR+MWdUfASuVWdnIS6azVW2YgLMcA1mV8/5Uhuz cPImB0R9RDIkOJIpwQwTxo6+ul835gb5VT5EDS0ZZ2o/aX6ByP2Go=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "rrg@irtf.org RG" Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:41:12 -0000 > Mea culpa. AH for IPv6 should not have included the IPv6 > Routing Prefixes either (although including the IPv6 IID > would have been sensible). No one listened to Noel and O'Dell. Well.... I should say some people listened and others ... Dino P.S. This thread is actually productive. Because if the same sort of basics are ignored just a new generation of people will make similar mistakes. You know how the saying goes. From rja@extremenetworks.com Thu Apr 16 09:11:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8883A6C55 for ; Thu, 16 Apr 2009 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id untTw2Kj8mua for ; Thu, 16 Apr 2009 09:11:33 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 2AA5F3A67EC for ; Thu, 16 Apr 2009 09:11:33 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI700GYCBOY0LC4@vms173005.mailsrvcs.net> for rrg@irtf.org; Thu, 16 Apr 2009 11:12:39 -0500 (CDT) Message-id: From: RJ Atkinson To: "rrg@irtf.org RG" In-reply-to: <17327A2B-DAEC-484F-AB61-A8A27DF72FA1@cisco.com> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 12:12:34 -0400 References: <96FCF8B6-0A2E-47DE-A549-2D52958A2B91@extremenetworks.com> <1B5E552F-4C33-4F41-A825-53BAE63B1028@cisco.com> <4835AFD53A246A40A3B8DA85D658C4BE7B0FA9@EVS-EC1-NODE4.surrey.ac.uk> <49E66888.7080100@gmail.com> <54AF9A3E-CCA5-4EBD-86F7-C2B6F7CFF71B@cisco.com> <2093B316-49E4-4A0D-A21E-3882C966F862@extremenetworks.com> <17327A2B-DAEC-484F-AB61-A8A27DF72FA1@cisco.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [rrg] Eliot's note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:11:34 -0000 On 16 Apr 2009, at 11:42, Dino Farinacci wrote: > No one listened to Noel and O'Dell. Well.... > I should say some people listened and others ... For the record, I supported both Noel and Mike O'Dell -- and their ideas -- long long ago. > Dino > > P.S. This thread is actually productive. Because if the same sort of > basics are ignored just a new generation of people will make similar > mistakes. You know how the saying goes. Those who do not learn history are doomed to repeat it. Cheers, Ran From tvest@pch.net Thu Apr 16 09:36:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469F43A6C1B for ; Thu, 16 Apr 2009 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOkW3ybI-wT5 for ; Thu, 16 Apr 2009 09:36:45 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id AB8DF3A69E6 for ; Thu, 16 Apr 2009 09:36:44 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA10.westchester.pa.mail.comcast.net with comcast id gCLz1b0050SCNGk5AGdytR; Thu, 16 Apr 2009 16:37:58 +0000 Received: from [172.16.1.3] ([24.125.119.245]) by OMTA09.westchester.pa.mail.comcast.net with comcast id gGdw1b0075Hlxyo3VGdwgF; Thu, 16 Apr 2009 16:37:57 +0000 From: Tom Vest To: Robin Whittle In-Reply-To: <49E6C0A9.5000606@firstpr.com.au> References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> Message-Id: <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 12:37:53 -0400 X-Mailer: Apple Mail (2.930.3) Cc: John Zwiebel , RRG Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:36:47 -0000 Hi Robin, Thanks very much for the detailed response. Further thoughts inline. On Apr 16, 2009, at 1:22 AM, Robin Whittle wrote: > Short version: Responding to Tom Vest's concern about how the > constraints on widespread adoption of a scalable > routing solution seem to preclude widespread > adoption of IPv6. > > Hi Tom, > > Regarding my suggested text: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04815.html > > you wrote: > >> FWIW I like what's here. However, if we subsequently find ourselves >> in a >> world where IPv6 remains undeployed, and (possession of) IPv4 >> continues >> to represent a critical bottleneck to nontrivial participation in the >> routing system, then most/all of the maxims below would seem to be >> largely or exclusively relevant to "incumbent" IPv4 holders. > > I tried to describe the constraints as I saw them. The pressure to > retain existing applications and stacks is extremely strong - surely > too strong in the foreseeable future to allow widespread voluntary > adoption of a solution which required extensive stack or application > changes. > > I didn't refer to the possibility of adopting a completely new kind > of new address space (IPv6 instead of IPv4) and the required new ISP > connectivity to support it, as would be the case if the solution > involved IPv6 or some other alternative to IPv4. > > That would be precluded by the points: > > 2 & 3 - Hosts with the IPv6 address only get multihoming etc. with > communication with other IPv6 hosts. Because the solution > presumably only provides benefits for IPv6 communications, > it fails to meet this constraint that it "fully supports > communications with all hosts - including all hosts in > non-upgraded networks." since, during adoption, most > hosts in non-upgraded networks are IPv4 hosts. > > 4 & 5 Most end-user networks which want multihoming do not, at > present, have all their hosts and applications fully ready > for IPv6. If I'm interpreting correctly, it seems that you agree with my original surmise, i.e., that the idea of "incremental deployability" as originally specified is completely consistent with an absolute prerequisite of (what is likely by the earliest feasible moment of applicability to be) "ownership" of IPv4 addresses. This may be less problematic, I suppose, if the intent is to scope the proposed recommendations as "institutional-level incremental deployability for current ( aka 'incumbent') routing system participants" -- and that scope is made explicit in the text. However, I originally interpreted the text more broadly, c.f., as guidelines intended to facilitate "deployability" more generally, toward the presumptive, pragmatic goal of real-world deployment. It seems to me that the only domain of conceivable relevance to "deployability" as defined by RRG is a built environment that is, as a practical matter, composed wholly of deployed routing protocols that derive (and/or are deprived of) much if not all of their value by virtue of the presence/absence of extra-institutional "network effects." An additional, perhaps contingent but nevertheless inescapable feature of the real-world deployability environment is the absolute need for one specific kind of quantity constrained protocol number resource (unique IPv4), the availability of which will shortly become (at the very least) highly uncertain for anyone who does not already have it. To my mind at least, this particular combination of environmental factors -- i.e., the centrality of specific, established network effects plus the de facto inaccessibility of those effects to any aspiring routing system participant that does not possess a specific, scarce, and potentially unobtainable legacy protocol-defined input -- imposes some hard constraints on any set of RRG "incremental deployability" recommendations. The network effects factor effectively makes the utility of any purely institution-level specification of "incremental deployability" highly dubious -- or alternately wholly contingent on the accommodation of those network effects at the individual institution (i.e., routing system participant) level. However, recognition of the real-world correlates of those network effects entails coming to terms with the inescapable quantitative/ demographic constraints that are inherent in IPv4. My own short version: explicitly acknowledge possession IPv4 as an absolute prerequisite, and institutional-level deployability as the intended scope of the proposed incrementalism recommendations. Alternately, modify as necessary to explicitly accommodate incremental deployment paths that are not contingent on possession of IPv4. > However, perhaps something needs to be added to the text to address > your concern about how the scope of text seems to be within the > current IPv4 situation, rather than looking beyond it. That is indeed my principled concern, based on the last couple of years of work and research. More (just a little) on that below... >> If I'm not >> off-base in this observation, it would have two troubling >> implications. >> First, it suggests that this particular vision of incremental >> deployability foregoes, if not excludes, one of the key drivers of >> technology change in other sectors -- i.e., the possibility of early >> adoption led by aspiring new entrants, in this case aspiring routing >> services providers. > > I understand you are referring to IPv6 being promoted by existing or > new ISPs who have a vision for IPv6 and promote its adoption. > > IPv6 adoption remains glacial: > > http://bgp.potaroo.net/v6/v6rpt.html > > BGP advertised Autonomous > prefixes Systems > > IPv4 219603 25296 > IPv6 855 741 > > I can't imagine the majority of current Internet users adopting it > any time soon. Actually we are in full agreement on this point. My intuitions are (1) that IPv6 will not be adopted by enough parties to become viable as a stand-alone extension to IPv4 for any entity that does not *also* possess IPv4, or exclusive beneficial use rights thereto. By implication, any set of prescriptions that defines "incremental deployability" without some consideration of the absolute finitude, and likely increasing non-availability of unique IPv4 address resources, will embed and thereby (potentially) perpetuate the requirement for IPv4. (2) that the present effort to scope "incremental deployability" is at least partially motivated by the desire to reduce the odds that future RRG efforts will encounter deployability impediments similar in form and/or impact to those that have been revealed by the IPv6 experience. The speculations below about how IPv6 might or might be deployed in the future are interesting, and might merit further discussion off- list, but are not relevant to the concerns I've expressed here. > Perhaps in the future it will be adopted for fixed networks in > countries where IPv4 space is in too-short supply. However, I think > that any such service would need IPv4 connectivity to be useful - so > IPv6 addresses for the hosts is not the whole story - the hosts still > need to tunnel to some IPv4 proxy server or whatever, so they can > function on the IPv4 Internet. > > The most likely scenario I can imagine for large-scale adoption of > IPv6 is in mobile networks - 3G cellphone networks and whatever they > develop into. AFAIK, this has not occurred to any substantial degree > yet. > > I agree that the constraints as I wrote them seem to preclude > widespread adoption of IPv6, except perhaps in some future mobile > networks where direct connectivity to IPv4 hosts is for some reason > not required. I think the text reflects the reality, however > unfortunate the reality is for the migration to IPv6. > > >> Second, while the recommendations should, if >> followed, increase the odds of the associated technology being widely >> deployed, it would still leave the fate of the technology in >> question to >> be determined absolutely by "incumbent" routing system participants. > > Since we (the RRG, the IETF etc.) have no coercive powers, I agree > that the fate of a particular network is absolutely determined by > those who are running and using the network. While I think I understand your point here, it seems to me that this particular phrasing is orthogonal to any relationship between RRG and incremental deployability. Granted, the IETF has no coercive powers. Of course, the fate of anything/everything outside of the scope of candidate future routing protocols is beyond RRG's ambit. These undeniable facts would clearly support an assertion like: "...the fate of a particular *network protocol* is absolutely determined by those who are using, or who would be able and willing to use that particular protocol." However, extrapolating beyond that to the fate of "a particular network" would only make sense if that "particular network" is *not* the environment that imposes deployability criteria (i.e., not the Internet as it exists concurrently), or else if one as prepared to concede the above points (i.e., possession of IPv4 is assumed, and should be understood as an absolute prerequisite for anyone who hopes to use this "incremental deployability" formula to actually deploy something). > I see our task as requiring the development of a new form of address > space, with all the supporting protocols and software for routers and > other network elements, which will solve the scaling problem if > widely deployed. Then we need to make that system so attractive that > it will be widely adopted by most end-user networks which want > multihoming etc. - even though they may neither know or care about > the scalability problem, bloated DFZ route numbers etc. We need to > show it works, that people can make money using it and generally > promote it. However, only if it works really well will it be widely > enough adopted to solve the routing scalability problem. I agree, but I think these claims only reinforce my point. Given our structural dependence on decentralized, privately incentivized action as the only vehicle for protocol deployment, your "so attractive" benchmark can only be understood in relative/comparative terms. Thus, regardless of the specific virtues of the hypothetical future network protocol candidate, the actual attractiveness hurdle for existing routing system participants will be defined by the private, individual operator-level benefits that the candidate protocol provides *over and above* the alternatives, including other candidate solutions that offer higher short-term private benefits (profits) and/or lower short- term direct costs -- as well as the ever-present option of just sticking with the status quo. By contrast, the attractiveness hurdle for aspiring ("non-incumbent") routing system participants will be all of the above *plus* the cost of acquiring IPv4. In the near future, that could well imply that deployment of any kind, incremental or otherwise, will only be possible for entities that have achieved a favorable outcome in negotiations to purchase scarce, non-substitutable IPv4 space from a competitor -- i.e., from a routing services provider that knows that the sale will, by definition, enable the buyer to enter the routing services market and thus become a potential direct competitor. The history of competition in industries in which "bottleneck" (essential + non-substitutable) inputs play a central role suggests that that hurdle could be very, very high. I don't think that RRG is responsible for the fact that IPv4 will soon impose these and other bottleneck effects on incremental deployability, or on the Internet more generally. However, I have reason to believe that it may be extremely difficult (i.e., approaching impossible) to define *any* routing protocol that might satisfy that attractiveness test for existing routing system participants -- and perhaps absolutely impossible to define an acceptable solution that does not *also* reproduce the same general demographic constraints that IPv4 will impose. This is why I feel strongly that any RRG statement on "incremental deployability" should not explicitly or implicitly assume possession of IPv4 as a prerequisite. My own idiosyncratic experiences lead me to believe that the deployability of any/all future RRG outputs may absolutely dependent on the ability of non-incumbents to lead and drive the adoption dynamic (more on this below). I don't expect the official RRG "incremental deployability" guidelines to adopt this stance, but neither could I support guidelines which are not equally applicable to all potential adopters, regardless of their access to IPv4. >> In this specific sense, a future technology that satisfies all of the >> requirements for "incremental deployability" might still end up >> getting >> effectively "vetoed," in the way that (some say) IPv6 has been >> vetoed. > > I am trying not to ascribe any particular meaning to "incremental > deployability". > > I don't agree that IPv6 has been "vetoed". It has been available for > 10 years or more an almost no-one really wants it, for the simple > reasons that it doesn't provide connectivity to the great majority of > hosts and that for most people, it provides no benefit over IPv4. In the real-world Internet where the provider-level value of a routing protocol is dictated by inter-provider network effects, an "abstain" vote by enough participants is equivalent to a system -wide veto. However, I didn't intend to use that term to imply anything more than what you stated in your response... >> Before I even attempt to suggest what kind of extensions or >> modifications might serve to remedy this perceived "incumbent bias" >> I'd >> be very interested in hearing reactions from others... > > I think the term "incumbent bias" implies an unreasonable resistance > to change. The perception of "incumbent bias" does not arise if the enumerated "incremental deployability" recommendations are not in fact contingent on possession of IPv4. By implication, an official position of "remaining agnostic" on this question would be appropriate IFF the final "incremental deployability" recommendations would be *equally* relevant, applicable to, and adoptable by both IPv4 haves and have-nots. > I don't think it is unreasonable that the great majority of Internet > users want and need a continuing service which enables them to > communicate with every other Internet host used by other similar > people. > > The IPv4 Internet is by far the biggest and most significant IT > system which has ever existed. In a free country, there would be no > demand for a service which failed to connect to even 1 or 2% of > hosts. An IPv6-only service fails to connect to nearly 100% of hosts. > > This is no fault of IPv6 - its just that no-one has figured out how > to remain IPv4 compatible while upgrading to another network. It > could be done, in principle - but only by radically rewriting all > applications to use a new stack. Even then, it would be a complex > and error-prone business trying to retain functionality running on > one or the other network exclusively, or using them both at the same > time. Again, we're in full agreement on these particulars, but as above I don't think that our agreement on these points is germane to the question at hand. > Here is a potential addition to the text, but I think this is taking > the scope of the piece beyond the constraints to adoption, and into > some additional goals we might have regarding the long-term > development of the Net: > > The above text attempts to summarise the real-world > constraints on a scalable routing solution. It > appears that these constraints create a very high > barrier to migration of significant numbers of > existing end-user networks from IPv4 to an IPv6 > service, either with or without retaining their > IPv4 address space. > > It follows that even if IPv6 had a scalable routing > solution, that the barriers to mass adoption of it > would remain so high as to preclude a mass migration > from IPv4. > > Our goal is to solve the routing scaling problem > in both the IPv4 and IPv6 Internets - and for the > foreseeable future, the problem only manifests in > the IPv4 Internet. > > Perhaps an additional goal of a scalable routing > solution would be - by some methods yet to be > determined - to facilitate adoption of an alternative > to IPv4 such as IPv6 which is a more promising > basis for accommodating very large numbers of > individual hosts, many of which are expected to be > mobile devices. > > Maybe something like this could be a footnote. I would go further than you and suggest that the proposed amendment has nothing at all to do with incremental deployment. I would much prefer to see the text explicitly acknowledge the fact of an IPv4 prerequisite, and all that it implies for incremental deployability, and deployability more generally. That said, what I would *most* like to see is some reformulation that illuminates possible incremental deployability paths that do not proceed from an assumption of possession of IPv4. **** So... for those who've gotten this far, I actually have reasons for believing that this modification is critically important. My personal experience is a one factor -- I helped to build out and "peer up" what was briefly a "Tier One" ISP, with most of my hands-on experience accumulated in the course of building out in parts of the world where artificially imposed IP addressing constraints were a common tool used by locally dominant operators. But much more apropos is the tentative findings of an ongoing 5+ year research project (first began as my prospective doctoral dissertation), which suggests that the Internet is at root a new kind of "liquidity system," one that is limited in scope to packetize-able things and which builds on a largely static "attachment" mechanism rather than the more dynamic "payment" mechanism of that older and more familiar liquidity system (i.e., the global system of monetary instruments, financial flows, credit creation, etc.). On this interpretation, the deployability of any future routing/ addressing protocol is likely to raise the same issues and impose the same challenges that many economies have experienced in the past when trying to integrate a new currency, or migrate from one currency to another. The existence of sovereign authority as a driver of currency migration makes some historical cases less relevant than others, but history reveals that even sovereign power cannot assure a successful liquidity system adaptation under some conditions. This shouldn't be altogether surprising, since the "circulating medium of exchange" (ala"money") was not originally invented so much as recognized post facto -- following its "emergence", usually in the form of some pretty-but-not-terribly-useful naturally occurring factor, as a widely acceptable, hence "fungible," temporary proxy for the thing(s) that aspiring buyers and sellers are actually trying to obtain. But to the main point, the most directly relevant historical cases are those in which sovereign power was not relevant, because the monetary liquidity system was not governed by a national treasury or central bank, but rather was largely self-coordinating through decentralized, limited, voluntary, private incentive-driven coordination mechanisms -- typically called "banker's clubs." Structurally and functionally, the monetary liquidity arrangements that characterized these so-called "free banking" periods bear an extremely strong resemblance to routing and addressing-related features of the TCP/IP-based Internet. And that's cause for serious concern. Anyone's who's still interested can find more details here: http://tinyurl.com/IPliquidity Tom From jnc@mercury.lcs.mit.edu Thu Apr 16 10:01:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CA13A6E9A for ; Thu, 16 Apr 2009 10:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX9oS-6b94Pu for ; Thu, 16 Apr 2009 10:01:18 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id E59BD3A6E29 for ; Thu, 16 Apr 2009 10:01:17 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0FA4B6BE57B; Thu, 16 Apr 2009 13:02:20 -0400 (EDT) To: rrg@irtf.org Message-Id: <20090416170223.0FA4B6BE57B@mercury.lcs.mit.edu> Date: Thu, 16 Apr 2009 13:02:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:01:18 -0000 > From: "Joel M. Halpern" > And v6 is still in sufficient flux that changes are far more practical. I just about fell off my chair when I read that. Some years back there was a suggestion to change TCPv6 so that the pseudo-header (and checksum) only included the "ID" part of the IPv6 address, and it was shot down, because 'it would cause imcompatability with the installed base', or words to that effect. So I'm not at all sure that the car's hood is as open as you seem to think it might be. Noel From dino@cisco.com Thu Apr 16 10:08:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB2B28C284 for ; Thu, 16 Apr 2009 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LslI614YeFZU for ; Thu, 16 Apr 2009 10:08:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1762B28C289 for ; Thu, 16 Apr 2009 10:06:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,199,1238976000"; d="scan'208";a="33925526" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 16 Apr 2009 17:07:40 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3GH7erb019045; Thu, 16 Apr 2009 10:07:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3GH7eXO025131; Thu, 16 Apr 2009 17:07:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 10:07:40 -0700 Received: from [192.168.1.3] ([10.21.93.249]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 10:07:39 -0700 Message-Id: <262366FA-05A0-43E0-9E1C-01B2C5E3396B@cisco.com> From: Dino Farinacci To: jnc@mercury.lcs.mit.edu (Noel Chiappa) In-Reply-To: <20090416170223.0FA4B6BE57B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 16 Apr 2009 10:07:39 -0700 References: <20090416170223.0FA4B6BE57B@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 16 Apr 2009 17:07:39.0683 (UTC) FILETIME=[D90FF730:01C9BEB5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=773; t=1239901660; x=1240765660; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=2s2yxIB+4NdR/RCTTvFJp12A//DwZXG6Nci4hjHx8wo=; b=h7cSZ+60kRMKojRWjRHHgouVrC7bX2Di5lYPA2w+paop+VpJNYjWzWKdXR 8Cs+lQ0e74k8e4nVZ6lD1AgYklvvGFvaY1nLd+HwhRLDkVehcY5Ea3qAQP9W IVfvBBDVH/6DsIVjHZF7R2uuitusZTgqjg1cOfiBwhMWs7LIOyTwA=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:08:04 -0000 >> From: "Joel M. Halpern" > >> And v6 is still in sufficient flux that changes are far more >> practical. > > I just about fell off my chair when I read that. Well, actually, I can say the same for IPv4. ;-) Dino > Some years back there was a suggestion to change TCPv6 so that the > pseudo-header (and checksum) only included the "ID" part of the IPv6 > address, > and it was shot down, because 'it would cause imcompatability with the > installed base', or words to that effect. > > So I'm not at all sure that the car's hood is as open as you seem to > think it > might be. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From wherrin@gmail.com Thu Apr 16 19:43:39 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F4F3A68F6 for ; Thu, 16 Apr 2009 19:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNy-xjP+qijL for ; Thu, 16 Apr 2009 19:43:38 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 76EBB3A689B for ; Thu, 16 Apr 2009 19:43:38 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so30854yxm.37 for ; Thu, 16 Apr 2009 19:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=MPIBPHSELoZTtNme+fN3u2rGhu4ZZn6MRLl32T0BIaI=; b=mcw1uulxOGkbyY+j4OvjG4He8R8kJjffm1udSdwJmj0jinFC6favw4A7Njb8p50OvA tPbXfAOgtiF+XWOAvgjJhAMTyND53bG7fj4fXgtmz7i8TKoVkHDts6+HbLSJ+ZVi4WTK pZwZUD4GscRI2347rmKSqBP6OQNuWtmDzzygM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DY3eOIVYP7QjWIV8N65gbiMO2pacHS3EzhHHNeAbrxxDztLsZTlUOPxywbxNyyKdCJ MA4iwN8viehOvVXPiO+ScZ9NPjqqX3AHohfxCdRPPSipgLH/frhyi7XyoDbYaOSVtshg atEIGz3SytDAGsBBrur+uGuoFVtJFK+5yqE8w= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.43.10 with SMTP id q10mr3034522anq.1.1239936291552; Thu, 16 Apr 2009 19:44:51 -0700 (PDT) In-Reply-To: <49E74B62.3020700@joelhalpern.com> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> Date: Thu, 16 Apr 2009 22:44:51 -0400 X-Google-Sender-Auth: 9cb2a1c52801e1a5 Message-ID: <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> From: William Herrin To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 02:43:39 -0000 On Thu, Apr 16, 2009 at 11:14 AM, Joel M. Halpern wrote: > Speaking only for myself, while I like solutions that help v4, I do not see > a problem with solving the architectural problem only, or first, for v6. Joel, Regardless of whether you see a problem with the idea, and despite the alleged consensus for it, fixing the problem for IPv6 first is not, in fact, what any of us are actually doing. The supposed consensus was false. If there was a consensus from that debate, it was that a solution process that failed to also resolve the problem for IPv6 would not be acceptable. Nor surprisingly, this latter statement reflects our behavior since. The point I endeavored to make to Tony is that he has repeated the mistake of declaring a false consensus and is likely reap the same results, namely damaged credibility and further difficulty shepherding us researchers into a coherent team. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Thu Apr 16 20:16:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C0C3A6D4E for ; Thu, 16 Apr 2009 20:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wITXZh4WxQDV for ; Thu, 16 Apr 2009 20:16:04 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id D5E0A3A6BD7 for ; Thu, 16 Apr 2009 20:15:34 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id gQK51b00316AWCUA6TGpb1; Fri, 17 Apr 2009 03:16:49 +0000 Received: from [192.168.0.110] ([24.6.155.154]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id gTGo1b0033L8a8Q8STGo0f; Fri, 17 Apr 2009 03:16:48 +0000 Message-ID: <49E7F48E.5040809@tony.li> Date: Thu, 16 Apr 2009 20:16:30 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rrg] Wiki page for terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:16:05 -0000 At Scott's request, I've started a wiki page for terminology. It's here: http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology?version=1 Enjoy! Tony From rw@firstpr.com.au Thu Apr 16 20:27:49 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699D83A6A6B for ; Thu, 16 Apr 2009 20:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr2590FdCqK4 for ; Thu, 16 Apr 2009 20:27:48 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 999233A6987 for ; Thu, 16 Apr 2009 20:27:47 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9D08F175B3F; Fri, 17 Apr 2009 13:28:59 +1000 (EST) Message-ID: <49E7F77E.10805@firstpr.com.au> Date: Fri, 17 Apr 2009 13:29:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> In-Reply-To: <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Zwiebel Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:27:49 -0000 Short version: Slightly amended text, followed by a brief reply to Tom Vest's message and some ideas on how large mobile networks could be the first large-scale IPv6 deployments. Changes indicated: *. Constraints imposed by the need for voluntary adoption * A successful solution to the routing and addressing scaling problem is tightly constrained by the need for it to be voluntarily adopted, over a period of * years, by the great majority of end-user networks * of all sizes who want or need multihoming, inbound traffic engineering and/or portability of their address space between ISPs. Broadly speaking, this means that at the time of introduction: 1 - The solution must provide immediate and compelling benefits to the end-user networks who adopt it, irrespective of how many other networks have so far adopted it. 2 - Therefore, it must provide multihoming, TE and portability for the adopting networks in a manner which fully supports communications with all hosts - including all hosts in non-upgraded networks. 3 - Therefore, the solution must be compatible with all hosts (stacks and applications) and routers in non-upgraded networks. 4 - The solution must be compatible with all existing applications in the adopting networks. 5 - Although in principle, some or many host stacks could be upgraded in the adopting networks, the difficulties this presents means that a scalable routing solution will only be widely enough adopted on a voluntary basis if no such upgrades are required in order for the new system to provide compelling benefits. Firstly, there are difficulties in motivating operating system / stack programmers to add and test new facilities. Secondly there may be costs and disruption for the adopting network in upgrading the stacks. Thirdly, in many or most end-user networks, some or many hosts will not be amenable to stack upgrades due to them using operating systems which are no longer being maintained or developed. This is especially the case for devices such as printers, routers etc. which do not use one of the major operating systems. 6 - The solution must be compatible with all existing DFZ routers. (Unless it can be shown that all DFZ routers can be upgraded - such as via a software update - by the time of introduction.) 7 - The solution must be attractive for the large number of smaller networks who currently cannot get PI space to do multihoming etc. Our goal is not just to reduce the number of DFZ routes but to enable a much larger number of end-user networks to gain multihoming, TE and portability than is currently possible. 8 - Ideally the solution will also be attractive for most or all end-user networks who currently have their own PI prefixes. This is firstly to improve scaling by attracting those larger end-user networks away from their current conventional PI address space usage and secondly to ensure that smaller networks which aspire to be bigger in the future will perceive the new kind of scalable end-user network address space as suitable for their long-term needs. 9 - Ideally the new system should not compromise security or performance compared to that of current PI or PA techniques. Any degradation in security, packet path lengths, end-to-end packet transit times, packet loss rates and general robustness etc. needs to be more than compensated for by reduced costs and/or benefits such as a more flexible and responsive multihoming restoration capability than is possible with current BGP techniques. 10 - The solution will probably not be widely enough * adopted if it requires upgrades to the internal routers of adopting networks - except perhaps in small networks such as SOHO where one or a few * inexpensive routers need upgrading anyway to * perform ITR and ETR etc. functions. In the longer term - in the years and decades to come - upgrades to DFZ routers, to ISP and end-user network internal routers and to host stacks can be made without significant cost or inconvenience and may allow enhanced performance for the new system. [Optional footnote if most people like it.] As a footnote, it should be acknowledged that the * constraints as described above seem to involve great * difficulty in providing any Internet service at all * - based on scalable routing or not - beyond IPv4. * The above text attempts to summarise the real-world constraints on a scalable routing solution. It appears that these constraints create a very high barrier to migration of significant numbers of existing end-user networks from IPv4 to an IPv6 service, either with or without retaining their IPv4 address space. It follows that even if IPv6 had a scalable routing solution, that the barriers to mass IPv6 adoption would remain high. A potential exception may be * mobile devices, whose functionality may not be as * dependent on full IPv4 connectivity as is the case * for most hosts today. [See note below.] * Our goal is to solve the routing scaling problem in both the IPv4 and IPv6 Internets - and for the foreseeable future, the problem only manifests in the IPv4 Internet. A good IPv4 scalable routing solution may enable * finer divisions in the address space than is * practical with current BGP techniques and so may * contribute to a significantly higher number of * end-user networks being able to use the available * space. Nonetheless, the finite limits of IPv4 * address space remain a serious concern, especially * for newly established ISPs and end-user networks. * On this basis, it would be desirable if a * scalable routing solution, in some way yet to be * determined, facilitated adoption of an alternative * to IPv4 - such as IPv6 - which is a more promising * basis for accommodating billions of hosts, many of * which are expected to be mobile devices. * Note on IPv6 mobile devices. I am envisaging a situation, such as in China or other countries, where cellphones and mobile PCs etc. need an IP address in order for various voice and messaging services to be provided, and for direct communications between devices in the same or similar mobile networks. The huge number of such mobile devices precludes giving each an IPv4 global unicast address, and for many purposes (but not global IPv4 connectivity) an IPv6 address may work fine. With a sufficiently large number of cellphones etc. on IPv6 like this, it would be profitable to deploy many commercial IPv6 servers to provide "content" for these devices would also be. This would make non-mobile IPv6-only services more attractive. This "mobile first" scenario for widespread IPv6 adoption is the most likely one I can imagine. A less likely scenario is certain countries providing IPv6 only DSL etc. services to customers who cannot access any IPv4 service. Hi Tom, I will respond more fully to your thoughtful message separately, probably with a subject like "Breaking IPv4's constraints". The main body of text above is intended to be a statement of fact about the major constraints which arise from our reliance on widespread voluntary adoption. This is to complement statements of the functional goals of the solution - such as to provide a new form of address space for end-user networks which scalably provides multihoming, inbound TE and portability. (Also, I think, support for global mobility.) Perhaps if enough people like this text - or some improved version of it - we could add it to: http://tools.ietf.org/html/draft-irtf-rrg-recommendation I am trying to keep it brief, but would like some kind of footnote to at least acknowledge the inherently IPv4-centric nature of these constraints - since IPv4 is not mentioned specifically in the main text. While this text embodies what I always meant by "incremental deployability" I am not trying to define this term. You wrote several times about my text as if it was to become "RRG "incremental deployability" recommendations". I want it to be a concise but reasonably complete statement of some constraints which most of us agree are are real-world limitations we must work within. Only by implication is it a "recommendation" - for how to evaluate potential solutions: proposals, architectures, candidate designs or whatever. I sense you are very concerned about the difficulty of establishing Internet services beyond the finite constraints of IPv4. I think there's nothing which could be written now which would contribute to a solution to this problem. I think a footnote is the best way of acknowledging this. - Robin From tony.li@tony.li Thu Apr 16 21:01:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D973A67F3 for ; Thu, 16 Apr 2009 21:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbGbrnNEy3Bh for ; Thu, 16 Apr 2009 21:01:15 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 371573A6990 for ; Thu, 16 Apr 2009 21:01:15 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id gT0L1b00i0FhH24ABU2VSe; Fri, 17 Apr 2009 04:02:29 +0000 Received: from [192.168.0.110] ([24.6.155.154]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id gU2T1b00L3L8a8Q8UU2UDE; Fri, 17 Apr 2009 04:02:29 +0000 Message-ID: <49E7FF3F.9010008@tony.li> Date: Thu, 16 Apr 2009 21:02:07 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> In-Reply-To: <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:01:16 -0000 Hi Bill, > Yikes! Tony, here's what our old friend Webster has to say about consensus: > consensus > n. > 1 an opinion held by all or most > 2 general agreement, esp. in opinion Here's what another authority has to say about consensus: Decisions are made by those who show up. -- Aaron Sorkin > The notion that because the other 461 subscribers of the list were not > offended enough to respond constitutes consensus in favor defies the > plain English meaning of the word consensus. Perhaps. However, it's still the rough consensus measurement mechanism that the IETF and this RG operate on. Anyone have any stats on what percentage of registered voters actually vote? ;-) > Last year, I and most of the rest of the group ignored your > declaration of consensus on "fix it for IPv6 first" and continued > focusing solely on approaches which work for IPv4. Interesting. I don't recall that. In fact, I've been very careful to do clear consensus checks. The only mail message that I can find that was like that said: Solving v4 without solving v6 is just a bandaid. Hopefully, we can do better. IMHO, it would be sufficient to fix just the v6 side of things, but again, that's personal opinion. Hope you read the whole sentence. Of course, there is the non-trivial probability that I'm afflicted with Mad Cow disease and that I'm forgetting something that we've done. I can find a few other consensus checks (interim meeting, renumbering, day of the meeting) but nothing that pertains to IPv6 vs. IPv4. AFAIK, that is an open point of disagreement and vehement discussion. ;-) Care to cite chapter and verse? Tony From jmh@joelhalpern.com Thu Apr 16 21:05:31 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BF93A6CF5 for ; Thu, 16 Apr 2009 21:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI90PGMoPKAJ for ; Thu, 16 Apr 2009 21:05:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8B8723A6D4E for ; Thu, 16 Apr 2009 21:05:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C2AF4303CE; Thu, 16 Apr 2009 21:06:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9B85C43039F; Thu, 16 Apr 2009 21:06:43 -0700 (PDT) Message-ID: <49E8004A.2030700@joelhalpern.com> Date: Fri, 17 Apr 2009 00:06:34 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> In-Reply-To: <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] IP Versions X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:05:31 -0000 Your comment that "fixing the problem for IPv6 first is not, in fact, what any of us are actually doing" is not, in fact, accurate. I know of several proposals whcih have been presented to the RRG, some of which I have or am helping with, with take exactly that approach. Yours, Joel William Herrin wrote: > On Thu, Apr 16, 2009 at 11:14 AM, Joel M. Halpern wrote: >> Speaking only for myself, while I like solutions that help v4, I do not see >> a problem with solving the architectural problem only, or first, for v6. > > Joel, > > Regardless of whether you see a problem with the idea, and despite the > alleged consensus for it, fixing the problem for IPv6 first is not, in > fact, what any of us are actually doing. > > The supposed consensus was false. If there was a consensus from that > debate, it was that a solution process that failed to also resolve the > problem for IPv6 would not be acceptable. Nor surprisingly, this > latter statement reflects our behavior since. > > The point I endeavored to make to Tony is that he has repeated the > mistake of declaring a false consensus and is likely reap the same > results, namely damaged credibility and further difficulty shepherding > us researchers into a coherent team. > > Regards, > Bill Herrin > From rw@firstpr.com.au Thu Apr 16 21:06:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BBD3A685D for ; Thu, 16 Apr 2009 21:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eCPtm+E0jN1 for ; Thu, 16 Apr 2009 21:06:12 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 96DB63A6DFE for ; Thu, 16 Apr 2009 21:05:42 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 4A04C175D0B; Fri, 17 Apr 2009 14:06:55 +1000 (EST) Message-ID: <49E80062.4010703@firstpr.com.au> Date: Fri, 17 Apr 2009 14:06:58 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rrg@irtf.org References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> In-Reply-To: <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Point of order - inadequate consensus process? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:06:13 -0000 Hi Bill and Joel, Tony's message on rough consensus regarding IPv4 and IPv6 (2008-06-14) was: http://www.ietf.org/mail-archive/web/rrg/current/msg02477.html Last week we did a consensus check on the following: |Our recommendation should be applicable to IPv6. It may or |may not also apply to IPv4, but at the very least must provide |a path forward for IPv6. It's my judgement that we have rough consensus on this. There is dissent, notably from Robin and Bill, but overall, it seems that we have rough consensus. >> Speaking only for myself, while I like solutions that help v4, I do not see >> a problem with solving the architectural problem only, or first, for v6. > > Joel, > > Regardless of whether you see a problem with the idea, and despite the > alleged consensus for it, fixing the problem for IPv6 first is not, in > fact, what any of us are actually doing. Except for Six/One Router, which only works for IPv6. > The supposed consensus was false. If there was a consensus from that > debate, it was that a solution process that failed to also resolve the > problem for IPv6 would not be acceptable. Nor surprisingly, this > latter statement reflects our behavior since. > > The point I endeavored to make to Tony is that he has repeated the > mistake of declaring a false consensus and is likely reap the same > results, namely damaged credibility and further difficulty shepherding > us researchers into a coherent team. I agree - this supposed consensus on IPv4 / IPv6 doesn't really reflect the view of the people who IMHO most matter in this field: those who are actively devising potentially practical solutions. LISP, APT, Ivip and TRRP all work with IPv4 and IPv6 and AFAIK, are all being developed initially for IPv4. If it really is the consensus view that the RRG solution should definitely fix the IPv6 scaling problem and may or may not fix the IPv4 problem then maybe it is time to form a new group. One measure of the seriousness of the scalable routing problem is the number of DFZ routes (BGP advertised prefixes). According to: http://bgp.potaroo.net/v6/v6rpt.html the IPv6 problem is about 1/256th that of the IPv4 problem. With the current doubling time of 2 years, it will take 16 years before the IPv6 scaling problem approximates that of today's IPv4 problem. So it would be an abrogation of our duty to consider solving the only problem in town as merely an option. I can't see anything in the RRG Charter which supports solving a problem which won't exist for a decade or two before solving the problem which exists right now. I have already commented on the consensus check regarding terminology: http://www.ietf.org/mail-archive/web/rrg/current/msg04786.html Dow Street (04792) and Bill Herrin (04824) initially thought the definitions were worth making - but changed their mind during the debate. I had this view from the start. - Robin From wherrin@gmail.com Thu Apr 16 21:50:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44393A6D29 for ; Thu, 16 Apr 2009 21:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NocvIiOF-Ne for ; Thu, 16 Apr 2009 21:50:12 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 9CFA43A6CFE for ; Thu, 16 Apr 2009 21:50:09 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so48104yxm.37 for ; Thu, 16 Apr 2009 21:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uNUaIg909yD+vzc9ojbfO7us9LxzL9eLj/i3T4qDC8k=; b=PyyyVHhR1BhayJUkdoXHt4090o3MWewGkpvGU1fZjGGqIVlVW9jrvFdDbUocIbHT/F ZHhZ2q59AU1oH08Ge86HH0l1swMmTCVLsCvIPT1oQvBkJxj/nQX8uBf/ivjiioTEl3LW nsGHP0jMwEp5yG0xcFti4xmBlKN3BDUebUqd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RYODbLzpo5aKI6nNqzlM6DL6wSLMyXTWKeuHYq0ctBKuhqaY3VyqdH/Thqjd4koEBe Bh0OU9B8zh2epHN4g2ctuoStvU5vRBCDddCS48hiKBa7Ivv+PaIeNj92nAS72XND1vB9 9mv8GMMjoP2HkjqWjtWIXAQuq1ks4hq2Thgdo= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.5.16 with SMTP id 16mr3185797ane.8.1239943882146; Thu, 16 Apr 2009 21:51:22 -0700 (PDT) In-Reply-To: <49E7FF3F.9010008@tony.li> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E7FF3F.9010008@tony.li> Date: Fri, 17 Apr 2009 00:51:22 -0400 X-Google-Sender-Auth: dcccf4149cceb33b Message-ID: <3c3e3fca0904162151y5f3ad94bw8053d159a2593065@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:50:13 -0000 On Fri, Apr 17, 2009 at 12:02 AM, Tony Li wrote: >> consensus >> n. >> 1 =A0 =A0 =A0 an opinion held by all or most >> 2 =A0 =A0 =A0 general agreement, esp. in opinion > > Here's what another authority has to say about consensus: > > =A0 =A0 =A0 =A0Decisions are made by those who show up. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0-- Aaron Sorkin Tony, While that's a great quote, I'm not convinced that a fictional character on a television show qualifies as an "authority." http://www.westwingtranscripts.com/search.php?flag=3DgetTranscript&id=3D22&= keyword=3Dmade%20by%20those%20who%20show%20up#thequery Even if he was an authority, the quote describes voting which our friend Webster defines quite differently than consensus: "A decision by a group on a proposal," not "general agreement." >> Last year, I and most of the rest of the group ignored your >> declaration of consensus on "fix it for IPv6 first" and continued >> focusing solely on approaches which work for IPv4. > > Interesting. =A0I don't recall that. In fact, I've been very > careful to do clear consensus checks. > Care to cite chapter and verse? Since Robin has thoughtfully done all the work for me: http://www.ietf.org/mail-archive/web/rrg/current/msg02477.html I suspect Mad Cow has nothing to do with it. As I do, you would like to see the researchers on the group come together as a more effective team. But voting doesn't forge a team... it splits folks apart. That's why the IETF seeks consensus INSTEAD OF voting. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Thu Apr 16 21:59:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0B128C0D8 for ; Thu, 16 Apr 2009 21:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pNTcHJQgxbx for ; Thu, 16 Apr 2009 21:59:10 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 9203A28B23E for ; Thu, 16 Apr 2009 21:59:10 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id gQK51b0060cQ2SLA8V0QuZ; Fri, 17 Apr 2009 05:00:24 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id gV0N1b0063L8a8Q8WV0PAU; Fri, 17 Apr 2009 05:00:24 +0000 Message-ID: <49E80CCF.2040006@tony.li> Date: Thu, 16 Apr 2009 21:59:59 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robin Whittle References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80062.4010703@firstpr.com.au> In-Reply-To: <49E80062.4010703@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] v4 and/or v6 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:59:12 -0000 Hi Robin, > Tony's message on rough consensus regarding IPv4 and IPv6 > (2008-06-14) was: > > http://www.ietf.org/mail-archive/web/rrg/current/msg02477.html > > Last week we did a consensus check on the following: > > |Our recommendation should be applicable to IPv6. It may or > |may not also apply to IPv4, but at the very least must provide > |a path forward for IPv6. > > It's my judgement that we have rough consensus on this. There > is dissent, notably from Robin and Bill, but overall, it seems > that we have rough consensus. Thank you for finding that. Your Google-fu is clearly stronger than mine. ;-) As is your memory. ;-) Please note that this is significantly different than "fix it for IPv6 first". As we did not, at the time, do an explicit consensus check on that at the time, you're well within your bounds to call for a formal check. >> Regardless of whether you see a problem with the idea, and despite the >> alleged consensus for it, fixing the problem for IPv6 first is not, in >> fact, what any of us are actually doing. > > Except for Six/One Router, which only works for IPv6. And ILNP. Both of which have no pretense of ever addressing IPv4. >> The supposed consensus was false. If there was a consensus from that >> debate, it was that a solution process that failed to also resolve the >> problem for IPv6 would not be acceptable. Nor surprisingly, this >> latter statement reflects our behavior since. If there's a semantic difference between this and the quote above, it's lost on me. > I agree - this supposed consensus on IPv4 / IPv6 doesn't really > reflect the view of the people who IMHO most matter in this field: > those who are actively devising potentially practical solutions. > LISP, APT, Ivip and TRRP all work with IPv4 and IPv6 and AFAIK, are > all being developed initially for IPv4. I'm sorry, but we are more egalitarian than that. All participants count equally. > One measure of the seriousness of the scalable routing problem is the > number of DFZ routes (BGP advertised prefixes). According to: > > http://bgp.potaroo.net/v6/v6rpt.html > > the IPv6 problem is about 1/256th that of the IPv4 problem. With > the current doubling time of 2 years, it will take 16 years before > the IPv6 scaling problem approximates that of today's IPv4 problem. This is clearly only a tactical view. The routing architectures of the two are wholly identical (with perhaps v6 address allocation policies being worse). If anything, this is soley a measure of the lack of v6 deployment. In the strategic view, the v6 problem must (also?) be solved. > I can't see anything in the RRG Charter which supports solving a > problem which won't exist for a decade or two before solving the > problem which exists right now. The RRG was chartered specifically to address the architectural issues. Not the implementation issues. If you want to fix the immediate scaling, I recommend that you go work at a router vendor and add more memory. ;-) Far more pragmatic and tactical than what we are doing. Tony From tony.li@tony.li Thu Apr 16 22:01:50 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88B23A695C for ; Thu, 16 Apr 2009 22:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEmOd9+wbETo for ; Thu, 16 Apr 2009 22:01:50 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 1A9BA3A67F3 for ; Thu, 16 Apr 2009 22:01:50 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id gUuE1b0050cQ2SLA1V2FTY; Fri, 17 Apr 2009 05:02:15 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id gV331b0073L8a8Q8WV33pe; Fri, 17 Apr 2009 05:03:04 +0000 Message-ID: <49E80D70.8040704@tony.li> Date: Thu, 16 Apr 2009 22:02:40 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Noel Chiappa References: <20090416170223.0FA4B6BE57B@mercury.lcs.mit.edu> In-Reply-To: <20090416170223.0FA4B6BE57B@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:01:51 -0000 > > And v6 is still in sufficient flux that changes are far more practical. > > I just about fell off my chair when I read that. > > Some years back there was a suggestion to change TCPv6 so that the > pseudo-header (and checksum) only included the "ID" part of the IPv6 address, > and it was shot down, because 'it would cause imcompatability with the > installed base', or words to that effect. Just because one person holds an opinion doesn't make it true. ;-) Tony From lear@cisco.com Thu Apr 16 22:06:35 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F5F3A67F3 for ; Thu, 16 Apr 2009 22:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.787 X-Spam-Level: X-Spam-Status: No, score=-9.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM1N0NEfKQR2 for ; Thu, 16 Apr 2009 22:06:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 23B2C3A6A6C for ; Thu, 16 Apr 2009 22:06:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,202,1238976000"; d="scan'208";a="38500458" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 05:07:40 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3H57eJb014877; Fri, 17 Apr 2009 07:07:40 +0200 Received: from adsl-247-3-fixip.tiscali.ch (dhcp-10-61-97-114.cisco.com [10.61.97.114]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H57dXY015651; Fri, 17 Apr 2009 05:07:39 GMT Message-ID: <49E80E9B.2040606@cisco.com> Date: Fri, 17 Apr 2009 07:07:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shredder/3.0b3pre MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> In-Reply-To: <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=361; t=1239944860; x=1240808860; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=Z0u428qHcvf+6UuUz8rthdLcWWO0iBF/o8bO/BNkkAw=; b=m8FBsW2VQElC7oDIe4PeFzTBLV1gVl2uaj8IhwzKcYKMFFC6jYSGHu3Cbp M4iU7fDD4sP95dRvgc2uf/BF3kIlKyIdKuTgylkfEYx3sEa3kP8gt/gxk9YZ /WyACzZ033; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:06:35 -0000 Bill, As a former chair in the IRSG I can tell you that Tony is within his rights to not even bother to call for a consensus. He has done so, but he gets to determine what that consensus is. That having been said, this is a research group. If you don't like the definitions, don't use them in your work. Nobody is forcing you to do so. Eliot From tony.li@tony.li Thu Apr 16 22:06:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BCF3A6DDC for ; Thu, 16 Apr 2009 22:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MuAybH3hrJe for ; Thu, 16 Apr 2009 22:06:47 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 0603A3A6D61 for ; Thu, 16 Apr 2009 22:06:46 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id gQK51b00D0EPchoAAV81i5; Fri, 17 Apr 2009 05:08:01 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id gV801b0093L8a8Q8MV80PM; Fri, 17 Apr 2009 05:08:01 +0000 Message-ID: <49E80E98.3030609@tony.li> Date: Thu, 16 Apr 2009 22:07:36 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E7FF3F.9010008@tony.li> <3c3e3fca0904162151y5f3ad94bw8053d159a2593065@mail.gmail.com> In-Reply-To: <3c3e3fca0904162151y5f3ad94bw8053d159a2593065@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:06:47 -0000 Hi Bill, > While that's a great quote, I'm not convinced that a fictional > character on a television show qualifies as an "authority." Actually, Aaron Sorkin was the writer. ;-) > Even if he was an authority, the quote describes voting which our > friend Webster defines quite differently than consensus: "A decision > by a group on a proposal," not "general agreement." Ok, fine. I don't want to quibble with you. We're voting. > I suspect Mad Cow has nothing to do with it. As I do, you would like > to see the researchers on the group come together as a more effective > team. But voting doesn't forge a team... it splits folks apart. That's > why the IETF seeks consensus INSTEAD OF voting. The IETF (and RRG) seek _rough_ consensus. The fact that they do so by a show of hands, a hum, or a doodle poll is merely a matter of mechanism. It's all just voting. Tony From wherrin@gmail.com Thu Apr 16 22:10:11 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8083A6A6C for ; Thu, 16 Apr 2009 22:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOg+aw4QNQXE for ; Thu, 16 Apr 2009 22:10:10 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 9716D3A6D3F for ; Thu, 16 Apr 2009 22:10:10 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so50262yxm.37 for ; Thu, 16 Apr 2009 22:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=vJqok5MNBLuu5mwvG298k6zYbatHNZpGFIrILRtksMw=; b=ke9wHBNq8/XW09deMeWqfaYdOBSv/tVUFS8ZpdatXyFTTYGdXbcnfiXtys45AnbMA7 9lo/MGZM1zo+3F4d7N3cX5tyHaqNXGAjVDy5OD4o5U8QMCjszYHZCzYU3RTxnuqO3ZsL JvCY7frVDARmSYjGrH5SA5Uqm5Oso3TERkhHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cDavS5gk91NFT8/O7TrVLdBigLYKLuQ0N9Lh3/45iykRA5rYevRleZCp1DVOsF4QLV E0LMfo3mGkwEfgZjaGOhiHf3kJdSHyoBjXdQf/zY+ZVHQqEB3KtbjTgYn+WaAFt0vc49 rclSRRZqdf4K4X++2vQBU5aseiO9zBxOWfNLQ= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.101.68.19 with SMTP id v19mr3186054ank.70.1239945083215; Thu, 16 Apr 2009 22:11:23 -0700 (PDT) In-Reply-To: <49E80E98.3030609@tony.li> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E7FF3F.9010008@tony.li> <3c3e3fca0904162151y5f3ad94bw8053d159a2593065@mail.gmail.com> <49E80E98.3030609@tony.li> Date: Fri, 17 Apr 2009 01:11:23 -0400 X-Google-Sender-Auth: b50082d90fb10cb5 Message-ID: <3c3e3fca0904162211j29402252g1415d8135dbdc31@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:10:11 -0000 On Fri, Apr 17, 2009 at 1:07 AM, Tony Li wrote: > Ok, fine. =A0I don't want to quibble with you. =A0We're voting. > > The IETF (and RRG) seek _rough_ consensus. =A0The fact that they do so by= a > show of hands, a hum, or a doodle poll is merely a matter of mechanism. > =A0It's all just voting. Tony, The IETF seeks rough consensus AND RUNNING CODE. Show me the code that justifies those definitions and I'll back down. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Thu Apr 16 22:27:26 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED3A3A6889 for ; Thu, 16 Apr 2009 22:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoAaUXe1SpVb for ; Thu, 16 Apr 2009 22:27:26 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id D4EAB3A687B for ; Thu, 16 Apr 2009 22:27:25 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so510322anc.37 for ; Thu, 16 Apr 2009 22:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3K/bvygl+ZXm16srzMvzRLLeRD9tJ7qbCy1WB7RI9B8=; b=g+Qqm2psAYYHtg5FZNfBYxuyeVJUDA5HrEUk4448TSq+GmqDlBgCeEzyg7CngvUE+U WneYlcMINiMwQOpu0GKcs13c8zprN/jqoUwuVwSMUUD7IEJ71jL83t0Js575a9wSSB0X OYjeajlsMhmyOnX5uanDJKaiu7lj96gGEud/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v/rqAQvIDPfKYgz19hrhZVWIJc3gxjNw+NHVBU0deZC6ZkWcX1drfs/BG7aAiQ76zw FPA2+Tw1wPJ6/WGo4bZ7GYNIYVrIXZQF3i6VyPVb5dQttmfvU2DAnnFUJM6FxGX+gBc5 G8G5P4kovehXuKh/YDtHct7dX+Lzry5s/s4Wo= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.57.13 with SMTP id f13mr3189236ana.77.1239946117559; Thu, 16 Apr 2009 22:28:37 -0700 (PDT) In-Reply-To: <49E80E9B.2040606@cisco.com> References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> Date: Fri, 17 Apr 2009 01:28:37 -0400 X-Google-Sender-Auth: 2aa778c68f60d851 Message-ID: <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> From: William Herrin To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:27:27 -0000 On Fri, Apr 17, 2009 at 1:07 AM, Eliot Lear wrote: > As a former chair in the IRSG I can tell you that Tony is within his righ= ts > to not even bother to call for a consensus. =A0He has done so, but he get= s to > determine what that consensus is. Eliot, If you want to talk about rights, I'm within my rights to thoroughly castigate the chair on those occasions when he determines consensus poorly. I'd rather talk about responsibilities. Tony has a responsibility to accurately assess and report whether and what consensus the group reaches. As a participant, I have a responsibility to call him on it when I see him miss the mark and, if necessary, establish a well justified record of dissent. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lear@cisco.com Thu Apr 16 22:40:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3F13A69F6 for ; Thu, 16 Apr 2009 22:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn+Tq4qrdXNB for ; Thu, 16 Apr 2009 22:40:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 707AC3A6A9F for ; Thu, 16 Apr 2009 22:40:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,202,1238976000"; d="scan'208,217";a="38500924" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 05:41:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3H5fYlv019223; Fri, 17 Apr 2009 07:41:34 +0200 Received: from adsl-247-3-fixip.tiscali.ch (dhcp-10-61-97-114.cisco.com [10.61.97.114]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H5fY7I019079; Fri, 17 Apr 2009 05:41:34 GMT Message-ID: <49E8168D.7030006@cisco.com> Date: Fri, 17 Apr 2009 07:41:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shredder/3.0b3pre MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> In-Reply-To: <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------010406060202060401020505" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2291; t=1239946894; x=1240810894; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=eft7pyySV6cEcalSwjUxWN52LBI3i0w/mvBQzi78GWA=; b=o3B+teY595MoqEcUFKCVbAvqTBOu+ak0xXvSlbJzXICsblYbIr/+wrPUMo eWYrmWc7ItUh8ehtGEhBalyXr+/DU+1IM6JljYdgA9gbIqbOoCotxqctNYZO gNf5bKJzVx; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:40:23 -0000 This is a multi-part message in MIME format. --------------010406060202060401020505 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/17/09 7:28 AM, William Herrin wrote: > I'd rather talk about responsibilities. Tony has a responsibility to > accurately assess and report whether and what consensus the group > reaches. Where did you come up with that? He has no such responsibility. He has a responsibility to see that routing research is spurred from his group. If he doesn't do that, then there's no point to the group. And how he does that is *completely* up to him and Lixia. > As a participant, I have a responsibility to call him on it > when I see him miss the mark and, if necessary, establish a well > justified record of dissent. > And he as a chair could boot your butt out, if he so chose. This is *not* the IETF. Eliot --------------010406060202060401020505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/17/09 7:28 AM, William Herrin wrote:
I'd rather talk about responsibilities. Tony has a responsibility to
accurately assess and report whether and what consensus the group
reaches.

Where did you come up with that?  He has no such responsibility.  He has a responsibility to see that routing research is spurred from his group.  If he doesn't do that, then there's no point to the group.  And how he does that is completely up to him and Lixia.


As a participant, I have a responsibility to call him on it
when I see him miss the mark and, if necessary, establish a well
justified record of dissent.

And he as a chair could boot your butt out, if he so chose.  This is not the IETF.

Eliot
--------------010406060202060401020505-- From wherrin@gmail.com Thu Apr 16 22:49:02 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400BD3A6D88 for ; Thu, 16 Apr 2009 22:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrRIjpvujrUL for ; Thu, 16 Apr 2009 22:49:01 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id BF4B03A69A9 for ; Thu, 16 Apr 2009 22:49:00 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so54534yxm.37 for ; Thu, 16 Apr 2009 22:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pTs6TyCVP2LpzWrbqq8nFIbf/HZdSO47vrAAc3WkGg8=; b=FDwuRnW/g71rXzZb3erxK3r0sGO3ti8gPXMd3aSGwOjf7n/sGW36K54BUaExz+XibA o/LP8VKqJg/vo6ZPHexMTxP0ryNFr1YyLoj66m9jZZCRkyf3TFYSCy9XJGuwrEZ0yqay pbWWqXS30QvkVufaDUJo86CLmQ+CShiql8JG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rg7khYwTRkEfovPJxjzjOAdYF7iZtzMbf2Jrm6zdG4C7nDCPYnbnR9Kb1usdMategE JEb4yBAZG3YrQop5WweQhCLUAh0OC6DfmL9BKYhSY1OwmzF0B0q8Eh1v8/lmqJZ5xWWM GcGSxqBb/qkTnWTs3u6TuHpHAXNyr5hD9I0Ks= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.207.14 with SMTP id e14mr3213942ang.139.1239947409996; Thu, 16 Apr 2009 22:50:09 -0700 (PDT) In-Reply-To: <49E80CCF.2040006@tony.li> References: <49DD6DD2.3060105@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80062.4010703@firstpr.com.au> <49E80CCF.2040006@tony.li> Date: Fri, 17 Apr 2009 01:50:09 -0400 X-Google-Sender-Auth: efe5d622f567a819 Message-ID: <3c3e3fca0904162250j1745aefaxe9cd04576b7ad2c5@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org, Robin Whittle Subject: Re: [rrg] v4 and/or v6 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:49:02 -0000 On Fri, Apr 17, 2009 at 12:59 AM, Tony Li wrote: >> =A0 =A0 =A0|Our recommendation should be applicable to IPv6. =A0It may o= r >> =A0 =A0 =A0|may not also apply to IPv4, but at the very least must provi= de >> =A0 =A0 =A0|a path forward for IPv6. >> >>> The supposed consensus was false. If there was a consensus from that >>> debate, it was that a solution process that failed to also resolve the >>> problem for IPv6 would not be acceptable. Nor surprisingly, this >>> latter statement reflects our behavior since. > > > If there's a semantic difference between this and the quote above, it's l= ost > on me. Tony, The first calls for solving the problem for IPv6 and then considering whether it can be backported to IPv4. The second calls for solving the problem for IPv4 while avoiding any (unlikely) pitfalls that would prevent an identical solution from working for IPv6. The difference is not all that subtle. > The RRG was chartered specifically to address the architectural issues. = =A0Not > the implementation issues. That was, is and will continue to be a cop-out. An architecture is dictated first and foremost by its achievability from the current state of affairs. Does no good to design an interstellar starship if you can't build an engine that moves it. First figure out how to build an engine. Then use the knowledge you gained to design a better starship. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Thu Apr 16 22:55:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B073A6DAA for ; Thu, 16 Apr 2009 22:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdiXH9QcGcHH for ; Thu, 16 Apr 2009 22:55:09 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id DBFF83A6A31 for ; Thu, 16 Apr 2009 22:55:08 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so55125yxm.37 for ; Thu, 16 Apr 2009 22:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=S7ZoZksgeEyeRmMaBK2LvG3NoiJNwAWwSBAvUgH+y08=; b=DfuXpDrNnP40q85/sQbTagLqLoCATmf50WQMbcOEu/AYyKl31Gfv3u7XsIRgS9e/xB 1vHM/4uFq/kWCF+BoAg/NGTiYHHDl82e1wJrFQmkQQC31BjTkIFAaa08xLSUlGX+xIPD hcwSVemG2fuC5Vve4UoWllvJg/ZboXgQ9buHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UOsNKRRP8as/cjEgGlMhgDM9GEFDOV1AHHMFrI+Yl1Oq4FqFG0xSuc0mekMC6C7obY z2nbXnuH/iZl7JSzVEsXaE7EEk3hB49no6FUXs5O1zyCI9xu18RvEqW5XGtea3SfIwbo Uy7UNCKDj+m0T3XxFZyVjM21y2SehdkyhA0ZU= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.5.16 with SMTP id 16mr2798248ane.22.1239947781779; Thu, 16 Apr 2009 22:56:21 -0700 (PDT) In-Reply-To: <49E8168D.7030006@cisco.com> References: <49DD6DD2.3060105@tony.li> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> Date: Fri, 17 Apr 2009 01:56:19 -0400 X-Google-Sender-Auth: cfdeedf0af943761 Message-ID: <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> From: William Herrin To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:55:10 -0000 On Fri, Apr 17, 2009 at 1:41 AM, Eliot Lear wrote: > On 4/17/09 7:28 AM, William Herrin wrote: >> As a participant, I have a responsibility to call him on it >> when I see him miss the mark and, if necessary, establish a well >> justified record of dissent. > > And he as a chair could boot your butt out, if he so chose. This is not the > IETF. Then as critical as I'm being of this one specific decision, I'll just have to rely on his good judgment not to take such a capricious action, won't I? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lear@cisco.com Thu Apr 16 22:57:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8175B3A6A6C for ; Thu, 16 Apr 2009 22:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri309qLddGml for ; Thu, 16 Apr 2009 22:57:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 18E883A6800 for ; Thu, 16 Apr 2009 22:57:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,202,1238976000"; d="scan'208,217";a="38501244" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2009 05:58:30 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3H5wUP0029626; Fri, 17 Apr 2009 07:58:30 +0200 Received: from adsl-247-3-fixip.tiscali.ch (dhcp-10-61-97-114.cisco.com [10.61.97.114]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3H5wUNE020985; Fri, 17 Apr 2009 05:58:30 GMT Message-ID: <49E81A86.2070206@cisco.com> Date: Fri, 17 Apr 2009 07:58:30 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shredder/3.0b3pre MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> In-Reply-To: <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------000908050207030107080808" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1200; t=1239947910; x=1240811910; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Point=20of=20order |Sender:=20; bh=MxKE1q2qyYMe+QkLk3qa57LZSRN6EO3yTQjELQI9K/o=; b=maBYCU3iG6+iil1rKgXVuj9ZVoAiorEl89Kf1uKkzmUkkWtGuD+nsvIRnU Idihrx6J8XYO63SpUYDByzDhJdNaYqHjZz8HdQka+rIXA9o3u0S+XiCH2FWS C9AJqf9zFT; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:57:19 -0000 This is a multi-part message in MIME format. --------------000908050207030107080808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit My point is that this is not a standards activity. I question whether rough consensus is even a good idea in a research environment. That a few people agree on terms is sufficient for *THEM* to collaborate together. That others do not agree may be sufficient for those others to collaborate, and let the best research win. Eliot --------------000908050207030107080808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit My point is that this is not a standards activity.  I question whether rough consensus is even a good idea in a research environment.  That a few people agree on terms is sufficient for THEM to collaborate together.  That others do not agree may be sufficient for those others to collaborate, and let the best research win.

Eliot
--------------000908050207030107080808-- From tony.li@tony.li Thu Apr 16 23:16:27 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C3D28C158 for ; Thu, 16 Apr 2009 23:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3BJVTkElj8r for ; Thu, 16 Apr 2009 23:16:26 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 6C3BD28C0FF for ; Thu, 16 Apr 2009 23:16:26 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id gWD71b0030mlR8UA7WHgLs; Fri, 17 Apr 2009 06:17:40 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id gWHf1b0043L8a8Q8XWHf8T; Fri, 17 Apr 2009 06:17:40 +0000 Message-ID: <49E81EE7.2070009@tony.li> Date: Thu, 16 Apr 2009 23:17:11 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <49DD6DD2.3060105@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80062.4010703@firstpr.com.au> <49E80CCF.2040006@tony.li> <3c3e3fca0904162250j1745aefaxe9cd04576b7ad2c5@mail.gmail.com> In-Reply-To: <3c3e3fca0904162250j1745aefaxe9cd04576b7ad2c5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Robin Whittle Subject: Re: [rrg] v4 and/or v6 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:16:27 -0000 Hi Bill, >>> |Our recommendation should be applicable to IPv6. It may or >>> |may not also apply to IPv4, but at the very least must provide >>> |a path forward for IPv6. >>> >>>> ... If there was a consensus from that >>>> debate, it was that a solution process that failed to also resolve the >>>> problem for IPv6 would not be acceptable. > > The first calls for solving the problem for IPv6 and then considering > whether it can be backported to IPv4. The second calls for solving the > problem for IPv4 while avoiding any (unlikely) pitfalls that would > prevent an identical solution from working for IPv6. > > The difference is not all that subtle. Where are you reading sequentiality into either statement? I'm not finding any, and certainly none was implied. >> The RRG was chartered specifically to address the architectural issues. Not >> the implementation issues. > > That was, is and will continue to be a cop-out. An architecture is > dictated first and foremost by its achievability from the current > state of affairs. > > Does no good to design an interstellar starship if you can't build an > engine that moves it. First figure out how to build an engine. Then > use the knowledge you gained to design a better starship. Well, I think that we've amply demonstrated that we know how to build _a_ routing architecture. We're using it. And I think that we are all well aware that any possible solution must be achievable. We may all have varying opinions about what is and is not achievable and the means of achieving them, but in the end, we need something of pragmatic value. Some of us (admittedly not all) feel that working out the architecture prior to getting into the implementation detail is the prefered path. Having been down the reverse path, I have to tell you that "cut once then measure twice" is not a path to happiness. ;-) This is exactly what lead to the chartering of the RRG as a research effort, not an IETF WG and why we are chartered to work on architecture. The output of the group is not supposed to be implementation or engineering, specifically because that would be out of scope for the IRTF. Cop-out or not, that's what's in the charter. Regards, Tony From rw@firstpr.com.au Thu Apr 16 23:43:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D203A67F8 for ; Thu, 16 Apr 2009 23:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+3Mb+nYQm9H for ; Thu, 16 Apr 2009 23:43:43 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id A5D603A67F3 for ; Thu, 16 Apr 2009 23:43:42 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C04C3175D12; Fri, 17 Apr 2009 16:44:54 +1000 (EST) Message-ID: <49E82569.6090505@firstpr.com.au> Date: Fri, 17 Apr 2009 16:44:57 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] List of RRG rough consensus checks X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:43:44 -0000 Short version: List of messages in which I think rough consensus has been declared. draft-irtf-rrg-design-goals-01 is now 1 3/4 years old and resulted from very little discussion. I don't think consensus for this document was formally established. I made a bunch of suggestions after version 01 which were never discussed. Hi Tony, In a recent message "Re: Point of order" you wrote that you couldn't recall or find any record of a consensus judgement you made: http://www.ietf.org/mail-archive/web/rrg/current/msg04836.html I think it is best not to rely on memory. I suggest there be a list of consensus tests / votes / judgements on the wiki - both those which succeed and those which fail. You also wrote, to Bill: > Thank you for finding that. Your Google-fu is clearly stronger > than mine. ;-) As is your memory. ;-) Please note that this is > significantly different than "fix it for IPv6 first". > > As we did not, at the time, do an explicit consensus check on that > at the time, you're well within your bounds to call for a formal > check. You didn't take a vote, but you did write: > It's my judgement that we have rough consensus on this. and since you are a co-chair, that's it: rough consensus has been declared, with or without votes. It is not unreasonable for Bill, others and me to assume "fix IPv6 first" as an implication of: Our recommendation should be applicable to IPv6. It may or may not also apply to IPv4, but at the very least must provide a path forward for IPv6. Below my signature are links to messages in which I believe you made judgements about consensus. I don't remember any more. BTW, I am searching my RRG archive in Thunderbird - not using Google. I don't recall any consensus test resulting in no consensus - but you have made statements identifying things which have not been tested and which I agree we probably wouldn't or didn't have consensus on. I haven't listed these in general, but one message linked to below has a few such items. One notable thing we haven't got formal consensus on is the RRG's Design Goals (2007-07-08): http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01 Between the initial version 00 and the 01 version which you seem to be happy with, not counting your messages (or Heiner Hummel's which did not suggest improvements) I counted only 14 messages from 7 people. A week after your version 01, I wrote a bunch of suggestions: http://www.ietf.org/mail-archive/web/rrg/current/msg00203.html but they were never discussed. When Lars Eggert wrote in April 2008 questioning whether there was consensus on rrg-design-goals-01, you wrote: http://www.ietf.org/mail-archive/web/rrg/current/msg02117.html > I must admit that I don't follow the RRG very closely very > often (it requires a full-time commitment), but I don't > remember the discussion around this document resulting in > a consensus. There was some discussion, but not a great deal of contention. The comments did taper off, and that was taken as a sign of rough consensus by yours truly. ... We intentionally did not issue it as an RFC so that it could be kept open for further changes. Suggestions are still welcome. Maybe a vote now would reveal rough consensus in support of your version 01, but I think it resulted from very little discussion and it would be a good thing to revise now - or perhaps to replace with the new Recommendations document. - Robin 2007-06-21 BGP convergence and messaging ----------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg00166.html Robin Whittle wrote: > Then, maybe we wouldn't be so unhappy about BGP's > convergence rate and the number of messages - which are > two of the primary reasons we are having to invent a > new routing and addressing architecture. I don't believe that we have anything like consensus on that view. In fact, rough consensus (as of Prague) was quite the contrary: convergence and messaging _can_ be handled without architectural changes. http://www.ietf.org/mail-archive/web/rrg/current/msg00169.html Yes, the consensus was that the dynamics do NOT require architectural changes. This was based on the discussion during the routing area meeting. 2008-05-23 Mapping granularity ------------------------------ The original text is here: http://www.ietf.org/mail-archive/web/rrg/current/msg01870.html I didn't follow the discussion or find where the final text was that we supposedly achieved consensus on. http://www.ietf.org/mail-archive/web/rrg/current/msg02241.html There are a few things that we have consensus on and even then there are contingencies on that consensus. Specifically, for the mapping function, we have consensus that we should support host specific identifiers, as well as blocks. The next statement of consensus was retracted in a subsequent message: We also have consensus that mapping systems that there should be active mechanisms for dealing with overload situations. (See this message for various things for which there was no consensus.) 2008-06-14 Solution for IPv6 definitely, IPv4 maybe ---------------------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg04836.html Last week we did a consensus check on the following: |Our recommendation should be applicable to IPv6. It may or |may not also apply to IPv4, but at the very least must provide |a path forward for IPv6. It's my judgement that we have rough consensus on this. There is dissent, notably from Robin and Bill, but overall, it seems that we have rough consensus. http://www.ietf.org/mail-archive/web/rrg/current/msg02500.html Hi Bill, > I counted: > > 9 for > > 3 accept with the reservation that the IPv4 and IPv6 > solutions should be identical > > 4 offering other reservations > > 3 against > > That's a pretty weak consensus. Are you sure you want to > roll forward without seeking a statement that more than > a minority can agree to without reservations? I admit that it's rough consensus, for varying definitions of 'rough'. ;-) I wasn't trying to take a vote, just express my sense of where we stand. If it becomes critical at some point and folks feel that it's necessary, I'm more than happy to put things to a formal vote. 2008-09-04 End-user networks not required to "renumber" ------------------------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg03365.html Our consensus check on renumbering has been running for several weeks now and seems to have converged. The result is a clear consensus for no renumbering. Of 15 participants, 10 people voted exclusively for no renumbering, 2 voted for no renumbering and another option, and 3 voted for other options. I find this to be a clear (if rough) However, see below for confusion about what this meant. This message (Consequences of no renumbering...): http://www.ietf.org/mail-archive/web/rrg/current/msg03377.html indicates you considered "renumbering" includes the once-off renumbering to adopt the new namespace. I thought "renumbering" meant having to renumber every time the end-user network chose a new ISP: http://www.ietf.org/mail-archive/web/rrg/current/msg03393.html So I am not sure that this supposed consensus really means anything. This next message seems to indicate you understand "renumbering" in terms of when changing ISPs, not in terms of a one-off renumbering to adopt the scalable address space: http://www.ietf.org/mail-archive/web/rrg/current/msg04185.html > So can we just say that solutions above the network > layer (including shim6, sctp and multipath transport) > are simply out of scope: the RRG has decided not to > work on them. Anything else is speculation. Except that that's not exactly true. The RRG has not exactly declared them out of scope. So far, solutions that are above the networking layer require per-host renumbering, and we have consensus that those solutions are not acceptable. If someone figured out an architecture (possibly combining automated renumbering technology) that fixed things above the network layer in an acceptable fashion, we would definitely consider it. 2008-11-08 Mobility not on the agenda? -------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg03854.html In previous discussions, I believe that we came to the consensus that RRG is not trying to solve the full-blown mobility problem. The rate of dynamism is higher than what we'd really like to support in any mapping function. (I vaguely recall rejection of mobility as a goal, but I don't recall it being put to a consensus test. Your apparent assumption that the mapping would change whenever the MN gets a new CoA is not valid. No-one has suggested how a core-edge separation scheme could work like that - which involves the assumption that the ETR function is in the MN. Please see: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf for how a core-edge separation scheme can support a global approach to mobility, for IPv4 and IPv6, with mapping changes only when the MN moves 1000km or so.) 2009-04-15 Terminology: locator, identifier & address ----------------------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/msg04724.html The definitions being voted on. http://www.ietf.org/mail-archive/web/rrg/current/msg04781.html The poll has now closed. The ayes have it, 10 to 4 (71%), which is reasonably clear consensus. The definitions listed are hereby adopted. Also of interest: 2009-01-02 Notes on the consensus determination process http://www.ietf.org/mail-archive/web/rrg/current/msg04185.html From HeinerHummel@aol.com Fri Apr 17 01:43:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1FC3A6F30 for ; Fri, 17 Apr 2009 01:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTfHj8VxfPmh for ; Fri, 17 Apr 2009 01:43:17 -0700 (PDT) Received: from imo-m14.mx.aol.com (imo-m14.mx.aol.com [64.12.138.204]) by core3.amsl.com (Postfix) with ESMTP id 306603A6E0B for ; Fri, 17 Apr 2009 01:43:17 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imo-m14.mx.aol.com (v107.10) with ESMTP id RELAYIN4-549e84169360; Fri, 17 Apr 2009 04:44:25 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v40_r1.5.) id i.c45.303b6cce (39330); Fri, 17 Apr 2009 04:44:22 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 17 Apr 2009 04:44:22 EDT To: tony.li@tony.li, rw@firstpr.com.au MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1239957862" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 64.12.78.138 Cc: rrg@irtf.org Subject: Re: [rrg] v4 and/or v6 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:43:18 -0000 -------------------------------1239957862 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 17.04.2009 07:00:32 Westeurop=E4ische Normalzeit schrei= bt tony.li@tony.li: > One measure of the seriousness of the scalable routing problem is the > number of DFZ routes (BGP advertised prefixes). According to: > > http://bgp.potaroo.net/v6/v6rpt.html > > the IPv6 problem is about 1/256th that of the IPv4 problem. With > the current doubling time of 2 years, it will take 16 years before > the IPv6 scaling problem approximates that of today's IPv4 problem. This is clearly only a tactical view. The routing architectures of the= two are wholly identical (with perhaps v6 address allocation policies being worse). If anything, this is soley a measure of the lack of v6 deployment. In the strategic view, the v6 problem must (also?) be solved. The IAB RAWS report states that IPv6 will increase the scaling problem by= at least factor 4 :-( How much worse would the current situation be if the figures on _http://bgp.potaroo.net/v6/v6rpt.html_ (http://bgp.potaroo.net/v6/v6rpt.ht= ml) were inversely related to v4 and v6 ?! Heiner Heiner -------------------------------1239957862 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 17.04.2009 07:00:32 Westeurop=E4ische Normalzeit= schreibt tony.li@tony.li:
> One measure of the seriousness of the scalable routing problem is the
>= ; number of DFZ routes (BGP advertised prefixes).  According to:
&= gt;
>    http://bgp.potaroo.net/v6/v6rpt.html
>
&= gt; the IPv6 problem is about 1/256th that of the IPv4 problem.  = With
> the current doubling time of 2 years, it will take 16 years= before
> the IPv6 scaling problem approximates that of today's IPv= 4 problem.


This is clearly only a tactical view.  The rout= ing architectures of the
two are wholly identical (with perhaps v6 addre= ss allocation policies
being worse).  If anything, this is soley= a measure of the lack of v6
deployment.

In the strategic view,= the v6 problem must (also?) be solved.
The IAB RAWS report states that IPv6 will increase the scaling proble= m by at least factor 4 :-(
How much worse would the current situation be if the figures on http://bgp.potaroo.net/v6/v6= rpt.html 
were inversely related to v4 and v6 ?!
 
Heiner
 
Heiner
 -------------------------------1239957862-- From swb@employees.org Fri Apr 17 05:29:42 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219AA3A69A2 for ; Fri, 17 Apr 2009 05:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqlI8OfoH-07 for ; Fri, 17 Apr 2009 05:29:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 363BF3A67F4 for ; Fri, 17 Apr 2009 05:29:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,204,1238976000"; d="scan'208";a="42068545" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2009 12:30:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3HCUrij007461; Fri, 17 Apr 2009 08:30:53 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3HCUrEJ013010; Fri, 17 Apr 2009 12:30:53 GMT Date: Fri, 17 Apr 2009 08:30:45 -0400 From: Scott Brim To: Eliot Lear Message-ID: <20090417123045.GE90172@cisco.com> Mail-Followup-To: Scott Brim , Eliot Lear , William Herrin , rrg@irtf.org References: <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> <49E81A86.2070206@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E81A86.2070206@cisco.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:29:42 -0000 Well ... In IETF WGs the product is supposed to be useful, so if only a few people out of a group even care to express an opinion on a draft, it shouldn't go forward. In the IRTF, it all depends on what the group is trying to accomplish. I do not believe the RRG is just a pure, unbounded research group at this time. The RRG has been asked to contribute to solving the Internet's problems, not just generate ideas. We have a mission and reality is rushing past. Whether Tony is doing a good job or not isn't a question. Rather, the question is whether he is doing what meets the needs of the group as it exists, in order to accomplish the goals we have been given. At the end of a topic discussion, it should be clear to all whether a rough consensus deserves to be declared, even the losers. Since some people (including me) think the process could be handled better, let's make it very explicit. If we get agreement on that we can work out what's needed. From swb@employees.org Fri Apr 17 05:41:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9481428C154 for ; Fri, 17 Apr 2009 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLOjSqPqwR23 for ; Fri, 17 Apr 2009 05:41:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BE3353A6893 for ; Fri, 17 Apr 2009 05:41:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,204,1238976000"; d="scan'208";a="42142179" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2009 12:42:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3HCgXIn012241 for ; Fri, 17 Apr 2009 08:42:33 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3HCgXs8003665 for ; Fri, 17 Apr 2009 12:42:33 GMT Date: Fri, 17 Apr 2009 08:42:31 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090417124231.GF90172@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49DD6DD2.3060105@tony.li> <49E555A3.80502@tony.li> <3c3e3fca0904142151y3ed1d026jb0d27f122eeef1ff@mail.gmail.com> <49E57A71.5000901@tony.li> <3c3e3fca0904150856i6d34d53ag936fc5b986e274d9@mail.gmail.com> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80062.4010703@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E80062.4010703@firstpr.com.au> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Point of order - inadequate consensus process? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:41:21 -0000 As for v6 and v4, it depends on the scope of what you want to cover. "Interesting" endpoints like new sensors and wireless devices can be covered by v6-only approaches, but there will be a huge swathe of the Internet which will remain v4 for many years. They are not going away. If RRG ignores them, people will develop solutions for them, probably involving NAT, and they will do not sooner than later. If you tell them you have a v6 solution and you'll get to v4 "later", you've lost them. From swb@employees.org Fri Apr 17 05:59:15 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92D23A677C for ; Fri, 17 Apr 2009 05:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsl+NPP-0fpm for ; Fri, 17 Apr 2009 05:59:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 17EAC3A6C98 for ; Fri, 17 Apr 2009 05:59:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,204,1238976000"; d="scan'208";a="42143513" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2009 13:00:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3HD0Nfs000760 for ; Fri, 17 Apr 2009 09:00:23 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3HD0NjS020480 for ; Fri, 17 Apr 2009 13:00:23 GMT Date: Fri, 17 Apr 2009 09:00:13 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090417130013.GG90172@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E82569.6090505@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E82569.6090505@firstpr.com.au> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] List of RRG rough consensus checks X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 12:59:16 -0000 Excerpts from Robin Whittle on Fri, Apr 17, 2009 04:44:57PM +1000: > In a recent message "Re: Point of order" you wrote that you couldn't > recall or find any record of a consensus judgement you made: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04836.html > > I think it is best not to rely on memory. I suggest there be a list > of consensus tests / votes / judgements on the wiki - both those > which succeed and those which fail. +1. I already asked Tony to put the definitions results on the wiki. Some history would be good too. From tvest@pch.net Fri Apr 17 10:02:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D1C3A6C98 for ; Fri, 17 Apr 2009 10:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=1.604, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H35pJWWv6vP5 for ; Fri, 17 Apr 2009 10:02:12 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id DF2A93A6826 for ; Fri, 17 Apr 2009 10:02:11 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA06.westchester.pa.mail.comcast.net with comcast id gatF1b0040mv7h056h2l1Y; Fri, 17 Apr 2009 17:02:45 +0000 Received: from [172.16.1.3] ([24.125.119.245]) by OMTA11.westchester.pa.mail.comcast.net with comcast id gh3R1b00F5Hlxyo3Xh3RY5; Fri, 17 Apr 2009 17:03:26 +0000 From: Tom Vest To: Robin Whittle In-Reply-To: <49E7F77E.10805@firstpr.com.au> References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 13:03:24 -0400 X-Mailer: Apple Mail (2.930.3) Cc: John Zwiebel , RRG Subject: Re: [rrg] Constraints on a solution - "incrementally deployable" again X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 17:02:14 -0000 On Apr 16, 2009, at 11:29 PM, Robin Whittle wrote: > Short version: Slightly amended text, followed by a brief > reply to Tom Vest's message and some ideas > on how large mobile networks could be the > first large-scale IPv6 deployments. > > Changes indicated: *. > > > Constraints imposed by the need for voluntary adoption * > > A successful solution to the routing and addressing > scaling problem is tightly constrained by the need > for it to be voluntarily adopted, over a period of * > years, by the great majority of end-user networks * > of all sizes who want or need multihoming, inbound > traffic engineering and/or portability of their > address space between ISPs. Thanks once again Robin. My concerns would be fully covered if the above language were changed slightly... A successful solution to the routing and addressing scaling problem is tightly constrained by the need for it to be both accessible to, and voluntarily adopted by the great majority of established and aspiring end-user networks who want or need multihoming, inbound traffic engineering and/or portability of their address space between ISPs. Because this voluntary adoption may occur over a period of years, the benefits of the solution itself should be broadly accessible to all end-user networks, regardless of their size or legacy (pre-solution) protocol endowments. > Broadly speaking, this means that at the time of > introduction: > > 1 - The solution must provide immediate and > compelling benefits to the end-user networks > who adopt it, irrespective of how many other > networks have so far adopted it. 1 - The solution must provide immediate and compelling benefits to any new or existing end-user network that adopts it, irrespective of how many other networks have so far adopted it. > 2 - Therefore, it must provide multihoming, TE and > portability for the adopting networks in a > manner which fully supports communications with > all hosts - including all hosts in non-upgraded > networks. > > 3 - Therefore, the solution must be compatible with > all hosts (stacks and applications) and routers > in non-upgraded networks. > > 4 - The solution must be compatible with all > existing applications in the adopting networks. > > 5 - Although in principle, some or many host stacks > could be upgraded in the adopting networks, the > difficulties this presents means that a scalable > routing solution will only be widely enough > adopted on a voluntary basis if no such upgrades > are required in order for the new system to > provide compelling benefits. > > Firstly, there are difficulties in motivating > operating system / stack programmers to add and > test new facilities. Secondly there may be > costs and disruption for the adopting network in > upgrading the stacks. Thirdly, in many or most > end-user networks, some or many hosts will not > be amenable to stack upgrades due to them using > operating systems which are no longer being > maintained or developed. This is especially > the case for devices such as printers, routers > etc. which do not use one of the major operating > systems. > > 6 - The solution must be compatible with all > existing DFZ routers. (Unless it can be shown > that all DFZ routers can be upgraded - such as > via a software update - by the time of > introduction.) > > 7 - The solution must be attractive for the large > number of smaller networks who currently cannot > get PI space to do multihoming etc. Our goal is > not just to reduce the number of DFZ routes but > to enable a much larger number of end-user > networks to gain multihoming, TE and portability > than is currently possible. > > 8 - Ideally the solution will also be attractive for > most or all end-user networks who currently have > their own PI prefixes. This is firstly to > improve scaling by attracting those larger > end-user networks away from their current > conventional PI address space usage and secondly > to ensure that smaller networks which aspire to > be bigger in the future will perceive the new > kind of scalable end-user network address space > as suitable for their long-term needs. > > 9 - Ideally the new system should not compromise > security or performance compared to that of > current PI or PA techniques. Any degradation > in security, packet path lengths, end-to-end > packet transit times, packet loss rates and > general robustness etc. needs to be more than > compensated for by reduced costs and/or benefits > such as a more flexible and responsive > multihoming restoration capability than is > possible with current BGP techniques. > > 10 - The solution will probably not be widely enough * > adopted if it requires upgrades to the internal > routers of adopting networks - except perhaps in > small networks such as SOHO where one or a few * > inexpensive routers need upgrading anyway to * > perform ITR and ETR etc. functions. > > In the longer term - in the years and decades to > come - upgrades to DFZ routers, to ISP and end-user > network internal routers and to host stacks can be > made without significant cost or inconvenience and > may allow enhanced performance for the new system. > > > [Optional footnote if most people like it.] > > As a footnote, it should be acknowledged that the * > constraints as described above seem to involve great * > difficulty in providing any Internet service at all * > - based on scalable routing or not - beyond IPv4. * > > The above text attempts to summarise the real-world > constraints on a scalable routing solution. It > appears that these constraints create a very high > barrier to migration of significant numbers of > existing end-user networks from IPv4 to an IPv6 > service, either with or without retaining their > IPv4 address space. > > It follows that even if IPv6 had a scalable routing > solution, that the barriers to mass IPv6 adoption > would remain high. A potential exception may be * > mobile devices, whose functionality may not be as * > dependent on full IPv4 connectivity as is the case * > for most hosts today. [See note below.] * > > Our goal is to solve the routing scaling problem > in both the IPv4 and IPv6 Internets - and for the > foreseeable future, the problem only manifests in > the IPv4 Internet. I would prefer something along the lines of: Our goal is to solve the routing scaling problem in in a manner that will accommodate growth of both IPv4 and IPv6 Internets. Because of the looming exhaustion of unallocated IPv4 addresses, this dual protocol orientation represents the narrowest possible scope that any candidate solution must address in order to have any chance of being successful. > A good IPv4 scalable routing solution may enable * > finer divisions in the address space than is * > practical with current BGP techniques and so may * > contribute to a significantly higher number of * > end-user networks being able to use the available * > space. Nonetheless, the finite limits of IPv4 * > address space remain a serious concern, especially * > for newly established ISPs and end-user networks. * > > On this basis, it would be desirable if a * > scalable routing solution, in some way yet to be * > determined, facilitated adoption of an alternative * > to IPv4 - such as IPv6 - which is a more promising * > basis for accommodating billions of hosts, many of * > which are expected to be mobile devices. * ***** > Note on IPv6 mobile devices. I am envisaging a situation, such as > in China or other countries, where cellphones and mobile PCs etc. > need an IP address in order for various voice and messaging services > to be provided, and for direct communications between devices in the > same or similar mobile networks. It's not an unimaginable scenario, but if China was truly hampered by a shortage of public IP addresses, that problem would have manifested itself years ago, in the course of extending non-mobile, IPv4-based Internet access. For a variety of reasons, China instead chose to develop alternative approaches for solving this problem -- mechanisms that are now coming to be known more widely as "carrier grade NATs." Scarcity of IPv4 was almost certainly not the primary factor driving this choice, but I would say that among the less obvious considerations, the commercial/competitive advantages of operator- imposed addressing were at least if not more important than more widely remarked-upon concerns about domestic order and state security. Thus, I would suggest that the China case tends to point to a quite different future than the one you suggest -- one that rather usefully illuminates the kind of concerns that I've tried to articulate in this exchange. (for the record: I had the unique privilege of playing a leading role in the design, deployment, activation, and shortly thereafter the dismantling of the only international joint venture Internet access service in China -- the ill-fated "Legend-AOL"... an absolute commercial disaster, but an amazing/unique learning experience for me personally). > The huge number of such mobile > devices precludes giving each an IPv4 global unicast address, and for > many purposes (but not global IPv4 connectivity) an IPv6 address may > work fine. > > With a sufficiently large number of cellphones etc. on IPv6 like > this, it would be profitable to deploy many commercial IPv6 servers > to provide "content" for these devices would also be. This would > make non-mobile IPv6-only services more attractive. This "mobile > first" scenario for widespread IPv6 adoption is the most likely one I > can imagine. A less likely scenario is certain countries providing > IPv6 only DSL etc. services to customers who cannot access any IPv4 > service. I agree with you that it's the most likely of all the plausible scenarios that one might imagine today. Unfortunately, I think that it too is highly unlikely. Not sure if it was your intent to incorporate the mobile scenario in the footnote, but I would recommend leaving it out. > Hi Tom, > > I will respond more fully to your thoughtful message separately, > probably with a subject like "Breaking IPv4's constraints". I'll look forward to that... > The main body of text above is intended to be a statement of fact > about the major constraints which arise from our reliance on > widespread voluntary adoption. This is to complement statements of > the functional goals of the solution - such as to provide a new form > of address space for end-user networks which scalably provides > multihoming, inbound TE and portability. (Also, I think, support for > global mobility.) > > Perhaps if enough people like this text - or some improved version of > it - we could add it to: > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation > > > I am trying to keep it brief, but would like some kind of footnote to > at least acknowledge the inherently IPv4-centric nature of these > constraints - since IPv4 is not mentioned specifically in the main > text. > > While this text embodies what I always meant by "incremental > deployability" I am not trying to define this term. You wrote > several times about my text as if it was to become "RRG "incremental > deployability" recommendations". I appreciate the clarification -- was not really clear about the "normative" content of the deployability text, apart from the obvious (i.e., no coercive authority, etc. -- already covered). In any case, any apparent mischaracterizations were the product of uncertainty, and not of any positive assumptions on my part that are inconsistent with your response... i.e., please consider them to be idiosyncrasies of phrasing with no particular relevance. > I want it to be a concise but reasonably complete statement of some > constraints which most of us agree are are real-world limitations we > must work within. > > Only by implication is it a "recommendation" - for how to evaluate > potential solutions: proposals, architectures, candidate designs or > whatever. > > I sense you are very concerned about the difficulty of establishing > Internet services beyond the finite constraints of IPv4. That is fair to say! > I think there's nothing which could be written now which would > contribute to a solution to this problem. I would hesitate to reach that conclusion, in part for the following reason(s): 1. Any future RRG "final product" is almost certain to come after IPv4 exhaustion and privatization (de facto and/or de jure). 2. If, after that point, RRG solutions are primarily or exclusively oriented toward IPv4 scaling/perpetuation, that will effectively put RRG in the novel role of maintainer of private/proprietary resources -- "proprietary" in a sense not unlike that in which specific branded commercial hardware or software is proprietary. The owners of the new proprietary resources may be numerous and widely distributed, but it will forevermore be a closed group, with something like "membership by invitation only." 3. Over the past decade or so, the population of routing system participants has been very dynamic, with appx. 5-10% growth in the form of new entrants each year (based on RIR "initial allocation" transactions involving IPv4) and a somewhat lower (and much harder to estimate) rate of departures due to M&A and/or termination of service.* After IPv4 runout or privatization (whichever comes first), the new add rate is likely to slow down to a trickle, leaving an ever- growing population of frustrated would-have-been routing system participants. At the same time, the drop rate is likely to increase as some large, well-heeled operators accelerate their pursuit of low- hanging IPv4 acquisition targets. Overall, this change is going to represent a radical, unprecedented break with the Internet growth processes of the last two decades. I don't think that it will take long for the general public to notice, and react. If and when all of this comes to pass, "open addressing" will quickly achieve, at least, the same level salience/urgency as "scalable routing" in the overall RRG problem space. In anticipation of (at the very least) this possibility, I would suggest that it would be prudent for RRG to capitalize on every possible opportunity to reaffirm its commitment to delivering a solution to both problems, starting now. Thanks again for being receptive to my troublesome and somewhat belated expressions of concern... Tom *(In the US at least, these routing system population dynamics almost exactly parallel those of the commercial banking sector). From wherrin@gmail.com Fri Apr 17 11:18:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58F828C185 for ; Fri, 17 Apr 2009 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aayBwqic1lvB for ; Fri, 17 Apr 2009 11:18:05 -0700 (PDT) Received: from mail-qy0-f115.google.com (mail-qy0-f115.google.com [209.85.221.115]) by core3.amsl.com (Postfix) with ESMTP id A4AB928C198 for ; Fri, 17 Apr 2009 11:18:05 -0700 (PDT) Received: by qyk13 with SMTP id 13so2182913qyk.15 for ; Fri, 17 Apr 2009 11:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=3Cbz/sk3qjWMUJ6MNHGXIiT2mf2PFCgnBt0AIf3jQ7U=; b=Nf/CSet8BNc7Y3VaPDsY8YQyjtt7+X4/IR1WoiXCGTV7pM6oACFH5FcPc50lPlXcpD uJlTzul1MNZpzUVegheIzWs7K6Kzxt9YblpvtFvnmRa+bjoRsDnpBKCdckGD8qgpEMQj Sdn5irP98YkkK3I1pTpW8tOMnUllUf19srU0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=R6tp3cAL8p1i92VCfjKQmHyfJXTwHEKzjIDz5SXh6rMgr7gHlpFeXibh7+hKgqVdYq G9ASqD7+/kQ73dTrdBOaQ9vb/9r827WKf6dLZ1o3Keqa5rDuShn49AR0SwMztKumbMba 1zntAPGqTi8uDCRZg8YN++nQvOG0xtzknSVEk= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.224.89.74 with SMTP id d10mr4145048qam.202.1239992353557; Fri, 17 Apr 2009 11:19:13 -0700 (PDT) In-Reply-To: <49E81A86.2070206@cisco.com> References: <49DD6DD2.3060105@tony.li> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> <49E81A86.2070206@cisco.com> Date: Fri, 17 Apr 2009 14:19:10 -0400 X-Google-Sender-Auth: 473dce98ddda60f7 Message-ID: <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> From: William Herrin To: rrg@irtf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:18:06 -0000 On Fri, Apr 17, 2009 at 1:58 AM, Eliot Lear wrote: > I question whether rough > consensus is even a good idea in a research environment.=A0 That a few pe= ople > agree on terms is sufficient for THEM to collaborate together.=A0 That ot= hers > do not agree may be sufficient for those others to collaborate, and let t= he > best research win. Eliot, That would be an unrecorded vote against an RRG-wide definition of locator and identifier. You propose, rather, that they be given meanings only within the context of the group collaborations in which they're used. Your statement above proves my point: There was no consensus. On Fri, Apr 17, 2009 at 8:30 AM, Scott Brim wrote: > At > the end of a topic discussion, it should be clear to all whether a > rough consensus deserves to be declared, even the losers. Right here we have an insightful explanation of the concept we call "consen= sus." On Fri, Apr 17, 2009 at 1:07 AM, Tony Li wrote: > The IETF (and RRG) seek _rough_ consensus. The fact that they do so by a > show of hands, a hum, or a doodle poll is merely a matter of mechanism. > It's all just voting. http://collaborationzone.com/consensus-isnt-taking-a-vote/ "Sounds like voting to me. Same process, same outcome: An idea is presented, there is discussion, the majority =93wins,=94 and there is a disaffected minority who agrees to =93live with=94 the decision - until the next chance they get to change it. Which means you=92ll get to make this decision again=85and again=85and again. And that=92s pretty much the opposite of a decision made by consensus." Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From swb@employees.org Fri Apr 17 11:35:15 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C55128C198 for ; Fri, 17 Apr 2009 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prLR+keCdlHB for ; Fri, 17 Apr 2009 11:35:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 22B103A681D for ; Fri, 17 Apr 2009 11:35:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,205,1238976000"; d="scan'208";a="42186511" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2009 18:36:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3HIaOlc009774 for ; Fri, 17 Apr 2009 14:36:24 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3HIaN5v014768 for ; Fri, 17 Apr 2009 18:36:23 GMT Date: Fri, 17 Apr 2009 14:36:20 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090417183620.GP90172@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> <49E81A86.2070206@cisco.com> <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:35:15 -0000 Excerpts from William Herrin on Fri, Apr 17, 2009 02:19:10PM -0400: > On Fri, Apr 17, 2009 at 1:58 AM, Eliot Lear wrote: > > I question whether rough > > consensus is even a good idea in a research environment.  That a few people > > agree on terms is sufficient for THEM to collaborate together.  That others > > do not agree may be sufficient for those others to collaborate, and let the > > best research win. This is different from a pure research environment. We have goals, even milestones. > On Fri, Apr 17, 2009 at 1:07 AM, Tony Li wrote: > > The IETF (and RRG) seek _rough_ consensus. The fact that they do so by a > > show of hands, a hum, or a doodle poll is merely a matter of mechanism. > > It's all just voting. > > http://collaborationzone.com/consensus-isnt-taking-a-vote/ > > "Sounds like voting to me. Same process, same outcome: An idea is > presented, there is discussion, the majority “wins,†and there is a > disaffected minority who agrees to “live with†the decision - until > the next chance they get to change it. Which means you’ll get to make > this decision again…and again…and again. And that’s pretty much the > opposite of a decision made by consensus." Well, here I'll disagree. Classic consensus is one of the few outcomes we shouldn't bother pursuing. We can produce: - one or more architectural possibilities, fully explored, which the IETF can then evaluate on its terms. However, these shouldn't just be whatever ideas people want to produce (à la what Eliot said), since the RRG is in a special situation right now. The RRG should have ROUGH consensus that they are worth taking to the IETF for further work. Sometimes these ideas take themselves to the IETF and ask the IETF's opinion directly and the RRG doesn't have to make a decision. - a framework for the IETF to use when proceeding (this seems to be what Tony's recommendation draft is heading toward). - critiques of ideas that have been brought up elsewhere, not in RRG, in terms of the above. From dow.street@linquest.com Fri Apr 17 11:48:32 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56FB3A6E35 for ; Fri, 17 Apr 2009 11:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVpx50yVuXJr for ; Fri, 17 Apr 2009 11:48:31 -0700 (PDT) Received: from smtp165.dfw.emailsrvr.com (smtp165.dfw.emailsrvr.com [67.192.241.165]) by core3.amsl.com (Postfix) with ESMTP id A94A63A6872 for ; Fri, 17 Apr 2009 11:48:31 -0700 (PDT) Received: from relay6.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay6.relay.dfw.mlsrvr.com (SMTP Server) with ESMTPS id F13A92FFFA; Fri, 17 Apr 2009 14:49:44 -0400 (EDT) Received: by relay6.relay.dfw.mlsrvr.com (Authenticated sender: dow.street-AT-linquest.com) with ESMTPSA id 9757D2FFF5; Fri, 17 Apr 2009 14:49:44 -0400 (EDT) Message-Id: <87E5EA46-E3E9-4689-AE6E-796E8DC2465E@linquest.com> From: Dow Street To: William Herrin In-Reply-To: <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 11:49:43 -0700 References: <49DD6DD2.3060105@tony.li> <49E64D15.6030903@tony.li> <3c3e3fca0904160453i6e00e450yb1203b5e94a1ab92@mail.gmail.com> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> <49E81A86.2070206@cisco.com> <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 18:48:32 -0000 William, Is your primary concern: a. that the polled definition of locator is unclear b. that the polled definition is clear, but you think some other =20 (clearly defined) thing should be called a "locator" instead c. that the consensus approach / process is insufficient, independent =20= of this particular definition Thanks, Dow On Apr 17, 2009, at 11:19 AM, William Herrin wrote: > On Fri, Apr 17, 2009 at 1:58 AM, Eliot Lear wrote: >> I question whether rough >> consensus is even a good idea in a research environment. That a =20 >> few people >> agree on terms is sufficient for THEM to collaborate together. =20 >> That others >> do not agree may be sufficient for those others to collaborate, and =20= >> let the >> best research win. > > Eliot, > > That would be an unrecorded vote against an RRG-wide definition of > locator and identifier. You propose, rather, that they be given > meanings only within the context of the group collaborations in which > they're used. > > Your statement above proves my point: There was no consensus. > > > On Fri, Apr 17, 2009 at 8:30 AM, Scott Brim wrote: >> At >> the end of a topic discussion, it should be clear to all whether a >> rough consensus deserves to be declared, even the losers. > > Right here we have an insightful explanation of the concept we call =20= > "consensus." > > > On Fri, Apr 17, 2009 at 1:07 AM, Tony Li wrote: >> The IETF (and RRG) seek _rough_ consensus. The fact that they do =20 >> so by a >> show of hands, a hum, or a doodle poll is merely a matter of =20 >> mechanism. >> It's all just voting. > > http://collaborationzone.com/consensus-isnt-taking-a-vote/ > > "Sounds like voting to me. Same process, same outcome: An idea is > presented, there is discussion, the majority =93wins,=94 and there is = a > disaffected minority who agrees to =93live with=94 the decision - = until > the next chance they get to change it. Which means you=92ll get to = make > this decision again=85and again=85and again. And that=92s pretty much = the > opposite of a decision made by consensus." > > > Regards, > Bill Herrin > > --=20 > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From rja@extremenetworks.com Fri Apr 17 19:02:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0E93A6A91 for ; Fri, 17 Apr 2009 19:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtvFZBnPOP-y for ; Fri, 17 Apr 2009 19:02:18 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id C3BDC3A6A2F for ; Fri, 17 Apr 2009 19:02:18 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI9001ATPA10OU3@vms173003.mailsrvcs.net> for rrg@irtf.org; Fri, 17 Apr 2009 18:01:18 -0500 (CDT) Message-id: From: RJ Atkinson To: "rrg@irtf.org RG" Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 19:01:13 -0400 X-Mailer: Apple Mail (2.930.3) Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 02:02:19 -0000 Folks, Eliot is quite right. This is *not* the IETF and so IETF rules, IETF processes, and IETF mantras (e.g. talk about running code) simply do NOT apply HERE. Folks that dislike the current Chairs approach don't have to participate here. Folks who do participate here are required by IRTF rules to respect the Chairs collective efforts to move things along, whether or not those folks like or dislike particular outcomes along the way. For what its worth, I think the RG Chairs are doing a fine job in dealing with a complex set of issues. Yours, Ran rja@extremenetworks.com PS: Folks who think the IETF is likely to simply take any IRTF RG's suggestions and blindly adopt them are wildly confused. History is shown that is not a likely outcome. From wherrin@gmail.com Fri Apr 17 20:31:05 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BF13A69FA for ; Fri, 17 Apr 2009 20:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO-SNDTxSpku for ; Fri, 17 Apr 2009 20:31:04 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 20F373A6B9F for ; Fri, 17 Apr 2009 20:30:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so817521ywh.37 for ; Fri, 17 Apr 2009 20:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=zB5oJ7nm7NDE5ybOYzPTcBRxTBxNw1SjHg9Re2HxAlI=; b=DIZpaartPxOoo4G2HF/bFvkq2e0G6POPNOfUdHCw/ET8cBqKWsEFPsSqZpaGb0XQ2z fZFkeZnPK0z83MmXVT2CqmBXs+G6UdPOnCXgOaOWndKn/qp4QilvUF8jKR3547gdn361 8TUpOYgeSNI7izUXcL+SnxYsB3Vk7++1fkH3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=yDS/7f/x0GqKZeYQ0c/STErIU9y8Kciamj7/Cky4d8LBv7lWl8+64f5pj0ubySPx6+ Z9b75BZfiRQt6Nqbu0dsWMSOmFFRYQLB/Fsookug7vDQJXf2aybqeJC8lbRRFNFLUYpb esrMn9ocJX3eYf9ESYCETFhU3zhv/n5Lw/JMI= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.174.13 with SMTP id w13mr3797453ane.53.1240025531651; Fri, 17 Apr 2009 20:32:11 -0700 (PDT) In-Reply-To: <87E5EA46-E3E9-4689-AE6E-796E8DC2465E@linquest.com> References: <49DD6DD2.3060105@tony.li> <49E74B62.3020700@joelhalpern.com> <3c3e3fca0904161944i410db422j40c2365b1a265b87@mail.gmail.com> <49E80E9B.2040606@cisco.com> <3c3e3fca0904162228h7dfa79bbo5aa1f6e3245ce6cc@mail.gmail.com> <49E8168D.7030006@cisco.com> <3c3e3fca0904162256l5bf4431es728b0b6190cf9fc0@mail.gmail.com> <49E81A86.2070206@cisco.com> <3c3e3fca0904171119tae23dd2uc3779bef74ee46f2@mail.gmail.com> <87E5EA46-E3E9-4689-AE6E-796E8DC2465E@linquest.com> Date: Fri, 17 Apr 2009 23:32:11 -0400 X-Google-Sender-Auth: b6e259120fbedd57 Message-ID: <3c3e3fca0904172032r52735068rf036d87301b69d14@mail.gmail.com> From: William Herrin To: Dow Street Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Point of order X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 03:31:05 -0000 On Fri, Apr 17, 2009 at 2:49 PM, Dow Street wrote= : > b. =A0that the polled definition is clear, but you think some other (clea= rly > defined) thing should be called a "locator" instead > c. =A0that the consensus approach / process is insufficient, independent = of > this particular definition Hi Dow, I'm criticizing Tony because he described his definitions of "locator" and "identifier" as a group consensus when it was very obviously anything but. Let me put it this way: I can live with it If Tony goes back to the IAB and says, "For convenience, we voted to assign the following meanings to the words identifier and locator." I have little use for the definitions assigned, but I can find other words. What bugs the heck out of me is the prospect that Tony goes back to the IAB and says, "It is the consensus of the RRG that locator and identifier mean..." or "We determined that locator and identifier mean..." That'd be dishonest. It badly misrepresents the situation and it misrepresents my own participation in the process. Now, I don't agree with the definitions. I also think a real consensus process, while more difficult to accomplish, would be more helpful than a vote. But my tirade is about the misrepresentation of the vote and its results. It was a vote, not a consensus check, and the results do not reflect a general consensus of the group. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Fri Apr 17 21:02:13 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D223A6B33 for ; Fri, 17 Apr 2009 21:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixjvnfBgIIMq for ; Fri, 17 Apr 2009 21:02:12 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 789A23A67E6 for ; Fri, 17 Apr 2009 21:02:12 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id grtH1b0080QkzPwACs3T1j; Sat, 18 Apr 2009 04:03:27 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id gs3S1b0053L8a8Q8Ns3SQR; Sat, 18 Apr 2009 04:03:27 +0000 Message-ID: <49E950FD.5030106@tony.li> Date: Fri, 17 Apr 2009 21:03:09 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim , Tony Li , rrg@irtf.org References: <49E559E0.2090302@tony.li> <20090415184037.GA47183@cisco.com> In-Reply-To: <20090415184037.GA47183@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 04:02:13 -0000 Hi Scott, > Second, what is the purpose of the exercise? I suspect that every > practical use case knows what properties it needs already for its > various identifiers. If you look at the requirements of a specific > use case the properties fall out. One possible purpose I could see > (and one I was trying to get at in my slides) would be to reduce the > number of identifiers we think we need. What do you have in mind? So, at a high order, I'm hoping to make forward progress. ;-) More specifically, if we can converge on what properties we would like identifiers to have, it might help to constrain the solution space. > First, there are a different uses for identifiers and each has > different requirements. Before we can talk about properties for > "identifiers" in general we need to separate out which particular uses > we are talking about. For example, are you including discovery > starting from FQDNs? Kerberos identifiers for auth/auth? I'm trying to stay independent of any particular use case and look at the abstract properties that we'd like to have in a locator/ID split. To help simplify the discussion (I hope ;-), I'll certainly stipulate that every solution is certainly going to have a number of identifiers. I think we're most interested in the identifiers that correspond to locators. Tony From tony.li@tony.li Fri Apr 17 22:31:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F3E3A6BD1 for ; Fri, 17 Apr 2009 22:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPjlpT+aU4Qq for ; Fri, 17 Apr 2009 22:31:05 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id D685A3A6ACA for ; Fri, 17 Apr 2009 22:30:52 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id grtl1b00217UAYkAAtY77D; Sat, 18 Apr 2009 05:32:07 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id gtY61b0093L8a8Q8ZtY7u4; Sat, 18 Apr 2009 05:32:07 +0000 Message-ID: <49E965C0.5020503@tony.li> Date: Fri, 17 Apr 2009 22:31:44 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian E Carpenter References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> In-Reply-To: <49E66B2E.3000503@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 05:31:06 -0000 >> - stable, at discretion of owner > > I'd say: must have a defined lifetime, set by the owner, which may be infinite. I like this. How about: "... and can be terminated at any time at the owner's discretion." >> - unambiguous > > I'd say: must have a defined scope within which they are unique and unambiguous. > The scope may be universal. [Now define 'universal'. It's not so easy.] How about 'global' instead? Do we really want local identifiers? Tony From rw@firstpr.com.au Sun Apr 19 08:03:22 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EFB3A6D76 for ; Sun, 19 Apr 2009 08:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45UiDOTDhkGK for ; Sun, 19 Apr 2009 08:03:21 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 615FA3A6D78 for ; Sun, 19 Apr 2009 08:03:21 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 69ACC1759D4; Mon, 20 Apr 2009 01:04:28 +1000 (EST) Message-ID: <49EB3D82.3020306@firstpr.com.au> Date: Mon, 20 Apr 2009 01:04:34 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] Constraints due to the need for voluntary adoption X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 15:03:22 -0000 The list of constraints due to the need for voluntary adoption is at: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ I hope people will comment on this, suggest improvements etc. Tom Vest expressed his support for an earlier version, and I have and I think Joel Halpern agrees with at least some of it. Three other people expressed their support for an earlier single-paragraph statement which I expanded to create the current draft list. There is a changelog mentioning the minor changes to the previous text. I added two new paragraphs at the end, the first of which I hope at least partially reflects Tom Vest's concerns: The benefits resulting from the best imaginable solution for IPv4 may be limited by shortage of IPv4 space and resulting difficulties for new networks in gaining this space. While no such restrictions exist with IPv6, constraints similar to 2, 3, 4 and 5 are likely to continue to be a barrier to widespread migration to IPv6. The above constraints generally apply for IPv4 when end-user networks already have IPv4 space and need to retain full connectivity to all, or almost all, existing hosts. They may not apply in other circumstances, such as if IPv4 space is unobtainable and/or if the functionality of devices in a newly established end-user network does not depend so strongly on connectivity to IPv4 hosts and/or if the hosts in the new network are all purpose built for it. Development of a large IPv6-based cellphone network may exemplify these circumstances. There is also a new footnote which discusses various questions which may arise regarding the list, but which I think need not be mentioned in the list itself. I will reply to Tom's most recent message in a new thread: Scalable solution hitting IPv4's limits - Robin From rw@firstpr.com.au Sun Apr 19 08:24:56 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC19428C214 for ; Sun, 19 Apr 2009 08:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_50=0.001, FB_NO_MORE_ADS=1.174, GB_I_INVITATION=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9smLPaAoCwbd for ; Sun, 19 Apr 2009 08:24:53 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 520C43A6810 for ; Sun, 19 Apr 2009 08:24:52 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id B27921759D4; Mon, 20 Apr 2009 01:26:06 +1000 (EST) Message-ID: <49EB4294.2070601@firstpr.com.au> Date: Mon, 20 Apr 2009 01:26:12 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] Scalable solution hitting IPv4's limits X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 15:24:56 -0000 Short version: Long reply to Tom Vest, discussing his concerns about IPv4, even with a scalable routing solution, hitting the limits of its address range and so causing difficulties for aspiring new ISPs. The same issues are covered more concisely in the footnote to the draft list of constraints. Also, some discussion of the TTR Mobility approach in the hope that people will read it and so not be so alarmed at the mention of mobility with scalable routing. I first described this in June 2007 and this full description, with diagrams, has been available for 8 months: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf Hi Tom, The list of constraints due to the need for voluntary adoption is at: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ I have added a second last paragraph which mentions some of your concerns. As I discuss here and in the Footnote at the above page, I think your concerns are important but that there is no need to change the list itself. I intend it to be a factual list of constraints we can all agree to - even if some of them seem to be at odds with a truly satisfactory outcome in terms of endless address space and the avoidance of barriers to new entrants. Here is a reply to your message in the "Constraints on a solution ..." thread. Thanks again for your thoughtful discussion and constructive suggestions. You wrote: >> Constraints imposed by the need for voluntary adoption * >> >> A successful solution to the routing and addressing >> scaling problem is tightly constrained by the need >> for it to be voluntarily adopted, over a period of * >> years, by the great majority of end-user networks * >> of all sizes who want or need multihoming, inbound >> traffic engineering and/or portability of their >> address space between ISPs. > > Thanks once again Robin. > > My concerns would be fully covered if the above language were changed > slightly... > > A successful solution to the routing and addressing > scaling problem is tightly constrained by the need > for it to be both accessible to, and voluntarily adopted by > the great majority of established and aspiring end-user > networks who want or need multihoming, inbound > traffic engineering and/or portability of their address > space between ISPs. Because this voluntary adoption may > occur over a period of years, the benefits of the solution > itself should be broadly accessible to all end-user networks, > regardless of their size or legacy (pre-solution) protocol > endowments. I have amended the text to: be both accessible to, and voluntarily adopted by and I hope you will find that the new second-last paragraph at least partially mentions your concerns. The benefits resulting from the best imaginable solution for IPv4 may be limited by shortage of IPv4 space and resulting difficulties for new networks in gaining this space. While no such restrictions exist with IPv6, constraints similar to 2, 3, 4 and 5 are likely to continue to be a barrier to widespread migration to IPv6. I want the list of constraints to be a terse description of things we all (ideally) agree are true. The focus is on what is needed for end-user networks and their ISPs to adopt the solution. As a statement of fact, this text does not assume that there is a solution which will meet all these constraints. I think there will be solutions which meet them all in IPv4 - but I agree that during ' adoption and in the decades to come, no matter how ubiquitously the scalable routing solution is adopted and how well it works, the address space shortage is likely to limit the IPv4 Internet's capacity to provide multihoming etc. for all end-user networks which want it. This includes especially those end-user networks which are to be established in the future and/or those whose Internet access would benefit from newly established ISPs who, in practice, may find it difficult to gain the address space they need. I added another paragraph at the end: The above constraints generally apply for IPv4 when end-user networks already have IPv4 space and need to retain full connectivity to all, or almost all, existing hosts. They may not apply in other circumstances, such as if IPv4 space is unobtainable and/or if the functionality of devices in a newly established end-user network does not depend so strongly on connectivity to IPv4 hosts and/or if the hosts in the new network are all purpose built for it. Development of a large IPv6-based cellphone network may exemplify these circumstances. which summarises the example I give in the Footnote about how I can imagine a newly established IPv6-based cell-phone network not being so affected by all these constraints. >> Broadly speaking, this means that at the time of >> introduction: >> >> 1 - The solution must provide immediate and >> compelling benefits to the end-user networks >> who adopt it, irrespective of how many other >> networks have so far adopted it. > > > 1 - The solution must provide immediate and > compelling benefits to any new or existing << > end-user network that adopts it, irrespective > of how many other networks have so far adopted > it. Thanks, I have used this suggestion. Regarding the Footnote, which I have completely rewritten, you wrote: >> Our goal is to solve the routing scaling problem >> in both the IPv4 and IPv6 Internets - and for the >> foreseeable future, the problem only manifests in >> the IPv4 Internet. Similar text is in the new Footnote. > I would prefer something along the lines of: > > Our goal is to solve the routing scaling problem in > in a manner that will accommodate growth of both IPv4 > and IPv6 Internets. Because of the looming exhaustion of > unallocated IPv4 addresses, this dual protocol orientation > represents the narrowest possible scope that any candidate > solution must address in order to have any chance of being > successful. I don't agree with this, for a number of reasons. Firstly, I don't assume that the only alternative to IPv4 is IPv6. Secondly I don't assume there is a solution to the IPv4 address shortage which enables most users to transition to some new protocol without disruption and costs they would in fact accept. I think most end-users would not accept having to abandon applications which work fine on IPv4 or having to use a network which did not give them full access to all hosts, most of which are on IPv4. Can you propose a solution which achieves the goals you want to set for any scalable routing solution? I believe the routing scalability problem can be solved for IPv4 and IPv6 separately, but I am yet to see how any system, involving scalable routing or not, could provide for mass adoption of IPv6 or some other protocol or disruption-free migration to that from IPv4. I think you have argued that a scalable routing solution for IPv4 will not succeed fully if at some point in the future, there is no more address space to accommodate new end-user networks. My counter argument is that in that case, those end-user networks wouldn't be able to get address space they would use in an unscalable way - so the real problem is address shortage and not a deficiency in routing scalability. I think the IPv4 address shortage - in absolute terms and/or in terms of overly concentrated control of usable space in the hands of established networks - will be the biggest limitation on the successful development of the Internet even if the scalable routing problem is fixed. I think IPv4 address exhaustion and fears of (to new entrants) unfair address distribution outcomes is a far better understood problem than the routing scaling problem. Ivip is well suited to making the very best use of IPv4 space - for instance by giving networks 1, 2, 3, 4, 5 or whatever number of contiguous IPv4 addresses they need. I think the most numerous types of end-user networks will be those which use one or a few IPv4 addresses. So theoretically we could have a billion such networks occupying a billion or two addresses with close to 100% utilization efficiency. I think LISP or APT could also be used in much the same way, although their EIDs are restricted to prefixes of 1, 2, 4, 8 etc. IPv4 addresses. The designers of neither proposal seem to be very interested in networks with a handful of addresses. I think the LISP designers in particular are heavily focused on substantial end-user networks which have 256 and more IPv4 addresses. Yet the whole benefit of LISP-ALT is its ability to handle essentially limitless numbers of EIDs and therefore end-user networks. I think LISP-NERD, the fastest and simplest of the proposals, could easily scale to 10 or 20 million EIDs. Yet it is impossible for me to imagine more than this number of fixed (non-mobile) end-user networks ever needing multihoming. With a population of 10B people, 10M end-user networks would be one for every 1000 people. I just cant imagine any more than this number of fixed networks having such a desire for multihoming to get two physically separate links and ISPs. Nor can I imagine more than this number of fixed end-user networks needing portability. So if LISP-ALT is going to be better than LISP-NERD, it is only going to be because LISP-NERD can't scale to the number of EIDs which LISP-ALT can handle with ease. (LISP-NERD, APT and Ivip, is far superior to LISP-ALT or TRRP because these first three involve little or no delay to any packets while the latter two involve often significant delays to initial packets due to the delays and perhaps packet losses inherent in their completely decentralised global query server networks. My point is that if LISP-ALT is to be better than LISP-NERD, then it must be due to LISP-ALT supporting mobile end-user networks. It can do this, with the TTR Mobility approach - as long as the designers accept that this involves the ETR is separate from the end-user network (they currently assume it within the end-user network) and if they accept the ETR not even being in the access network - it is in a network of the TTR company (or some network of an ISP which is where the TTR company has its TTR). The TTR is typically physically close to the access network, such as 100km or less: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf So if LISP-ALT is to be superior to LISP-NERD for IPv4 - meaning it is going to support 100M, 1B, 2B etc. EIDs (and nearly the same number of end-user networks), then it is going to have to support Mobility - and mobile devices probably only need a single IPv4 address. The same is true of APT and Ivip - both can use the TTR Mobility approach and both must support mobility if they are going to cope with more end-user networks than LISP-NERD could comfortably handle. Ivip is intended to scale well to billions of micronets (EIDs in LISP terminology) and to have many advantages over LISP-ALT/NERD and the other alternatives, including better modularity and better support for the TTR Mobility model. To summarise the above: Ivip should be highly capable of using IPv4 space in a highly efficient manner. While the designers of APT and LISP don't seem to be thinking in these terms, I think their systems could do much the same. So I think the best scalable routing system for IPv4 will enable a very high utilization of IPv4 space. In principle, this may provide considerable leeway for new-entrant end-user networks. With Ivip the new SPI space (Scalable PI space) for each end-user network will be rented from some company which "own" a much larger "Mapped Address Block" (MAB), which is a BGP advertised prefix. A typical MAB may contain 64K to 1M or whatever IPv4 addresses - and this can be used for micronets of all sizes, including in principle 64K or 1M or whatever single IPv4 address micronets. The companies which "own" the MABs and rent out the space will not necessarily be ISPs. They will generally be commercial operations like ISPs, but they don't need an access network. The MAB company needs to ensure there are OITRDs (Open ITRs in the DFZ - like LISP Proxy Tunnel Routers) for its MABs, ideally multiple OITRDs physically distributed all over the Net. If it runs them itself, the MAB company needs to be an AS. However, it could easily pay some other company to run those OITRDs. In a fully developed Ivip system, the global unicast address space would be divided into several types of usage. The actual BGP advertised prefixes for these could be all over the place. 1 - Conventional prefixes for ISPs which use it for their own internal purposes, their servers and routers etc. and for providing PA space to many of their customers. This PA space includes substantial end-user networks which need multiple addresses. It also includes the hundreds of millions of DSL, cable modem etc. customers who currently use a single IPv4 address each. 2 - Conventional prefixes for end-user networks which are ASes and are not using Ivip-mapped space. 3 - MABs which are "owned" by MAB companies and rented out to end-user networks which are using this Ivip-mapped SPI space. If we imagine an idealised situation in which all the end-user networks adopt SPI space then this leaves only three categories of address space: 1a - ISPs use this for their internal purposes, and for ITR and ETR addresses. 1b - That part of ISP's prefixes which are devoted to their numerous PA customers. 3 - MAB space which is used with potentially very high utilization rates approaching 100% for SPI-using end-user networks. In the long-term future, here are some figures: 1a - 100M } ISPs } 1b - 2,000M } 3 - 1,600M } MAB companies, which are not necessarily ISPs. Let's say there are 10M fixed end-user networks using SPI space and that on average they need 80 IPv4 addresses. Most need less, such as 4 or 8 and quite a few need only 1 or 2. However a small number of these are corporations, universities, hospitals, government departments, hosting companies etc. which need thousands or hundreds of thousands of IPv4 addresses. This leaves 800M IPv4 SPI addresses available for mobile end-user networks - physically mobile devices such as cellphones, media players or PCs. There won't be much difference in the near future - an Iphone or Gphone is arguably all these already. These will work fine with a single IPv4 address. These devices can use this address via Ivip and the TTR Mobility system no matter what their connection to the Net, including behind NAT. Many such mobile devices will have their CoA on one of the 1b addresses - they will have a PA address to themselves. Others will be behind NAT, so multiple such devices might be on WiFi etc. behind NAT and sharing a single 1b address. These mobile devices need at least one CoA - and they need their own unique SPI address - type 3, which they rent from the MAB company, which is not necessarily an ISP. I think that in your model of IPv4 adoption, the crucial question is how new entrants: Aspiring ISPs End-user networks which want an AS and their own PI prefixes. gain access to address space when it is all held by either existing ISPs or existing PI-using end-user networks. In the above model of Ivip usage (I think LISP or APT would be the same in principle) the system does provide SPI space for potentially far more end-user networks than could ever have the resources to get their own PI space. 1, 2, 3, 64 to 128 or similar smallish number of IPv4 addresses will surely be less expensive than the full costs of gaining one or more /24 prefixes and having ISPs advertise it in BGP. (Theoretically the current /24 limit on the prefixes routers accept could be loosened to allow 128, 64, 32 etc. address prefixes - but I can't imagine this happening as long as there is already unsustainable growth in the number of DFZ routes.) Mobile end-users are dependent on ISPs in one way or another to give them Internet access and a CoA. They are also dependent on a MAB company from whom they rent probably a single IPv4 address, which they can use via any ISP in the world. They also need to pay a TTR company, which needs its own 1a type of space to run its TTRs (which are ETRs as far as the Ivip system is concerned). However a single TTR on a single IP address can simultaneously handle dozens to hundreds of simultaneous mobile end-users via the one IP address. A non-mobile end-user network does not need any PA space - since it has no CoA. They need one or two ISPs to provide Internet access. No matter how many SPI addresses each end-user network has, these only require a single ETR in each of its ISPs. Each such ETR can simultaneously serve the needs of many such end-user networks. With Ivip, the ETRs for fixed end-user networks are in the ISPs they use. This is totally different than for LISP, in which each end-user network has its own ETR for each ISP. So for LISP, no matter how many EID addressees the end-user network has, it consumes at least one IPv4 address for the ETR it uses for each of its two or more ISPs. These ETR addresses come from the ISP's 1a type space. So an ISP with 10,000 LISP end-user networks needs at least 10,000 separate type 1a IP addresses for all these ETR addresses. With Ivip, the same ISP might handle 100 end-user networks with each of its ETRs, so it only needs 100 type 1a IPv4 addresses. In this model, it is vital that aspiring ISPs AND MAB companies can get the address space they need. To the extent that they can and to the extent that the compete and provide good services, this enables the actual SPI-using end-user networks to get the Internet access they need AND the SPI address space they need. So your concern about IPv4 address space shortage and control by incumbents is just as valid as without Ivip. The details are different, because MAB companies are not necessarily ISPs, with all their physical infrastructure in particular locations. I can imagine Ivip working nicely and providing really high utilization for the IPv4 address space - provided it is made available by whoever currently "owns" it. If, as I suspect, we will be stuck in IPv4 for a very long time, I think there will be increasing regulatory pressures to free up underutilised address space to make it available to ISPs and MAB companies which will use it efficiently. Also, those companies which do use it efficiently will be able to derive profits and so pay a price for the space which makes it attractive for underutilising companies to sell it. Still, depending on the world's population and how important it will be for cellphones/PCs to have a globally mobile IPv4 address, there may well be a point, even with the fairest distribution of the 3.7B global unicast IPv4 addresses, where the demand can only be met by putting some or many mobile devices on IPv6 and/or by forcing some or many DSL etc. customers onto some second-rate kind of NATed service, rather than the current practice of giving each customer their own global unicast IPv4 address. This is a long way of saying that in principle I agree with your concerns, but that I can imagine technical and commercial developments - such as Ivip with TTR mobility - which enable the IPv4 address space to be utilized close to 100%. Since I foresee the barriers to mass IPv6 adoption (except perhaps for cellphones) will remain very high, I think it will generally be cheaper and easier at any one point in time to keep making the most of IPv4 than to for anyone to try to migrate to IPv6 without using an IPv4 address. Arguably, this would be a painful, drawn-out torture. Maybe it would be best if the entire IPv4 Internet evaporated sometime soon and forced everyone to move to IPv6 instead. It is not a popular position, but I think there is a lot of scope for squeezing more and more from IPv4 and that we will probably be depending on it as THE global Internet for decades to come. At the same time, I am keen to facilitate any development which could provide a better alternative. >> Note on IPv6 mobile devices. I am envisaging a situation, such as >> in China or other countries, where cellphones and mobile PCs etc. >> need an IP address in order for various voice and messaging services >> to be provided, and for direct communications between devices in the >> same or similar mobile networks. > > It's not an unimaginable scenario, but if China was truly hampered by a > shortage of public IP addresses, that problem would have manifested > itself years ago, in the course of extending non-mobile, IPv4-based > Internet access. For a variety of reasons, China instead chose to > develop alternative approaches for solving this problem -- mechanisms > that are now coming to be known more widely as "carrier grade NATs." > Scarcity of IPv4 was almost certainly not the primary factor driving > this choice, but I would say that among the less obvious considerations, > the commercial/competitive advantages of operator-imposed addressing > were at least if not more important than more widely remarked-upon > concerns about domestic order and state security. Thus, I would suggest > that the China case tends to point to a quite different future than the > one you suggest -- one that rather usefully illuminates the kind of > concerns that I've tried to articulate in this exchange. I understand from this that what I wrote about widespread IPv6 adoption scenarios is less likely to occur than I suggested. I am keen to know of anything concerning IPv6 adoption or the lack thereof in large mobile networks, in China and in other countries where one might expect the IPv4 address shortage to strongly motivate the adoption of IPv6-only or perhaps dual stack services. I think it is relevant to scalable routing, but perhaps it is too contentious to be put on the RRG list. I see you have some research materials at: http://tinyurl.com/IPliquidity which leads to a page at your site http://www.eyeconomics.com . > (for the record: I had the unique privilege of playing a leading role in > the design, deployment, activation, and shortly thereafter the > dismantling of the only international joint venture Internet access > service in China -- the ill-fated "Legend-AOL"... an absolute commercial > disaster, but an amazing/unique learning experience for me personally). Very interesting. I hope this learning experience somehow pays the bills today! I see http://www.caida.org/home/staff/tvest/ has your your extensive ~2006 CV and I understand you are part of the RIPE NCC Science Group, though I found no web pages for this. >> The huge number of such mobile >> devices precludes giving each an IPv4 global unicast address, and for >> many purposes (but not global IPv4 connectivity) an IPv6 address may >> work fine. >> >> With a sufficiently large number of cellphones etc. on IPv6 like >> this, it would be profitable to deploy many commercial IPv6 servers >> to provide "content" for these devices would also be. This would >> make non-mobile IPv6-only services more attractive. This "mobile >> first" scenario for widespread IPv6 adoption is the most likely one I >> can imagine. A less likely scenario is certain countries providing >> IPv6 only DSL etc. services to customers who cannot access any IPv4 >> service. > > I agree with you that it's the most likely of all the plausible > scenarios that one might imagine today. > Unfortunately, I think that it too is highly unlikely. OK - but see the footnote at: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ for why I think the total functionality of a large IPv6 cellphone network wouldn't depend so much on IPv4 connectivity as would conventional Internet services. > Not sure if it was your intent to incorporate the mobile scenario in the > footnote, but I would recommend leaving it out. I wrote a longer footnote which mentions it extensively. I think that for most RRG folks: Scalable_Routing + Mobility = Teeth-itch I hope people will read: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf and so hopefully realise that a core-edge separation scheme such as LISP, APT or Ivip can directly support a new ETR-like Translating Tunnel Router approach to global IP address mobility, for IPv4 and IPv6. This would be a good complement to existing MIP techniques. It does NOT involve frequent mapping changes - such as every time the MN gets a new CoA. >> Hi Tom, >> >> I will respond more fully to your thoughtful message separately, >> probably with a subject like "Breaking IPv4's constraints". > > I'll look forward to that... I am hoping that this message and the footnote is a good response to the interesting matters you have raised so far. >> ... >> >> While this text embodies what I always meant by "incremental >> deployability" I am not trying to define this term. You wrote >> several times about my text as if it was to become "RRG "incremental >> deployability" recommendations". > > I appreciate the clarification -- was not really clear about the > "normative" content of the deployability text, apart from the obvious > (i.e., no coercive authority, etc. -- already covered). In any case, any > apparent mischaracterizations were the product of uncertainty, and not > of any positive assumptions on my part that are inconsistent with your > response... i.e., please consider them to be idiosyncrasies of phrasing > with no particular relevance. OK. >> ... >> >> I sense you are very concerned about the difficulty of establishing >> Internet services beyond the finite constraints of IPv4. > > That is fair to say! With good reason, I believe. While I can imagine Ivip and fair distribution of IPv4 space creating a better IPv4 outcome than most people think possible, even if these things eventuate as I hope, there will be many years of difficulties beforehand. >> I think there's nothing which could be written now which would >> contribute to a solution to this problem. > > I would hesitate to reach that conclusion, in part for the following > reason(s): > > 1. Any future RRG "final product" is almost certain to come after IPv4 > exhaustion and privatization (de facto and/or de jure). I agree. > 2. If, after that point, RRG solutions are primarily or exclusively > oriented toward IPv4 scaling/perpetuation, that will effectively put RRG > in the novel role of maintainer of private/proprietary resources -- > "proprietary" in a sense not unlike that in which specific branded > commercial hardware or software is proprietary. The owners of the new > proprietary resources may be numerous and widely distributed, but it > will forevermore be a closed group, with something like "membership by > invitation only." Yes - but this assumes that the RRG solution could have done more to enable widespread adoption of IPv6. That is outside the formal scope of the RRG's goals, AFAIK. If I can make Ivip in some way facilitate migration from IPv4 to IPv6 or any better alternative, I will do so. Without any specific suggestion for how a scalable routing solution or anything else could help with easing the dependence on IPv4, I don't think it is fair to insist that the RRG or anyone else should do more to achieve such a goal. I count it as a highly desirable goal, but not a requirement. If I thought there was a way of doing it, then I would change my mind and regard it as a requirement - because it is so important. I am trying to keep the list of constraints and its associated test as terse as possible. The first of the new paragraphs at least acknowledges that in practical terms, the constraints apply entirely within IPv4 and also suggest that constraints similar to 2, 3, 4 and 5 are a major factor in the failure of IPv6 to be widely adopted. Please suggest improvements, but I am really trying to keep it short. It is my experience that anything longer than about 4 paragraphs tends to be largely ignored by some key RRG people. > 3. Over the past decade or so, the population of routing system > participants has been very dynamic, with appx. 5-10% growth in the form > of new entrants each year (based on RIR "initial allocation" > transactions involving IPv4) and a somewhat lower (and much harder to > estimate) rate of departures due to M&A and/or termination of service.* > After IPv4 runout or privatization (whichever comes first), the new add > rate is likely to slow down to a trickle, leaving an ever-growing > population of frustrated would-have-been routing system participants. I know little about these things, but it is easy for me to imagine the big fish eating the small fish - especially with the economic crisis. I guess the most numerous and significant of these aspiring new networks - in terms of competition policy and in terms of development of Internet services in countries which are not well served at present - would be new ISPs and cell-phone companies wanting to be ISPs to give their customers direct Internet access. There would also be a growing number of end-user networks - new and existing - who have the resources and the impetus to get multihoming, TE and portability with existing BGP techniques, if they could only get their own PI space. I think a good scalable routing solution will enable many such end-user networks to use the new kind of address space, without the investment in BGP routers and expertise. Furthermore, many more smaller networks who would never have the resources or justification to get PI prefixes will be able to use the new kind of scalable address space too, for low costs and by using as few IP addresses as they really need. > At the same time, the drop rate is likely to increase as some large, > well-heeled operators accelerate their pursuit of low-hanging IPv4 > acquisition targets. Overall, this change is going to represent a > radical, unprecedented break with the Internet growth processes of the > last two decades. I don't think that it will take long for the general > public to notice, and react. > > If and when all of this comes to pass, "open addressing" will quickly > achieve, at least, the same level salience/urgency as "scalable routing" > in the overall RRG problem space. In anticipation of (at the very least) > this possibility, I would suggest that it would be prudent for RRG to > capitalize on every possible opportunity to reaffirm its commitment to > delivering a solution to both problems, starting now. I fully agree that the RRG should discuss and encourage the design of scalable routing solutions which also help with: 1 - Improving IPv4 address space utilization. I think any decent core-edge separation scheme will be capable of this. 2 - Fairer allocation of IPv4 addresses to new ISPs. I can't see how the RRG can affect this, other than by helping to design a flexible, efficient, scalable routing system which enables finer slicing and dicing of the address space, which is the same thing as 1 above. 3 - Adoption of and transition to IPv6. This nut has never come close to being cracked. I think it may be impossible. I don't assume it is so, but until you or anyone else has a scheme which will work, in part by meeting constraints similar to those I listed, I don't think it is fair to expect anyone else to solve this infernal problem. I also believe that because the TTR mobility approach is so desirable and is such an easy extension of a core-edge separation scheme, that the RRG should take a greater interest in it. Also, mobility is the only way I can imagine that any of the proposals LISP-ALT, APT, Ivip or TRRP will be required to scale beyond the 10M or so EIDs which could easily be handled by the simpler, more direct and optimally fast LISP-NERD. > Thanks again for being receptive to my troublesome and somewhat belated > expressions of concern... > > Tom I really appreciate your messages. This field has many technical, human and commercial complexities. I think progress often results from detailed, thoughtful discussions. - Robin From wherrin@gmail.com Sun Apr 19 09:06:31 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B863A683E for ; Sun, 19 Apr 2009 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x14fDJaDYxaS for ; Sun, 19 Apr 2009 09:06:30 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id CAC353A6822 for ; Sun, 19 Apr 2009 09:06:30 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so438474and.37 for ; Sun, 19 Apr 2009 09:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=bGakkN4NEn3xUqVdv/8u4Tf+a3e0RSI6d0jChvolwaA=; b=AItWbQhiP9tx2b1Rz2ibqJrCwUkOX8zZ1+tUPMgVGZ2+97TFVDkXqoyXpzi7YTQog6 gA6Dtcb4qkjn6txYS9sAwnuCyjjJuGe5OxoS6rRRsqAzDAJIYWuQK0afdPD2zJd8pCps nrB3yTs2OwhXiDNdeVRL2G0+NkxAbr41iCRvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Vi4rgGMoBhE1deO4bkWSLaM+GTUXb89bZ9BL41FPEQmWx4q+ZVcBBbpJWA3oo9u2os hvhfwdP40UkxYlfyJ/EbnGUktCkmNR8Ee/l6kVJbDJ0LC0osLflAbBUptl14rUqnnK+c O3Pof9yy5UMNw3by6ExX9UgKjQXEi8nbFX2jc= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.137.12 with SMTP id k12mr6384564and.124.1240157265742; Sun, 19 Apr 2009 09:07:45 -0700 (PDT) In-Reply-To: <49EB3D82.3020306@firstpr.com.au> References: <49EB3D82.3020306@firstpr.com.au> Date: Sun, 19 Apr 2009 12:07:45 -0400 X-Google-Sender-Auth: e51c64634457896c Message-ID: <3c3e3fca0904190907t5336f71dvaebf09aed7ed3791@mail.gmail.com> From: William Herrin To: Robin Whittle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] Constraints due to the need for voluntary adoption X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 16:06:32 -0000 On Sun, Apr 19, 2009 at 11:04 AM, Robin Whittle wrote: > The list of constraints due to the need for voluntary adoption is at: > > =A0 http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ Hi Robin, I like where you're going with this list. I'd suggest a change to point 6. You have: 6 - The solution must be compatible with all existing DFZ routers. (Unless it can be shown that all DFZ routers can be upgraded - such as via a software update - by the time of introduction.) First, I'd drop the "unless." There really is no "unless" here. We've demonstrated rather conclusively that in today's Internet it is highly impractical to try to get the 31,000 individual organizations who compose the DFZ to deploy configuration changes ahead of that individual organization's direct use for the change. Then I'd change it to something like: 6 - The solution must function compatibly with existing DFZ router deployme= nts. Asking them to forklift their hardware is bad but they're going to do that on a 3 to 5 year cycle anyway. Where the effort falls apart is asking them to reprogram their systems before they're in a position to derive a benefit from doing so. I'd also suggest a change in point 1. You have: 1 - The solution must provide immediate and compelling benefits to any new or existing end-user networks which adopt it, irrespective of how many other networks have so far adopted it. I'd change "end-user networks which" to "end users who," and then "other networks" to "others." I know you're not a fan of the strategy B approaches, but some of them have the prospect of being functional as soon as two participating hosts have been upgraded regardless of what happens with the rest of their local networks. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Sun Apr 19 09:12:42 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA3E28C25C for ; Sun, 19 Apr 2009 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt4tDCRnMNqw for ; Sun, 19 Apr 2009 09:12:41 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 4AAD828C21F for ; Sun, 19 Apr 2009 09:12:41 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1102335ywh.37 for ; Sun, 19 Apr 2009 09:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Wsz+ChxUuJ8pkJnnj5jr2AxAh0w0xgqwwNYPEdFcPDM=; b=abvqtGlHgvf6ifU1VFjPmwpgETQTzFmGhY2rMGe0izWDRCxJUDGKCB9/DhTrOsHwh6 XXjK/wIWl6Ch1pMpnl6YZopV5RFiHcJw9nSH7GGEVEAeIFPdPc45sYL4ioWtA9RxXVI7 uwK3SB985TmQFFZnxfmv574j8QgHug+4OwPDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=fczfnJe27KPyeWlzekLoaPmSlwTD2BZbbo8z+wm1WM9iFSOb39Jpm+d1KY5ETZfQb2 cAjFnm7GYG7A9LThnd1cUK8L9wGRrRHPvHzjBkL/81qGyS2HFSDkjTiUYZXOq/kTmrIa n7ySnZm+kFix68gU97TvpLWFITvN5ktzgogBM= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.45.5 with SMTP id s5mr599078ans.108.1240157636125; Sun, 19 Apr 2009 09:13:56 -0700 (PDT) Date: Sun, 19 Apr 2009 12:13:55 -0400 X-Google-Sender-Auth: 11f72bf1274eb3b0 Message-ID: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> From: William Herrin To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 16:12:42 -0000 > Put differently, anycast addresses are no different than, and arguably > worses than, PI addresses. =A0A whole lot of our work is to get PI addres= ses > out of the core table. =A0Getting PI out, but allowing unlimited anycast = in > would not be progress. Several of you have made comments like the above. In my head I can almost see the rest of you behind your screens, sagely nodding your heads in agreement that anycast shouldn't be a first-class citizen in the architecture. Before anyone nods his way into a mistake, I'd ask you to consider a simple question: What might anycast look like in the various approaches we've discussed to solving the routing problem? Let's look at a map-encap strategy A system first. What can't it do adequately without anycast? And how can it provide routeless anycast? First off your non-local packets need to find an ingress router. The more specific local routes will keep local packets away. The rest will follow a default route to the ingress router. Or is there some other way you'll find the ITR? Somehow force it inline with all packets routed? You'll no more run your network on just one ingress encoder than you'd run it on a single DNS server or a single T1. Okay, well, some of you will but those of you who are serious about reliability won't. No, you'll have two or several ingress routers. And each one will ANYCAST the default route so that if one of them fails the packets seamlessly reroute to the other. What about the transition period? For a while there'll be both legacy routing and the ITR/ETR routing. How will you bridge the legacy systems in? Well, every one of us who has come up with a strategy-A solution has posited some sort of ITR in the core that advertises short prefixes out to the legacy system and encodes the packets it gets for delivery in the new system. Will we have one for all the ETRs serving 192.0.0.0/8 and one for all the ETRs serving 193.0.0.0/8? Yeah right. We'll have 20 geographically distributed ITRs for 192.0.0.0/4, each of which will announce 192.0.0.0/4 via ANYCAST. And if you plan to go out and query a distributed map database (as more of you do now than did two years ago when I proposed it) then you'll announce your map roots via ANYCAST too. But that's only half the equation. Strategy A systems don't just consume anycast routes, they provide them. And unless you do something really bone-headed in your design, they do it in the map without consuming slots in the routing table. You do a map lookup on the destination. You get a prioritized list of of egress routers. Though presumably multiple entry points into the same system, this is no more a rule than with routes in the BGP table. Make each egress an entrance to a different, geographically and topologically diverse, host. The akamai-like map server dynamically reorders the list based on its heuristic guess as to which of the hosts are closer or further from you. Presto! You connect to the nearest server through minor magic in the map. Give the ingress router a mild resistance to change during relookups and you even get anycast with a very high probability of packets reaching the same respondent over time -- rather handy for anycast TCP which isn't really practical in the current routing system. Stable TCP over anycast would, by the way, be fantastic news for the CDNs and their customers which include, oh, just about every major content provider on the web. Of course, you might implement strategy A badly. You can build a rigid design where the map is static and the ingress router has no discretion whatsoever for which egress it sends to. But none of you made that mistake in your designs, right? Strategy B systems alter or replace TCP with a protocol that doesn't use the layer-3 address for its transport identity. They use a map to find the current set of "locators." Routeless anycast here works in much the same way as strategy A. The map is like an enhanced DNS SRV record. Better really: not only do the endpoints know which set of locators to try first, they know which locators match each of the multiple hosts returned by the lookup. You're actually guaranteed to get the same respondent for the duration of the layer-4 connection. It's SO easy. And, of course, anycast and unicast routes are identical in every respect in strategy D, E and F systems since the routes on those RIBs function identically to what we have today. With this in mind, I propose a statement which is, on its face, absurd. Yet each time you consider it in the coming months and years, you'll find it makes more and more sense: Unicast is a special case of anycast in which there is only one destination endpoint. Food for thought. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tony.li@tony.li Sun Apr 19 09:43:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D135828C225 for ; Sun, 19 Apr 2009 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlDY1Ihy-rIj for ; Sun, 19 Apr 2009 09:43:30 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id CE91128C0F9 for ; Sun, 19 Apr 2009 09:43:29 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id hRj91b0060QkzPwAFUklf7; Sun, 19 Apr 2009 16:44:45 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id hUkk1b00N3L8a8Q8NUkkM1; Sun, 19 Apr 2009 16:44:45 +0000 Message-ID: <49EB54EC.5060801@tony.li> Date: Sun, 19 Apr 2009 09:44:28 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> In-Reply-To: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 16:43:30 -0000 Bill, > Before anyone nods his way into a mistake, I'd ask you to consider a > simple question: What might anycast look like in the various > approaches we've discussed to solving the routing problem? What you're proposing is certainly reasonable. The gist is that you don't end up with a global route per service, and that you use the mapping function to convert anycast into a unicast service. Some folks do that already today (e.g., http://www.pool.ntp.org) with DNS as the mapping function. That's certainly fine and has no impact on routing whatsoever, obviously. We just don't call it anycast. > With this in mind, I propose a statement which is, on its face, > absurd. Yet each time you consider it in the coming months and years, > you'll find it makes more and more sense: > > Unicast is a special case of anycast in which there is only one > destination endpoint. Nothing absurd about it. It's been said many times that unicast is a special case of multicast and your observation is that anycast fits in the middle of that hierarchy, since anycast is also a special case of multicast where delivery is to only one receiver. Regards, Tony From jmh@joelhalpern.com Sun Apr 19 10:41:37 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC7C3A6864 for ; Sun, 19 Apr 2009 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-1.178, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl2xO6Exar+e for ; Sun, 19 Apr 2009 10:41:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7E9723A67AA for ; Sun, 19 Apr 2009 10:41:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EA4B643036A; Sun, 19 Apr 2009 10:42:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id EC049430339; Sun, 19 Apr 2009 10:42:50 -0700 (PDT) Message-ID: <49EB6290.6000903@joelhalpern.com> Date: Sun, 19 Apr 2009 13:42:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> In-Reply-To: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 17:41:37 -0000 I suspect that our disagreement may relate to the definition of Anycast. For example, IPv6 anycast, which as I understand it is a prefix followed by all zero bits, and routes to any place that handles the prefix. Is sensible, routable, scalable, and ought to be aggregateable. I have no problem with it. I also have no problem with the fact taht DNS names often resolve to multiple IP addresses, any of which can be used by the client aplicaiton to reach the entity of interest. Where I have trouble is treating as a name for a topological location in the net, a quantity as long as the full address (32 IPv4 bits or 128 IPv6 bits) and having that thing reachable in multiple distinct topological locations, with no aggregation possible. While that can be used for special purposes, it appears to me that it is a special purpose hack, placing application / service information in the routing system, rather than a first class service component usable at whatever scale anyone wants to use it. Having read the text below, given that you refer to multiple routes to a prefix as a form of anycast, I am left confused as to what you are arguing should be treated as a full part of the architecture. Yours, Joel William Herrin wrote: >> Put differently, anycast addresses are no different than, and arguably >> worses than, PI addresses. A whole lot of our work is to get PI addresses >> out of the core table. Getting PI out, but allowing unlimited anycast in >> would not be progress. > > Several of you have made comments like the above. In my head I can > almost see the rest of you behind your screens, sagely nodding your > heads in agreement that anycast shouldn't be a first-class citizen in > the architecture. > > Before anyone nods his way into a mistake, I'd ask you to consider a > simple question: What might anycast look like in the various > approaches we've discussed to solving the routing problem? > > > > Let's look at a map-encap strategy A system first. What can't it do > adequately without anycast? And how can it provide routeless anycast? > > First off your non-local packets need to find an ingress router. The > more specific local routes will keep local packets away. The rest will > follow a default route to the ingress router. Or is there some other > way you'll find the ITR? Somehow force it inline with all packets > routed? > > You'll no more run your network on just one ingress encoder than you'd > run it on a single DNS server or a single T1. Okay, well, some of you > will but those of you who are serious about reliability won't. No, > you'll have two or several ingress routers. And each one will ANYCAST > the default route so that if one of them fails the packets seamlessly > reroute to the other. > > What about the transition period? For a while there'll be both legacy > routing and the ITR/ETR routing. How will you bridge the legacy > systems in? Well, every one of us who has come up with a strategy-A > solution has posited some sort of ITR in the core that advertises > short prefixes out to the legacy system and encodes the packets it > gets for delivery in the new system. Will we have one for all the ETRs > serving 192.0.0.0/8 and one for all the ETRs serving 193.0.0.0/8? Yeah > right. We'll have 20 geographically distributed ITRs for 192.0.0.0/4, > each of which will announce 192.0.0.0/4 via ANYCAST. > > And if you plan to go out and query a distributed map database (as > more of you do now than did two years ago when I proposed it) then > you'll announce your map roots via ANYCAST too. > > > But that's only half the equation. Strategy A systems don't just > consume anycast routes, they provide them. And unless you do something > really bone-headed in your design, they do it in the map without > consuming slots in the routing table. > > You do a map lookup on the destination. You get a prioritized list of > of egress routers. Though presumably multiple entry points into the > same system, this is no more a rule than with routes in the BGP table. > Make each egress an entrance to a different, geographically and > topologically diverse, host. The akamai-like map server dynamically > reorders the list based on its heuristic guess as to which of the > hosts are closer or further from you. Presto! You connect to the > nearest server through minor magic in the map. > > Give the ingress router a mild resistance to change during relookups > and you even get anycast with a very high probability of packets > reaching the same respondent over time -- rather handy for anycast TCP > which isn't really practical in the current routing system. > > Stable TCP over anycast would, by the way, be fantastic news for the > CDNs and their customers which include, oh, just about every major > content provider on the web. > > > Of course, you might implement strategy A badly. You can build a rigid > design where the map is static and the ingress router has no > discretion whatsoever for which egress it sends to. But none of you > made that mistake in your designs, right? > > > Strategy B systems alter or replace TCP with a protocol that doesn't > use the layer-3 address for its transport identity. They use a map to > find the current set of "locators." Routeless anycast here works in > much the same way as strategy A. The map is like an enhanced DNS SRV > record. Better really: not only do the endpoints know which set of > locators to try first, they know which locators match each of the > multiple hosts returned by the lookup. You're actually guaranteed to > get the same respondent for the duration of the layer-4 connection. > It's SO easy. > > > And, of course, anycast and unicast routes are identical in every > respect in strategy D, E and F systems since the routes on those RIBs > function identically to what we have today. > > > With this in mind, I propose a statement which is, on its face, > absurd. Yet each time you consider it in the coming months and years, > you'll find it makes more and more sense: > > Unicast is a special case of anycast in which there is only one > destination endpoint. > > Food for thought. > > Regards, > Bill Herrin > > > > From jeroen@unfix.org Sun Apr 19 11:07:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1408B3A6818 for ; Sun, 19 Apr 2009 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GniO7nxAID+h for ; Sun, 19 Apr 2009 11:07:46 -0700 (PDT) Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id 0D0773A67B7 for ; Sun, 19 Apr 2009 11:07:46 -0700 (PDT) Received: from [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 9035C401FEE; Sun, 19 Apr 2009 20:08:59 +0200 (CEST) Message-ID: <49EB68BC.8020607@spaghetti.zurich.ibm.com> Date: Sun, 19 Apr 2009 20:09:00 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "Joel M. Halpern" References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB6290.6000903@joelhalpern.com> In-Reply-To: <49EB6290.6000903@joelhalpern.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB55F3BA363CE914AF797AC7" Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 18:07:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB55F3BA363CE914AF797AC7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [sidetrack: anycast ipv6 note] Joel M. Halpern wrote: > I suspect that our disagreement may relate to the definition of Anycast= =2E > For example, IPv6 anycast, which as I understand it is a prefix followe= d > by all zero bits, Actually, it is just like IPv4, you configure a /128 in IPv6 or a /32 in IPv4 and route it. The host that picks it up wins. The one you mention is called a 'subnet anycast address', which is the "0" on the subnet, if you have a /64, it is is the all-zero address; if you have a /127 though, you suddenly have a problem: 0 =3D subnet anycast= , 1 is the first address, and indeed then it is full and it does not work. Which is why /127's are a bad idea to use; 2x /128 works of course ;) Ggreets, Jeroen --------------enigAB55F3BA363CE914AF797AC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD4DBQFJ62i8KaooUjM+fCMRAvRaAJMF15g9PGj6Kf0YU1p/tqReYa5GAJ44Sn/9 YmM7Mx7Fjc4BP7viUC3+Dg== =FSSs -----END PGP SIGNATURE----- --------------enigAB55F3BA363CE914AF797AC7-- From tvest@pch.net Sun Apr 19 16:29:47 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766E83A6F66 for ; Sun, 19 Apr 2009 16:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM4gTDBVeqSN for ; Sun, 19 Apr 2009 16:29:45 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5ECE83A6F28 for ; Sun, 19 Apr 2009 16:29:45 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA06.westchester.pa.mail.comcast.net with comcast id hR6X1b0040ldTLk56bWJqZ; Sun, 19 Apr 2009 23:30:18 +0000 Received: from [172.16.1.3] ([24.125.119.245]) by OMTA04.westchester.pa.mail.comcast.net with comcast id hbX01b00G5Hlxyo3QbX0f4; Sun, 19 Apr 2009 23:31:01 +0000 From: Tom Vest To: Robin Whittle In-Reply-To: <49EB4294.2070601@firstpr.com.au> References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> <49EB4294.2070601@firstpr.com.au> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 19 Apr 2009 19:30:58 -0400 X-Mailer: Apple Mail (2.930.3) Cc: RRG Subject: Re: [rrg] Scalable solution hitting IPv4's limits / main text X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:29:47 -0000 On Apr 19, 2009, at 11:26 AM, Robin Whittle wrote: > Short version: Long reply to Tom Vest, discussing his concerns > about IPv4, even with a scalable routing solution, > hitting the limits of its address range and so > causing difficulties for aspiring new ISPs. > > The same issues are covered more concisely in the > footnote to the draft list of constraints. > > Also, some discussion of the TTR Mobility approach > in the hope that people will read it and so not be > so alarmed at the mention of mobility with scalable > routing. I first described this in June 2007 and > this full description, with diagrams, has been > available for 8 months: > > http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf > > > Hi Tom, > > The list of constraints due to the need for voluntary adoption is at: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > I have added a second last paragraph which mentions some of your > concerns. As I discuss here and in the Footnote at the above page, I > think your concerns are important but that there is no need to change > the list itself. I intend it to be a factual list of constraints we > can all agree to - even if some of them seem to be at odds with a > truly satisfactory outcome in terms of endless address space and the > avoidance of barriers to new entrants. > > > Here is a reply to your message in the "Constraints on a solution > ..." thread. Thanks again for your thoughtful discussion and > constructive suggestions. You wrote: > >>> Constraints imposed by the need for voluntary adoption * >>> >>> A successful solution to the routing and addressing >>> scaling problem is tightly constrained by the need >>> for it to be voluntarily adopted, over a period of * >>> years, by the great majority of end-user networks * >>> of all sizes who want or need multihoming, inbound >>> traffic engineering and/or portability of their >>> address space between ISPs. >> >> Thanks once again Robin. >> >> My concerns would be fully covered if the above language were changed >> slightly... >> >> A successful solution to the routing and addressing >> scaling problem is tightly constrained by the need >> for it to be both accessible to, and voluntarily adopted by >> the great majority of established and aspiring end-user >> networks who want or need multihoming, inbound >> traffic engineering and/or portability of their address >> space between ISPs. Because this voluntary adoption may >> occur over a period of years, the benefits of the solution >> itself should be broadly accessible to all end-user networks, >> regardless of their size or legacy (pre-solution) protocol >> endowments. > > I have amended the text to: > > be both accessible to, and voluntarily adopted by > > and I hope you will find that the new second-last paragraph at least > partially mentions your concerns. > > The benefits resulting from the best imaginable > solution for IPv4 may be limited by shortage of IPv4 > space and resulting difficulties for new networks in > gaining this space. While no such restrictions exist > with IPv6, constraints similar to 2, 3, 4 and 5 are > likely to continue to be a barrier to widespread > migration to IPv6. Hi Robin, Thanks for taking (what must have been considerable) time to reply in detail. The above two modifications do, indeed, adequately reflect the concerns I expressed. > I want the list of constraints to be a terse description of things we > all (ideally) agree are true. The focus is on what is needed for > end-user networks and their ISPs to adopt the solution. > > As a statement of fact, this text does not assume that there is a > solution which will meet all these constraints. I think there will > be solutions which meet them all in IPv4 - but I agree that during ' > adoption and in the decades to come, no matter how ubiquitously the > scalable routing solution is adopted and how well it works, the > address space shortage is likely to limit the IPv4 Internet's > capacity to provide multihoming etc. for all end-user networks which > want it. Of course I agree on this point, but this particular goal was never explicitly stated, nor implied, nor even contemplated by me. The idea that merely "wanting it" -- i.e., full access to all of the 'rights, privileges, and responsibilities' that are enjoyed by direct participants in the Internet's routing subsystem -- is or should be by itself sufficient for any institution to lay claim to a share of that system's finite carrying capacity -- fundamentally contradicts the findings of my own personal experience and research (maybe common sense too, if I presumed to know what that was). More precisely stated, the implications of my recent work suggests that the very nature of the constraints that dictate the requirement for "incremental deployability" are *the same* structural constraints that absolutely dictate that any/every conceivable current and future routing system that could ever be adopted and deployed in this manner will -- inevitably, necessarily -- embody some set of features that ultimately make all such systems vulnerable to some version of *the same* systemic risks to which the current system is vulnerable, namely: -- "inflation" (c.f., generalized/cumulative/direct impact of individual demands on routing system carrying capacity that are borne by all/other participants in that routing system) -- "deflation" (c.f., generalized/cumulative impact of non- availability of routing system capacity and/or address resources, which manifests as diminished growth potential for existing participants and a progressive barrier to the emergence of potential new participants) -- "stagnation" (c.f., generalized/cumulative impact of non- availability of "standard"/"DFZ" routing system capacity and/or "standard"/uniform address resources, which manifests as a progressive degradation of and loss of confidence in the consistency/ predictability of precisely those "network effects" that make a shared, inter-domain routing system so valuable to its direct participants, as well as to indirect stakeholders). Another way of putting this is that the specific problems that RRG is trying to solve are actually just specific manifestations of more general risks -- risks that are *not* primarily or exclusively an artifact of current routing and addressing technology. Rather, these risks are a natural, organic, and (probably) largely unavoidable feature of *all* liquidity mechanisms -- i.e., all "technically mediated exchange systems." They are unavoidable because a necessary condition of possibility for the existence/emergence of such mediated exchange systems is the prior existence of a population of diverse, independent, often competing economic agents (individuals, institutions, etc.), members of which might often enjoy opportunities to productively interact with one another, but for the existence of various "transactional frictions" (foregoing details on this for now). "Liquidity system" and/or "technical medium of exchange" are the interchangeable terms that I've adopted [1] to describe the thing that emerges in some (not all) situations, which is functionally distinguished by its capacity to reduce if not eliminate those frictions for all participants who voluntarily adopt it -- thereby becoming participating members in that particular liquidity system. The intrinsic friction-reducing benefits of participation (growth, profit, etc.) attracts and retains participants within that system, which creates/strengthens incentives for system participants to interact with each other ever more intensively (producing as a result the devision of labor, specialization, etc.). However, those same benefits also have the organic effect of intensifying competition between system participants, which eventually results in their becoming aware of the liquidity mechanism itself, and its possible uses as a strategic, (anti)competitive tool. I'll spare the list the rest of the evolving story. Those interested can find more of it is on my personal website (links below). In any event, I wholeheartedly share RRG's ambition to contribute to the alleviation these problems. The story above explains why systems like ours need liquidity mechanisms, and what benefits they confer -- and risks they impose -- on those systems that are lucky enough to have one. However, that "need" does not entail that it will be fulfilled. Obviously, another absolute condition of possibility is the existence of some candidate mechanism(s) that is capable of initiating and sustaining this liquidity process over time. Not all candidate liquidity mechanisms are created equal, and I think of RRG's core mandate as the definition of the "best possible" successor liquidity mechanism for the Internet that we have inherited -- with "best possible" defined as (max. [probability of adoption * probability of sustainability, given known structural and exogenous risks]). That said, I do not believe that the problems that RRG is trying to solve are amenable to any complete or final "solution" -- nor even to much symptomatic relief unless the root cause(s) of the problems are recognized and addressed directly. And that brings me back to the point of departure, Robin, which was the contrast between "desire" or (self-asserted) "need" vs. *eligibility*. It seems to me that the formula that made it possible for the last RRG-relevant domain-wide solution (CIDR) to "work" -- i.e., to be both (1) accepted by, at least, the minimum set of parties required to get started, and (2) to continue to be regarded as tolerable/acceptable by the majority of direct, indirect, and aspiring stakeholders thereafter -- involved three key ingredients: 1. The idea that there is a (i.e., at least one) technically justifiable/defensible set of criteria that can be used to determine an institution's "eligibility" to consume some share of the common/ default routing system's finite carrying capacity. To maximize sustainability over time, these criteria should establish a link between individual-level demand for participation and the potential system-wide benefits of allocating a share of finite system carrying capacity to the aspiring participant. 2. To further maximize sustainability over time, eligibility criteria should be responsive to changing conditions, e.g., an expansion of the system's finite carrying capacity should be reflected in the corresponding eligibility criteria. That makes eligibility criteria management dependent on the active participation of those who are closest to the implementation technologies and practices. 3. These eligibility criteria should, in both principle and practice, form the primary basis for allocating finite routing system carrying capacity. Achieving this in a sustainable way is only possible if the eligibility criteria are administered, and the associated resources distributed, through some neutral, transparent mechanism that is substantially insulated from the competitive dynamics that govern most direct interactions between existing liquidity system participants. In other words, the allocation mechanism must be insulated from the very dynamics that make the liquidity system itself so valuable, and which make the potential risks and consequences of liquidity system capture, collapse, or premature obsolescence so severe. So, to your point about not being able to "provide multihoming etc. for all end-user networks which want it," I respond that that is not a realistic goal, given the joint constraints of technology and human nature. I seriously doubt that it ever will be, because in an uncertain world full of real and/or potential competitors, people will always "want" more than they currently "need," and nothing short of infinite carrying capacity or a change in human nature can remedy that. However, I believe with even greater seriousness that we must aspire to preserve -- or barring that possibility to recreate with the shortest humanly possible interruption -- those three conditions, and the kind of "eligibility-based" system admission process that results when those conditions are in place. I believe this strongly because the history of liquidity systems past suggests that if those conditions are not sustained or restored in (effectively no) time, whatever endures may not be redeemable, or worth redeeming for that matter, and in any event system maintenance by then is then likely to have become someone else's problem. Just as the "need" for a liquidity mechanism like TCP/IP does not guarantee that one will emerge and be widely adopted, neither does that need guarantee that an existing mechanism will endure, or in enduring superficially ("in form only") continue to provide those substantive benefits that make liquidity systems so valuable, and so vanishingly rare in the wild. Monetary liquidity systems have come and gone in the past -- but the ones that have both "gone" and subsequently "come back" have almost universally been backed by sovereign power -- and 100% of those were/ are exclusively national in scope. What that portends for the future of our own, first-of-its kind, extra-territorial, attachment-based liquidity mechanism is left as a exercise for the reader. Note: To prevent the weight of this message from giving the Internet a hernia, I've split out comments on the footnote next in a separate message, to follow shortly. Thanks again for your responsiveness... TV [1] The terms come a newish subfield of academic/operational macroeconomic research that focuses on topics like the origin of "money" and the sustainable management of monetary systems, most of whose leading contributors seem to be current or former commercial banking professionals or central bank/monetary policy decision makers. Definition and comparison of "technical media of exchange" aka "liquidity mechanisms": http://www.eyeconomics.com/eyecononomics.com/MoEDdefined.html Expected consequences of the looming transition in Internet "liquidity mechanisms": http://www.eyeconomics.com/eyecononomics.com/NetStagflationPaper.html From wherrin@gmail.com Sun Apr 19 16:31:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DAD3A6405 for ; Sun, 19 Apr 2009 16:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQxumoMDoSMc for ; Sun, 19 Apr 2009 16:31:39 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 0C6563A6D5B for ; Sun, 19 Apr 2009 16:31:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so508145and.37 for ; Sun, 19 Apr 2009 16:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=iQWndW9uENonUw9FbzETiBGVAjAwLHhC/pjBtmTPn5E=; b=QMmagyyXsdgMvUvTwMOzCAdzU62D9hfeG6g8Y+9+pB6oKlxZGfyFcv3uWmKh7Vt+lL CHtfQetuOjxq4qWbPMSjicpcdeTUr/KSC+4jET8RicNZfWNPeyD+VqW+l6rIHY/9ZpHu QUTXZfWm0y/an+Ln/0rY4NnYnqmA1VL5qX9M8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=K8t4V41OXZYlzpgwEi8g4BmqAvXlaxa3BlESQaj3FeoDfdyn3cb+G9mueoLt9pwry6 bkjEB9J0hLGFrGUwTLjSlC4IuAfFfRM+RZK2MMYKxmnQVBW1RBZxVSM5C6inBherjKut rQqndd2N0TZzOuGH4TAiNnBBUDU3dnLbyZUKM= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.140.15 with SMTP id n15mr6470800and.105.1240183974017; Sun, 19 Apr 2009 16:32:54 -0700 (PDT) In-Reply-To: <49EB54EC.5060801@tony.li> References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> Date: Sun, 19 Apr 2009 19:32:53 -0400 X-Google-Sender-Auth: e075c93f6d06b1fa Message-ID: <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:31:40 -0000 On Sun, Apr 19, 2009 at 1:42 PM, Joel M. Halpern wrot= e: > I suspect that our disagreement may relate to the definition of Anycast. Hi Joel, I'm talking about anycast as described in RFCs 1546, 3068 and 3258. I'm not well familiar with RFC 2526 but it seems to describe some subnet-centric considerations which would be outside of the RRG's scope. On Sun, Apr 19, 2009 at 12:44 PM, Tony Li wrote: >> Unicast is a special case of anycast in which there is only one >> destination endpoint. > > Nothing absurd about it. It's been said many times that unicast is a > special case of multicast and your observation is that anycast fits in th= e > middle of that hierarchy, since anycast is also a special case of multica= st > where delivery is to only one receiver. Hi Tony, I disagree with you there. Broadcast and Multicast are forms of non-determinisitic routing. Anycast and unicast are both forms of deterministic routing. There's a wide gulf between deterministic and non-deterministic routing. What works efficiently for one just flat doesn't work well for the other. I claim that on the deterministic side, the difference between anycast and its unicast subset is sufficiently trivial that a well conceived protocol will neither need nor want to treat the two cases differently. When I say, "Unicast is a case of anycast in which there is only one destination endpoint," I really mean it. Unicast doesn't exist. It's just a convenience label for Anycast in which only one destination endpoint is currently active, and that's precisely how the routing system treats it. The same can't be said of multicast. Multicast has different semantics even if there's only one host in the group. Still think I haven't proposed a radically different way to visualize the routing system? > What you're proposing is certainly reasonable. =A0The gist is that you do= n't > end up with a global route per service, and that you use the mapping > function to convert anycast into a unicast service. > > Some folks do that already today (e.g., http://www.pool.ntp.org) with DNS= as > the mapping function. If using DNS that way worked, we could all go home. Unfortunately, what happens is that the ntp server looks up the name to address binding once when the machine boots and never reconsiders it during the year and a half the server is running, even after queries to the server's IP address stop returning data. This is typical. Though their operational cycle is usually limited to days or weeks, web browsers do the same thing. (DNS pinning) The strategy B systems essentially replace DNS with a system where the timeouts are mandatory. The strategy A systems add an additional layer of indirection between DNS and routing so that the DNS is free to continue its trend toward static bindings. In both approaches we acknowledge that decades of practice have rendered the existing forward DNS irretrievable as a source of dynamic binding to the routing elements. > =A0That's certainly fine and has no impact on =A0routing > whatsoever, obviously. =A0We just don't call it anycast. If it quacks like a duck... Regards, Bill --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rw@firstpr.com.au Sun Apr 19 20:47:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC0B3A6C8D for ; Sun, 19 Apr 2009 20:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4D0MMuf+bKh for ; Sun, 19 Apr 2009 20:47:39 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C570A3A6B83 for ; Sun, 19 Apr 2009 20:47:38 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id CBEC6175C5B; Mon, 20 Apr 2009 13:48:52 +1000 (EST) Message-ID: <49EBF0AB.2000804@firstpr.com.au> Date: Mon, 20 Apr 2009 13:48:59 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49EB3D82.3020306@firstpr.com.au> <3c3e3fca0904190907t5336f71dvaebf09aed7ed3791@mail.gmail.com> In-Reply-To: <3c3e3fca0904190907t5336f71dvaebf09aed7ed3791@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Constraints due to the need for voluntary adoption X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 03:47:41 -0000 Short version: Responding to Bill's suggested changes to the text. Detailed discussion of prospects for DFZ routers having new functions to suit the scalable routing solution. A new version of 6 - I will update the draft in the next day or so: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ Hi Bill, Thanks for this: > I like where you're going with this list. and for your suggestions. > I'd suggest a change to point 6. You have: > > 6 - The solution must be compatible with all > existing DFZ routers. (Unless it can be shown > that all DFZ routers can be upgraded - such as > via a software update - by the time of > introduction.) > > First, I'd drop the "unless." There really is no "unless" here. We've > demonstrated rather conclusively that in today's Internet it is highly > impractical to try to get the 31,000 individual organizations who > compose the DFZ to deploy configuration changes ahead of that > individual organization's direct use for the change. OK - this prompted me to think in more detail about altering DFZ router functionality. Below is updated text which is more narrow than "all DFZ routers", but which continues to allow for the possibility of new DFZ router functionality in time for actual deployment. Core-edge separation schemes rely on the DFZ for transporting packets in a manner different to that which occurs according to their destination address. One approach is for an ITR to encapsulate the packet - give it a new outer destination address - and then use the DFZ and all other as they function today to forward the encapsulated packet to ETR. Another approach (Six/One Router) involves changing the destination address so the packet goes from the ITR-like router to the ETR-like router, and than changing it back to the original address at the ETR-like router. Encapsulation is inefficient and has PMTUD problems which requires the addition of considerable complexity, state, processing effort etc. in ITRs and ETRs. The only approaches to address rewriting (Six/One Router and SHIM6) are for IPv6. I made two proposals for tweaking DFZ router behaviour (and also some internal routers of ISP networks adopting the scalable routing solution) which would enable ITR -> ETR tunneling of packets without altering their destination address and without encapsulation or any extra bytes being added: EAF - http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw PFL - http://www.firstpr.com.au/ip/ivip/ivip6/ These two "Modified Header Forwarding" (MHF) approaches are the only ones I know of - but perhaps more will be developed. Neither involve changes to BGP. Both involve changes to the FIB and changes to the code which creates Packet Too Big messages. For IPv6 PFL, there is also a change to the way the RIB drives the FIB. There would be a single new configuration item for each one - whether to enable it or not. None of these changes are particularly complex considering the enormous number of things the FIB and RIB etc. already do. Considering just IPv6, let's say that in 2012 the IETF develops PFL and recommends that all new routers have this function. There's no tearing hurry deploying the solution in IPv6, but we need to plan for it. Let's imagine that by 2017, 80% of DFZ routers have been manufactured since 2012 and have PFL built-in. IF the remaining 20% of routers have had firmware updates to implement PFL and IF the operators have either as a matter of course installed suitable updated firmware or could be cajoled into doing so by 2017, then we have a basis for scalable routing ITR -> ETR forwarding in 2017 which is much more simple and efficient than encapsulation and its PMTUD complexities. IPv6 encapsulation overhead is highly significant, especially for VoIP packets. I doubt if any router now, less still in 2017, implements its IPv6 FIB in raw silicon. If none of them do, then they can all be made to support PFL with a firmware update. I am keen to craft some words which allow for this sort of development. Doing the same for IPv4 could be a lot trickier. Maybe by the time we need to deploy the solution, there will still be too many DFZ routers with FIBs implemented in hardware. On the other hand, at the current rate of progress, it may be 2017 before we implement scalable routing for IPv4 - by which time I expect all routers would have firmware-defined FIB functions. You mention "31,000 individual organizations who compose the DFZ". I guess you are referring to the number depicted in Fig 7 of: http://www.potaroo.net/tools/asn32/ (Salute Geoff Huston for maintaining this and related pages!) Now I will discuss today's IPv4 figures as a basis for estimating how many ASes would need to upgrade their "DFZ router". Any AS end-user network such as NET-A which has its PI prefixes advertised in the DFZ, but which only connects to the DFZ via its upstream ISPs is not a concern for us. These ASes have no DFZ routers. NET-B is an AS end-user network with a PI prefix advertised in BGP, and with a BGP router single-homed to an ISP. That router is not part of the DFZ. As long as NET-B doesn't adopt the scalable routing solution (by installing ITRs and/or ETRs), it need not upgrade its router. ISP-X has one or more BGP routers multihomed to other ISPs, but it does not allow transit traffic. These are DFZ routers, but as long as ISP-X does not adopt the scalable routing solution (that is, it does not have ITRs or ETRs in its own network or in the network of any of its PI or PA customers) then it doesn't need to upgrade its routers either. NET-C is an end-user network which resembles ISP-X in that it has one or more DFZ routers, multihomed to upstream ISPs. By definition, end-user networks don't allow transit through their routers. So as long as NET-C does not adopt the scalable routing solution, it need not upgrade its routers. So the routers which need to be upgraded belong to only a subset of the 31,000 ASes: 1 - The DFZ routers and some, many or all internal routers of any end-user network or ISP which adopts the scalable routing solution. 2 - All transit routers. Depending on when the scalable routing solution is needed, this could be too much of an ask for IPv4, but I don't rule it out. I think it is a perfectly practical idea for IPv6, unless IPv6's adoption rate skyrockets soon and requires a solution to be implemented much faster than I anticipate. I figure transit routers are typically larger, recent production, routers and so would be likely to be amenable to firmware upgrade if they were not already manufactured with the EAF or PFL features built-in. I can't prove any of this is possible, but considering the benefits in avoiding encapsulation altogether, and my guess that it will be later in the coming decade when a scalable routing solution is actually deployed, I want to write the constraints text in a way which does not rule out such new functionality in DFZ routers. > Then I'd change it to something like: > > 6 - The solution must function compatibly with existing DFZ router deployments. This means just the same as the first sentence. I think this on its own, without the original second sentence, unnecessarily assumes that transit router functionality can't be upgraded in time for deployment. Here is another attempt, but it specifically allows for the possibility of upgraded functionality which you just argued could never be possible. I hope I have convinced you that it is not out of the question, especially with a longer timeframe for deploying the solution. IT projects typically take longer than anyone cares to admit. This is a major upgrade to the world's most entrenched and important IT system. If I had to pick a year for 50/50 odds of initial actual deployment, I would say 2017 for IPv4. At current growth rates (which may increase, I admit) the DFZ would have grown to about 650k by then. So maybe it will be 1M after allowing for lots more chopping of address space once the fresh pastures are all used up. The new text involves a more narrow definition of than the previous "DFZ routers": 6 - If the solution requires extra functionality in interdomain routers, then it must be feasible from technical and business perspectives for the relevant routers to have this functionality in time for deployment. For instance, a core-edge separation scheme which relied on new router functions for ITR to ETR tunneling would require the functionality to be present in all transit routers and in the routers of all ISPs with customers which adopt the solution. > Asking them to forklift their hardware is bad but they're going to do > that on a 3 to 5 year cycle anyway. Where the effort falls apart is > asking them to reprogram their systems before they're in a position to > derive a benefit from doing so. ISPs adopting the solution have a clear economic incentive to upgrade their routers. I figure the cost of firmware upgrades would be minimal. Maybe they upgrade their firmware regularly anyway - so there would be no extra cost or inconvenience, assuming the router vendors made the one-off investment of adding the new feature. I figure router vendors would be highly motivated to do so, in part to ensure their routers continue to implement every protocol in creation - and also to show how well engineered and open-ended their products are. Assuming modern routers can be upgraded with firmware, I don't think it is too much to ask all transit ISPs to ensure their routers are ready for the new arrangements, with 2 to 4 years notice, or whatever is required. The alternative is launching with complex, inefficient encapsulation and then in the longer term transitioning to something like EAF and PFL once all routers have the new capabilities. One gotcha with this idea of avoiding encapsulation from the start is the difficulty of testing the system on a global basis before the transit routers have the updated functionality. Maybe we could prototype with encapsulation, without bothering to handle the PMTUD stuff. > I'd also suggest a change in point 1. You have: > > 1 - The solution must provide immediate and > compelling benefits to any new or existing > end-user networks which adopt it, irrespective > of how many other networks have so far adopted > it. > > I'd change "end-user networks which" to "end users who," and then > "other networks" to "others." > > I know you're not a fan of the strategy B approaches, but some of them > have the prospect of being functional as soon as two participating > hosts have been upgraded regardless of what happens with the rest of > their local networks. Initially I created new text based on your suggestion. Then I had second thoughts and for now will retain the current text. I don't want the text to assume that all scalable routing solutions are all core-edge separation approaches, meaning network-based systems such as LISP, APT, Ivip and TRRP (Six/One Route too?) with ITRs and ETRs etc. (The next bit is for readers learning their way in scalable routing.) In your taxonomy: http://bill.herrin.us/network/rrgarchitectures.html as used in: http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 and as I attempted to match to actual proposals: http://www.firstpr.com.au/ip/ivip/rrgarch/ Strategy B covers core-edge-elimination architectures. This is very different from core-edge separation. See: Towards a Future Internet Architecture: Arguments for Separating Edges from Transit Core Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf Core-edge elimination involves major host changes - to stacks and I think applications. There are no changes to DFZ or other routers. Hosts do all the work. AFAIK, such schemes are only potentially practical for IPv6, because every host needs two addresses - at least one ("locator" I think) that it uses to connect to the network and one ("identifier" I think) for its applications to use, which is still used if the "locator" changes. There's not enough space in IPv4 to do his on a large scale. I think your suggested change was to allow for a solution which involved individual hosts, rather than whole networks. Can these Strategy B approaches be adopted by individual hosts, without any change to addressing in the networks they are operating within? I will assume they can be - and that they do not involve any network making a change to its routers or connection to ISPs. Ideally, the wording wouldn't assume the schemes are either host-based or router-based. I could update point 1 like: 1 - The solution must provide immediate and compelling benefits to any new or existing end-user networks or end-users who adopt it, irrespective of how many other networks or end-users have so far adopted it. But the rest of the text assumes that networks adopt the solution, not individual hosts. Whatever the type of solution, it will in practice be adopted by entire end-user networks. (Though in principle there might be only one host in such a network.) Our goal is to provide multihoming etc. on a scalable basis for end-user networks, so I think it is best to retain consistent terminology about networks adopting the solution, even if the solution involves changing only the hosts in the network, rather than the network itself, by way of altering its routers or method of connecting to one or more ISPs. Thank again. - Robin From rw@firstpr.com.au Sun Apr 19 21:50:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA573A6A4D for ; Sun, 19 Apr 2009 21:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0aqFmZWwrHc for ; Sun, 19 Apr 2009 21:50:17 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 1F04D3A6928 for ; Sun, 19 Apr 2009 21:50:16 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 1D6D817558B; Mon, 20 Apr 2009 14:51:31 +1000 (EST) Message-ID: <49EBFF59.90200@firstpr.com.au> Date: Mon, 20 Apr 2009 14:51:37 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> In-Reply-To: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 04:50:19 -0000 Short version: I support a relatively specific, narrow, use of the term "anycast" - where one of two or more destination hosts may receive the packet. I recognise "anycast" is used rather loosely - one of those words which needs to be preceded by someone waving a red flag and carrying a definition for the purposes of the discussion. Also correcting what I think are some misunderstandings about Ivip. Hi Bill, I won't comment on all you wrote - just on a few points. I grappled with the meaning of "anycast" in 2007 and 2008: http://www.google.com/search?q=Robin+anycast+RRG+-%22rrg+Discussion+Archive%22 Initially I called the ITRs in the core "anycast ITRs in the core/DFZ". I was convinced by one of the LISP team that this was an incorrect use of "anycast". So I renamed them to OITRDs - "Open ITRs in the DFZ". I decided that the best meaning to assume for "anycast" is an address or prefix which is advertised as in a local routing system and/or the DFZ from multiple routers and where the packets are actually handled by separate hosts. So if an ISP has two border routers both advertising 12.34.56.0/24 and within that, the address 12.34.56.78 is handled by a single host, then this is not "anycast" - it is just advertising the same route from two or more border routers. If there are two or more hosts responding to the same address - 12.34.56.78 - and each one has its own router advertising the encompassing prefix, then this is a true use of "anycast". The address 12.34.45.67 is not the name for any particular device - it is just an address which is used by multiple destination hosts, all of which presumably use the received packets in some consistent and useful manner. They don't have to respond in exactly the same manner, but they presumably exist for a common purpose and can collectively be relied upon to perform one or more tasks. In the case of OITRDs there are typically more than one OITRD which advertises a given MAB (Mapped Address Block). They all tunnel packets addressed to any given micronet (such as 12.34.56.77 to 12.34.56.80) to one ETR address. Generally, with Ivip, that will mean one (non-anycast) ETR which will forward the packets to one end-user network where the packets will go to one host. So I think that OITRDs, LISP Proxy Tunnel Routers (PTRs) etc. are not inherently a form of anycast. I could imagine anycast being used with with Ivip - and probably in principle with LISP, APT or TRRP: 1 - Anycast ETRs. There could be multiple physical ETRs with the same address. So the packets are tunneled from ITRs to whichever (typically "closer") ETR the DFZ and internal routing system forwards the tunneled packet to. It is a separate issue whether those multiple ETRs forward the packets to a single destination host or to a separate host for each ETR. 2 - Anycast hosts. There may be one ETR or there might be anycast ETRs as above. There are two or more destination hosts with the same address, and depending on how the one or more ETRs link to these destination hosts, the packets may go to one or another of them. I am not sure what use these arrangements might be - but they may well have uses for non-TCP, simple request and response protocols. There may well be a role for anycast query servers in local networks - however I think it is more likely to involve anycast or some other zero configuration default arrangement so that ITRs can discover their nearest Query Servers' addresses and so use one or more of them. I may use TCP between the ITR and the Query Server, so we can't have the Query Servers on anycast addresses. You wrote, in part: > You'll no more run your network on just one ingress encoder than you'd > run it on a single DNS server or a single T1. Okay, well, some of you > will but those of you who are serious about reliability won't. No, > you'll have two or several ingress routers. And each one will ANYCAST > the default route so that if one of them fails the packets seamlessly > reroute to the other. Likewise, I don't think that the word "anycast" should be used to describe multiple ITRs (internal to a network or OITRDs in the DFZ) advertising the same MAB - since this doesn't necessarily and won't typically result in the packets being handled by multiple destination hosts. > What about the transition period? For a while there'll be both legacy > routing and the ITR/ETR routing. How will you bridge the legacy > systems in? Well, every one of us who has come up with a strategy-A > solution has posited some sort of ITR in the core that advertises > short prefixes out to the legacy system and encodes the packets it > gets for delivery in the new system. This is a description of Ivip OITRDs or LISP PTRs. However, I don't think of it as a "transition period". I expect there will always be some networks which don't have ITRs, and so there will always be a need for OITRDs. > Will we have one for all the ETRs > serving 192.0.0.0/8 and one for all the ETRs serving 193.0.0.0/8? Yeah > right. We'll have 20 geographically distributed ITRs for 192.0.0.0/4, > each of which will announce 192.0.0.0/4 via ANYCAST. There are various ways it could be done. You could have a single set of widely distributed OITRDs each advertising every MAB. You could have one set of OITRDs advertising one or more MABs and another set advertising others. See: Ivip business models: fast push & OITRDs 2008-04-18 http://www.ietf.org/mail-archive/web/rrg/current/msg02100.html > And if you plan to go out and query a distributed map database (as > more of you do now than did two years ago when I proposed it) then > you'll announce your map roots via ANYCAST too. I think LISP-ALT is the only other currently developed proposal (AKA candidate architecture) which uses a global query server system, as does your TRRP system. TRRP is a DNS-like query server system and LISP-ALT's is totally different - there are no servers advertised in the Internet in any way. Each ITR is either a part of the ALT network or it connects to a Map Resolver which is. So AFAIK, TRRP is the only one which might use anycast as part of the mapping system, in the form of anycast servers in the global DNS-like query server system. Anycast may well have a role in LISP Map Resolvers, but this is not the same as anycast DNS-like servers as you would use in TRRP. > Stable TCP over anycast would, by the way, be fantastic news for the > CDNs and their customers which include, oh, just about every major > content provider on the web. I can't imagine any robust approach to TCP using anycast. The routing system could change at any time and direct the packets to another destination host. Unless all those hosts were in some way linked to behave as a single system, TCP or any other protocol in which the host stores state, would not be reliable. > You do a map lookup on the destination. You get a prioritized list > of of egress routers. Ivip's mapping has no list. The mapping specifies the matching micronet and has a single ETR address. If that ETR goes down, it is up to the end-user network - or more likely a multihoming monitoring company they appoint to do the work - to decide on an alternative ETR address and to send this as a real-time mapping update, which all the ITRs which need it will get in a few seconds. See the new section "The actual source of mapping changes" in the recently updated Summary and Analysis: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf > Of course, you might implement strategy A badly. You can build a rigid > design where the map is static and the ingress router has no > discretion whatsoever for which egress it sends to. But none of you > made that mistake in your designs, right? This is not a mistake in Ivip. It is a core part of the architecture. It is GOOD that the end-user network can and must control the mapping in real time. Then there is no need for multiple ETR addresses, ITRs having to decide between them etc. Also, it modularly separates the decision making process about where to tunnel packets (for instance due to an outage being detected) right out of the core-edge separation system. LISP, APT and TRRP monolithically integrate this, because in none of these systems do you have essentially real-time mapping distribution - so you must provide multiple ETR addresses and add a lot of complexity to ITRs so they can decide which ETR address to use. - Robin From tony.li@tony.li Sun Apr 19 22:02:38 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C153A69E5 for ; Sun, 19 Apr 2009 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFZJIJkFiqem for ; Sun, 19 Apr 2009 22:02:37 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 6DD453A6817 for ; Sun, 19 Apr 2009 22:02:37 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id hUMm1b0050mlR8UA2h3toJ; Mon, 20 Apr 2009 05:03:53 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id hh3s1b00Q3L8a8Q8Xh3sZP; Mon, 20 Apr 2009 05:03:53 +0000 Message-ID: <49EC0200.9060600@tony.li> Date: Sun, 19 Apr 2009 22:02:56 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> In-Reply-To: <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 05:02:38 -0000 Hi Bill, > I disagree with you there. Broadcast and Multicast are forms of > non-determinisitic routing. Anycast and unicast are both forms of > deterministic routing. Interesting. That rumbling sound you here is Dino's keyboard... ;-) How do you figure it's non-deterministic? If you take a global snapshot at any given point in time, then for any given mcast packet sent by a given source, it's straightforward to compute the receivers. Similarly for broadcast, it's trivial to see who should receive it. > When I say, "Unicast is a case of anycast in which there is only one > destination endpoint," I really mean it. Unicast doesn't exist. It's > just a convenience label for Anycast in which only one destination > endpoint is currently active, and that's precisely how the routing > system treats it. Except that we haven't figured out how to aggregate anycast, which from a routing perspective, makes it completely unique. > The same can't be said of multicast. Multicast has different semantics > even if there's only one host in the group. Say more please, I'm not following. > Still think I haven't proposed a radically different way to visualize > the routing system? Not yet, but I don't grok your perspective yet. > If using DNS that way worked, we could all go home. Unfortunately, > what happens is that the ntp server looks up the name to address > binding once when the machine boots and never reconsiders it during > the year and a half the server is running, even after queries to the > server's IP address stop returning data. Ok, but how would a map resolution change that? Is the key point here that whatever mapping function is used, the map result has a TTL and needs to be refreshed periodically? Or, the applications need to be able to trigger a refresh? > The strategy B systems essentially replace DNS with a system where the > timeouts are mandatory. The strategy A systems add an additional layer > of indirection between DNS and routing so that the DNS is free to > continue its trend toward static bindings. In both approaches we > acknowledge that decades of practice have rendered the existing > forward DNS irretrievable as a source of dynamic binding to the > routing elements. Hmmm... not at all convinced. And I'm still not seeing how strategy A does anything significantly different other than giving us a chance to re-implement differently. You certainly don't want the ITR to be application/service aware, so it's simply forced into periodic retries. It seems like that is also going to have numerous downsides, such as broken anycast connections. > If it quacks like a duck... It doesn't seem to quack at all. ;-) Tony From rw@firstpr.com.au Mon Apr 20 02:01:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEC03A6B2B for ; Mon, 20 Apr 2009 02:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMORWF5g49jV for ; Mon, 20 Apr 2009 02:01:04 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C57AD3A6A97 for ; Mon, 20 Apr 2009 02:00:43 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id B1B1A1756AE; Mon, 20 Apr 2009 19:01:57 +1000 (EST) Message-ID: <49EC3A0C.8090008@firstpr.com.au> Date: Mon, 20 Apr 2009 19:02:04 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> <49EB4294.2070601@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Scalable solution hitting IPv4's limits / main text X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 09:01:07 -0000 Long message ahead: Discussing Tom's "Liquidity Systems" view of the Internet's routing and addressing system. I haven't yet found any insights from it which help with scalable routing. Discussion of how with LISP, APT, Ivip or TRRP more and more address space will be needed by the "MAB" companies who rent the space out as EID prefixes micronets or whatever is the name for the new kind of scalable address space for end-user networks. It follows that a greater proportion of space will be needed by these companies, and a lesser proportion by ISPs. I give a contrived example of an ISP with a single /24 being able to serve 10,000 end-user networks which between them have 100,000 IPv4 addresses of EID / micronet etc. space. Also, how competition between these MAB companies will help drive a healthy market for obtaining space which is less profitably utilised than will be possible with a good scalable routing solution. Hi Tom, Thanks for this: > Thanks for taking (what must have been considerable) time to reply in > detail. > > The above two modifications do, indeed, adequately reflect the concerns > I expressed. It did take a while to work it out. Originally I wasn't going to add anything, but I am happy your concerns and discussion prompted me to add these two paragraphs. >> I want the list of constraints to be a terse description of things we >> all (ideally) agree are true. The focus is on what is needed for >> end-user networks and their ISPs to adopt the solution. >> >> As a statement of fact, this text does not assume that there is a >> solution which will meet all these constraints. I think there will >> be solutions which meet them all in IPv4 - but I agree that during ' >> adoption and in the decades to come, no matter how ubiquitously the >> scalable routing solution is adopted and how well it works, the >> address space shortage is likely to limit the IPv4 Internet's >> capacity to provide multihoming etc. for all end-user networks which >> want it. > > Of course I agree on this point, but this particular goal was never > explicitly stated, nor implied, nor even contemplated by me. > The idea that merely "wanting it" -- i.e., full access to all of the > 'rights, privileges, and responsibilities' that are enjoyed by direct > participants in the Internet's routing subsystem -- is or should be by > itself sufficient for any institution to lay claim to a share of that > system's finite carrying capacity -- fundamentally contradicts the > findings of my own personal experience and research (maybe common sense > too, if I presumed to know what that was). With Ivip at least, and I think also for LISP, APT and TRRP, wanting / needing (who is to say which is true?) multihoming, TE and portability and then getting it via Ivip certainly does not involve: full access to all of the 'rights, privileges, and responsibilities' that are enjoyed by direct participants in the Internet's routing subsystem If a network either does not exist, or exists on PA space, then it has a price to pay to obtain some Ivip-mapped "SPI" (Scalable PI) address space, whether it be a single IPv4 address or thousands of such addresses. If the network already exists, it also need to be renumbered to the new SPI address range. There will be ongoing rental fees for the SPI space, paid to the MAB company who "owns" or at least has rights to, the MAB (Mapped Address Block) which is advertised in BGP and which contains the User Address Blocks (UAB) of many other end-user networks. How each end-user network splits up the one or more IP addresses in its UAB into micronets (1 or more contiguous IP addresses with a single mapping) is up to the end-user network. They will typically pay per mapping change - to the MAB company, who will typically pay a Root Update Authorisation System (RUAS) company to send the mapping change to all the world's full database Query Servers. The MAB company will also directly or via some other company run OITRDs (Open ITRs in the DFZ) which are necessary for handling packets sent to SPI addresses in its MABs from hosts in networks without ITRs. Since traffic volumes for OITRDs would vary enormously, the end-user network will typically need to pay in proportion to how much traffic these OITRDs handle for their micronets. So merely "wanting" something won't make it happen. The end-user network needs to be willing to pay for all this. It won't be very expensive when compared to the total costs of getting an AS, PI space etc. While the end-user network gets its own set of global unicast IP addresses (SPI addresses), which it can use at any ISP which has an ETR, this doesn't to me constitute what you wrote and which I quoted above. These end-user networks don't need to know anything about BGP etc. or be responsible for running DFZ routers. This will be a mass-market service, competitively provided by multiple MAB companies all round the world. These MAB companies may be ISPs - but they need not be, because there is no need for physical infrastructure other than someone to run their OITRDs in various locations around the Net. Before Ivip etc. for an end-user network to gain global unicast addresses it either had to rent some PA space from an ISP or get an AS, and gain a PI prefix (and then have ISPs advertise this prefix). Once Ivip or similar is available, they will have a third, highly attractive, option: rent some SPI address space in a MAB and use it at any ISP which has an ETR. Imagine a scenario in which an ISP-M sets up shop purely for the purpose of serving customers with SPI addresses. ISP-M may or may not have MABs of its own to rent space in. I will assume it doesn't. Its customers will already have rented their SPI space from one of many MAB companies. In Ivip, the ETR is typically in the ISP network. (Except for with TTR mobility, where the ETR is the Translating Tunnel Router, ideally located near the access network.) Let's say each ETR can handle 100 end-user networks. Let's say ISP-M has 10,000 separate end-user network customers, each with an average of 10 IP4 addresses of SPI space. The entire ISP-M could be run nicely on a /24. It needs 100 global unicast ordinary ("RLOC" in LISP terms) IP addresses for its ETRs. It can use the same addresses for ITRs too - and ITRs will frequently be in the end-user networks anyway, including in some sending hosts. ISP-M also needs addresses for query servers etc. So ISP-M could be serving 100,000 IP addresses of SPI space via 256 "RLOC" addresses. If all those end-user networks were multihomed to another ISP, then in theory they could all be served by two similar ISPs ISP-M and ISP-N, each with only a /24 of space themselves. LISP as currently conceived is a little differently. The LISP designers assume that the ETRs will be at the end-user network. So each such network needs a single "RLOC" address from each of its ISPs for the ETR which links to each ISP. Therefore, ISP-M would need at least 10,000 RLOC addresses and so would ISP-N. LISP-ALT, as currently conceived, needs the ETRs to be at the end-user network for at least two reasons. Firstly, reachability of the ETRs from any ITR is taken as meaning reachability of the end-user network. (This is not the case for Ivip.) Secondly, the ETRs need to act as a unified system, so they need to be owned and operated by the end-user network, and robustly linked together no matter what outages etc. occur. While LISP is less efficient with RLOC space than Ivip, the point remains that an ISP serving SPI customers does not need to have much space at all. One or more end-user network with 64K addresses can in principle work fine from a single ETR. This significantly changes the address requirements for ISPs. There still is an address requirement for this SPI space - but it is handled by MAB companies gaining rights to large slabs of address space, and then making money by renting that space out. For an end-user network in any one physical location, they may only be able to choose between one or a small number of ISPs, since only those ISPs have physical infrastructure to their site. However, the end-user network's SPI address can come from any MAB company in the world. More on the competition effects of this below. > More precisely stated, the implications of my recent work suggests that > the very nature of the constraints that dictate the requirement for > "incremental deployability" are *the same* structural constraints that > absolutely dictate that any/every conceivable current and future routing > system that could ever be adopted and deployed in this manner will -- > inevitably, necessarily -- embody some set of features that ultimately > make all such systems vulnerable to some version of *the same* systemic > risks to which the current system is vulnerable, namely: IOW: a good scalable routing solution can improve scalability within IPv4, but as far as we know, can't help any one network or all uses, bust out of IPv4 dependence to use some other system, such as IPv6. To achieve such an outcome may well be impossible. > -- "inflation" (c.f., generalized/cumulative/direct impact of individual > demands on routing system carrying capacity that are borne by all/other > participants in that routing system) These financial system analogies strike me as rather loose. End-user networks adopting SPI space place no burden on the BGP control plane whatsoever. There is a burden, from each MAB, but that is not related to how many end-user networks share that MAB, how many micronets they split the MAB into, or how frequently they change the mapping for those micronets. With Ivip, mapping changes are paid for by the end-user network - so they are not an unreasonable burden on the RUAS. (This is not a perfect system, but it goes a long way to paying for the cost the mapping changes impose on all parties which need to carry it.) Indeed, these charges are a source of revenue and MAB companies would compete in part by offering lower fees which still enabled them to run a profitable business. Hopefully all this will be clear if you read: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf and Ivip business models: fast push & OITRDs 2008-04-18 http://www.ietf.org/mail-archive/web/rrg/current/msg02100.html > -- "deflation" (c.f., generalized/cumulative impact of non-availability > of routing system capacity and/or address resources, which manifests as > diminished growth potential for existing participants and a progressive > barrier to the emergence of potential new participants) IOW: Shortage of address space. This will still happen with Ivip or whatever, but it will happen later due to the ability to slice and dice the address space into small increments which can be used efficiently due to being very useful to many end-user networks and profitable for MAB companies when rented at a cost end-user networks are happy to pay. > -- "stagnation" (c.f., generalized/cumulative impact of non-availability > of "standard"/"DFZ" routing system capacity and/or "standard"/uniform > address resources, which manifests as a progressive degradation of and > loss of confidence in the consistency/predictability of precisely those > "network effects" that make a shared, inter-domain routing system so > valuable to its direct participants, as well as to indirect stakeholders). IOW: When existing and new companies find it harder than is ideal for them to get address space, due to shortages, hoarding, unfair distribution systems etc. > Another way of putting this is that the specific problems that RRG is > trying to solve are actually just specific manifestations of more > general risks -- risks that are *not* primarily or exclusively an > artifact of current routing and addressing technology. I disagree. The general problems of IPv4s address space being finite and less than would be ideal are a totally separate matter from the problem of unscalable growth in the burden of work on DFZ routers, together with the inability of those so burdened (DFZ router operators) to recover costs from those who impose the burden. This growth is primarily due to the fact that at present, without a scalable routing system, the only way an end-user network can get multihoming, TE and portability is to get its own PI prefix (one or more /24s - is a /22 a typical allocation?) and then to advertise this as one or more prefixes (/24, /23 etc.) in the global BGP system. A core-edge separation scheme such as LISP, APT, Ivip or TRRP (Six/One Router too, but just for IPv6) would change all that, since there would be this new kind of SPI (my term, not used in LISP etc.) space which would suit the needs of large and small end-user networks much better than getting their own AS, PI prefixes etc. Maybe there is some aloof framework from which you can see the routing scaling problem as a specific instance of some more generalised set of circumstances. To me it is a specific set of circumstances which occurs due to BGP's finite ability to cope with large numbers of prefixes and frequent updates to those prefixes. It is the same in principle for IPv4 or IPv6, but there is no problem yet for IPv6, and the IPv4 scaling problem happens to be occurring at a time when fresh IPv4 space is running out. It so happens that a routing scaling solution will, in my view, enable much better utilisation of IPv4 address space. How much time that will buy us, I am not sure. It depends a lot on population growth - which can't be assumed given global warming's effects - on Internet usage, and on whether cell-phone networks want to use a global unicast IPv4 address for each device, or whether they will use IPv4 NAT or IPv6 instead. > Rather, these > risks are a natural, organic, and (probably) largely unavoidable feature > of *all* liquidity mechanisms -- i.e., all "technically mediated > exchange systems." They are unavoidable because a necessary condition of > possibility for the existence/emergence of such mediated exchange > systems is the prior existence of a population of diverse, independent, > often competing economic agents (individuals, institutions, etc.), > members of which might often enjoy opportunities to productively > interact with one another, but for the existence of various > "transactional frictions" (foregoing details on this for now). > "Liquidity system" and/or "technical medium of exchange" are the > interchangeable terms that I've adopted [1] to describe the thing that > emerges in some (not all) situations, which is functionally > distinguished by its capacity to reduce if not eliminate those frictions > for all participants who voluntarily adopt it -- thereby becoming > participating members in that particular liquidity system. The intrinsic > friction-reducing benefits of participation (growth, profit, etc.) > attracts and retains participants within that system, which > creates/strengthens incentives for system participants to interact with > each other ever more intensively (producing as a result the devision of > labor, specialization, etc.). However, those same benefits also have the > organic effect of intensifying competition between system participants, > which eventually results in their becoming aware of the liquidity > mechanism itself, and its possible uses as a strategic, > (anti)competitive tool. > > I'll spare the list the rest of the evolving story. Those interested can > find more of it is on my personal website (links below). I think there are some interesting parallels between IP addressing and currencies, but I am not sure that they have so far provided me with any important insights which help me solve scalable routing or the larger problem of transitioning to a system without oppressive address space limits. > In any event, I wholeheartedly share RRG's ambition to contribute to the > alleviation these problems. The story above explains why systems like > ours need liquidity mechanisms, and what benefits they confer -- and > risks they impose -- on those systems that are lucky enough to have one. > However, that "need" does not entail that it will be fulfilled. I understand this as the purported "need" to solve the IPv4 addressing limitation problem does not mean that this will be achieved. I am sure humanity will cope with being boxed into IPv4 indefinitely. It is not ideal, but it is not necessarily disastrous either. So I don't regard it as a true "need" like our need for air, water, food, space, the right temperatures, social and political freedom and structures etc. > Obviously, another absolute condition of possibility is the existence of > some candidate mechanism(s) that is capable of initiating and sustaining > this liquidity process over time. Not all candidate liquidity mechanisms > are created equal, and I think of RRG's core mandate as the definition > of the "best possible" successor liquidity mechanism for the Internet > that we have inherited -- with "best possible" defined as (max. > [probability of adoption * probability of sustainability, given known > structural and exogenous risks]). I am not sure if RRG folks would recognise the group's goals if the encountered them unawares expressed in those words! I think the RRG's role is to provide a scalable routing solution which achieves something like the three goals A, B and C in my footnote: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ I also suggest we aim for D and E (Mobility and open-ended flexibility), but these are not officially part of the RRG's goals. > That said, I do not believe that the > problems that RRG is trying to solve are amenable to any complete or > final "solution" -- nor even to much symptomatic relief unless the root > cause(s) of the problems are recognized and addressed directly. Do you think there is something important we haven't recognised, and that when we do, we will be able to solve the larger problem of migrating from IPv4 to something more expansive? > And that brings me back to the point of departure, Robin, which was the > contrast between "desire" or (self-asserted) "need" vs. *eligibility*. > It seems to me that the formula that made it possible for the last > RRG-relevant domain-wide solution (CIDR) to "work" -- i.e., to be both > (1) accepted by, at least, the minimum set of parties required to get > started, and (2) to continue to be regarded as tolerable/acceptable by > the majority of direct, indirect, and aspiring stakeholders thereafter > -- involved three key ingredients: > > 1. The idea that there is a (i.e., at least one) technically > justifiable/defensible set of criteria that can be used to determine an > institution's "eligibility" to consume some share of the common/default > routing system's finite carrying capacity. To maximize sustainability > over time, these criteria should establish a link between > individual-level demand for participation and the potential system-wide > benefits of allocating a share of finite system carrying capacity to the > aspiring participant. > > 2. To further maximize sustainability over time, eligibility criteria > should be responsive to changing conditions, e.g., an expansion of the > system's finite carrying capacity should be reflected in the > corresponding eligibility criteria. That makes eligibility criteria > management dependent on the active participation of those who are > closest to the implementation technologies and practices. > > 3. These eligibility criteria should, in both principle and practice, > form the primary basis for allocating finite routing system carrying > capacity. I am wary of using the term "carrying capacity" to refer to the resource of address space. To me, carrying capacity is to do with moving packets physically. The question of address space quite a separate set of limitations on the entire network. > Achieving this in a sustainable way is only possible if the > eligibility criteria are administered, and the associated resources > distributed, through some neutral, transparent mechanism that is > substantially insulated from the competitive dynamics that govern most > direct interactions between existing liquidity system participants. In > other words, the allocation mechanism must be insulated from the very > dynamics that make the liquidity system itself so valuable, and which > make the potential risks and consequences of liquidity system capture, > collapse, or premature obsolescence so severe. You mean you don't believe that the Market always produces the best outcomes for all???? This is not Capitalism's finest hour, and I don't have ultimate faith in markets, but I don't see them as useless or inherently prone to failure. I think your previous paragraph asserts that acceptable outcomes can only arise for all participants, in the case of IPv4 address space allocation at least, if there is is some overarching, "fair" (however defined) system which does not at all resemble a "market". I think there is some truth in this. For instance, if the allocation system gives 90% of the space to 10% of the applicants, then the outcome is bound to be unacceptable for most. But let's consider the power of a market to achieve not so bad outcomes, even from a lousy starting point. Let's say Ivip or whatever enables MAB companies to obtain (beg, borrow, cajole, purchase or rent) space and rent it out profitably as SPI space. MAB companies can get address space from anywhere, rent it to anyone and need no physical infrastructure (they can pay other companies to run OITRD and to handle the mapping). So there is going to be a great competitive market developing between MAB companies and all the end-user networks for whom the costs of SPI space (fairly low) make it worth getting, for some combination of multihoming, TE and/or portability between ISPs. Consider yourself as a MAB company, and me as another one. We are renting out space at a rapid rate and our ability to do so profitably depends in large part to our ability to get new space for this purpose. Companies like yours and mine are able to turn IPv4 space into a cash cow. Now consider some ISP ISP-A or AS end-user network NET-B. They have currently got a bunch of space. That space is worth something to them, and they have certain costs. If the way they use their space is less profitable per IPv4 address than what your MAB company or mine is ready to pay for it, then it is in their interests to move their usage into a corner of their existing space and rent or sell or whatever the rest of the space to a MAB company like yours or mine. This new ability of the MAB companies to use space very effectively means that market forces alone will cause companies to be motivated to compact their usage to similar efficiency and then sell whatever space they no longer need. (This would be dependent on RIR policies allowing sale or rental of space. I am not assuming that would be the case - but one way or another, if someone has a bunch of stuff they don't really need and someone else needs it and is willing to pay for it, that thing is going to go one way and money the other before long.) Your gloomy model seems to assume that all address space is owned by ISPs, and that an ISP-X relinquishing space to an ISP-Y is necessarily going to loose out. But ISPs only compete in defined geographic regions. If an ISP in Melbourne Australia gives some space to an ISP in Borneo, there is no change in competitive advantage. The MAB companies do compete globally, so they will be fighting to get space as long as they can rent it out profitably. I think the combination of: Greatly increased ability to use IPv4 space close to 100% efficiency. A market for this in the form of non-mobile end-user networks wanting multihoming, TE and portability. A further potentially vast and lucrative market for mobile end-user networks (cellphones / PCs) wanting just a single IPv4 address they can use anywhere via the TTR Mobility system. A market for advertisable prefixes of global unicast IPv4 space developing by hook or by crook. will enable a gradual but over time thorough saturation of IPv4 usage with generally stable cost per IPv4 address, due to the global demand from MAB companies competing with ISPs and the large PI using end-user networks for available space. The more end-user networks use SPI space, the less space an ISP needs to run its network as some proportion of its customers convert from PA space to to SPI space. So it is possible to imagine many end-user networks being on MAB space, the rest being on PA space, and so the ISPs having all the space not devoted to MABs. That space would be largely devoted to DSL etc. PI customers and the rest would be used for ETR and ITR addresses. This is simplistic, but it illustrates how market forces would encourage networks which were not making much money from their address space to rent or sell it to those who can. There would still be iniquities - such as if those who happened to get a huge amount of space were able to profit by renting or selling it. My point is that these market processes, while not ideal in principle or in practice, would to quite a large extent provide sufficient space to the ISPs and MAB companies who need it, because they would be able to make money from this space - and so could afford to buy or rent it from those who are using it less intensively and presumably less profitably. > So, to your point about not being able to "provide multihoming etc. for > all end-user networks which want it," I respond that that is not a > realistic goal, given the joint constraints of technology and human > nature. I was using "want it" as shorthand for "want it sufficiently to pay the price, which would be lower than the only current option: an AS and a PI prefix". I like this better than "need" it, because it is easy for people outside the network to say that some end-user network doesn't really "need" multihoming or whatever. If Ivip or something likes it succeeds, it would have the effect that SPI space and its benefits be generally available at a price that is attractive to many more end-user networks than would currently be able to afford PI space, even if it was available. > I seriously doubt that it ever will be, because in an uncertain > world full of real and/or potential competitors, people will always > "want" more than they currently "need," and nothing short of infinite > carrying capacity or a change in human nature can remedy that. Sure, I was trying to be concise by using just "want". > However, > I believe with even greater seriousness that we must aspire to preserve > -- or barring that possibility to recreate with the shortest humanly > possible interruption -- those three conditions, and the kind of > "eligibility-based" system admission process that results when those > conditions are in place. I know little about the machinations of RIRs. I imagine that already and increasingly in the years to come, some highly sophisticated and enlightened policies are being developed and enforced regarding who gets to keep whatever space was previously allocated them in the prior days of Plenty, when it was assumed that a much lower rate of actual utilisation was all that was practical. If Ivip or similar works as I intend it then this will set a new high standard for close to 100% utilisation of IP addresses. I expect many end-user network will be happy with one, a few or a relatively small number of addresses whereas in the past, they might have been able to justify getting a /22 or similar. > I believe this strongly because the history of liquidity systems past > suggests that if those conditions are not sustained or restored in > (effectively no) time, whatever endures may not be redeemable, or worth > redeeming for that matter, and in any event system maintenance by then > is then likely to have become someone else's problem. This is pretty bleak. I don't see any great disaster occurring in IPv4. I just think we will develop means of using the space more and more intensively. A scalable routing solution such as LISP, APT, Ivip or TRRP would be a crucial part of this. > Just as the "need" > for a liquidity mechanism like TCP/IP does not guarantee that one will > emerge and be widely adopted, neither does that need guarantee that an > existing mechanism will endure, or in enduring superficially ("in form > only") continue to provide those substantive benefits that make > liquidity systems so valuable, and so vanishingly rare in the wild. I agree that systems don't automatically run the way most people would like them, but I don't foresee any great crunch in IPv4, unless perhaps everyone insists on having a cellphone with its own dedicated IPv4 address. That is perfectly possible with the TTR Mobility approach - but there probably won't be enough IPv4 addresses to go around. That won't be a sudden thing. Humanity will cope with cellphones not having their own IPv4 address! > Monetary liquidity systems have come and gone in the past -- but the > ones that have both "gone" and subsequently "come back" have almost > universally been backed by sovereign power -- and 100% of those were/are > exclusively national in scope. What that portends for the future of our > own, first-of-its kind, extra-territorial, attachment-based liquidity > mechanism is left as a exercise for the reader. Hmmm - it is intriguing to think that this uncommonly well designed networking protocol actually created something like an international currency. IPv4 address space futures anyone? > Note: To prevent the weight of this message from giving the Internet a > hernia, I've split out comments on the footnote next in a separate > message, to follow shortly. > > Thanks again for your responsiveness... > > TV The Internet will be fine. It has an endless supply of recycled electrons. The time, interest and attention span of RRG participants is another matter - it is a precious resource. There should be a refreshment stall here for people who made the distance. That unpleasant prickling sensation you feel is one or two RRG folks sticking pins in your effigy every time you write more than about 4 paragraphs in a list message. Maybe they will give mine a bit of a rest. - Robin From tvest@pch.net Mon Apr 20 04:39:30 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906F83A6AF2 for ; Mon, 20 Apr 2009 04:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn191hVGDuhX for ; Mon, 20 Apr 2009 04:39:29 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 6D5113A6B6E for ; Mon, 20 Apr 2009 04:39:29 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA02.westchester.pa.mail.comcast.net with comcast id hlmt1b0020ldTLk52ngLKx; Mon, 20 Apr 2009 11:40:20 +0000 Received: from [172.16.1.3] ([24.125.119.245]) by OMTA04.westchester.pa.mail.comcast.net with comcast id hngk1b00D5Hlxyo3Qnglig; Mon, 20 Apr 2009 11:40:45 +0000 From: Tom Vest To: Robin Whittle In-Reply-To: <49EC3A0C.8090008@firstpr.com.au> References: <49E69AB5.6060409@firstpr.com.au> <49E6C0A9.5000606@firstpr.com.au> <5AE46131-A768-4159-8F28-75D1A5CA27B4@pch.net> <49E7F77E.10805@firstpr.com.au> <49EB4294.2070601@firstpr.com.au> <49EC3A0C.8090008@firstpr.com.au> Message-Id: <1E63F894-FC4D-4B05-9B26-DC1A0C155759@pch.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 07:40:42 -0400 X-Mailer: Apple Mail (2.930.3) Cc: RRG Subject: Re: [rrg] Scalable solution hitting IPv4's limits / main text (time out) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:39:30 -0000 On Apr 20, 2009, at 5:02 AM, Robin Whittle wrote: > Long message ahead: > > Discussing Tom's "Liquidity Systems" view of the > Internet's routing and addressing system. > > I haven't yet found any insights from it which > help with scalable routing. > > Discussion of how with LISP, APT, Ivip or TRRP > more and more address space will be needed by the > "MAB" companies who rent the space out as EID > prefixes micronets or whatever is the name for the > new kind of scalable address space for end-user > networks. > > It follows that a greater proportion of space will > be needed by these companies, and a lesser proportion > by ISPs. I give a contrived example of an ISP with a > single /24 being able to serve 10,000 end-user > networks which between them have 100,000 IPv4 > addresses of EID / micronet etc. space. > > Also, how competition between these MAB companies > will help drive a healthy market for obtaining > space which is less profitably utilised than will > be possible with a good scalable routing solution. Hi Robin, Thanks again for the very detailed response; it is flattering whenever anyone take the time to do something like this, even if the response is substantially or entirely critical. So, thank you once more. I can certainly understand how one might arrive at an initial impression that the "liquidity system" view provides no new insights for how to structure RRG's efforts, and even how a cursory or partial reading might leave one with doubts about its overall validity. I will do my best to challenge those impressions as soon as I get past a couple of urgent work assignments, hopefully in the next 24-36 hours. In the mean time, I will simply remark that the theory did not emerge with RRG in mind, but rather has been developing over the last six years, initially based on my hands-on experience as a very large operator working across many different material, commercial, and regulatory environments, at a level of the industry where largely unconstrained strategic bargaining plays a substantial role in shaping some relatively inflexible decision making constraints for the rest of the industry (and before that as a very well-placed but passive observer of the topmost levels of the international telecom and monetary policy-making spheres, and after that as an advisor to protocol resource coordinating institutions, regulators, and private investors). The theory is not narrowly conceived in instrumental terms, along the lines of the RRG charter, but rather is an attempt to integrate a very broad range of empirical regularities in a meaningful, illuminating way. Assuming that they continue to hold up to ongoing scrutiny, recognition of and theoretical engagement with those regularities *should* usefully inform the kind of work that of RRG is chartered to undertake, if only by illuminating any hypothetically interesting development trajectories that have proven to be consistently productive and/or unproductive under "similar" conditions in the past. I believe that the theory does satisfy, and will continue to satisfy that standard -- and perhaps do even more -- but I recognize that the burden will be mine, perhaps indefinitely, to continuously illustrate and defend those claims. Of course, even if the theory manages to live up to that challenge forever, there is no guarantee that it will deliver a specific solution that can meet all of the looming challenges without sacrificing any of the features that have made the Internet so distinctive (and I would add, important) to date. I would like to think that it could, and might yet, but failing to do that would not invalidate the theory, or even its potential relevance to RRG. To quote a favorite movie, we are in a "tight spot"... I'd very much like to see us get out of that spot without making any irreversible tradeoffs that we might sorely (but impotently) regret going forward. So, look for a more substantive response in the next day or two... and thanks again. Regards, TV From irtf@tonistoev.info Mon Apr 20 06:03:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EDC3A68AE for ; Mon, 20 Apr 2009 06:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7Cwjy0RKnoN for ; Mon, 20 Apr 2009 06:03:17 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 3FF313A6880 for ; Mon, 20 Apr 2009 06:03:17 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LvtAi-0003zb-Fp for rrg@irtf.org; Mon, 20 Apr 2009 16:04:28 +0300 From: Toni Stoev Date: Mon, 20 Apr 2009 16:04:27 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline To: IRTF RRG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200904201604.28029.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 13:03:18 -0000 Now The Domain Name System identifies a node by its fully qualified domain name= , which: =2D is topology=E2=80=90independent; =2D is stable, and has a defined lifetime; =2D is unambiguous; =2D is distinguishable (two for same object); =2D has hierarchical structure; =2D is generated, distributed, managed. But domain names are meaningful to humans, and therefore are network eccent= ric. On the other hand, Internet Protocol addresses are easily issuable, because= they consist of numbers. So let us take a numeric fully qualified identifier. The innermost part is a number of a node, and any previous numbers denote a= uthorities that have issued sublevel numbers. We put a news that the identified sublevel knows locator of its parent. So = acquaintance is mutual, and bidirectionally is to be used. Toni From dino@cisco.com Mon Apr 20 10:01:14 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F7028C2A8 for ; Mon, 20 Apr 2009 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emcU7nJ5NepN for ; Mon, 20 Apr 2009 10:01:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 68B053A680F for ; Mon, 20 Apr 2009 10:00:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,218,1238976000"; d="scan'208";a="154911980" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Apr 2009 17:01:37 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3KH1ZYe010959; Mon, 20 Apr 2009 10:01:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3KH1Zk7011686; Mon, 20 Apr 2009 17:01:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 10:01:35 -0700 Received: from [192.168.1.2] ([10.21.88.144]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 10:01:34 -0700 Message-Id: <3D8CC5F9-1355-407B-AE7C-C1F46CBB6447@cisco.com> From: Dino Farinacci To: Tony Li In-Reply-To: <49EC0200.9060600@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Mon, 20 Apr 2009 10:01:34 -0700 References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 20 Apr 2009 17:01:34.0963 (UTC) FILETIME=[A9531C30:01C9C1D9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=353; t=1240246895; x=1241110895; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Anycast=20in=20the=20core=20arc hitecture |Sender:=20; bh=zqzBUEBdbx5aiQOr+3lmEfrUpWnaYgTiLBqGCvj9eGo=; b=Ho2wtE/x69oWTcw7Ds9vmRY71zzWrIKvS/xh++6DFtaSctD/9ZOBPjjfH2 9IEmuRm6XQrMXM5jpgcdVhT6J7+zVA9M2ZrlUIRyMsCNJB2KFB2FOy7KdySM 4Pi5BScagJ; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 17:01:14 -0000 > Interesting. That rumbling sound you here is Dino's > keyboard... ;-) How do you figure it's non-deterministic? If you > take a global snapshot at any given point in time, then for any > given mcast packet sent by a given source, it's straightforward to > compute the receivers. ;-) I look forward to Bill's reply. ;-) Dino From swb@employees.org Mon Apr 20 12:27:57 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6603A696F for ; Mon, 20 Apr 2009 12:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnlGqFCLEP71 for ; Mon, 20 Apr 2009 12:27:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 88EF13A67B6 for ; Mon, 20 Apr 2009 12:27:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,218,1238976000"; d="scan'208";a="289582787" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2009 19:29:00 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3KJSx5W018511 for ; Mon, 20 Apr 2009 12:28:59 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n3KJSXhC015230 for ; Mon, 20 Apr 2009 19:28:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 15:28:53 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 15:28:53 -0400 Date: Mon, 20 Apr 2009 15:28:51 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090420192851.GG34560@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> <20090415184037.GA47183@cisco.com> <49E950FD.5030106@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E950FD.5030106@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Apr 2009 19:28:53.0513 (UTC) FILETIME=[3D82CF90:01C9C1EE] Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:27:57 -0000 Excerpts from Tony Li on Fri, Apr 17, 2009 09:03:09PM -0700: > More specifically, if we can converge on what properties we would > like identifiers to have, it might help to constrain the solution > space. > >> First, there are a different uses for identifiers and each has >> different requirements. Before we can talk about properties for >> "identifiers" in general we need to separate out which particular >> uses we are talking about. For example, are you including >> discovery starting from FQDNs? Kerberos identifiers for auth/auth? > > I'm trying to stay independent of any particular use case and look > at the abstract properties that we'd like to have in a locator/ID > split. But identifiers need different properties for different purposes. > To help simplify the discussion (I hope ;-), I'll certainly stipulate > that every solution is certainly going to have a number of identifiers. > I think we're most interested in the identifiers that correspond to > locators. Let's be clear what we're working on then. It's properties of identifiers for the things that will initially be contacted in order to set up communication flows (probably aka stack IDs). Yes? After that we can look at properties of identifiers used for session control. They may be the same identifiers, as in HIP or ILNP, but they need not be. OK? From swb@employees.org Mon Apr 20 12:31:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECD23A67F4 for ; Mon, 20 Apr 2009 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lHmHIE-f1IY for ; Mon, 20 Apr 2009 12:31:07 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8F2253A6B82 for ; Mon, 20 Apr 2009 12:30:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,218,1238976000"; d="scan'208";a="34056293" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2009 19:32:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3KJW731024291 for ; Mon, 20 Apr 2009 12:32:07 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3KJVv2I026726 for ; Mon, 20 Apr 2009 19:32:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 15:32:03 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 15:32:03 -0400 Date: Mon, 20 Apr 2009 15:31:58 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090420193158.GH34560@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E965C0.5020503@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Apr 2009 19:32:03.0694 (UTC) FILETIME=[AEDE20E0:01C9C1EE] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:31:08 -0000 Excerpts from Tony Li on Fri, Apr 17, 2009 10:31:44PM -0700: > >>> - stable, at discretion of owner >> >> I'd say: must have a defined lifetime, set by the owner, which may be infinite. > > I like this. How about: "... and can be terminated at any time at the > owner's discretion." In actual use the owner may have committed to a minimum duration. Brian's phrasing is better imho. >>> - unambiguous >> >> I'd say: must have a defined scope within which they are unique and >> unambiguous. The scope may be universal. [Now define 'universal'. >> It's not so easy.] > > How about 'global' instead? > > Do we really want local identifiers? Let's not assume too much about solutions. Everything has scope. From swb@employees.org Mon Apr 20 13:37:46 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DC73A6D6D for ; Mon, 20 Apr 2009 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RKBJ0WfrrjJ for ; Mon, 20 Apr 2009 13:37:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BAEC23A6A58 for ; Mon, 20 Apr 2009 13:37:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,219,1238976000"; d="scan'208";a="289619923" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2009 20:38:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3KKcakn025704 for ; Mon, 20 Apr 2009 13:38:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3KKcapV025877 for ; Mon, 20 Apr 2009 20:38:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:38:36 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 16:38:35 -0400 Date: Mon, 20 Apr 2009 16:38:26 -0400 From: Scott Brim To: RRG Message-ID: <20090420203826.GA46916@cisco.com> Mail-Followup-To: Scott Brim , RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EBFF59.90200@firstpr.com.au> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB6290.6000903@joelhalpern.com> <49EB68BC.8020607@spaghetti.zurich.ibm.com> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB6290.6000903@joelhalpern.com> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 20 Apr 2009 20:38:36.0095 (UTC) FILETIME=[FA862CF0:01C9C1F7] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:37:46 -0000 Excerpts from Tony Li on Sun, Apr 19, 2009 09:44:28AM -0700: >> Unicast is a special case of anycast in which there is only one >> destination endpoint. > > Nothing absurd about it. It's been said many times that unicast is a > special case of multicast and your observation is that anycast fits in > the middle of that hierarchy, since anycast is also a special case of > multicast where delivery is to only one receiver. Tony: I think these are statements about routing, not about addressing, but I'm not sure. How would what you say here work with the definition of a locator? Excerpts from William Herrin on Sun, Apr 19, 2009 07:32:53PM -0400: > > Nothing absurd about it. It's been said many times that unicast is a > > special case of multicast and your observation is that anycast fits in the > > middle of that hierarchy, since anycast is also a special case of multicast > > where delivery is to only one receiver. > > Hi Tony, > > I disagree with you there. Broadcast and Multicast are forms of > non-determinisitic routing. Anycast and unicast are both forms of > deterministic routing. Is that because the _potential_ recipients are already known? > There's a wide gulf between deterministic and non-deterministic > routing. What works efficiently for one just flat doesn't work well > for the other. > > I claim that on the deterministic side, the difference between anycast > and its unicast subset is sufficiently trivial that a well conceived > protocol will neither need nor want to treat the two cases > differently. > > When I say, "Unicast is a case of anycast in which there is only one > destination endpoint," I really mean it. Unicast doesn't exist. It's > just a convenience label for Anycast in which only one destination > endpoint is currently active, and that's precisely how the routing > system treats it. > > The same can't be said of multicast. Multicast has different semantics > even if there's only one host in the group. > > Still think I haven't proposed a radically different way to visualize > the routing system? How would you change the definition of a locator to match this? From wherrin@gmail.com Mon Apr 20 14:52:27 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43043A6B03 for ; Mon, 20 Apr 2009 14:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7i2-z5SiqOP for ; Mon, 20 Apr 2009 14:52:26 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 7B2123A6CEC for ; Mon, 20 Apr 2009 14:52:26 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so899351yxg.37 for ; Mon, 20 Apr 2009 14:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=I8tEK4Ur8+clu9SG0x3VjFkXSm+HCWizam2kLtjwJS8=; b=uE70BR33BQFlJ9DcnNlpCxRDV/a8wgVEUTb6vEwRGxSNsNFb3rh94dfmpvk1WOgjlE zkQvSzXEyf69utllTrOBzLJkyO5U1JOwsTWdrjlmWO4LztRlk7AaOipklZLeRZ0DwUKc X2VApc90s9khtvoPgQDKvpJoFlfZ+S1wDxW60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=WPQjC8+i9nP2QKPOubsV/vyRhn3kaKNJbOYi6033FjeADpfUfdLl5mhGuY9Rt+HBct yvBP1LPAoTwry6ZupGByxdxPUtM0pKbT7/oGSfKwJeCBD8itWvkjwFBzGq/543LVAFGH ilZTFfq+7Rk6x3hWPw0vz69R5iuPIswi18Pn4= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.225.12 with SMTP id x12mr6340830ang.75.1240264422416; Mon, 20 Apr 2009 14:53:42 -0700 (PDT) In-Reply-To: <49EC0200.9060600@tony.li> References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> Date: Mon, 20 Apr 2009 17:53:42 -0400 X-Google-Sender-Auth: 63fb3ec8eef37284 Message-ID: <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> From: William Herrin To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:52:28 -0000 On Mon, Apr 20, 2009 at 1:02 AM, Tony Li wrote: >> I disagree with you there. Broadcast and Multicast are forms of >> non-determinisitic routing. Anycast and unicast are both forms of >> deterministic routing. > > Interesting. =A0That rumbling sound you here is Dino's keyboard... =A0;-)= How do > you figure it's non-deterministic? =A0 If you take a global snapshot at a= ny > given point in time, then for any given mcast packet sent by a given sour= ce, > it's straightforward to compute the receivers. Hi Tony, I have this mental picture of the NFAs and DFAs (finite automata) used to process regular grammars from the formal languages class I took in college. All NFA's can be translated to DFAs but the translation explosively grows the automata. Seems to me like NFAs are decent metaphors for broadcast and multicast while DFAs are metaphors for anycast and unicast. And I think its notable that anycast groups with unicast (it's DFA-like) instead of grouping with multicast. > Except that we haven't figured out how to aggregate anycast, which from a > routing perspective, makes it completely unique. What do you mean? Anycast aggregates the same way as unicast: whenever the endpoints physically group together, they aggregate. At a practical level, that's rarely useful for anycast... But then at a practical level aggregating unicast that way (or failing to) is the source of our current grief. >> The same can't be said of multicast. Multicast has different semantics >> even if there's only one host in the group. > > Say more please, I'm not following. With anycast, the packet's next hop is always in exactly one direction, precisely the same as with unicast. And knowledge about what that next hop should be propagates precisely the same way. With multicast, the packet is replicated in all currently valid directions with complex subscription/desubscription overhead that has to be maintained even if there's only one receiver in the group. >> If using DNS that way worked, we could all go home. Unfortunately, >> what happens is that the ntp server looks up the name to address >> binding once when the machine boots and never reconsiders it during >> the year and a half the server is running, even after queries to the >> server's IP address stop returning data. > > Ok, but how would a map resolution change that? =A0Is the key point here = that > whatever mapping function is used, the map result has a TTL and needs to = be > refreshed periodically? =A0Or, the applications need to be able to trigge= r a > refresh? You'd put the map resolution outside the app developer's scope, either in the network (as proposed by strategy A) or in the system-level host software (as proposed by strategy B). Unprivileged applications simply wouldn't be able to diddle with addresses at the routing layer. With a guaranteed maximum time that a given map remains valid and no application-level access to the routing element, the protocol and weigh in favor of renumbering for aggregation instead of rerouting for multiple connections. But this is rather off on a tangent from anycast and its rather identical nature to unicast. On Mon, Apr 20, 2009 at 4:38 PM, Scott Brim wrote: >> When I say, "Unicast is a case of anycast in which there is only one >> destination endpoint," I really mean it. Unicast doesn't exist. It's >> just a convenience label for Anycast in which only one destination >> endpoint is currently active, and that's precisely how the routing >> system treats it. >> >> The same can't be said of multicast. Multicast has different semantics >> even if there's only one host in the group. > > How would you change the definition of a locator to match this? Hi Scott, Outside the context of specific solution strategies, I'm not sure the term "locator" is useful here, in any of its definitions. The most helpful term I've found here that could use a definition is "respondent," the particular anycasted device that you end up talking to. On Mon, Apr 20, 2009 at 12:51 AM, Robin Whittle wrote: >> You do a map lookup on the destination. You get a prioritized list >> of of egress routers. > Ivip's mapping has no list. Hi Robin, Call that a criticism of Ivip then. The change from current routing's presentation to the app layer will have consequences, some foreseeable and others unexpected. >> Stable TCP over anycast would, by the way, be fantastic news for the >> CDNs and their customers which include, oh, just about every major >> content provider on the web. > > I can't imagine any robust approach to TCP using anycast. The > routing system could change at any time and direct the packets to > another destination host. The routing system can change any time, interrupting communication between two endpoints. From a CDN's perspective, it just has to remain stable long enough to deliver the content about as often as it succeeds without anycast. The real problem with making TCP stable over anycast is not not routing changes that connect you to a different respondent. It's that you can be equidistant between two respondents with routing configured to send packets to one or the other more or less at random. If you rigged the routing system so that given two equidistant routes you picked one and then stuck with it until either the one you selected was withdrawn or until the metric on the other improved by at least two or three distance units, you'd have TCP over anycast that's stable enough for a substantial number of use cases. Certainly stable enough for a case like adding and removing machines from a geographically distributed web cluster. Regards, Bill --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rw@firstpr.com.au Mon Apr 20 17:34:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE62E3A69B9 for ; Mon, 20 Apr 2009 17:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[AWL=-2.282, BAYES_00=-2.599, GB_ROLEX=5, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vpHq203D+oy for ; Mon, 20 Apr 2009 17:34:19 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 39FC43A6900 for ; Mon, 20 Apr 2009 17:34:19 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id D033D175CBA; Tue, 21 Apr 2009 10:35:33 +1000 (EST) Message-ID: <49ED14DD.70701@firstpr.com.au> Date: Tue, 21 Apr 2009 10:35:41 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> In-Reply-To: <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 00:34:22 -0000 Short version: Bill suggests anycast TCP would be practical for at least some purposes if the routing system was "rigged" so (in any given short to medium time period) routers sent packets along one path only. I thought BGP routers at least, and probably all others already did this - but perhaps I am wrong. In a previous message Bill made broad statements about core-edge separation techniques which includes Ivip, which were contrary to how Ivip would work. I corrected this with a clearer description, and he responded "Call that a criticism of Ivip then." but the things I described look like benefits to me. Hi Bill, You wrote, in part: > Anycast aggregates the same way as unicast: whenever > the endpoints physically group together, they aggregate. At a > practical level, that's rarely useful for anycast... But then at a > practical level aggregating unicast that way (or failing to) is the > source of our current grief. Routers can't tell the difference between anycast and unicast. Only someone with complete knowledge of the network can determine which is which. If there are two routers advertising the prefix, that could be either. If each such router sends its packet to the one destination host, it is unicast. If each sends its packets to a separate destination host, it is anycast. > Call that a criticism of Ivip then. By investing in real-time (a few seconds) mapping distribution to all the ITRs which need it, there is no need for multiple ETR addresses or for ITRs to do any reachability testing and associated ETR address decision-making. End-user networks can do whatever they like with the mapping, whenever they like (for a fee which largely ensures their activity is not an unfair burden on anyone). End-user networks can therefore employ any reachability testing they like, make decisions in any way they like about multihoming and inbound TE, including real-time changes to reflect changing traffic patterns which could never be achieved in LISP, APT or TRRP's ITR-based load spreading approach. End-user networks can appoint other companies to control their mapping, so those companies can use global networks and arbitrarily sophisticated probing and decision-making algorithms, including taking input from the end-user network itself, such as for real-time load balancing. Eliminating the ITR's need for probing ETR reachability (except as a by-product of the PMTUD stuff which is unfortunately necessary for encapsulation) means there is no need for extra bits, headers etc. in traffic packets, or any other ITR <-> ETR communication. Not needing any extra bits, this enables the system to use Modified Header Forwarding instead of encapsulation, once sufficient DFZ and other routers are upgraded, completely eliminating encapsulation overhead and PMTUD problems. This doesn't sound like a critique to me! > The change from current routing's presentation to the app layer > will have consequences, some foreseeable and others unexpected. This was in the same paragraph as your mention of Ivip. Are you referring to Ivip or anycast - I can't understand what you mean in either case, though as mentioned below, I think anycast is generally unsuitable for session-based protocols. Anycast with entirely stable router behaviour would be no different to applications than unicast - as long as there were no outages, network structure changes etc. Ivip doesn't affect applications, and either do the other core-edge separation candidate architectures APT, LISP or TRRP, except to the extent that some initial packets may be delayed significantly - which is only a potential problem with LISP-ALT and TRRP. >>> Stable TCP over anycast would, by the way, be fantastic news for the >>> CDNs and their customers which include, oh, just about every major >>> content provider on the web. >> >> I can't imagine any robust approach to TCP using anycast. The >> routing system could change at any time and direct the packets to >> another destination host. > > The routing system can change any time, interrupting communication > between two endpoints. Yes, but when there is a genuine interruption - packets not reaching their destination - this is a situation from which the routing system rapidly recovers. Much more often, when some router decides to send packets a different way, there is no loss of connectivity at all in a unicast setting. With anycast, that change may send the packets which formerly went to destination host A (via its router X) towards some other router Y which advertises the same prefix, or a prefix encompassing the same address. Then the packets go to host B, completely disrupting the former communication with A. My understanding, which is compatible with: http://en.wikipedia.org/wiki/Akamai_Technologies http://en.wikipedia.org/wiki/Content_Delivery_Network is that CDNs use a fancy DNS server to provide different IP addresses to different queriers, thereby generally directing hosts to communicate with nearby CDN servers. This is not anycast, but anycast has apparently been used for "DDoS scrubbing", which I think is not intended primarily to be a normal or reliable service: http://en.wikipedia.org/wiki/Prolexic As is widely known, anycast is fine for many simple, stateless, non-session-based query and response protocols including UDP-based DNS. > From a CDN's perspective, it just has to remain > stable long enough to deliver the content about as often as it > succeeds without anycast. Anycast doesn't look suitable for CDN use, for the reason stated above and due to: > The real problem with making TCP stable over anycast is not not > routing changes that connect you to a different respondent. It's that > you can be equidistant between two respondents with routing configured > to send packets to one or the other more or less at random. Do DFZ routers actually behave this way? I recall that BGP has a mechanism for choosing decisively between two "equidistant" routes (number of ASes as adjusted by whatever factors have been configured). I recall a BGP router is required to chose the route with the lowest number AS. So is this really required, in the DFZ or in internal routing systems?: > If you rigged the routing system so that given two equidistant routes > you picked one and then stuck with it until either the one you > selected was withdrawn or until the metric on the other improved by at > least two or three distance units, you'd have TCP over anycast that's > stable enough for a substantial number of use cases. I thought the routers already behaved this way. If so, then at present, most people judge anycast, at least in DFZ, as being unsuitable for any communication protocol such as TCP in which the hosts store state. This is not due, AFAIK, to routers spreading packets over multiple paths, and so potentially to multiple anycast destination hosts, but purely due to the possibility that a router changing the packets' path from one peer to another will send all subsequent packets to a different anycast destination host. > Certainly stable enough for a case like adding and removing machines > from a geographically distributed web cluster. I don't understand this. The problem with anycast is that a router could break the communication as just described - sending packets which previously went to cluster A to a geographically distant cluster B, which I assume is unable to access or modify the state stored in cluster A's servers. So B would be unable to continue to serve TCP and higher level protocol sessions which A was serving. - Robin From xuxh@huawei.com Mon Apr 20 18:46:08 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7243A6E00 for ; Mon, 20 Apr 2009 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32QxovCVLEJO for ; Mon, 20 Apr 2009 18:46:08 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7AD793A6A60 for ; Mon, 20 Apr 2009 18:45:38 -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 <0KIF008Q6GY482@szxga03-in.huawei.com> for rrg@irtf.org; Tue, 21 Apr 2009 09:46:52 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIF002XEGY4MU@szxga03-in.huawei.com> for rrg@irtf.org; Tue, 21 Apr 2009 09:46:52 +0800 (CST) Date: Tue, 21 Apr 2009 09:46:52 +0800 From: Xu Xiaohu In-reply-to: <200904201604.28029.irtf@tonistoev.info> To: 'Toni Stoev' , 'IRTF RRG' Message-id: <001301c9c223$0b390560$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnBuJS4BwAY3HoWRd2TTv7VqmAR1AAZ8PMg Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:46:08 -0000 =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 Toni Stoev > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA4=D4=C220=C8=D5 21:04 > =CA=D5=BC=FE=C8=CB: IRTF RRG > =D6=F7=CC=E2: [rrg] Next topic: properties of identifiers >=20 > Now >=20 > The Domain Name System identifies a node by its fully=20 > qualified domain name, which: > - is topology=A9\independent; > - is stable, and has a defined lifetime; > - is unambiguous; > - is distinguishable (two for same object); > - has hierarchical structure; > - is generated, distributed, managed. >=20 > But domain names are meaningful to humans, and therefore are=20 > network eccentric. >=20 > On the other hand, Internet Protocol addresses are easily=20 > issuable, because they consist of numbers. >=20 > So let us take a numeric fully qualified identifier. > The innermost part is a number of a node, and any previous=20 > numbers denote authorities that have issued sublevel numbers. Sound interesting. By the way, taken the following items mentioned by = Tony in his previous email together into account, the identifiers should = have the same length as IPv6 address (or IPv4 address) and be capable of asserting ownership. - facilitate session=A9\level referrals - stable, at discretion of owner Xiaohu > We put a news that the identified sublevel knows locator of=20 > its parent. So acquaintance is mutual, and bidirectionally is=20 > to be used. >=20 > Toni > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg >=20 From tony.li@tony.li Mon Apr 20 22:14:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4893A69C5 for ; Mon, 20 Apr 2009 22:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzahiMdFjyaA for ; Mon, 20 Apr 2009 22:14:40 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id B3E5B3A6817 for ; Mon, 20 Apr 2009 22:14:40 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id houx1b0030QkzPwA75Fxch; Tue, 21 Apr 2009 05:15:57 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id i5Fw1b00B3L8a8Q8N5FxXA; Tue, 21 Apr 2009 05:15:57 +0000 Message-ID: <49ED5674.30706@tony.li> Date: Mon, 20 Apr 2009 22:15:32 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim , RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EBFF59.90200@firstpr.com.au> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB6290.6000903@joelhalpern.com> <49EB68BC.8020607@spaghetti.zurich.ibm.com> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB6290.6000903@joelhalpern.com> <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <20090420203826.GA46916@cisco.com> In-Reply-To: <20090420203826.GA46916@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 05:14:41 -0000 Hi Scott, >> Nothing absurd about it. It's been said many times that unicast is a >> special case of multicast and your observation is that anycast fits in >> the middle of that hierarchy, since anycast is also a special case of >> multicast where delivery is to only one receiver. > > Tony: I think these are statements about routing, not about > addressing, but I'm not sure. How would what you say here work with > the definition of a locator? Addressing is routing is addressing. ;-) I'm not sure I see the connection. Intrinsically, anycast is _not_ about locators. It is about services. If you take Bill's approach (how about we call it 'anymap'), then obviously, that resolves to a real (locator, identifier) tuple. >> I disagree with you there. Broadcast and Multicast are forms of >> non-determinisitic routing. Anycast and unicast are both forms of >> deterministic routing. > > Is that because the _potential_ recipients are already known? The actual recipients are already known. Tony From tony.li@tony.li Mon Apr 20 22:56:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883AE3A6BA8 for ; Mon, 20 Apr 2009 22:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeXM3lOVJo9h for ; Mon, 20 Apr 2009 22:56:43 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id 7DC013A69EB for ; Mon, 20 Apr 2009 22:56:43 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id i5GX1b0030b6N64AE5y0VQ; Tue, 21 Apr 2009 05:58:00 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id i5xz1b0073L8a8Q8P5xzua; Tue, 21 Apr 2009 05:58:00 +0000 Message-ID: <49ED604C.2020407@tony.li> Date: Mon, 20 Apr 2009 22:57:32 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> In-Reply-To: <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 05:56:44 -0000 Hi Bill, > I have this mental picture of the NFAs and DFAs (finite automata) used > to process regular grammars from the formal languages class I took in > college. All NFA's can be translated to DFAs but the translation > explosively grows the automata. > > Seems to me like NFAs are decent metaphors for broadcast and multicast > while DFAs are metaphors for anycast and unicast. And I think its > notable that anycast groups with unicast (it's DFA-like) instead of > grouping with multicast. Ok, I remember these. Still have the textbook right here. ;-) >> Except that we haven't figured out how to aggregate anycast, which from a >> routing perspective, makes it completely unique. > > What do you mean? Anycast aggregates the same way as unicast: whenever > the endpoints physically group together, they aggregate. At a > practical level, that's rarely useful for anycast... But then at a > practical level aggregating unicast that way (or failing to) is the > source of our current grief. Well, the problem with aggregating anycast is that it ends up with one route per service. In a world of highly differentiated services, the sheer number of services could be explosive. And you can only aggregate them if they are numbered appropriately and are topologically correlated. How often is that going to happen with anycast? To be fair, we do get substantial aggregation up to the site level with unicast, it's above that level that things get iffy. >>> The same can't be said of multicast. Multicast has different semantics >>> even if there's only one host in the group. >> Say more please, I'm not following. > > With anycast, the packet's next hop is always in exactly one > direction, precisely the same as with unicast. And knowledge about > what that next hop should be propagates precisely the same way. > > With multicast, the packet is replicated in all currently valid > directions with complex subscription/desubscription overhead that has > to be maintained even if there's only one receiver in the group. Having watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and IS-IS, I'm having a hard time saying that the "complex subscription/desubscription" overhead for multicast is all that much worse than what we do for unicast. As for the forwarding plane, the differences are NOT that large. Ok, yes, there is an order of magnitude more complexity in doing the packet replication, but it becomes quite clear that with one receiver it does devolve nicely into an effective unicast. No one would implement unicast that way, of course, but that's an efficiency issue, not a conceptual one. Even if multicast's differentiation is the replication in the data plane, I'm not sure I see how that becomes non-deterministic. I see no references to an oracle. The right things always seems to happen with total determinism. >> Ok, but how would a map resolution change that? Is the key point here that >> whatever mapping function is used, the map result has a TTL and needs to be >> refreshed periodically? Or, the applications need to be able to trigger a >> refresh? > > You'd put the map resolution outside the app developer's scope, either > in the network (as proposed by strategy A) or in the system-level host > software (as proposed by strategy B). Unprivileged applications simply > wouldn't be able to diddle with addresses at the routing layer. > > With a guaranteed maximum time that a given map remains valid and no > application-level access to the routing element, the protocol and > weigh in favor of renumbering for aggregation instead of rerouting for > multiple connections. > > But this is rather off on a tangent from anycast and its rather > identical nature to unicast. Seems like useful implementation strategies to me. And it leads me again to the conclusion that it's again not something that's happening within the routing subsystem. Tony From HeinerHummel@aol.com Tue Apr 21 01:00:33 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952D13A6E4E for ; Tue, 21 Apr 2009 01:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=1.821, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq7DCxVJo1xH for ; Tue, 21 Apr 2009 01:00:32 -0700 (PDT) Received: from imr-d02.mx.aol.com (imr-d02.mx.aol.com [205.188.157.40]) by core3.amsl.com (Postfix) with ESMTP id 0B15E3A6D3F for ; Tue, 21 Apr 2009 01:00:31 -0700 (PDT) Received: from imo-m27.mx.aol.com (imo-m27.mail.aol.com [172.20.107.73]) by imr-d02.mx.aol.com (v107.10) with ESMTP id RELAYIN3-449ed7d422f7; Tue, 21 Apr 2009 04:01:06 -0400 Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imo-m27.mx.aol.com (v107.10) with ESMTP id RELAYIN4-549ed7d3731; Tue, 21 Apr 2009 04:01:05 -0400 Received: from HeinerHummel@aol.com by imo-da03.mx.aol.com (mail_out_v40_r1.5.) id i.c32.50258aea (39952); Tue, 21 Apr 2009 04:00:51 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 21 Apr 2009 04:00:51 EDT To: tony.li@tony.li, bill@herrin.us MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240300851" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 172.20.107.73 Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 08:00:33 -0000 -------------------------------1240300851 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable What are the requirements for Anycast in a new architecture? As I understand Anycast is about delivery to one out of multiple destinations within a given scope. Where is the center point of this scope ? Is it always the location of the= source ? Can/should it be something to be provided/signalled (which makes sense if= alternatives to that case were allowed where the source is this center point)? Who determines the final Unicast destination ? the source? the ingress router? Or also some router/server along the path? May an enforced detour of the forwarding path wind up in selecting a different Unicast destination - done by any transit router? I'll appreciate learning the answers to these questions because I think= there are multiple ways to conceive and implement Anycast (not just the = traditional one). There are quite a few concepts developed for other servi= ces which are likewise applicable to Anycast: MIP4 care of address server, HIP= rendez-vous server,... Heiner In einer eMail vom 21.04.2009 07:58:07 Westeurop=E4ische Normalzeit schrei= bt tony.li@tony.li: Hi Bill, > I have this mental picture of the NFAs and DFAs (finite automata) used > to process regular grammars from the formal languages class I took in > college. All NFA's can be translated to DFAs but the translation > explosively grows the automata. > > Seems to me like NFAs are decent metaphors for broadcast and multicast > while DFAs are metaphors for anycast and unicast. And I think its > notable that anycast groups with unicast (it's DFA-like) instead of > grouping with multicast. Ok, I remember these. Still have the textbook right here. ;-) >> Except that we haven't figured out how to aggregate anycast, which fro= m a >> routing perspective, makes it completely unique. > > What do you mean? Anycast aggregates the same way as unicast: whenever > the endpoints physically group together, they aggregate. At a > practical level, that's rarely useful for anycast... But then at a > practical level aggregating unicast that way (or failing to) is the > source of our current grief. Well, the problem with aggregating anycast is that it ends up with one route per service. In a world of highly differentiated services, the sheer number of services could be explosive. And you can only aggregate= them if they are numbered appropriately and are topologically correlated. How often is that going to happen with anycast? To be fair, we do get substantial aggregation up to the site level with= unicast, it's above that level that things get iffy. >>> The same can't be said of multicast. Multicast has different semantic= s >>> even if there's only one host in the group. >> Say more please, I'm not following. > > With anycast, the packet's next hop is always in exactly one > direction, precisely the same as with unicast. And knowledge about > what that next hop should be propagates precisely the same way. > > With multicast, the packet is replicated in all currently valid > directions with complex subscription/desubscription overhead that has > to be maintained even if there's only one receiver in the group. Having watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and IS-IS, I'm having a hard time saying that the "complex subscription/desubscription" overhead for multicast is all that much worse than what we do for unicast. As for the forwarding plane, the differences are NOT that large. Ok, yes, there is an order of magnitude more complexity in doing the packet= replication, but it becomes quite clear that with one receiver it does devolve nicely into an effective unicast. No one would implement unicast that way, of course, but that's an efficiency issue, not a conceptual one. Even if multicast's differentiation is the replication in the data plane, I'm not sure I see how that becomes non-deterministic. I see no= references to an oracle. The right things always seems to happen with total determinism. >> Ok, but how would a map resolution change that? Is the key point here= that >> whatever mapping function is used, the map result has a TTL and needs= to be >> refreshed periodically? Or, the applications need to be able to trigger a >> refresh? > > You'd put the map resolution outside the app developer's scope, either > in the network (as proposed by strategy A) or in the system-level host > software (as proposed by strategy B). Unprivileged applications simply > wouldn't be able to diddle with addresses at the routing layer. > > With a guaranteed maximum time that a given map remains valid and no > application-level access to the routing element, the protocol and > weigh in favor of renumbering for aggregation instead of rerouting for > multiple connections. > > But this is rather off on a tangent from anycast and its rather > identical nature to unicast. Seems like useful implementation strategies to me. And it leads me again to the conclusion that it's again not something that's happening within the routing subsystem. Tony _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1240300851 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
What are the requirements for Anycast in a new architecture?
As I understand Anycast  is about delivery to one out of multipl= e destinations within a given scope.
Where is the center point of this scope ? Is it always the location= of the source ?
Can/should it be something to be provided/signalled (which makes sens= e if alternatives to that case were allowed where the source is this center point)?
 
Who determines the final Unicast destination ? the source? the ingres= s router? Or also some router/server along the path?
May an enforced detour of the forwarding path  wind up in= selecting a different Unicast destination - done by any transit router?
 
I'll appreciate learning the answers to these questions because= I think there are multiple ways to conceive and implement Anycast (not just= the traditional one). There are quite a few concepts developed for other servi= ces which are likewise applicable to Anycast: MIP4 care of address server, HIP= rendez-vous server,...
 
 
Heiner
 
 
 
 
In einer eMail vom 21.04.2009 07:58:07 Westeurop=E4ische Normalzeit= schreibt tony.li@tony.li:
Hi Bill,

> I have this mental picture of the NFAs and DFAs (finit= e automata) used
> to process regular grammars from the formal langu= ages class I took in
> college. All NFA's can be translated to DFAs but= the translation
> explosively grows the automata.
>
> See= ms to me like NFAs are decent metaphors for broadcast and multicast
> wh= ile DFAs are metaphors for anycast and unicast. And I think its
> nota= ble that anycast groups with unicast (it's DFA-like) instead of
> grou= ping with multicast.


Ok, I remember these.  Still have the te= xtbook right here.  ;-)


>> Except that we haven't figured= out how to aggregate anycast, which from a
>> routing perspective,= makes it completely unique.
>
> What do you mean? Anycast aggrega= tes the same way as unicast: whenever
> the endpoints physically group= together, they aggregate. At a
> practical level, that's rarely us= eful for anycast... But then at a
> practical level aggregating unicast= that way (or failing to) is the
> source of our current grief.


Well, the problem with aggregating anycast is that it= ends up with one
route per service.  In a world of highly differenti= ated services, the
sheer number of services could be explosive.  And= you can only aggregate
them if they are numbered appropriately and are= topologically
correlated.  How often is that going to happen wi= th anycast?

To be fair, we do get substantial aggregation up to the= site level with
unicast, it's above that level that things get iffy.


>>> The same can't be said of multicast. Multi= cast has different semantics
>>> even if there's only one host in= the group.
>> Say more please, I'm not following.
>
>= With anycast, the packet's next hop is always in exactly one
> directio= n, precisely the same as with unicast. And knowledge about
> what tha= t next hop should be propagates precisely the same way.
>
> With= multicast, the packet is replicated in all currently valid
> direc= tions with complex subscription/desubscription overhead that has
> to be= maintained even if there's only one receiver in the group.


Ha= ving watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and
IS-I= S, I'm having a hard time saying that the "complex
subscription/desubscript= ion" overhead for multicast is all that much
worse than what we do for unicast.

As for the forwarding plane, the differences are NOT tha= t large.  Ok,
yes, there is an order of magnitude more complexity= in doing the packet
replication, but it becomes quite clear that with= one receiver it does
devolve nicely into an effective unicast.  No= one would implement
unicast that way, of course, but that's an efficienc= y issue, not a
conceptual one.

Even if multicast's differentiat= ion is the replication in the data
plane, I'm not sure I see how that becom= es non-deterministic.  I see no
references to an oracle.  The= right things always seems to happen with
total determinism.


>= ;> Ok, but how would a map resolution change that?  Is the key point= here that
>> whatever mapping function is used, the map result has= a TTL and needs to be
>> refreshed periodically?  Or, the applic= ations need to be able to trigger a
>> refresh?
>
> You'd= put the map resolution outside the app developer's scope, either
> in= the network (as proposed by strategy A) or in the system-level host
>= software (as proposed by strategy B). Unprivileged applications simply> wouldn't be able to diddle with addresses at the routing layer.
>=
> With a guaranteed maximum time that a given map remains valid= and no
> application-level access to the routing element, the protocol= and
> weigh in favor of renumbering for aggregation instead of rer= outing for
> multiple connections.
>
> But this is rather of= f on a tangent from anycast and its rather
> identical nature to unicast.


Seems like useful implementation strategies to me.&n= bsp; And it leads me
again to the conclusion that it's again not somethin= g that's happening
within the routing subsystem.

Tony
______________________________________________= _
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1240300851-- From pfrejborg@gmail.com Tue Apr 21 02:25:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963B828B23E for ; Tue, 21 Apr 2009 02:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2TaVCs8exrL for ; Tue, 21 Apr 2009 02:25:15 -0700 (PDT) Received: from mail-qy0-f123.google.com (mail-qy0-f123.google.com [209.85.221.123]) by core3.amsl.com (Postfix) with ESMTP id 0D1143A6967 for ; Tue, 21 Apr 2009 02:25:14 -0700 (PDT) Received: by qyk29 with SMTP id 29so1948588qyk.15 for ; Tue, 21 Apr 2009 02:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D9060FL0T4jlfCJ+/89tHwVjoRY09Xi+dx51iVwYOPs=; b=KH9WrTCH/qQRq1I8EVRcC5RpSinWVO/pLJXM31leCwwqqYwL+XRaM3p8kTs1SuliUQ uQtMHic3LD6e22/P14TZcAuJIrvXcEymB7WhfRHsjzDTMTXX7bgupjidaqsaGLaNYiv6 u4Tpj6bc/L5i4JJpdgajZm0cw1ATnr5vK5164= 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=C+vyC70Z0opSRjootNui0JVV+t/X8Ug6MKYTkOrJKdRK4J8rlXo80oYFie9YflE4ie TMMZbD0Iw5j1lRyl2Ipe/BDqNRvf+6J0eDMmYKbO2wPKvPKgFRsqDWd7TLv1jicE/tof j/YYOR6QCJs7vvNf4T/yBQXrxR6sE4Edp0Vh4= MIME-Version: 1.0 Received: by 10.229.82.81 with SMTP id a17mr843759qcl.107.1240305991037; Tue, 21 Apr 2009 02:26:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Apr 2009 12:26:30 +0300 Message-ID: <5bc37fd40904210226r6df7fb6cna377a5fe6fa3d57e@mail.gmail.com> From: Patrick Frejborg To: HeinerHummel@aol.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 09:25:22 -0000 Heiner, guess there are several ways to implement Anycast in a new architecture, here is one way of doing it ... I'm currently rewriting my draft - after I had studied the Dagstuhl material I noticed that I had used only locators (though using locator and identifier in my text) and not seen the new dimension (which is currently named identifier) . So I'm changing my text, which is not published yet: - Area Locator, ALOC (it could also be called Autonomous system LOCator or Aggregate LOCator). The purpose of the ALOC is to locate an AS, or a group of AS, in Internet. - Local Locator, LLOC. The purpose of the LLOC is to locate a host connected to an ALOC realm And I have also added an identifier to the draft but later more on that once there is a consensus about identifier So here is an example of the usage of Anycast and locator in an architectur= e. Note, no session or flow state in the LSR. Also converging from one LSR to another LSR is depending upon the convergence time of IGP. Hack or no hack? 3. An overview of the hIPv4 framework In this section we will discuss the roles of the new elements, introduced by the hIPv4 framework, and their dependencies. As mentioned in the introduction section the role of an Area LOCator (ALOC) prefix is similar as to a country code in PSTN. I.e. the ALOC prefix provides a location functionality of an Autonomous System (AS), or a group of AS, in Internet. The ALOC prefix will be used for routing and forwarding purposes in Internet, thus the ALOC prefix must be globally unique and is allocated from an IPv4 address block. This globally unique IPv4 address block is called the Global Locator Block (GLB). When an AS (or group of AS) are assigned an ALOC prefix the area has the potential to become an ALOC realm. In order to establish an ALOC realm more elements, further than the ALOC prefix, are needed. One or multiple Locator Swap Router (LSR) must be attached to the ALOC realm. A LSR element is a node capable of swapping the values of the IPv4 header and the new shim header, called the location/identifier header. The swap mechanism of the headers is described in detail in section 7, step 4. Today=92s routers do not support the LSR functionality. Therefore the new functionality will most likely be developed on an external device attached to a router belonging to the ALOC realm. The external LSR might be a computer with two interface attached to a router, the first interface configured with the prefix of the ALOC and the second interface with any IPv4 prefix. The LSR do not make us of dynamic routing protocols, neither a forwarding information base (FIB) is needed - the LSR is producing a service, i.e. swapping headers. The swap mechanism is applied on per datagram basis and the information needed to carry out the swap is included in the header of the hIPv4 datagram. Thus a computer with enough computing and I/O resources is sufficient to take the role as a LSR. Later on, the LSR functionality might be integrated into the forwarding plane of a router. One LSR can not handle all the incoming traffic designated for an ALOC realm; it would also create a potential single point of failure in the network. Therefore, several LSRs shall be installed in the ALOC realm and the LSRs shall use the ALOC prefix as their locator and the routers are announcing the ALOC prefix as an Anycast address within the local ALOC realm. Also, the ALOC prefix is advertised throughout the DFZ by BGP mechanisms. The placement of the LSRs in the network will influence on the ingress traffic to the ALOC realm, the LSR is providing =93nearest routing=94 functionality. -- patte On Tue, Apr 21, 2009 at 11:00 AM, wrote: > What are the requirements for Anycast in a new architecture? > As I understand Anycast=A0 is about delivery to one out of multiple > destinations=A0within a given scope. > Where is the center point of this scope ? Is it always the location of th= e > source ? > Can/should it be something to be provided/signalled (which makes sense if > alternatives to that case were allowed where the source is this center > point)? > > Who determines the final Unicast destination ? the source? the ingress > router? Or also some router/server along the path? > May=A0an enforced detour of the forwarding path=A0 wind up in selecting a > different Unicast destination - done by any transit router? > > I'll appreciate=A0learning the answers to these questions because I think > there are multiple ways to conceive and implement Anycast (not just the > traditional one). There are quite a few concepts developed for other > services which are likewise applicable to Anycast: MIP4 care of address > server, HIP rendez-vous server,... > > > Heiner > > > > > In einer eMail vom 21.04.2009 07:58:07 Westeurop=E4ische Normalzeit schre= ibt > tony.li@tony.li: > > Hi Bill, > >> I have this mental picture of the NFAs and DFAs (finite automata) used >> to process regular grammars from the formal languages class I took in >> college. All NFA's can be translated to DFAs but the translation >> explosively grows the automata. >> >> Seems to me like NFAs are decent metaphors for broadcast and multicast >> while DFAs are metaphors for anycast and unicast. And I think its >> notable that anycast groups with unicast (it's DFA-like) instead of >> grouping with multicast. > > > Ok, I remember these.=A0 Still have the textbook right here.=A0 ;-) > > >>> Except that we haven't figured out how to aggregate anycast, which from= a >>> routing perspective, makes it completely unique. >> >> What do you mean? Anycast aggregates the same way as unicast: whenever >> the endpoints physically group together, they aggregate. At a >> practical level, that's rarely useful for anycast... But then at a >> practical level aggregating unicast that way (or failing to) is the >> source of our current grief. > > > Well, the problem with aggregating anycast is that it ends up with one > route per service.=A0 In a world of highly differentiated services, the > sheer number of services could be explosive.=A0 And you can only aggregat= e > them if they are numbered appropriately and are topologically > correlated.=A0 How often is that going to happen with anycast? > > To be fair, we do get substantial aggregation up to the site level with > unicast, it's above that level that things get iffy. > > >>>> The same can't be said of multicast. Multicast has different semantics >>>> even if there's only one host in the group. >>> Say more please, I'm not following. >> >> With anycast, the packet's next hop is always in exactly one >> direction, precisely the same as with unicast. And knowledge about >> what that next hop should be propagates precisely the same way. >> >> With multicast, the packet is replicated in all currently valid >> directions with complex subscription/desubscription overhead that has >> to be maintained even if there's only one receiver in the group. > > > Having watched the development of PIM, BGP, OSPF, ARP, HSRP, VRRP, and > IS-IS, I'm having a hard time saying that the "complex > subscription/desubscription" overhead for multicast is all that much > worse than what we do for unicast. > > As for the forwarding plane, the differences are NOT that large.=A0 Ok, > yes, there is an order of magnitude more complexity in doing the packet > replication, but it becomes quite clear that with one receiver it does > devolve nicely into an effective unicast.=A0 No one would implement > unicast that way, of course, but that's an efficiency issue, not a > conceptual one. > > Even if multicast's differentiation is the replication in the data > plane, I'm not sure I see how that becomes non-deterministic.=A0 I see no > references to an oracle.=A0 The right things always seems to happen with > total determinism. > > >>> Ok, but how would a map resolution change that?=A0 Is the key point her= e >>> that >>> whatever mapping function is used, the map result has a TTL and needs t= o >>> be >>> refreshed periodically?=A0 Or, the applications need to be able to trig= ger >>> a >>> refresh? >> >> You'd put the map resolution outside the app developer's scope, either >> in the network (as proposed by strategy A) or in the system-level host >> software (as proposed by strategy B). Unprivileged applications simply >> wouldn't be able to diddle with addresses at the routing layer. >> >> With a guaranteed maximum time that a given map remains valid and no >> application-level access to the routing element, the protocol and >> weigh in favor of renumbering for aggregation instead of rerouting for >> multiple connections. >> >> But this is rather off on a tangent from anycast and its rather >> identical nature to unicast. > > > Seems like useful implementation strategies to me.=A0 And it leads me > again to the conclusion that it's again not something that's happening > within the routing subsystem. > > 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 tony.li@tony.li Tue Apr 21 08:47:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0C03A6B27 for ; Tue, 21 Apr 2009 08:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bok2OPrvH4kZ for ; Tue, 21 Apr 2009 08:47:03 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 84E5528C1FC for ; Tue, 21 Apr 2009 08:47:00 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id iBjp1b0030vp7WLA4FoHl8; Tue, 21 Apr 2009 15:48:17 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id iFoH1b0013L8a8Q8RFoHb2; Tue, 21 Apr 2009 15:48:17 +0000 Message-ID: <49EDEA85.6070307@tony.li> Date: Tue, 21 Apr 2009 08:47:17 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> <20090420193158.GH34560@cisco.com> In-Reply-To: <20090420193158.GH34560@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:47:03 -0000 Hi Scott, Scott Brim wrote: > In actual use the owner may have committed to a minimum duration. > Brian's phrasing is better imho. Ok, I can live with that. >>>> - unambiguous >>> I'd say: must have a defined scope within which they are unique and >>> unambiguous. The scope may be universal. [Now define 'universal'. >>> It's not so easy.] >> How about 'global' instead? >> >> Do we really want local identifiers? > > Let's not assume too much about solutions. Everything has scope. Again, the point of the discussion is to figure out what classes of solutions actually are appropriate. It seems to me like supporting local identifiers is worthy of discussion. I've seen one advocate for them (ILNP), where they make a handy opportunity for those folks who prefer privacy. Changing your locator to something with local scope does provide benefits in that area, but it creates issues in others. Do identifiers now come in a split namespace? Here there be complexity... ;-) Are folks ok with this? Tony From swb@employees.org Tue Apr 21 09:03:26 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D13A3A6AC8 for ; Tue, 21 Apr 2009 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTdRHOz2IWe2 for ; Tue, 21 Apr 2009 09:03:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 102AE3A6A67 for ; Tue, 21 Apr 2009 09:03:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,225,1238976000"; d="scan'208";a="155339454" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2009 16:04:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3LG4PG6003082 for ; Tue, 21 Apr 2009 09:04:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3LG4OSd015194 for ; Tue, 21 Apr 2009 16:04:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 12:04:24 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 12:04:23 -0400 Date: Tue, 21 Apr 2009 12:04:14 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090421160414.GQ70118@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> <20090420193158.GH34560@cisco.com> <49EDEA85.6070307@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EDEA85.6070307@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 21 Apr 2009 16:04:24.0025 (UTC) FILETIME=[D6BD4490:01C9C29A] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:03:26 -0000 Excerpts from Tony Li on Tue, Apr 21, 2009 08:47:17AM -0700: > > Hi Scott, > > Scott Brim wrote: >> In actual use the owner may have committed to a minimum duration. >> Brian's phrasing is better imho. > > Ok, I can live with that. > >>>>> - unambiguous >>>> I'd say: must have a defined scope within which they are unique >>>> and unambiguous. The scope may be universal. [Now define >>>> 'universal'. It's not so easy.] >>> How about 'global' instead? >>> >>> Do we really want local identifiers? >> >> Let's not assume too much about solutions. Everything has scope. > > Again, the point of the discussion is to figure out what classes of > solutions actually are appropriate. It seems to me like supporting > local identifiers is worthy of discussion. Oh. Then I think we actually agree on procedure, but let's make it explicit: The goal is to figure out which classes of solutions are appropriate, and one input to that is to look at the implications each solution class has on properties of identifiers. Some of us have been saying that you can't do "properties of identifiers" in general, you have to talk about which kinds of identifiers, in which context. I guess you agree. If so, sorry, I hadn't understood. Yes, local identifiers are worthy of discussion. > I've seen one advocate for them (ILNP), where they make a handy > opportunity for those folks who prefer privacy. Changing your > locator to something with local scope does provide benefits in that > area, but it creates issues in others. Do identifiers now come in > a split namespace? Here there be complexity... ;-) Are folks ok > with this? Again, I would like the process to be explicit, otherwise we will probably ramble around and it will be hard to agree on whether we have reached any agreements. Do you want to start specifically with the class of solutions that includes ILNP, look specifically at "host" identifiers, and look at implications/possibilities/requirements? That would be fine with me. From HeinerHummel@aol.com Tue Apr 21 10:39:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD58E3A6DF8 for ; Tue, 21 Apr 2009 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=1.594, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIJiVDnHu2bc for ; Tue, 21 Apr 2009 10:39:14 -0700 (PDT) Received: from imr-m06.mx.aol.com (imr-m06.mx.aol.com [64.12.138.200]) by core3.amsl.com (Postfix) with ESMTP id 583E83A6E04 for ; Tue, 21 Apr 2009 10:39:14 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-m06.mx.aol.com (v107.10) with ESMTP id RELAYIN4-549ee04d43c0; Tue, 21 Apr 2009 13:39:32 -0400 Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v40_r1.5.) id o.cb5.5366a3f5 (39330); Tue, 21 Apr 2009 13:39:28 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 21 Apr 2009 13:39:28 EDT To: pfrejborg@gmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240335568" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 205.188.169.202 Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:39:16 -0000 -------------------------------1240335568 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IApUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UsCnRob3VnaCBpdCBkb2VzIG5vdCB5ZXQgYW5zd2Vy IG15IHF1ZXN0aW9ucy4gSSAnbSBzdGlsbCBsb29raW5nIGZvcndhcmQgdG8gIApiZSBhZHZpc2Vk LgpIZWluZXIKIApJbiBlaW5lciBlTWFpbCB2b20gMjEuMDQuMjAwOSAxMToyNjo0MSBXZXN0ZXVy b3DDpGlzY2hlIE5vcm1hbHplaXQgc2NocmVpYnQgIApwZnJlamJvcmdAZ21haWwuY29tOgoKSGVp bmVyLAoKZ3Vlc3MgdGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBpbXBsZW1lbnQgQW55Y2FzdCBp biBhICBuZXcKYXJjaGl0ZWN0dXJlLCBoZXJlIGlzIG9uZSB3YXkgb2YgZG9pbmcgaXQgLi4uCgpJ J20gY3VycmVudGx5ICByZXdyaXRpbmcgbXkgZHJhZnQgLSBhZnRlciBJIGhhZCBzdHVkaWVkIHRo ZSBEYWdzdHVobAptYXRlcmlhbCBJIG5vdGljZWQgIHRoYXQgSSBoYWQgdXNlZCBvbmx5IGxvY2F0 b3JzICh0aG91Z2ggdXNpbmcgbG9jYXRvcgphbmQgaWRlbnRpZmllciBpbiBteSAgdGV4dCkgYW5k IG5vdCBzZWVuIHRoZSBuZXcgZGltZW5zaW9uICh3aGljaCBpcwpjdXJyZW50bHkgbmFtZWQgIGlk ZW50aWZpZXIpICAuIFNvIEknbSBjaGFuZ2luZyBteSB0ZXh0LCB3aGljaCBpcyBub3QKcHVibGlz aGVkICB5ZXQ6Ci0gQXJlYSBMb2NhdG9yLCBBTE9DIChpdCBjb3VsZCBhbHNvIGJlIGNhbGxlZCBB dXRvbm9tb3VzICBzeXN0ZW0KTE9DYXRvciBvciBBZ2dyZWdhdGUgTE9DYXRvcikuIFRoZSBwdXJw b3NlIG9mIHRoZSBBTE9DIGlzIHRvIGxvY2F0ZSAgYW4KQVMsIG9yIGEgZ3JvdXAgb2YgQVMsIGlu IEludGVybmV0LgotIExvY2FsIExvY2F0b3IsIExMT0MuIFRoZSBwdXJwb3NlICBvZiB0aGUgTExP QyBpcyB0byBsb2NhdGUgYSBob3N0CmNvbm5lY3RlZCB0byBhbiBBTE9DIHJlYWxtCkFuZCBJIGhh dmUgIGFsc28gYWRkZWQgYW4gaWRlbnRpZmllciB0byB0aGUgZHJhZnQgYnV0IGxhdGVyIG1vcmUg b24KdGhhdCBvbmNlIHRoZXJlIGlzICBhIGNvbnNlbnN1cyBhYm91dCBpZGVudGlmaWVyCgpTbyBo ZXJlIGlzIGFuIGV4YW1wbGUgb2YgdGhlIHVzYWdlIG9mICBBbnljYXN0IGFuZCBsb2NhdG9yIGlu IGFuIAphcmNoaXRlY3R1cmUuCk5vdGUsIG5vIHNlc3Npb24gb3IgZmxvdyBzdGF0ZSBpbiAgdGhl IExTUi4gQWxzbyBjb252ZXJnaW5nIGZyb20gb25lCkxTUiB0byBhbm90aGVyIExTUiBpcyBkZXBl bmRpbmcgdXBvbiB0aGUgIGNvbnZlcmdlbmNlIHRpbWUgb2YgSUdQLiBIYWNrCm9yIG5vIGhhY2s/ CgozLiBBbiBvdmVydmlldyBvZiB0aGUgIGhJUHY0IGZyYW1ld29yawpJbiB0aGlzIHNlY3Rpb24g d2Ugd2lsbCBkaXNjdXNzIHRoZSByb2xlcyBvZiB0aGUgbmV3ICBlbGVtZW50cywKaW50cm9kdWNl ZCBieSB0aGUgaElQdjQgZnJhbWV3b3JrLCBhbmQgdGhlaXIgZGVwZW5kZW5jaWVzLgpBcyAgbWVu dGlvbmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiB0aGUgcm9sZSBvZiBhbiBBcmVhIExP Q2F0b3IKKEFMT0MpICBwcmVmaXggaXMgc2ltaWxhciBhcyB0byBhIGNvdW50cnkgY29kZSBpbiBQ U1ROLiBJLmUuIHRoZSBBTE9DCnByZWZpeCAgcHJvdmlkZXMgYSBsb2NhdGlvbiBmdW5jdGlvbmFs aXR5IG9mIGFuIEF1dG9ub21vdXMgU3lzdGVtIChBUyksCm9yIGEgZ3JvdXAgIG9mIEFTLCBpbiBJ bnRlcm5ldC4gVGhlIEFMT0MgcHJlZml4IHdpbGwgYmUgdXNlZCBmb3IKcm91dGluZyBhbmQgZm9y d2FyZGluZyAgcHVycG9zZXMgaW4gSW50ZXJuZXQsIHRodXMgdGhlIEFMT0MgcHJlZml4IG11c3QK YmUgZ2xvYmFsbHkgdW5pcXVlIGFuZCBpcyAgYWxsb2NhdGVkIGZyb20gYW4gSVB2NCBhZGRyZXNz IGJsb2NrLiBUaGlzCmdsb2JhbGx5IHVuaXF1ZSBJUHY0IGFkZHJlc3MgIGJsb2NrIGlzIGNhbGxl ZCB0aGUgR2xvYmFsIExvY2F0b3IgQmxvY2sKKEdMQikuCldoZW4gYW4gQVMgKG9yIGdyb3VwIG9m ICBBUykgYXJlIGFzc2lnbmVkIGFuIEFMT0MgcHJlZml4IHRoZSBhcmVhIGhhcwp0aGUgcG90ZW50 aWFsIHRvIGJlY29tZSBhbiAgQUxPQyByZWFsbS4gSW4gb3JkZXIgdG8gZXN0YWJsaXNoIGFuIEFM T0MKcmVhbG0gbW9yZSBlbGVtZW50cywgZnVydGhlciB0aGFuICB0aGUgQUxPQyBwcmVmaXgsIGFy ZSBuZWVkZWQuIE9uZSBvcgptdWx0aXBsZSBMb2NhdG9yIFN3YXAgUm91dGVyIChMU1IpIG11c3Qg IGJlIGF0dGFjaGVkIHRvIHRoZSBBTE9DIHJlYWxtLgpBIExTUiBlbGVtZW50IGlzIGEgbm9kZSBj YXBhYmxlIG9mIHN3YXBwaW5nICB0aGUgdmFsdWVzIG9mIHRoZSBJUHY0CmhlYWRlciBhbmQgdGhl IG5ldyBzaGltIGhlYWRlciwgY2FsbGVkIHRoZSAgbG9jYXRpb24vaWRlbnRpZmllciBoZWFkZXIu ClRoZSBzd2FwIG1lY2hhbmlzbSBvZiB0aGUgaGVhZGVycyBpcyBkZXNjcmliZWQgIGluIGRldGFp bCBpbiBzZWN0aW9uIDcsCnN0ZXAgNC4gVG9kYXnigJlzIHJvdXRlcnMgZG8gbm90IHN1cHBvcnQg dGhlIExTUiAgZnVuY3Rpb25hbGl0eS4KVGhlcmVmb3JlIHRoZSBuZXcgZnVuY3Rpb25hbGl0eSB3 aWxsIG1vc3QgbGlrZWx5IGJlICBkZXZlbG9wZWQgb24gYW4KZXh0ZXJuYWwgZGV2aWNlIGF0dGFj aGVkIHRvIGEgcm91dGVyIGJlbG9uZ2luZyB0byB0aGUgQUxPQyAgcmVhbG0uIFRoZQpleHRlcm5h bCBMU1IgbWlnaHQgYmUgYSBjb21wdXRlciB3aXRoIHR3byBpbnRlcmZhY2UgYXR0YWNoZWQgdG8g IGEKcm91dGVyLCB0aGUgZmlyc3QgaW50ZXJmYWNlIGNvbmZpZ3VyZWQgd2l0aCB0aGUgcHJlZml4 IG9mIHRoZSBBTE9DICBhbmQKdGhlIHNlY29uZCBpbnRlcmZhY2Ugd2l0aCBhbnkgSVB2NCBwcmVm aXguIFRoZSBMU1IgZG8gbm90IG1ha2UgdXMgIG9mCmR5bmFtaWMgcm91dGluZyBwcm90b2NvbHMs IG5laXRoZXIgYSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UgIChGSUIpCmlzIG5lZWRlZCAt IHRoZSBMU1IgaXMgcHJvZHVjaW5nIGEgc2VydmljZSwgaS5lLiBzd2FwcGluZyBoZWFkZXJzLiAg VGhlCnN3YXAgbWVjaGFuaXNtIGlzIGFwcGxpZWQgb24gcGVyIGRhdGFncmFtIGJhc2lzIGFuZCB0 aGUgIGluZm9ybWF0aW9uCm5lZWRlZCB0byBjYXJyeSBvdXQgdGhlIHN3YXAgaXMgaW5jbHVkZWQg aW4gdGhlIGhlYWRlciBvZiB0aGUgIGhJUHY0CmRhdGFncmFtLiBUaHVzIGEgY29tcHV0ZXIgd2l0 aCBlbm91Z2ggY29tcHV0aW5nIGFuZCBJL08gcmVzb3VyY2VzICBpcwpzdWZmaWNpZW50IHRvIHRh a2UgdGhlIHJvbGUgYXMgYSBMU1IuIExhdGVyIG9uLCB0aGUgTFNSICBmdW5jdGlvbmFsaXR5Cm1p Z2h0IGJlIGludGVncmF0ZWQgaW50byB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZiBhIHJvdXRlci4g IE9uZSBMU1IgY2FuCm5vdCBoYW5kbGUgYWxsIHRoZSBpbmNvbWluZyB0cmFmZmljIGRlc2lnbmF0 ZWQgZm9yIGFuIEFMT0MgIHJlYWxtOyBpdAp3b3VsZCBhbHNvIGNyZWF0ZSBhIHBvdGVudGlhbCBz aW5nbGUgcG9pbnQgb2YgZmFpbHVyZSBpbiB0aGUgIG5ldHdvcmsuClRoZXJlZm9yZSwgc2V2ZXJh bCBMU1JzIHNoYWxsIGJlIGluc3RhbGxlZCBpbiB0aGUgQUxPQyByZWFsbSBhbmQgIHRoZQpMU1Jz IHNoYWxsIHVzZSB0aGUgQUxPQyBwcmVmaXggYXMgdGhlaXIgbG9jYXRvciBhbmQgdGhlIHJvdXRl cnMgIGFyZQphbm5vdW5jaW5nIHRoZSBBTE9DIHByZWZpeCBhcyBhbiBBbnljYXN0IGFkZHJlc3Mg d2l0aGluIHRoZSBsb2NhbCAgQUxPQwpyZWFsbS4gQWxzbywgdGhlIEFMT0MgcHJlZml4IGlzIGFk dmVydGlzZWQgdGhyb3VnaG91dCB0aGUgREZaIGJ5ICBCR1AKbWVjaGFuaXNtcy4gVGhlIHBsYWNl bWVudCBvZiB0aGUgTFNScyBpbiB0aGUgbmV0d29yayB3aWxsIGluZmx1ZW5jZSAgb24KdGhlIGlu Z3Jlc3MgdHJhZmZpYyB0byB0aGUgQUxPQyByZWFsbSwgdGhlIExTUiBpcyBwcm92aWRpbmcgIOKA nG5lYXJlc3QKcm91dGluZ+KAnSBmdW5jdGlvbmFsaXR5LgoKLS0gcGF0dGUKCk9uIFR1ZSwgQXBy IDIxLCAgMjAwOSBhdCAxMTowMCBBTSwgIDxIZWluZXJIdW1tZWxAYW9sLmNvbT4gd3JvdGU6Cj4g V2hhdCBhcmUgIHRoZSByZXF1aXJlbWVudHMgZm9yIEFueWNhc3QgaW4gYSBuZXcgYXJjaGl0ZWN0 dXJlPwo+IEFzIEkgdW5kZXJzdGFuZCAgQW55Y2FzdCAgaXMgYWJvdXQgZGVsaXZlcnkgdG8gb25l IG91dCBvZiBtdWx0aXBsZQo+ICBkZXN0aW5hdGlvbnMgd2l0aGluIGEgZ2l2ZW4gc2NvcGUuCj4g V2hlcmUgaXMgdGhlIGNlbnRlciBwb2ludCBvZiAgdGhpcyBzY29wZSA/IElzIGl0IGFsd2F5cyB0 aGUgbG9jYXRpb24gb2YgCnRoZQo+IHNvdXJjZSA/Cj4gIENhbi9zaG91bGQgaXQgYmUgc29tZXRo aW5nIHRvIGJlIHByb3ZpZGVkL3NpZ25hbGxlZCAod2hpY2ggbWFrZXMgc2Vuc2UgIAppZgo+IGFs dGVybmF0aXZlcyB0byB0aGF0IGNhc2Ugd2VyZSBhbGxvd2VkIHdoZXJlIHRoZSBzb3VyY2UgaXMg dGhpcyAgY2VudGVyCj4gcG9pbnQpPwo+Cj4gV2hvIGRldGVybWluZXMgdGhlIGZpbmFsIFVuaWNh c3QgIGRlc3RpbmF0aW9uID8gdGhlIHNvdXJjZT8gdGhlIGluZ3Jlc3MKPiByb3V0ZXI/IE9yIGFs c28gc29tZSAgcm91dGVyL3NlcnZlciBhbG9uZyB0aGUgcGF0aD8KPiBNYXkgYW4gZW5mb3JjZWQg ZGV0b3VyIG9mIHRoZSAgZm9yd2FyZGluZyBwYXRoICB3aW5kIHVwIGluIHNlbGVjdGluZyBhCj4g ZGlmZmVyZW50IFVuaWNhc3QgIGRlc3RpbmF0aW9uIC0gZG9uZSBieSBhbnkgdHJhbnNpdCByb3V0 ZXI/Cj4KPiBJJ2xsICBhcHByZWNpYXRlIGxlYXJuaW5nIHRoZSBhbnN3ZXJzIHRvIHRoZXNlIHF1 ZXN0aW9ucyBiZWNhdXNlIEkgIHRoaW5rCj4gdGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gY29u Y2VpdmUgYW5kIGltcGxlbWVudCBBbnljYXN0IChub3QgIGp1c3QgdGhlCj4gdHJhZGl0aW9uYWwg b25lKS4gVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGNvbmNlcHRzIGRldmVsb3BlZCAgZm9yIG90aGVy Cj4gc2VydmljZXMgd2hpY2ggYXJlIGxpa2V3aXNlIGFwcGxpY2FibGUgdG8gQW55Y2FzdDogTUlQ NCBjYXJlICBvZiBhZGRyZXNzCj4gc2VydmVyLCBISVAgcmVuZGV6LXZvdXMgc2VydmVyLC4uLgo+ Cj4KPiAgSGVpbmVyCj4KPgo+Cj4KPiBJbiBlaW5lciBlTWFpbCB2b20gMjEuMDQuMjAwOSAgMDc6 NTg6MDcgV2VzdGV1cm9ww6Rpc2NoZSBOb3JtYWx6ZWl0IApzY2hyZWlidAo+ICB0b255LmxpQHRv bnkubGk6Cj4KPiBIaSBCaWxsLAo+Cj4+IEkgaGF2ZSB0aGlzICBtZW50YWwgcGljdHVyZSBvZiB0 aGUgTkZBcyBhbmQgREZBcyAoZmluaXRlIGF1dG9tYXRhKSB1c2VkCj4+IHRvICBwcm9jZXNzIHJl Z3VsYXIgZ3JhbW1hcnMgZnJvbSB0aGUgZm9ybWFsIGxhbmd1YWdlcyBjbGFzcyBJIHRvb2sgaW4K Pj4gIGNvbGxlZ2UuIEFsbCBORkEncyBjYW4gYmUgdHJhbnNsYXRlZCB0byBERkFzIGJ1dCB0aGUg dHJhbnNsYXRpb24KPj4gIGV4cGxvc2l2ZWx5IGdyb3dzIHRoZSBhdXRvbWF0YS4KPj4KPj4gU2Vl bXMgdG8gbWUgbGlrZSBORkFzICBhcmUgZGVjZW50IG1ldGFwaG9ycyBmb3IgYnJvYWRjYXN0IGFu ZCBtdWx0aWNhc3QKPj4gd2hpbGUgREZBcyBhcmUgIG1ldGFwaG9ycyBmb3IgYW55Y2FzdCBhbmQg dW5pY2FzdC4gQW5kIEkgdGhpbmsgaXRzCj4+IG5vdGFibGUgdGhhdCAgYW55Y2FzdCBncm91cHMg d2l0aCB1bmljYXN0IChpdCdzIERGQS1saWtlKSBpbnN0ZWFkIG9mCj4+IGdyb3VwaW5nICB3aXRo IG11bHRpY2FzdC4KPgo+Cj4gT2ssIEkgcmVtZW1iZXIgdGhlc2UuICBTdGlsbCBoYXZlICB0aGUg dGV4dGJvb2sgcmlnaHQgaGVyZS4gIDstKQo+Cj4KPj4+IEV4Y2VwdCB0aGF0ICB3ZSBoYXZlbid0 IGZpZ3VyZWQgb3V0IGhvdyB0byBhZ2dyZWdhdGUgYW55Y2FzdCwgd2hpY2ggCmZyb20gYQo+Pj4g IHJvdXRpbmcgcGVyc3BlY3RpdmUsIG1ha2VzIGl0IGNvbXBsZXRlbHkgdW5pcXVlLgo+Pgo+PiBX aGF0ICBkbyB5b3UgbWVhbj8gQW55Y2FzdCBhZ2dyZWdhdGVzIHRoZSBzYW1lIHdheSBhcyB1bmlj YXN0OiB3aGVuZXZlcgo+PiAgdGhlIGVuZHBvaW50cyBwaHlzaWNhbGx5IGdyb3VwIHRvZ2V0aGVy LCB0aGV5IGFnZ3JlZ2F0ZS4gQXQgYQo+PiAgcHJhY3RpY2FsIGxldmVsLCB0aGF0J3MgcmFyZWx5 IHVzZWZ1bCBmb3IgYW55Y2FzdC4uLiBCdXQgdGhlbiBhdCBhCj4+ICBwcmFjdGljYWwgbGV2ZWwg YWdncmVnYXRpbmcgdW5pY2FzdCB0aGF0IHdheSAob3IgZmFpbGluZyB0bykgaXMgIHRoZQo+PiBz b3VyY2Ugb2Ygb3VyIGN1cnJlbnQgZ3JpZWYuCj4KPgo+IFdlbGwsIHRoZSAgcHJvYmxlbSB3aXRo IGFnZ3JlZ2F0aW5nIGFueWNhc3QgaXMgdGhhdCBpdCBlbmRzIHVwIHdpdGggb25lCj4gcm91dGUg cGVyICBzZXJ2aWNlLiAgSW4gYSB3b3JsZCBvZiBoaWdobHkgZGlmZmVyZW50aWF0ZWQgc2Vydmlj ZXMsIHRoZQo+IHNoZWVyICBudW1iZXIgb2Ygc2VydmljZXMgY291bGQgYmUgZXhwbG9zaXZlLiAg QW5kIHlvdSBjYW4gb25seSAgYWdncmVnYXRlCj4gdGhlbSBpZiB0aGV5IGFyZSBudW1iZXJlZCBh cHByb3ByaWF0ZWx5IGFuZCBhcmUgIHRvcG9sb2dpY2FsbHkKPiBjb3JyZWxhdGVkLiAgSG93IG9m dGVuIGlzIHRoYXQgZ29pbmcgdG8gaGFwcGVuIHdpdGggIGFueWNhc3Q/Cj4KPiBUbyBiZSBmYWly LCB3ZSBkbyBnZXQgc3Vic3RhbnRpYWwgYWdncmVnYXRpb24gdXAgdG8gIHRoZSBzaXRlIGxldmVs IHdpdGgKPiB1bmljYXN0LCBpdCdzIGFib3ZlIHRoYXQgbGV2ZWwgdGhhdCB0aGluZ3MgZ2V0ICBp ZmZ5Lgo+Cj4KPj4+PiBUaGUgc2FtZSBjYW4ndCBiZSBzYWlkIG9mIG11bHRpY2FzdC4gIE11bHRp Y2FzdCBoYXMgZGlmZmVyZW50IHNlbWFudGljcwo+Pj4+IGV2ZW4gaWYgdGhlcmUncyBvbmx5IG9u ZSAgaG9zdCBpbiB0aGUgZ3JvdXAuCj4+PiBTYXkgbW9yZSBwbGVhc2UsIEknbSBub3QgIGZvbGxv d2luZy4KPj4KPj4gV2l0aCBhbnljYXN0LCB0aGUgcGFja2V0J3MgbmV4dCBob3AgaXMgIGFsd2F5 cyBpbiBleGFjdGx5IG9uZQo+PiBkaXJlY3Rpb24sIHByZWNpc2VseSB0aGUgc2FtZSBhcyB3aXRo ICB1bmljYXN0LiBBbmQga25vd2xlZGdlIGFib3V0Cj4+IHdoYXQgdGhhdCBuZXh0IGhvcCBzaG91 bGQgYmUgIHByb3BhZ2F0ZXMgcHJlY2lzZWx5IHRoZSBzYW1lIHdheS4KPj4KPj4gV2l0aCBtdWx0 aWNhc3QsIHRoZSAgcGFja2V0IGlzIHJlcGxpY2F0ZWQgaW4gYWxsIGN1cnJlbnRseSB2YWxpZAo+ PiBkaXJlY3Rpb25zIHdpdGggIGNvbXBsZXggc3Vic2NyaXB0aW9uL2Rlc3Vic2NyaXB0aW9uIG92 ZXJoZWFkIHRoYXQgaGFzCj4+IHRvIGJlICBtYWludGFpbmVkIGV2ZW4gaWYgdGhlcmUncyBvbmx5 IG9uZSByZWNlaXZlciBpbiB0aGUgIGdyb3VwLgo+Cj4KPiBIYXZpbmcgd2F0Y2hlZCB0aGUgZGV2 ZWxvcG1lbnQgb2YgUElNLCBCR1AsICBPU1BGLCBBUlAsIEhTUlAsIFZSUlAsIGFuZAo+IElTLUlT LCBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHNheWluZyB0aGF0ICB0aGUgImNvbXBsZXgKPiBzdWJz Y3JpcHRpb24vZGVzdWJzY3JpcHRpb24iIG92ZXJoZWFkIGZvciBtdWx0aWNhc3QgaXMgIGFsbCB0 aGF0IG11Y2gKPiB3b3JzZSB0aGFuIHdoYXQgd2UgZG8gZm9yIHVuaWNhc3QuCj4KPiBBcyAgZm9y IHRoZSBmb3J3YXJkaW5nIHBsYW5lLCB0aGUgZGlmZmVyZW5jZXMgYXJlIE5PVCB0aGF0IGxhcmdl LiAgIE9rLAo+IHllcywgdGhlcmUgaXMgYW4gb3JkZXIgb2YgbWFnbml0dWRlIG1vcmUgY29tcGxl eGl0eSBpbiBkb2luZyB0aGUgIHBhY2tldAo+IHJlcGxpY2F0aW9uLCBidXQgaXQgYmVjb21lcyBx dWl0ZSBjbGVhciB0aGF0IHdpdGggb25lIHJlY2VpdmVyICBpdCBkb2VzCj4gZGV2b2x2ZSBuaWNl bHkgaW50byBhbiBlZmZlY3RpdmUgdW5pY2FzdC4gIE5vIG9uZSB3b3VsZCAgaW1wbGVtZW50Cj4g dW5pY2FzdCB0aGF0IHdheSwgb2YgY291cnNlLCBidXQgdGhhdCdzIGFuIGVmZmljaWVuY3kgaXNz dWUsICBub3QgYQo+IGNvbmNlcHR1YWwgb25lLgo+Cj4gRXZlbiBpZiBtdWx0aWNhc3QncyAgZGlm ZmVyZW50aWF0aW9uIGlzIHRoZSByZXBsaWNhdGlvbiBpbiB0aGUgZGF0YQo+IHBsYW5lLCBJJ20g bm90IHN1cmUgSSAgc2VlIGhvdyB0aGF0IGJlY29tZXMgbm9uLWRldGVybWluaXN0aWMuICBJIHNl ZSBubwo+IHJlZmVyZW5jZXMgdG8gIGFuIG9yYWNsZS4gIFRoZSByaWdodCB0aGluZ3MgYWx3YXlz IHNlZW1zIHRvIGhhcHBlbiB3aXRoCj4gdG90YWwgIGRldGVybWluaXNtLgo+Cj4KPj4+IE9rLCBi dXQgaG93IHdvdWxkIGEgbWFwICByZXNvbHV0aW9uIGNoYW5nZSB0aGF0PyAgSXMgdGhlIGtleSBw b2ludCBoZXJlCj4+PiAgdGhhdAo+Pj4gd2hhdGV2ZXIgbWFwcGluZyBmdW5jdGlvbiBpcyB1c2Vk LCB0aGUgbWFwIHJlc3VsdCBoYXMgYSAgVFRMIGFuZCBuZWVkcyAKdG8KPj4+IGJlCj4+PiByZWZy ZXNoZWQgIHBlcmlvZGljYWxseT8gIE9yLCB0aGUgYXBwbGljYXRpb25zIG5lZWQgdG8gYmUgYWJs ZSB0byAgCnRyaWdnZXIKPj4+IGEKPj4+IHJlZnJlc2g/Cj4+Cj4+ICBZb3UnZCBwdXQgdGhlIG1h cCByZXNvbHV0aW9uIG91dHNpZGUgdGhlIGFwcCBkZXZlbG9wZXIncyBzY29wZSwgIGVpdGhlcgo+ PiBpbiB0aGUgbmV0d29yayAoYXMgcHJvcG9zZWQgYnkgc3RyYXRlZ3kgQSkgb3IgaW4gdGhlICBz eXN0ZW0tbGV2ZWwgaG9zdAo+PiBzb2Z0d2FyZSAoYXMgcHJvcG9zZWQgYnkgc3RyYXRlZ3kgQiku ICBVbnByaXZpbGVnZWQgYXBwbGljYXRpb25zIHNpbXBseQo+PiB3b3VsZG4ndCBiZSBhYmxlIHRv IGRpZGRsZSB3aXRoICBhZGRyZXNzZXMgYXQgdGhlIHJvdXRpbmcgbGF5ZXIuCj4+Cj4+IFdpdGgg YSBndWFyYW50ZWVkICBtYXhpbXVtIHRpbWUgdGhhdCBhIGdpdmVuIG1hcCByZW1haW5zIHZhbGlk IGFuZCBubwo+PiAgYXBwbGljYXRpb24tbGV2ZWwgYWNjZXNzIHRvIHRoZSByb3V0aW5nIGVsZW1l bnQsIHRoZSBwcm90b2NvbCBhbmQKPj4gIHdlaWdoIGluIGZhdm9yIG9mIHJlbnVtYmVyaW5nIGZv ciBhZ2dyZWdhdGlvbiBpbnN0ZWFkIG9mIHJlcm91dGluZyAgZm9yCj4+IG11bHRpcGxlIGNvbm5l Y3Rpb25zLgo+Pgo+PiBCdXQgdGhpcyBpcyAgcmF0aGVyIG9mZiBvbiBhIHRhbmdlbnQgZnJvbSBh bnljYXN0IGFuZCBpdHMgcmF0aGVyCj4+IGlkZW50aWNhbCAgbmF0dXJlIHRvIHVuaWNhc3QuCj4K Pgo+IFNlZW1zIGxpa2UgdXNlZnVsIGltcGxlbWVudGF0aW9uICBzdHJhdGVnaWVzIHRvIG1lLiAg QW5kIGl0IGxlYWRzIG1lCj4gYWdhaW4gdG8gdGhlIGNvbmNsdXNpb24gdGhhdCAgaXQncyBhZ2Fp biBub3Qgc29tZXRoaW5nIHRoYXQncyBoYXBwZW5pbmcKPiB3aXRoaW4gdGhlIHJvdXRpbmcgIHN1 YnN5c3RlbS4KPgo+IFRvbnkKPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPiBycmcgbWFpbGluZyAgbGlzdAo+IHJyZ0BpcnRmLm9yZwo+ICBodHRwOi8v d3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vcnJnCj4KPgo+ICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHJyZyBtYWlsaW5nICBsaXN0Cj4gcnJn QGlydGYub3JnCj4gIGh0dHA6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ycmcKPgo+ CgoKIAo= -------------------------------1240335568 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjYw MDAuMTY4MjUiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4KPEJPRFkgaWQ9cm9sZV9ib2R5IHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQXJpYWwiIApi b3R0b21NYXJnaW49NyBsZWZ0TWFyZ2luPTcgdG9wTWFyZ2luPTcgcmlnaHRNYXJnaW49Nz48Rk9O VCBpZD1yb2xlX2RvY3VtZW50IApmYWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPgo8RElW Pgo8RElWPlRoYW5rcyBmb3ImbmJzcDt5b3VyIHJlc3BvbnNlLDwvRElWPgo8RElWPnRob3VnaCBp dCBkb2VzIG5vdCB5ZXQgYW5zd2VyIG15IHF1ZXN0aW9ucy4gSSAnbSBzdGlsbCBsb29raW5nIGZv cndhcmQgdG8gCmJlIGFkdmlzZWQuPC9ESVY+CjxESVY+SGVpbmVyPC9ESVY+CjxESVY+Jm5ic3A7 PC9ESVY+CjxESVY+SW4gZWluZXIgZU1haWwgdm9tIDIxLjA0LjIwMDkgMTE6MjY6NDEgV2VzdGV1 cm9ww6Rpc2NoZSBOb3JtYWx6ZWl0IHNjaHJlaWJ0IApwZnJlamJvcmdAZ21haWwuY29tOjwvRElW Pgo8QkxPQ0tRVU9URSAKc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogYmx1ZSAycHggc29saWQiPjxGT05UIAogIHN0eWxlPSJCQUNLR1JPVU5E LUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwIAogIHNpemU9Mj5I ZWluZXIsPEJSPjxCUj5ndWVzcyB0aGVyZSBhcmUgc2V2ZXJhbCB3YXlzIHRvIGltcGxlbWVudCBB bnljYXN0IGluIGEgCiAgbmV3PEJSPmFyY2hpdGVjdHVyZSwgaGVyZSBpcyBvbmUgd2F5IG9mIGRv aW5nIGl0IC4uLjxCUj48QlI+SSdtIGN1cnJlbnRseSAKICByZXdyaXRpbmcgbXkgZHJhZnQgLSBh ZnRlciBJIGhhZCBzdHVkaWVkIHRoZSBEYWdzdHVobDxCUj5tYXRlcmlhbCBJIG5vdGljZWQgCiAg dGhhdCBJIGhhZCB1c2VkIG9ubHkgbG9jYXRvcnMgKHRob3VnaCB1c2luZyBsb2NhdG9yPEJSPmFu ZCBpZGVudGlmaWVyIGluIG15IAogIHRleHQpIGFuZCBub3Qgc2VlbiB0aGUgbmV3IGRpbWVuc2lv biAod2hpY2ggaXM8QlI+Y3VycmVudGx5IG5hbWVkIAogIGlkZW50aWZpZXIpJm5ic3A7IC4gU28g SSdtIGNoYW5naW5nIG15IHRleHQsIHdoaWNoIGlzIG5vdDxCUj5wdWJsaXNoZWQgCiAgeWV0OjxC Uj4tIEFyZWEgTG9jYXRvciwgQUxPQyAoaXQgY291bGQgYWxzbyBiZSBjYWxsZWQgQXV0b25vbW91 cyAKICBzeXN0ZW08QlI+TE9DYXRvciBvciBBZ2dyZWdhdGUgTE9DYXRvcikuIFRoZSBwdXJwb3Nl IG9mIHRoZSBBTE9DIGlzIHRvIGxvY2F0ZSAKICBhbjxCUj5BUywgb3IgYSBncm91cCBvZiBBUywg aW4gSW50ZXJuZXQuPEJSPi0gTG9jYWwgTG9jYXRvciwgTExPQy4gVGhlIHB1cnBvc2UgCiAgb2Yg dGhlIExMT0MgaXMgdG8gbG9jYXRlIGEgaG9zdDxCUj5jb25uZWN0ZWQgdG8gYW4gQUxPQyByZWFs bTxCUj5BbmQgSSBoYXZlIAogIGFsc28gYWRkZWQgYW4gaWRlbnRpZmllciB0byB0aGUgZHJhZnQg YnV0IGxhdGVyIG1vcmUgb248QlI+dGhhdCBvbmNlIHRoZXJlIGlzIAogIGEgY29uc2Vuc3VzIGFi b3V0IGlkZW50aWZpZXI8QlI+PEJSPlNvIGhlcmUgaXMgYW4gZXhhbXBsZSBvZiB0aGUgdXNhZ2Ug b2YgCiAgQW55Y2FzdCBhbmQgbG9jYXRvciBpbiBhbiBhcmNoaXRlY3R1cmUuPEJSPk5vdGUsIG5v IHNlc3Npb24gb3IgZmxvdyBzdGF0ZSBpbiAKICB0aGUgTFNSLiBBbHNvIGNvbnZlcmdpbmcgZnJv bSBvbmU8QlI+TFNSIHRvIGFub3RoZXIgTFNSIGlzIGRlcGVuZGluZyB1cG9uIHRoZSAKICBjb252 ZXJnZW5jZSB0aW1lIG9mIElHUC4gSGFjazxCUj5vciBubyBoYWNrPzxCUj48QlI+My4gQW4gb3Zl cnZpZXcgb2YgdGhlIAogIGhJUHY0IGZyYW1ld29yazxCUj5JbiB0aGlzIHNlY3Rpb24gd2Ugd2ls bCBkaXNjdXNzIHRoZSByb2xlcyBvZiB0aGUgbmV3IAogIGVsZW1lbnRzLDxCUj5pbnRyb2R1Y2Vk IGJ5IHRoZSBoSVB2NCBmcmFtZXdvcmssIGFuZCB0aGVpciBkZXBlbmRlbmNpZXMuPEJSPkFzIAog IG1lbnRpb25lZCBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gdGhlIHJvbGUgb2YgYW4gQXJl YSBMT0NhdG9yPEJSPihBTE9DKSAKICBwcmVmaXggaXMgc2ltaWxhciBhcyB0byBhIGNvdW50cnkg Y29kZSBpbiBQU1ROLiBJLmUuIHRoZSBBTE9DPEJSPnByZWZpeCAKICBwcm92aWRlcyBhIGxvY2F0 aW9uIGZ1bmN0aW9uYWxpdHkgb2YgYW4gQXV0b25vbW91cyBTeXN0ZW0gKEFTKSw8QlI+b3IgYSBn cm91cCAKICBvZiBBUywgaW4gSW50ZXJuZXQuIFRoZSBBTE9DIHByZWZpeCB3aWxsIGJlIHVzZWQg Zm9yPEJSPnJvdXRpbmcgYW5kIGZvcndhcmRpbmcgCiAgcHVycG9zZXMgaW4gSW50ZXJuZXQsIHRo dXMgdGhlIEFMT0MgcHJlZml4IG11c3Q8QlI+YmUgZ2xvYmFsbHkgdW5pcXVlIGFuZCBpcyAKICBh bGxvY2F0ZWQgZnJvbSBhbiBJUHY0IGFkZHJlc3MgYmxvY2suIFRoaXM8QlI+Z2xvYmFsbHkgdW5p cXVlIElQdjQgYWRkcmVzcyAKICBibG9jayBpcyBjYWxsZWQgdGhlIEdsb2JhbCBMb2NhdG9yIEJs b2NrPEJSPihHTEIpLjxCUj5XaGVuIGFuIEFTIChvciBncm91cCBvZiAKICBBUykgYXJlIGFzc2ln bmVkIGFuIEFMT0MgcHJlZml4IHRoZSBhcmVhIGhhczxCUj50aGUgcG90ZW50aWFsIHRvIGJlY29t ZSBhbiAKICBBTE9DIHJlYWxtLiBJbiBvcmRlciB0byBlc3RhYmxpc2ggYW4gQUxPQzxCUj5yZWFs bSBtb3JlIGVsZW1lbnRzLCBmdXJ0aGVyIHRoYW4gCiAgdGhlIEFMT0MgcHJlZml4LCBhcmUgbmVl ZGVkLiBPbmUgb3I8QlI+bXVsdGlwbGUgTG9jYXRvciBTd2FwIFJvdXRlciAoTFNSKSBtdXN0IAog IGJlIGF0dGFjaGVkIHRvIHRoZSBBTE9DIHJlYWxtLjxCUj5BIExTUiBlbGVtZW50IGlzIGEgbm9k ZSBjYXBhYmxlIG9mIHN3YXBwaW5nIAogIHRoZSB2YWx1ZXMgb2YgdGhlIElQdjQ8QlI+aGVhZGVy IGFuZCB0aGUgbmV3IHNoaW0gaGVhZGVyLCBjYWxsZWQgdGhlIAogIGxvY2F0aW9uL2lkZW50aWZp ZXIgaGVhZGVyLjxCUj5UaGUgc3dhcCBtZWNoYW5pc20gb2YgdGhlIGhlYWRlcnMgaXMgZGVzY3Jp YmVkIAogIGluIGRldGFpbCBpbiBzZWN0aW9uIDcsPEJSPnN0ZXAgNC4gVG9kYXnigJlzIHJvdXRl cnMgZG8gbm90IHN1cHBvcnQgdGhlIExTUiAKICBmdW5jdGlvbmFsaXR5LjxCUj5UaGVyZWZvcmUg dGhlIG5ldyBmdW5jdGlvbmFsaXR5IHdpbGwgbW9zdCBsaWtlbHkgYmUgCiAgZGV2ZWxvcGVkIG9u IGFuPEJSPmV4dGVybmFsIGRldmljZSBhdHRhY2hlZCB0byBhIHJvdXRlciBiZWxvbmdpbmcgdG8g dGhlIEFMT0MgCiAgcmVhbG0uIFRoZTxCUj5leHRlcm5hbCBMU1IgbWlnaHQgYmUgYSBjb21wdXRl ciB3aXRoIHR3byBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gCiAgYTxCUj5yb3V0ZXIsIHRoZSBmaXJz dCBpbnRlcmZhY2UgY29uZmlndXJlZCB3aXRoIHRoZSBwcmVmaXggb2YgdGhlIEFMT0MgCiAgYW5k PEJSPnRoZSBzZWNvbmQgaW50ZXJmYWNlIHdpdGggYW55IElQdjQgcHJlZml4LiBUaGUgTFNSIGRv IG5vdCBtYWtlIHVzIAogIG9mPEJSPmR5bmFtaWMgcm91dGluZyBwcm90b2NvbHMsIG5laXRoZXIg YSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uIGJhc2UgCiAgKEZJQik8QlI+aXMgbmVlZGVkIC0gdGhl IExTUiBpcyBwcm9kdWNpbmcgYSBzZXJ2aWNlLCBpLmUuIHN3YXBwaW5nIGhlYWRlcnMuIAogIFRo ZTxCUj5zd2FwIG1lY2hhbmlzbSBpcyBhcHBsaWVkIG9uIHBlciBkYXRhZ3JhbSBiYXNpcyBhbmQg dGhlIAogIGluZm9ybWF0aW9uPEJSPm5lZWRlZCB0byBjYXJyeSBvdXQgdGhlIHN3YXAgaXMgaW5j bHVkZWQgaW4gdGhlIGhlYWRlciBvZiB0aGUgCiAgaElQdjQ8QlI+ZGF0YWdyYW0uIFRodXMgYSBj b21wdXRlciB3aXRoIGVub3VnaCBjb21wdXRpbmcgYW5kIEkvTyByZXNvdXJjZXMgCiAgaXM8QlI+ c3VmZmljaWVudCB0byB0YWtlIHRoZSByb2xlIGFzIGEgTFNSLiBMYXRlciBvbiwgdGhlIExTUiAK ICBmdW5jdGlvbmFsaXR5PEJSPm1pZ2h0IGJlIGludGVncmF0ZWQgaW50byB0aGUgZm9yd2FyZGlu ZyBwbGFuZSBvZiBhIHJvdXRlci4gCiAgT25lIExTUiBjYW48QlI+bm90IGhhbmRsZSBhbGwgdGhl IGluY29taW5nIHRyYWZmaWMgZGVzaWduYXRlZCBmb3IgYW4gQUxPQyAKICByZWFsbTsgaXQ8QlI+ d291bGQgYWxzbyBjcmVhdGUgYSBwb3RlbnRpYWwgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUgaW4g dGhlIAogIG5ldHdvcmsuPEJSPlRoZXJlZm9yZSwgc2V2ZXJhbCBMU1JzIHNoYWxsIGJlIGluc3Rh bGxlZCBpbiB0aGUgQUxPQyByZWFsbSBhbmQgCiAgdGhlPEJSPkxTUnMgc2hhbGwgdXNlIHRoZSBB TE9DIHByZWZpeCBhcyB0aGVpciBsb2NhdG9yIGFuZCB0aGUgcm91dGVycyAKICBhcmU8QlI+YW5u b3VuY2luZyB0aGUgQUxPQyBwcmVmaXggYXMgYW4gQW55Y2FzdCBhZGRyZXNzIHdpdGhpbiB0aGUg bG9jYWwgCiAgQUxPQzxCUj5yZWFsbS4gQWxzbywgdGhlIEFMT0MgcHJlZml4IGlzIGFkdmVydGlz ZWQgdGhyb3VnaG91dCB0aGUgREZaIGJ5IAogIEJHUDxCUj5tZWNoYW5pc21zLiBUaGUgcGxhY2Vt ZW50IG9mIHRoZSBMU1JzIGluIHRoZSBuZXR3b3JrIHdpbGwgaW5mbHVlbmNlIAogIG9uPEJSPnRo ZSBpbmdyZXNzIHRyYWZmaWMgdG8gdGhlIEFMT0MgcmVhbG0sIHRoZSBMU1IgaXMgcHJvdmlkaW5n IAogIOKAnG5lYXJlc3Q8QlI+cm91dGluZ+KAnSBmdW5jdGlvbmFsaXR5LjxCUj48QlI+LS0gcGF0 dGU8QlI+PEJSPk9uIFR1ZSwgQXByIDIxLCAKICAyMDA5IGF0IDExOjAwIEFNLCZuYnNwOyAmbHQ7 SGVpbmVySHVtbWVsQGFvbC5jb20mZ3Q7IHdyb3RlOjxCUj4mZ3Q7IFdoYXQgYXJlIAogIHRoZSBy ZXF1aXJlbWVudHMgZm9yIEFueWNhc3QgaW4gYSBuZXcgYXJjaGl0ZWN0dXJlPzxCUj4mZ3Q7IEFz IEkgdW5kZXJzdGFuZCAKICBBbnljYXN0Jm5ic3A7IGlzIGFib3V0IGRlbGl2ZXJ5IHRvIG9uZSBv dXQgb2YgbXVsdGlwbGU8QlI+Jmd0OyAKICBkZXN0aW5hdGlvbnMmbmJzcDt3aXRoaW4gYSBnaXZl biBzY29wZS48QlI+Jmd0OyBXaGVyZSBpcyB0aGUgY2VudGVyIHBvaW50IG9mIAogIHRoaXMgc2Nv cGUgPyBJcyBpdCBhbHdheXMgdGhlIGxvY2F0aW9uIG9mIHRoZTxCUj4mZ3Q7IHNvdXJjZSA/PEJS PiZndDsgCiAgQ2FuL3Nob3VsZCBpdCBiZSBzb21ldGhpbmcgdG8gYmUgcHJvdmlkZWQvc2lnbmFs bGVkICh3aGljaCBtYWtlcyBzZW5zZSAKICBpZjxCUj4mZ3Q7IGFsdGVybmF0aXZlcyB0byB0aGF0 IGNhc2Ugd2VyZSBhbGxvd2VkIHdoZXJlIHRoZSBzb3VyY2UgaXMgdGhpcyAKICBjZW50ZXI8QlI+ Jmd0OyBwb2ludCk/PEJSPiZndDs8QlI+Jmd0OyBXaG8gZGV0ZXJtaW5lcyB0aGUgZmluYWwgVW5p Y2FzdCAKICBkZXN0aW5hdGlvbiA/IHRoZSBzb3VyY2U/IHRoZSBpbmdyZXNzPEJSPiZndDsgcm91 dGVyPyBPciBhbHNvIHNvbWUgCiAgcm91dGVyL3NlcnZlciBhbG9uZyB0aGUgcGF0aD88QlI+Jmd0 OyBNYXkmbmJzcDthbiBlbmZvcmNlZCBkZXRvdXIgb2YgdGhlIAogIGZvcndhcmRpbmcgcGF0aCZu YnNwOyB3aW5kIHVwIGluIHNlbGVjdGluZyBhPEJSPiZndDsgZGlmZmVyZW50IFVuaWNhc3QgCiAg ZGVzdGluYXRpb24gLSBkb25lIGJ5IGFueSB0cmFuc2l0IHJvdXRlcj88QlI+Jmd0OzxCUj4mZ3Q7 IEknbGwgCiAgYXBwcmVjaWF0ZSZuYnNwO2xlYXJuaW5nIHRoZSBhbnN3ZXJzIHRvIHRoZXNlIHF1 ZXN0aW9ucyBiZWNhdXNlIEkgCiAgdGhpbms8QlI+Jmd0OyB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5 cyB0byBjb25jZWl2ZSBhbmQgaW1wbGVtZW50IEFueWNhc3QgKG5vdCAKICBqdXN0IHRoZTxCUj4m Z3Q7IHRyYWRpdGlvbmFsIG9uZSkuIFRoZXJlIGFyZSBxdWl0ZSBhIGZldyBjb25jZXB0cyBkZXZl bG9wZWQgCiAgZm9yIG90aGVyPEJSPiZndDsgc2VydmljZXMgd2hpY2ggYXJlIGxpa2V3aXNlIGFw cGxpY2FibGUgdG8gQW55Y2FzdDogTUlQNCBjYXJlIAogIG9mIGFkZHJlc3M8QlI+Jmd0OyBzZXJ2 ZXIsIEhJUCByZW5kZXotdm91cyBzZXJ2ZXIsLi4uPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IAog IEhlaW5lcjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSW4gZWluZXIg ZU1haWwgdm9tIDIxLjA0LjIwMDkgCiAgMDc6NTg6MDcgV2VzdGV1cm9ww6Rpc2NoZSBOb3JtYWx6 ZWl0IHNjaHJlaWJ0PEJSPiZndDsgCiAgdG9ueS5saUB0b255LmxpOjxCUj4mZ3Q7PEJSPiZndDsg SGkgQmlsbCw8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBJIGhhdmUgdGhpcyAKICBtZW50YWwgcGljdHVy ZSBvZiB0aGUgTkZBcyBhbmQgREZBcyAoZmluaXRlIGF1dG9tYXRhKSB1c2VkPEJSPiZndDsmZ3Q7 IHRvIAogIHByb2Nlc3MgcmVndWxhciBncmFtbWFycyBmcm9tIHRoZSBmb3JtYWwgbGFuZ3VhZ2Vz IGNsYXNzIEkgdG9vayBpbjxCUj4mZ3Q7Jmd0OyAKICBjb2xsZWdlLiBBbGwgTkZBJ3MgY2FuIGJl IHRyYW5zbGF0ZWQgdG8gREZBcyBidXQgdGhlIHRyYW5zbGF0aW9uPEJSPiZndDsmZ3Q7IAogIGV4 cGxvc2l2ZWx5IGdyb3dzIHRoZSBhdXRvbWF0YS48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgU2Vl bXMgdG8gbWUgbGlrZSBORkFzIAogIGFyZSBkZWNlbnQgbWV0YXBob3JzIGZvciBicm9hZGNhc3Qg YW5kIG11bHRpY2FzdDxCUj4mZ3Q7Jmd0OyB3aGlsZSBERkFzIGFyZSAKICBtZXRhcGhvcnMgZm9y IGFueWNhc3QgYW5kIHVuaWNhc3QuIEFuZCBJIHRoaW5rIGl0czxCUj4mZ3Q7Jmd0OyBub3RhYmxl IHRoYXQgCiAgYW55Y2FzdCBncm91cHMgd2l0aCB1bmljYXN0IChpdCdzIERGQS1saWtlKSBpbnN0 ZWFkIG9mPEJSPiZndDsmZ3Q7IGdyb3VwaW5nIAogIHdpdGggbXVsdGljYXN0LjxCUj4mZ3Q7PEJS PiZndDs8QlI+Jmd0OyBPaywgSSByZW1lbWJlciB0aGVzZS4mbmJzcDsgU3RpbGwgaGF2ZSAKICB0 aGUgdGV4dGJvb2sgcmlnaHQgaGVyZS4mbmJzcDsgOy0pPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7 Jmd0OyZndDsgRXhjZXB0IHRoYXQgCiAgd2UgaGF2ZW4ndCBmaWd1cmVkIG91dCBob3cgdG8gYWdn cmVnYXRlIGFueWNhc3QsIHdoaWNoIGZyb20gYTxCUj4mZ3Q7Jmd0OyZndDsgCiAgcm91dGluZyBw ZXJzcGVjdGl2ZSwgbWFrZXMgaXQgY29tcGxldGVseSB1bmlxdWUuPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7IFdoYXQgCiAgZG8geW91IG1lYW4/IEFueWNhc3QgYWdncmVnYXRlcyB0aGUgc2FtZSB3 YXkgYXMgdW5pY2FzdDogd2hlbmV2ZXI8QlI+Jmd0OyZndDsgCiAgdGhlIGVuZHBvaW50cyBwaHlz aWNhbGx5IGdyb3VwIHRvZ2V0aGVyLCB0aGV5IGFnZ3JlZ2F0ZS4gQXQgYTxCUj4mZ3Q7Jmd0OyAK ICBwcmFjdGljYWwgbGV2ZWwsIHRoYXQncyByYXJlbHkgdXNlZnVsIGZvciBhbnljYXN0Li4uIEJ1 dCB0aGVuIGF0IGE8QlI+Jmd0OyZndDsgCiAgcHJhY3RpY2FsIGxldmVsIGFnZ3JlZ2F0aW5nIHVu aWNhc3QgdGhhdCB3YXkgKG9yIGZhaWxpbmcgdG8pIGlzIAogIHRoZTxCUj4mZ3Q7Jmd0OyBzb3Vy Y2Ugb2Ygb3VyIGN1cnJlbnQgZ3JpZWYuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IFdlbGwsIHRo ZSAKICBwcm9ibGVtIHdpdGggYWdncmVnYXRpbmcgYW55Y2FzdCBpcyB0aGF0IGl0IGVuZHMgdXAg d2l0aCBvbmU8QlI+Jmd0OyByb3V0ZSBwZXIgCiAgc2VydmljZS4mbmJzcDsgSW4gYSB3b3JsZCBv ZiBoaWdobHkgZGlmZmVyZW50aWF0ZWQgc2VydmljZXMsIHRoZTxCUj4mZ3Q7IHNoZWVyIAogIG51 bWJlciBvZiBzZXJ2aWNlcyBjb3VsZCBiZSBleHBsb3NpdmUuJm5ic3A7IEFuZCB5b3UgY2FuIG9u bHkgCiAgYWdncmVnYXRlPEJSPiZndDsgdGhlbSBpZiB0aGV5IGFyZSBudW1iZXJlZCBhcHByb3By aWF0ZWx5IGFuZCBhcmUgCiAgdG9wb2xvZ2ljYWxseTxCUj4mZ3Q7IGNvcnJlbGF0ZWQuJm5ic3A7 IEhvdyBvZnRlbiBpcyB0aGF0IGdvaW5nIHRvIGhhcHBlbiB3aXRoIAogIGFueWNhc3Q/PEJSPiZn dDs8QlI+Jmd0OyBUbyBiZSBmYWlyLCB3ZSBkbyBnZXQgc3Vic3RhbnRpYWwgYWdncmVnYXRpb24g dXAgdG8gCiAgdGhlIHNpdGUgbGV2ZWwgd2l0aDxCUj4mZ3Q7IHVuaWNhc3QsIGl0J3MgYWJvdmUg dGhhdCBsZXZlbCB0aGF0IHRoaW5ncyBnZXQgCiAgaWZmeS48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZn dDsmZ3Q7Jmd0OyZndDsgVGhlIHNhbWUgY2FuJ3QgYmUgc2FpZCBvZiBtdWx0aWNhc3QuIAogIE11 bHRpY2FzdCBoYXMgZGlmZmVyZW50IHNlbWFudGljczxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7IGV2ZW4g aWYgdGhlcmUncyBvbmx5IG9uZSAKICBob3N0IGluIHRoZSBncm91cC48QlI+Jmd0OyZndDsmZ3Q7 IFNheSBtb3JlIHBsZWFzZSwgSSdtIG5vdCAKICBmb2xsb3dpbmcuPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7IFdpdGggYW55Y2FzdCwgdGhlIHBhY2tldCdzIG5leHQgaG9wIGlzIAogIGFsd2F5cyBp biBleGFjdGx5IG9uZTxCUj4mZ3Q7Jmd0OyBkaXJlY3Rpb24sIHByZWNpc2VseSB0aGUgc2FtZSBh cyB3aXRoIAogIHVuaWNhc3QuIEFuZCBrbm93bGVkZ2UgYWJvdXQ8QlI+Jmd0OyZndDsgd2hhdCB0 aGF0IG5leHQgaG9wIHNob3VsZCBiZSAKICBwcm9wYWdhdGVzIHByZWNpc2VseSB0aGUgc2FtZSB3 YXkuPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7IFdpdGggbXVsdGljYXN0LCB0aGUgCiAgcGFja2V0 IGlzIHJlcGxpY2F0ZWQgaW4gYWxsIGN1cnJlbnRseSB2YWxpZDxCUj4mZ3Q7Jmd0OyBkaXJlY3Rp b25zIHdpdGggCiAgY29tcGxleCBzdWJzY3JpcHRpb24vZGVzdWJzY3JpcHRpb24gb3ZlcmhlYWQg dGhhdCBoYXM8QlI+Jmd0OyZndDsgdG8gYmUgCiAgbWFpbnRhaW5lZCBldmVuIGlmIHRoZXJlJ3Mg b25seSBvbmUgcmVjZWl2ZXIgaW4gdGhlIAogIGdyb3VwLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0 OyBIYXZpbmcgd2F0Y2hlZCB0aGUgZGV2ZWxvcG1lbnQgb2YgUElNLCBCR1AsIAogIE9TUEYsIEFS UCwgSFNSUCwgVlJSUCwgYW5kPEJSPiZndDsgSVMtSVMsIEknbSBoYXZpbmcgYSBoYXJkIHRpbWUg c2F5aW5nIHRoYXQgCiAgdGhlICJjb21wbGV4PEJSPiZndDsgc3Vic2NyaXB0aW9uL2Rlc3Vic2Ny aXB0aW9uIiBvdmVyaGVhZCBmb3IgbXVsdGljYXN0IGlzIAogIGFsbCB0aGF0IG11Y2g8QlI+Jmd0 OyB3b3JzZSB0aGFuIHdoYXQgd2UgZG8gZm9yIHVuaWNhc3QuPEJSPiZndDs8QlI+Jmd0OyBBcyAK ICBmb3IgdGhlIGZvcndhcmRpbmcgcGxhbmUsIHRoZSBkaWZmZXJlbmNlcyBhcmUgTk9UIHRoYXQg bGFyZ2UuJm5ic3A7IAogIE9rLDxCUj4mZ3Q7IHllcywgdGhlcmUgaXMgYW4gb3JkZXIgb2YgbWFn bml0dWRlIG1vcmUgY29tcGxleGl0eSBpbiBkb2luZyB0aGUgCiAgcGFja2V0PEJSPiZndDsgcmVw bGljYXRpb24sIGJ1dCBpdCBiZWNvbWVzIHF1aXRlIGNsZWFyIHRoYXQgd2l0aCBvbmUgcmVjZWl2 ZXIgCiAgaXQgZG9lczxCUj4mZ3Q7IGRldm9sdmUgbmljZWx5IGludG8gYW4gZWZmZWN0aXZlIHVu aWNhc3QuJm5ic3A7IE5vIG9uZSB3b3VsZCAKICBpbXBsZW1lbnQ8QlI+Jmd0OyB1bmljYXN0IHRo YXQgd2F5LCBvZiBjb3Vyc2UsIGJ1dCB0aGF0J3MgYW4gZWZmaWNpZW5jeSBpc3N1ZSwgCiAgbm90 IGE8QlI+Jmd0OyBjb25jZXB0dWFsIG9uZS48QlI+Jmd0OzxCUj4mZ3Q7IEV2ZW4gaWYgbXVsdGlj YXN0J3MgCiAgZGlmZmVyZW50aWF0aW9uIGlzIHRoZSByZXBsaWNhdGlvbiBpbiB0aGUgZGF0YTxC Uj4mZ3Q7IHBsYW5lLCBJJ20gbm90IHN1cmUgSSAKICBzZWUgaG93IHRoYXQgYmVjb21lcyBub24t ZGV0ZXJtaW5pc3RpYy4mbmJzcDsgSSBzZWUgbm88QlI+Jmd0OyByZWZlcmVuY2VzIHRvIAogIGFu IG9yYWNsZS4mbmJzcDsgVGhlIHJpZ2h0IHRoaW5ncyBhbHdheXMgc2VlbXMgdG8gaGFwcGVuIHdp dGg8QlI+Jmd0OyB0b3RhbCAKICBkZXRlcm1pbmlzbS48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsm Z3Q7Jmd0OyBPaywgYnV0IGhvdyB3b3VsZCBhIG1hcCAKICByZXNvbHV0aW9uIGNoYW5nZSB0aGF0 PyZuYnNwOyBJcyB0aGUga2V5IHBvaW50IGhlcmU8QlI+Jmd0OyZndDsmZ3Q7IAogIHRoYXQ8QlI+ Jmd0OyZndDsmZ3Q7IHdoYXRldmVyIG1hcHBpbmcgZnVuY3Rpb24gaXMgdXNlZCwgdGhlIG1hcCBy ZXN1bHQgaGFzIGEgCiAgVFRMIGFuZCBuZWVkcyB0bzxCUj4mZ3Q7Jmd0OyZndDsgYmU8QlI+Jmd0 OyZndDsmZ3Q7IHJlZnJlc2hlZCAKICBwZXJpb2RpY2FsbHk/Jm5ic3A7IE9yLCB0aGUgYXBwbGlj YXRpb25zIG5lZWQgdG8gYmUgYWJsZSB0byAKICB0cmlnZ2VyPEJSPiZndDsmZ3Q7Jmd0OyBhPEJS PiZndDsmZ3Q7Jmd0OyByZWZyZXNoPzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyAKICBZb3UnZCBw dXQgdGhlIG1hcCByZXNvbHV0aW9uIG91dHNpZGUgdGhlIGFwcCBkZXZlbG9wZXIncyBzY29wZSwg CiAgZWl0aGVyPEJSPiZndDsmZ3Q7IGluIHRoZSBuZXR3b3JrIChhcyBwcm9wb3NlZCBieSBzdHJh dGVneSBBKSBvciBpbiB0aGUgCiAgc3lzdGVtLWxldmVsIGhvc3Q8QlI+Jmd0OyZndDsgc29mdHdh cmUgKGFzIHByb3Bvc2VkIGJ5IHN0cmF0ZWd5IEIpLiAKICBVbnByaXZpbGVnZWQgYXBwbGljYXRp b25zIHNpbXBseTxCUj4mZ3Q7Jmd0OyB3b3VsZG4ndCBiZSBhYmxlIHRvIGRpZGRsZSB3aXRoIAog IGFkZHJlc3NlcyBhdCB0aGUgcm91dGluZyBsYXllci48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsg V2l0aCBhIGd1YXJhbnRlZWQgCiAgbWF4aW11bSB0aW1lIHRoYXQgYSBnaXZlbiBtYXAgcmVtYWlu cyB2YWxpZCBhbmQgbm88QlI+Jmd0OyZndDsgCiAgYXBwbGljYXRpb24tbGV2ZWwgYWNjZXNzIHRv IHRoZSByb3V0aW5nIGVsZW1lbnQsIHRoZSBwcm90b2NvbCBhbmQ8QlI+Jmd0OyZndDsgCiAgd2Vp Z2ggaW4gZmF2b3Igb2YgcmVudW1iZXJpbmcgZm9yIGFnZ3JlZ2F0aW9uIGluc3RlYWQgb2YgcmVy b3V0aW5nIAogIGZvcjxCUj4mZ3Q7Jmd0OyBtdWx0aXBsZSBjb25uZWN0aW9ucy48QlI+Jmd0OyZn dDs8QlI+Jmd0OyZndDsgQnV0IHRoaXMgaXMgCiAgcmF0aGVyIG9mZiBvbiBhIHRhbmdlbnQgZnJv bSBhbnljYXN0IGFuZCBpdHMgcmF0aGVyPEJSPiZndDsmZ3Q7IGlkZW50aWNhbCAKICBuYXR1cmUg dG8gdW5pY2FzdC48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgU2VlbXMgbGlrZSB1c2VmdWwgaW1w bGVtZW50YXRpb24gCiAgc3RyYXRlZ2llcyB0byBtZS4mbmJzcDsgQW5kIGl0IGxlYWRzIG1lPEJS PiZndDsgYWdhaW4gdG8gdGhlIGNvbmNsdXNpb24gdGhhdCAKICBpdCdzIGFnYWluIG5vdCBzb21l dGhpbmcgdGhhdCdzIGhhcHBlbmluZzxCUj4mZ3Q7IHdpdGhpbiB0aGUgcm91dGluZyAKICBzdWJz eXN0ZW0uPEJSPiZndDs8QlI+Jmd0OyBUb255PEJSPiZndDsgCiAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBycmcgbWFpbGluZyAKICBsaXN0 PEJSPiZndDsgcnJnQGlydGYub3JnPEJSPiZndDsgCiAgaHR0cDovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JyZzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyAKICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IHJyZyBtYWlsaW5nIAog IGxpc3Q8QlI+Jmd0OyBycmdAaXJ0Zi5vcmc8QlI+Jmd0OyAKICBodHRwOi8vd3d3LmlydGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnJnPEJSPiZndDs8QlI+Jmd0OzwvRk9OVD48L0JMT0NLUVVPVEU+ PC9ESVY+CjxESVY+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+PC9GT05UPjwvQk9EWT48L0hUTUw+ Cg== -------------------------------1240335568-- From irtf@tonistoev.info Tue Apr 21 10:44:55 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9F13A6BD3 for ; Tue, 21 Apr 2009 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_20=-0.74, TO_MALFORMED=1.17] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9G+FsNvbJgd for ; Tue, 21 Apr 2009 10:44:54 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 57E833A69D0 for ; Tue, 21 Apr 2009 10:44:54 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LwK2p-0007kj-AY for rrg@irtf.org; Tue, 21 Apr 2009 20:46:07 +0300 Content-Disposition: inline From: Toni Stoev Date: Tue, 21 Apr 2009 20:46:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: "Undisclosed.Recipients:"@core3.amsl.com Message-Id: <200904212046.06565.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Cc: IRTF RRG Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:44:55 -0000 Thank you for commenting, Xiaohu. See my reply below. > > The Domain Name System identifies a node by its fully=20 > > qualified domain name, which: > > - is topology=EF=BF=BDindependent; > > - is stable, and has a defined lifetime; > > - is unambiguous; > > - is distinguishable (two for same object); > > - has hierarchical structure; > > - is generated, distributed, managed. > >=20 > > But domain names are meaningful to humans, and therefore are=20 > > network eccentric. > >=20 > > On the other hand, Internet Protocol addresses are easily=20 > > issuable, because they consist of numbers. > >=20 > > So let us take a numeric fully qualified identifier. > > The innermost part is a number of a node, and any previous=20 > > numbers denote authorities that have issued sublevel numbers. >=20 > Sound interesting. By the way, taken the following items mentioned by Tony > in his previous email together into account, the identifiers should have > the same length as IPv6 address (or IPv4 address) and be capable of > asserting ownership. =46ixed length has led to lack of scalability. Also, keeping identifier whe= re locator resides is no decoupling of roles of the two assets. If we want significant change, we must take outstanding action. Solutions are variable length and protocol options. > - facilitate session=EF=BF=BDlevel referrals Definitely, identifier is going to be an important component of connection/= session identification. What facilitation is needed? > - stable, at discretion of owner Within a numeric fully qualified identifier the final node number can be ne= gotiated. Furthermore, a node can change its identification provider. Thus identifier can be stable/changeable at discretion of owner. > Xiaohu >=20 > > We put a news that the identified sublevel knows locator of=20 > > its parent. So acquaintance is mutual, and bidirectionally is=20 > > to be used. > >=20 > > Toni > > _______________________________________________ > > rrg mailing list > > rrg@irtf.org > > http://www.irtf.org/mailman/listinfo/rrg > >=20 >=20 > From wherrin@gmail.com Tue Apr 21 14:52:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F7E3A6D19 for ; Tue, 21 Apr 2009 14:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppl8j3ZTMQtD for ; Tue, 21 Apr 2009 14:52:39 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 5AEA03A6C2F for ; Tue, 21 Apr 2009 14:52:39 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1029895qwe.7 for ; Tue, 21 Apr 2009 14:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=RbvkcjIcOvPWGwZjWbgU/OYfPd5zoWw89qQcSJd2zSY=; b=pgn1nVlJ7aNHhyT31nejuOFn1XGqI4DJ12zQ24hoVBlcf7hky50ZvWCFHhMbyZmiAo c/URMLAFMz2uVH0e3H2dHr4wXlIMDu2X0z33DreHwviHR7jlizm6TV184XF1lb+vogUl hRcMR1Rqkx4Ri+NTuJ4p+MzN2MTA3FOeZ7S8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=H2bRou+SB7VFMO9Z7EigA2MBszaca/fnGE3JEI7KK22mci/ouaQmPRoeboKtzAfM5X 1OE9o56IkfADT3Gplv2nsLLAnbfhnXDhUEnn1febWNq6AAkl6OEcvehup0qZ5sczvjc7 sh3KpBirB4xrZ6CkAbfcsLWvds7oqku088El0= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.229.84.201 with SMTP id k9mr1665932qcl.84.1240350835740; Tue, 21 Apr 2009 14:53:55 -0700 (PDT) In-Reply-To: <49ED604C.2020407@tony.li> References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> Date: Tue, 21 Apr 2009 17:53:55 -0400 X-Google-Sender-Auth: a97ca453c1cfed31 Message-ID: <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> From: William Herrin To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:52:40 -0000 On Tue, Apr 21, 2009 at 1:57 AM, Tony Li wrote: >>> Except that we haven't figured out how to aggregate anycast, which from= a >>> routing perspective, makes it completely unique. >> >> What do you mean? Anycast aggregates the same way as unicast: whenever >> the endpoints physically group together, they aggregate. > > Well, the problem with aggregating anycast is that it ends up with one ro= ute > per service. =A0In a world of highly differentiated services, the sheer n= umber > of services could be explosive. =A0And you can only aggregate them if the= y are > numbered appropriately and are topologically correlated. How's that different from, say, cnn.com, aggregated with the other Turner services and spread across two of Turner's three unicast routes? If TCP was stable over anycast, they might actually be able to drop one of those unicast routes. Seems to me that the aggregability of services has more to do with the size of the services set than it does with whether the service is unicast or anycast. Big important web site =3D at least one more route in the table. > As for the forwarding plane, the differences are NOT that large. =A0Ok, y= es, > there is an order of magnitude more complexity in doing the packet > replication, but it becomes quite clear that with one receiver it does > devolve nicely into an effective unicast. Effective unicast that is an order of magnitude more expensive to implement= . Anycast, on the other hand, is precisely the same as unicast in both the forwarding and data planes... And as I mentioned, it's relatively trivial to get it to look precisely the same in each of the two major solution strategies as well. > Even if multicast's differentiation is the replication in the data plane, > I'm not sure I see how that becomes non-deterministic. =A0I see no refere= nces > to an oracle. =A0The right things always seems to happen with total > determinism. I think of deterministic as "pick one direction" while non-deterministic is "travel all valid directions." I'm open to a better word choice. >> You'd put the map resolution outside the app developer's scope, either >> in the network (as proposed by strategy A) or in the system-level host >> software (as proposed by strategy B). Unprivileged applications simply >> wouldn't be able to diddle with addresses at the routing layer. >> >> With a guaranteed maximum time that a given map remains valid and no >> application-level access to the routing element, the protocol and >> weigh in favor of renumbering for aggregation instead of rerouting for >> multiple connections. > > Seems like useful implementation strategies to me. =A0And it leads me aga= in to > the conclusion that it's again not something that's happening within the > routing subsystem. I had a discussion with a colleague earlier today. He was having a problem with a mapping app on his web site going through a particular proxy server that didn't support http keepalive. To render a map page with all the plotted points, he would generate around 500 ssl http requests. With keepalive this would generate around 30 ssl connections. Without keepalive it generates 500 and runs so very much slower. Where's the error here? The proxy that doesn't support keepalive? Or the app that needs to generate 500 https queries in order to render a web page? Which one do you zero in on and change? The upper layers set requirements on the routing layer in a manner the routing layer can't handle efficiently. One answer is that we redesign the routing layer. Another is that we alter the requirements. Ruling either answer out of scope would, at the very best, be failing to think outside the box. On Tue, Apr 21, 2009 at 4:00 AM, wrote: > As I understand Anycast is about delivery to one out of multiple > destinations within a given scope. Hi Heiner, I would have said "closest one from the set of valid destinations," but your version is good enough. > Where is the center point of this scope ? Is it always the location of th= e > source ? I don't understand the question. What is a center point wrt routing? > What are the requirements for Anycast in a new architecture? Well, that's the crux of the discussion, isn't it? Anycast and unicast are identical in every respect in the current architecture. How do we bound the unforeseeable consequences if that isn't true in the new one? I'm getting ready to introduce an anycast route into the table in order to implement a "continuing operations" system with three sites half a world apart. "Continuing operations" is a fancy phrase for "disaster recovery," something that became really popular almost 8 years ago. Once a packet hits any of the always-running sites, a VPN takes it back to the site with the servers flagged "best" for that particular address, so holistically its unicast but from the perspective of the Internet core its anycast from three distinct locations. Would this have any hope of working right in an architecture that didn't accommodate anycast? How many such uses are out there, ready to impede the deployment of the unwary plan? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From HeinerHummel@aol.com Tue Apr 21 15:27:49 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC96B3A696E for ; Tue, 21 Apr 2009 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=1.947, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgyFn4VJC2di for ; Tue, 21 Apr 2009 15:27:49 -0700 (PDT) Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by core3.amsl.com (Postfix) with ESMTP id D44A53A63D3 for ; Tue, 21 Apr 2009 15:27:48 -0700 (PDT) Received: from imo-m19.mx.aol.com (imo-m19.mail.aol.com [172.20.107.65]) by imo-d20.mx.aol.com (v107.10) with ESMTP id RELAYIN2-349ee489d15c; Tue, 21 Apr 2009 18:28:45 -0400 Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imo-m19.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249ee4890200; Tue, 21 Apr 2009 18:28:32 -0400 Received: from HeinerHummel@aol.com by imo-ma03.mx.aol.com (mail_out_v40_r1.5.) id z.ccc.4fb8f167 (48624); Tue, 21 Apr 2009 18:25:51 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 21 Apr 2009 18:25:39 EDT To: bill@herrin.us, tony.li@tony.li MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240352739" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 172.20.107.65 Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 22:27:49 -0000 -------------------------------1240352739 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 21.04.2009 23:54:19 Westeurop=E4ische Normalzeit schrei= bt bill@herrin.us: On Tue, Apr 21, 2009 at 4:00 AM, wrote: > As I understand Anycast is about delivery to one out of multiple > destinations within a given scope. Hi Heiner, I would have said "closest one from the set of valid destinations," but your version is good enough. More precisely "closest one from the set of valid destinations with respec= t to the source," > Where is the center point of this scope ? Is it always the location of= the > source ? I don't understand the question. What is a center point wrt routing? My question is: with anycast do we always understand the above, or could= it also be any particular destination within the scope of an indicated remot= e location like a different continent? What do we understand by Anycast in the future ? Some one must do the mapping to a specific Unicast address? Is it always the ingress ? Or can't= there be reasonable anycast services which require to send the data to some far= distant anycast server where it will be mapped to some local unicast addresss ? > What are the requirements for Anycast in a new architecture? Well, that's the crux of the discussion, isn't it? Anycast and unicast are identical in every respect in the current architecture. How do we bound the unforeseeable consequences if that isn't true in the new one? I'm getting ready to introduce an anycast route into the table in order to implement a "continuing operations" system with three sites half a world apart. "Continuing operations" is a fancy phrase for "disaster recovery," something that became really popular almost 8 years ago. Once a packet hits any of the always-running sites, a VPN takes it back to the site with the servers flagged "best" for that particular address, so holistically its unicast but from the perspective of the Internet core its anycast from three distinct locations. Would this have any hope of working right in an architecture that didn't accommodate anycast? How many such uses are out there, ready to impede the deployment of the unwary plan? Sorry, I don't understand what you are hereby saying. Heiner Regards, Bill Herrin -------------------------------1240352739 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 21.04.2009 23:54:19 Westeurop=E4ische Normalzeit= schreibt bill@herrin.us:
On Tue, Apr 21, 2009 at 4:00 AM,  <HeinerHummel@aol.com> wrote:
&g= t; As I understand Anycast  is about delivery to one out of multiple
&= gt; destinations within a given scope.

Hi Heiner,

I would have= said "closest one from the set of valid destinations,"
but your version is= good enough.
More precisely "closest one from the set of valid destinations with= respect to the source,"



> Where is the center point of this scope ? Is= it always the location of the
> source ?

I don't understand the quest= ion. What is a center point wrt routing?

My question is: with anycast do we always understand the above, or co= uld it also be any particular destination within the scope of an indicated remote= location like a different continent?
 
What do we understand by Anycast in the future ? Some one must do the= mapping to a specific Unicast address? Is it always the ingress ? Or can't= there be reasonable anycast services which require to send the data to some = ;far distant  anycast server where it will be mapped to some  local= unicast addresss ?

> What are the requirements for Anycast in a new architecture?

Well= , that's the crux of the discussion, isn't it? Anycast and unicast
are= identical in every respect in the current architecture. How do we
bou= nd the unforeseeable consequences if that isn't true in the new
one?

= I'm getting ready to introduce an anycast route into the table in
order= to implement a "continuing operations" system with three sites
half a wo= rld apart. "Continuing operations" is a fancy phrase for
"disaster recove= ry," something that became really popular almost 8
years ago. Once a packe= t hits any of the always-running sites, a VPN
takes it back to the site with= the servers flagged "best" for that
particular address, so holistically= its unicast but from the
perspective of the Internet core its anycast fro= m three distinct
locations.

Would this have any hope of working= right in an architecture that
didn't accommodate anycast? How many such use= s are out there, ready to
impede the deployment of the unwary plan?
Sorry, I don't understand what you are hereby saying.
Heiner
 

Regards,
Bill Herrin


 
 -------------------------------1240352739-- From irtf@tonistoev.info Tue Apr 21 16:41:20 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7022E3A6A1A for ; Tue, 21 Apr 2009 16:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS2utrmegBag for ; Tue, 21 Apr 2009 16:41:19 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id A15823A68C7 for ; Tue, 21 Apr 2009 16:41:19 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LwPbl-0000Uu-Pz for rrg@irtf.org; Wed, 22 Apr 2009 02:42:33 +0300 From: Toni Stoev To: IRTF RRG Date: Wed, 22 Apr 2009 02:42:32 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904220242.32513.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Numeric fully qualified identifier X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:41:20 -0000 Summary I am offering a solution for identifier. The solution is a numeric-only variation of FQDN with mutual locator cognition between adjacent levels. Innermost level numbers can be negotiated instead of assigned. Let us first see conformance of this solution, and then consider any inherited restrictions. From rw@firstpr.com.au Tue Apr 21 21:02:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6F228C3CF for ; Tue, 21 Apr 2009 21:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_BACKHAIR_33=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-19aROj87hE for ; Tue, 21 Apr 2009 21:02:13 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 53B773A6859 for ; Tue, 21 Apr 2009 21:02:12 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9CCA4175A29; Wed, 22 Apr 2009 14:03:27 +1000 (EST) Message-ID: <49EE9718.9060100@firstpr.com.au> Date: Wed, 22 Apr 2009 14:03:36 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> In-Reply-To: <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture - sep. OK; elim not? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 04:02:16 -0000 Short version: Detailed discussion, with examples, of anycast ETRs anycast hosts and Bill's current real-world project which is arguably anycast. Ivip (and I guess other core-edge elimination schemes) handle anycast hosts just fine - no extra complications. Anycast ETRs are also possible with Ivip, but they would typically require their own MAB prefix and so would not involve any reduction in burden on the DFZ compared to doing ordinary anycast hosts as is done today. I can't imagine how a core-edge elimination scheme would do anycast hosts. But that is a question for those who design such things. I think ILNP is the only such design which is intended to help with routing scalability (this is not a goal of HIP) - and I don't understand ILNP clearly enough to try to think about it doing something like anycast. Hi Bill, You wrote, in part: > Anycast, on the other hand, is precisely the same as unicast in both > the forwarding and data planes... I agree. As I wrote: http://www.ietf.org/mail-archive/web/rrg/current/msg04884.html Routers can't tell the difference between anycast and unicast. Only someone with complete knowledge of the network can determine which is which. If there are two routers advertising the host's prefix, that could be either. If each such router sends its packet to the one destination host, it is unicast. If each sends its packets to a separate destination host, it is anycast. > And as I mentioned, it's relatively trivial to get it to look > precisely the same in each of the two major solution strategies > as well. I think this is probably not true of Strategy B (core-edge elimination, in which new host stack and perhaps application functions do all the work and end-user networks never have their own stable address space. Most of this message considers anycast in a core-edge separation scheme (Strategy A, no host changes - such as LISP, APT, Ivip and TRRP). I think core-edge separation schemes naturally support globally anycast hosts without any difficulties. They may also be able to support anycast ETRs - but that is somewhat separate question, since you could have anycast ETRs and a single, unicast, host. Anycast ETRs and anycast hosts may also be possible. Basically, core-edge separation schemes seem to support anycast hosts naturally and without any extra complication. I can't easily imagine how a core-edge elimination scheme could do so without a lot of extra complexity. This is one more reason for me preferring core-edge elimination over separation. Other reasons include: 1 - Separation is possible to introduce voluntarily, since it involves no changes to host stacks or applications. It seems very challenging or impossible to introduce core-edge elimination on a voluntary basis due to the need for stack and probably application changes an the consequent lack of support in the new system for hosts without these upgrades. 2 - I think core-edge separation schemes support the best division of labour between hosts and the routing system: the host gets a stable IP address and doesn't have to worry about network- based things like multihoming, outages, reconfigurations, portability, TE, mobility etc. (Supporters of core-edge elimination schemes prefer the network to do less and the hosts to do more.) Perhaps a more stringent statement is true: Within a core-edge separation scheme, it will be just as impossible for a router or the routing system in general to tell the difference between anycast and unicast as it is without the scheme. If so, then I think there is no extra effort required on the part of host anycast operations or in altering the core-edge separation scheme to make host anycast indistinguishable from host unicast. However . . . "host anycast" with a core-edge separation scheme does not necessarily mean "ETR anycast". The two could go together, but without "ETR anycast" a core-edge separation scheme with "host anycast" alone doesn't look much like the common conventional use of "host anycast". With ordinary BGP (and/or an IGP I guess, or the two combined?), just looking at the routing system, we can't distinguish between unicast with two separate routers advertising the same address (for simplicity assumed here to be advertising the same prefix) and anycast: R2------R5--\ / \ | \ SH---->R1 R4---R6 DH Unicast with R5 and R7 advertising \ / | / the same prefix which includes the R3------R7--/ one host. Fig 1 \___________/ << Scope of the routing system R2------R5--->DH1 / \ | Anycast: same address used by two SH---->R1 R4---R6 hosts, each host connected to a \ / | separate router. Each router R3------R7--->DH2 advertises the same prefix. Fig 2 \___________/ << Scope of the routing system Any router and indeed the entire routing system can't tell whether it is host anycast or not - and host anycast works just fine, within its well-known limits of being unable to support session based communications unless the destination hosts have a link and share session state. As I wrote in the earlier message, thinking of Ivip for the moment, where ETRs are typically in the ISP (ignoring mobility for this discussion - anycast and mobility make no practical sense to me), we could have anycast ETRs and/or with anycast hosts. In the following, for brevity, I will assume just the BGP routing system, but there will also be IGP routers which are not shown. ITR ETR R2------R5 / \ | \ Single ETR with dual border routers SH-I1->R1 R4---R6 E1->DH advertising its address. \ / | / Single destination host = unicast. R3------R7 \___________/ << Scope of the BGP routing system \_/ \_/ << Scope of the core-edge separation scheme \_____________________/ << Scope of the now extended interdomain routing system Fig 3 In Fig 3 we have a destination host DH which is part of an SPI-using (Ivip's Scalable PI space, of individually mapped micronets) end-user network. That network is not shown, but is in the same location as DH. This host's network's ETR E1 is single-homed to an ISP which has two border routers R5 and R7, both of which advertise the ISP's prefix which encompasses E1's address. Many other end-user networks can use this ETR, and many other ETRs and PI customers can use this prefix, so Ivip is being used here in a way which greatly reduces the burden on the BGP control plane compared to each end-user network having its own BGP advertised prefix. Fig 4 shows a multihomed example of the same arrangement: ITR ETRs R2------R5 / \ | \ Single ETR in each ISP. Each ISP SH-I1->R1 R4---R6 E1 has dual border routers advertising \ / | / \ the ETR address. R3------R7 \ | \ R9------R10 DH Single destination host = unicast. / \ \ / R12--R13 E2--/ \ / / R14-----R11 Fig 4 ISP1 has ETR E1 whose address is advertised by R5 and R7. ISP2 has ETR E2 whose address is advertised by R10 and R11. This is a typical core-edge separation approach to a multihomed end-user network. With LISP, the ETRs would be at the destination network. With Ivip, they could be, but would probably be in the ISP networks, where each ETR would also be serving multiple other end-user networks, via its one IP address. These ETR devices may also be ITRs. (For TTR mobility, E1 and E2 are Translating Tunnel Routers - and they may be near, or perhaps within, the access networks where DH has a care-of address.) The next diagram depicts the theoretical possibility of "anycast" ETRs. This is extending the usage of "anycast" somewhat, since it normally only refers to destination hosts. However, from the point of view of the packet being tunneled from the ITR to the ETR, the ETR is the destination host of the tunneled packet. If there are two ETRs on the same address, with separate routers advertising this address, then it is fair to think of the ETRs themselves being "anycast". Note regarding Modified Header Forwarding: The above is fine for encapsulation. I haven't considered "anycast ETRs" with Modified Header Forwarding. I think it is possible, but haven't considered the details or what benefits there might be. Whether or not there are one or more destination hosts is a separate issue. ITR ETRs R2---- R5--->E1 / \ | \ "Anycast" ETRs SH-I1->R1 R4---R6 DH Single host (functionally unicast) \ / | / R3-----R7--->E2 Fig 5 This should be possible with Ivip's non-encapsulation approaches: Modified Header Forwarding (MHF) across the DFZ. With the two separate MHF approaches for IPv4 and IPv6, there is no communication whatsoever from the ETR to the ITR. The ITR neither knows nor cares whether there are 2 separate "anycast" ETRs or not. As far as host communications are concerned, the situation is clearly unicast. Maybe there would be reasons for doing this. With encapsulation, it would be trickier, since the Ivip ITRs do sometimes need to engage in two-way communication with ETRs to manage PMTUD - Path MTU Discovery. I will assume for the moment this could be done. (The communications are brief and the system would probably cope with a router switching its forwarding so the ITR found itself dealing with E2 instead of E1.) Changes in the routing system, such as R1 choosing R3 instead of R2 as its next hop for the ETRs prefix, may still result in a differing PMTU between I1 and whichever ETR receives the packet. But that would have occurred in the Fig 4 and Fig 5 scenarios anyway. I will consider this anycast ETR scenario when developing Ivip's PMTUD system. No matter what the ETR arrangement, assuming it works, the above is still unicast from the point of view of the host. As with Fig 1 and 2, the BGP routing system can't tell the difference between host unicast and host anycast. If encapsulation is used, for PMTUD handling, the core-edge separation scheme may need to have special mechanisms to cope with anycast ETRs which presumably don't communicate directly with each other. In the above diagram, there is only one ETR address for the micronet, or in LISP terms, only one RLOC address for the EID. Multihoming is not being attempted, but this could still be used for portability, including for the TTR mobility model. So in this case, there is no multihoming failure detection decision to make. With both Ivip and LISP, the ITRs always tunnel packets to the one ETR address. If one ETR becomes unusable, then packets will be lost as long as its router still advertised that prefix. This is the risk taken by whoever chose to have anycast ETRs. However, if both ETRs are working fine and can connect to DH, then if R5 dies, or becomes unreachable to the rest of the Net, then BGP will adapt and cause all tunneled packets from all ITRs to go to R7 and therefore E2, with no significant disruption in host-to-host connectivity. There could be significant differences between how Ivip and LISP would handle multihoming failures if there were anycast ETRs at one or both ETR addresses. Fig 6 depicts two ISPs each with two anycast ETRs, each with its own border router advertising the ETR address to the DFZ. There is still a single destination host. I am not sure why anyone would do this, but there may be a reason. ITRs ETRs R2------R5-->E1 / \ | \ Each ISP has anycast ETRs. SH-I1->R1 R4---R6 \ \ / | \ R3------R7-->E2---\ | DH Single destination host = unicast. R9------R10->E3---/ / \ / SH2-I2-R12--R13 / \ / / R14-----R11->E4 Fig 6 This also shows a second sending host SH2 with its ITR I2. With LISP, APT or I guess TRRP, each ITR figures out for itself which of the two ETR address in the mapping it will use for tunneling packets with the EID address of DH. With LISP, I will assume the E1/E2 RLOC address is preferred in the mapping, when the ITR can reach both E1/E2 and E3/E4. For example, the initial path taken through the routing system by the encapsulated packets is: I1 R1 R2 R5 E1 I2 R12 R9 R3 R7 E2 (I2's packets may well have gone via R4, R6, R6 and then to E1, but I want an example in which I2's packets go to a different ETR than E1, even though they are anycast on the same address.) If R7 dies, I2 will still find the RLOC address of E1/E2 reachable, since the BGP routers will quickly readjust themselves to send the packets: I2 R12 R9 R3 R4 R6 R5 E1 That is fine, since E1 is just as good as E2 (other than any problems with potential session state in ITR<->ETR communications - maybe LISP has no such stateful ITR<->ETR communications). However, going back to the initial state, if E2 dies, or can't reach DH and in either case R7 still advertises its address, then there will be trouble which LISP's I2 ITR will recover from: I2 will find (by some means, I am not sure what) that E2 is unreachable. Since R7 is still advertising the prefix which encompasses the E1/E2 ETR address, there's no way I2's packets to this address will get to E1. So I2 will figure out that the ETR (it assumes one ETR) at the address of E1/E2 is dead and will therefore use the other RLOC address instead - that of E3/E4. Now, the two paths used by packets will be: I1 R1 R2 R5 E1 I2 R12 R9 R10 E3 The free-wheel'in LISP ITR will have figured out its own arrangements for coping with a partial outage in the reachability of what, to the LISP system, is a "single" ETR. The situation with Ivip might be less happy, since Ivip ITRs don't do any reachability testing (except, as a by-product of PMTUD management, which is only needed for encapsulation). With the above example, both ITRs would initially be tunneling packets to a single ETR address: E1/E2. Ivip ITRs have only a single ETR address to use. It is up to the end-user network to send a mapping change if it wants the ITRs to tunnel packets to another ETR address. With the above failure of E2 on its own, with R7 continuing to advertise E2's address, I2 would not be able to get packets to DH at all. The only way the Ivip system could respond to the outage properly would be for the mapping to be changed to the E3/E4 address instead. (With Ivip, an end-user network would typically pay a probing company to constantly probe reachability and to issue mapping changes as necessary to restore connectivity in the even of one ETR being unusable - by sending a mapping change with the address of the other ETR. Therefore, if an end-user network chose to have anycast ETRs, it had better implement some fancy scheme for testing that every single one of them is reachable from wherever ITRs might be - and that that each such anycast ETR is able to get packets to the destination network. Depending on how topologically separated E1 is from E2, and likewise E3 from E4, and depending on how many probing servers were used, and where they were topologically located, it may or may not be possible to achieve this. I am not sure why anycast ETRs would be an advantage. Ivip could probably support them for MHF, and probably for encapsulation too. I doubt if LISP-ALT could support them, because (AFAIK) there is so much ITR-ETR communication and because ETRs are the authoritative source of mapping and so have to communicate with the ALT network, probably via Map Servers. Assuming Ivip could support anycast ETRs, special care would be needed in probing the connectivity of all such ETRs. The question of whether ETRs are anycast is in some ways separate from whether the destination hosts are anycast. Figs 3, 4, 5 and 6 show anycast ETRs with a single unicast DH destination host. It is easy to have a core edge separation with unicast ETRs and *locally* anycast destination hosts. Here is an adaptation of Fig 4 showing three destination hosts, all with the same IP address, in the same end-user network: ITR ETRs R2------R5 / \ | \ Single ETR in each ISP. Each ISP SH-I1->R1 R4---R6 E1 has dual border routers advertising \ / | / \ the ETR address. R3------R7 \ DH1 | \ / R9------R10 [network]--DH2 / \ \ / \ R12--R13 E2--/ DH3 \ / / R14-----R11 Three destination hosts = locally Fig 7 unicast. This local use of anycast clearly has nothing to do with the BGP routing system or the core-edge separation system, which would support it perfectly. What about anycast ETRs each with their own destination hosts, which are therefore also host anycast? ITRs ETRs R2------R5-->E1->DH1 / \ | Each ISP has anycast ETRs. SH-I1->R1 R4---R6 \ / | R3------R7-->E2->DH2 | R9------R10->E3->DH3 / \ SH2-I2-R12--R13 Four destination hosts, each one \ / anycast in a global sense. R14-----R11->E4->DH4 Fig 8 E1 and E2 are on the same (RLOC) address, which is in a prefix advertised by both R5 and R7. Likewise, E3 and E4 are both on another (RLOC) address, which is advertised by both R10 and R11. Note: Just because this could be made to work doesn't mean it is a good idea or that this is a use of Ivip etc. which helps with scalable routing. Fig 8 could in principle help with routing scalability since the ETRs E1/E2 are on one address in a prefix of one ISP and the E3/E4 ETRs are on another address of another ISP. However, it is only a scalable use of Ivip if these same prefixes can be used by many other end-user networks. Presumably R5 and R7 are geographically at very different locations, otherwise there would be little point in having separate ETRs. But why would an ISP do this? Maybe they would. Maybe other customers want a similar arrangement. But if they don't, then this represents an irregular use of a prefix and probably the only beneficiary is going to be for network with above ETRs. That makes it one or two BGP advertised prefixes for one end-user network, which achieves no benefits in routing scaling. See also Figs 9 and 10 for a similar example. It might be best not to use Ivip or any other core-edge separation technique. I think this would have similar potential problems as the scenario depicted in Fig 6: LISP-ALT probably not going to work, due to the difficulties supporting the complex communications of ETRs with ITRs and the ALT network. If it did, the free-wheel'in ITRs may be able to cope on their own with some outages which would be trickier to detect and cope with if the system was Ivip. This is genuinely host anycast from the point of view of the hosts. However, the fact that it is host anycast is only visible to the hosts. As far as I can see, in all these scenarios, whether the destination host is unicast, locally anycast (Fig 7) or globally anycast (Fig 8), the BGP system and the core-edge separation system both work fine and dandy. They can't tell anything about the unicast/anycast status of the destination hosts *because* the core-edge separation scheme has nothing at all to do with hosts. I would be surprised if the same would be true of a core-edge separation scheme. There, the hosts have much more complex stack and perhaps application software. I can't imagine how this would work with two physical hosts having the same IP address, within the one local network (Fig 7) or in separate topological places as in Fig 8. So I think this is another reason to prefer core-edge separation schemes over core-edge elimination schemes. The former continues to allow for the use of anycast hosts, and the latter either doesn't allow it, or would involve some additional complications to make it, or something similar to it, work. However, perhaps in a core-edge elimination scheme, all the things done by anycast at present are no longer needed. (I can't imagine how, but I don't clearly understand any core-edge elimination schemes.) I don't support core-edge elimination schemes (AKA Strategy B in Bill's taxonomy) and will leave someone else to debate how they would work with, or replace, anycast hosts. >> What are the requirements for Anycast in a new architecture? > > Well, that's the crux of the discussion, isn't it? Anycast and unicast > are identical in every respect in the current architecture. How do we > bound the unforeseeable consequences if that isn't true in the new > one? Hopefully the above treatise will be a starting point for foreseeing any differences and at least some of the consequences. > I'm getting ready to introduce an anycast route into the table in > order to implement a "continuing operations" system with three sites > half a world apart. "Continuing operations" is a fancy phrase for > "disaster recovery," something that became really popular almost 8 > years ago. Once a packet hits any of the always-running sites, a VPN > takes it back to the site with the servers flagged "best" for that > particular address, so holistically its unicast but from the > perspective of the Internet core its anycast from three distinct > locations. If you had a single server at your single data centre, then this would be an ordinary unicast server with three separate "border routers" in your global VPN-linked network. If you had three separate servers somehow operating on the same address in your data centre, this would be locally anycast hosts with three separate routers advertising the same prefix. I am not sure why anyone would do this, or how they would work except for stateless communications, but it would be possible. Presumably there would be three routers in the local network, one for each host, and each one would stop advertising the address as soon as its host died. That would give automatic failover. I understand you have three separate hosts, in the one data centre, with the same IP address (at least as far as their communications with the outside world are concerned - they would have other addresses so you could talk to them separately via TCP etc.). You have some system for directing packets to the three servers based on which VPN they arrived from. You presumably also take the emitted packets from each server and send them out on the matching VPN. Assuming there is a direct 1:1 relationship between VPN and server, then I think you have a genuine host anycast arrangement. However, the servers are co-located and could, in principle, share session state. If they did this, then you could use them for session-based communications. Anycast servers are not inherently incapable of being used for session-based communications. It is just that they are usually assumed to be physically separate and therefore incapable of sharing the state of each session. I think you could implement your project with Ivip. You want a single IP address for your three servers and you want packets sent to this address to be tunneled to your data centre via physically separate routers at geographically and topologically distant sites SA, SB and SC. These routers connect to your data centre by presumably robust VPN links. I think the motivation for this must be one or the other or both of: 1 - You don't trust the interdomain routing system (BGP + Ivip or whatever) to get packets from sending hosts to your data centre. AND you would prefer to rely on the interdomain routing system to get the packets to the generally closer sites SA, SB and SC together with the costs, reliability etc. inherent in the VPN links to your central data centre. This may be motivated by concerns over path lengths, delays packet loss rates etc. It may also be motivated by wanting to reduce the ability of certain parties to observe the passage of these packets between those hosts and your servers. 2 - You want to use the approximate geographical / topological information implied about the sending host due to its packet arriving at one of your S1, S2 or S3 sites. So you presumably choose to do this rather than use a geographically / topologically sensitive DNS system to give out different IP addresses to hosts in different areas of the Net, as is done by Akamai. I guess the way you are achieving this now is like: S1 R2------R5---\ / \ | \ SH---->R1 R4---R6 \ \ / | \ /-DH1 R3------R7------[Data center]--DH2 | S2 / \-DH3 | / R9------R10---/ / \ / S3 SH2----R12--R13-/ 3 destination hosts, each one \ / anycast in a global sense since they R14 have the same address. Fig 9 All three routers R5, R7 and R10 advertise the same prefix. Since you can't use this prefix anywhere else, unless you are using it also for some other purpose, you have one prefix of your own for this particular project. This is either your own PI prefix, or some prefix you have convinced a single ISP to advertise (and they have routers at all three sites) or you have somehow convinced separate ISPs to advertise the one prefix which is not yours. In the former case you have portability and in the latter two you do not. If R5, R7 and R10 are yours and you multihome them like this, then it should work pretty well, provided each router stops advertising the prefix the moment the VPN link dies and if your data centre and servers copes OK with one region's hosts suddenly connecting via one of the other routers and therefore using a different VPN. To survive that, if your servers use session-based protocols, they need to be able to share the session state. To achieve point 1 with Ivip, you need to have an ETR at each site S1, S2 and S3. These need to have the same IP address, since the destination hosts have the one IP address and therefore all ITRs will use the same mapping. So these will be three anycast ETRs. (Side-note on LISP: If you were doing this with LISP, but LISP couldn't support anycast ETRs, you could make it happen by having each ETR on its own RLOC address and then have all three addresses in the mapping. Each ETR would have to somehow drop packets with source addresses which it decided were indicative of the source packet not being in its area. Then, each ITR would discover that only one of the ETRs was reachable. How could the ETRs do this? They would need to look at the outer source address of the packets, which shows the ITR address, and do some fancy algorithm to figure out where the ITR was in its preferred area or not. This cannot be discovered from the BGP system by any conventional means. So this is much messier and probably less effective than using anycast ETRs with Ivip, in which case the BGP system does all the work of sending packets from ITRs in a given "area" as defined by the DFZ's current forwarding behaviour.) ITRs ETRs S1 R2------R5-->E1 3 Anycast ETRs - all the same address. / \ | \ SH-I1->R1 R4---R6 \ \ / | \ /-DH1 R3------R7-->E2-[Data center]--DH2 | S2 / \-DH3 | / R9------R10->E3 / \ / S3 SH2-I2-R12--R13-/ 3 destination hosts, each one \ / anycast in a global sense since they R14 have the same address. Fig 10 To do this, R5, R7 and R10 would all be advertising the same prefix. The most likely arrangement is that you have this prefix only for the use of this particular set of sites, and this set of 3 servers - and perhaps also for other similar sets of servers. This would mean that you are either operating your own routers directly, or that you are getting someone else to advertise your prefix. As long as you were the only end-user network using this arrangement, then there is no benefit to using Ivip, at least in terms of scalability. Your prefix would be a MAB (Mapped Address Block) and this would be only used for your end-user network. Therefore the scaling benefits of Ivip - many end-user networks sharing the one MAB and therefore spreading their burden on the BGP control plane over exactly one prefix, rather than one or more for each network - would not apply in this case. (The same would be true of LISP, APT or TRRP.) Unless there was some other benefit to using Ivip, I suggest you not bother with it and continue to do exactly what you are doing now - as in Fig 9. In some core-edge separation schemes, there is talk of "transition periods" and the like, as if one day, it won't be possible for an end-user network to have its own conventional BGP-mapped prefix. That is not the case with Ivip. So you would always be able to do what you are currently doing. It is inherently unscalable, but Ivip can't do exactly what you want in a way which helps with scalability - unless there are other end-user networks such as your own which also want to use these ETRs or ETRs in the same prefix in the same sites S1, S2 and S3. > Would this have any hope of working right in an architecture that > didn't accommodate anycast? How many such uses are out there, ready to > impede the deployment of the unwary plan? You can do it now. You could probably do it with Ivip (if encapsulation is used for Ivip, I would need to ensure that the PMTUD stuff worked OK with anycast ETRs - I am not sure this is possible), but you are probably better doing it as you do now. LISP probably couldn't do it. AFAIK, as long as you are the only network with anycast anything in these three locations, then you need your own BGP advertised prefix. You need this for the way you do it now and for Ivip - so there are no scaling advantages to using Ivip. How would you do this with a core-edge elimination scheme? That would have to be answered by someone who designed such a scheme. - Robin From HeinerHummel@aol.com Wed Apr 22 00:47:15 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44BB3A6B9B for ; Wed, 22 Apr 2009 00:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=1.623, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gf1c4LJUej5 for ; Wed, 22 Apr 2009 00:47:14 -0700 (PDT) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by core3.amsl.com (Postfix) with ESMTP id 998DA3A6CC8 for ; Wed, 22 Apr 2009 00:47:14 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imo-d23.mx.aol.com (v107.10) with ESMTP id RELAYIN1-249eecbb536b; Wed, 22 Apr 2009 03:48:05 -0400 Received: from HeinerHummel@aol.com by imo-ma01.mx.aol.com (mail_out_v40_r1.5.) id z.bf5.5672253e (42808); Wed, 22 Apr 2009 03:47:58 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 22 Apr 2009 03:47:56 EDT To: HeinerHummel@aol.com, bill@herrin.us, tony.li@tony.li MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240386476" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 64.12.78.136 Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 07:47:16 -0000 -------------------------------1240386476 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I think, I have found the answer to one of my questions by myself: GRE-tunneled Anycast with a far remote outer address and a locally scoped= inner anycast address. Heiner In einer eMail vom 22.04.2009 00:29:24 Westeurop=E4ische Normalzeit schrei= bt HeinerHummel@aol.com: In einer eMail vom 21.04.2009 23:54:19 Westeurop=E4ische Normalzeit schre= ibt bill@herrin.us: On Tue, Apr 21, 2009 at 4:00 AM, wrote: > As I understand Anycast is about delivery to one out of multiple > destinations within a given scope. Hi Heiner, I would have said "closest one from the set of valid destinations," but your version is good enough. More precisely "closest one from the set of valid destinations with respect to the source," > Where is the center point of this scope ? Is it always the location of= the > source ? I don't understand the question. What is a center point wrt routing? My question is: with anycast do we always understand the above, or could= it also be any particular destination within the scope of an indicated rem= ote location like a different continent? What do we understand by Anycast in the future ? Some one must do the mapping to a specific Unicast address? Is it always the ingress ? Or can't= there be reasonable anycast services which require to send the data to so= me far distant anycast server where it will be mapped to some local unicast addresss ? > What are the requirements for Anycast in a new architecture? Well, that's the crux of the discussion, isn't it? Anycast and unicast are identical in every respect in the current architecture. How do we bound the unforeseeable consequences if that isn't true in the new one? I'm getting ready to introduce an anycast route into the table in order to implement a "continuing operations" system with three sites half a world apart. "Continuing operations" is a fancy phrase for "disaster recovery," something that became really popular almost 8 years ago. Once a packet hits any of the always-running sites, a VPN takes it back to the site with the servers flagged "best" for that particular address, so holistically its unicast but from the perspective of the Internet core its anycast from three distinct locations. Would this have any hope of working right in an architecture that didn't accommodate anycast? How many such uses are out there, ready to impede the deployment of the unwary plan? Sorry, I don't understand what you are hereby saying. Heiner Regards, Bill Herrin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1240386476 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I think, I have found the answer to one of my questions by myself:
GRE-tunneled Anycast with a far remote outer address and a locally sc= oped inner anycast address.
 
Heiner
 
 
In einer eMail vom 22.04.2009 00:29:24 Westeurop=E4ische Normalzeit= schreibt HeinerHummel@aol.com:
In einer eMail vom 21.04.2009 23:54:19 Westeurop=E4ische Normalzeit= schreibt bill@herrin.us:
On Tue, Apr 21, 2009 at 4:00 AM,  <HeinerHummel@aol.com> wrote:
> As I understand Anycast  is about delivery to one= out of multiple
> destinations within a given scope.

Hi Heiner,

I would have said "closest one from the set of valid destinations,"
but your version is good enough.
More precisely "closest one from the set of valid destinations with= respect to the source,"



> Where is the center point of this scope ? Is= it always the location of the
> source ?

I don't understand= the question. What is a center point wrt routing?
My question is: with anycast do we always understand the above, or= could it also be any particular destination within the scope of an indicated= remote location like a different continent?
 
What do we understand by Anycast in the future ? Some one must do= the mapping to a specific Unicast address? Is it always the ingress ? Or can= 't there be reasonable anycast services which require to send the data to= some far distant  anycast server where it will be mapped to some  local unicast addresss ?

> What are the requirements for Anycast in a new architecture?

Well, that's the crux of the discussion, isn't it= ? Anycast and unicast
are identical in every respect in the current= architecture. How do we
bound the unforeseeable consequences if tha= t isn't true in the new
one?

I'm getting ready to introduce an= anycast route into the table in
order to implement a "continuing operations" system with three sites
half a world apart. "Continuing= operations" is a fancy phrase for
"disaster recovery," something th= at became really popular almost 8
years ago. Once a packet hits any of= the always-running sites, a VPN
takes it back to the site with the serv= ers flagged "best" for that
particular address, so holistically its uni= cast but from the
perspective of the Internet core its anycast from thre= e distinct
locations.

Would this have any hope of working righ= t in an architecture that
didn't accommodate anycast? How many such uses= are out there, ready to
impede the deployment of the unwary plan?
Sorry, I don't understand what you are hereby saying.
Heiner
 

Regards,
Bill Herrin


 


________________________________________= _______
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1240386476-- From tony.li@tony.li Wed Apr 22 08:42:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8849B28C57B for ; Wed, 22 Apr 2009 08:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbCXpLrBkx5Q for ; Wed, 22 Apr 2009 08:42:39 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id A59A928C525 for ; Wed, 22 Apr 2009 08:42:39 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id icF01b00217UAYkABfjxts; Wed, 22 Apr 2009 15:43:57 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id ifjx1b0023L8a8Q8ZfjxQm; Wed, 22 Apr 2009 15:43:57 +0000 Message-ID: <49EF3B04.4040901@tony.li> Date: Wed, 22 Apr 2009 08:43:00 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim , rrg@irtf.org References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> <20090420193158.GH34560@cisco.com> <49EDEA85.6070307@tony.li> <20090421160414.GQ70118@cisco.com> In-Reply-To: <20090421160414.GQ70118@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:42:40 -0000 Hi Scott, > Oh. Then I think we actually agree on procedure, but let's make it > explicit: > > The goal is to figure out which classes of solutions are > appropriate, and one input to that is to look at the implications > each solution class has on properties of identifiers. Agree. > Some of us have been saying that you can't do "properties of > identifiers" in general, you have to talk about which kinds of > identifiers, in which context. I guess you agree. If so, sorry, I > hadn't understood. No, I think it's reasonable to talk about the classes of solutions and the reasonable properties of the (host, interface, stack, ...) identifier that is bound to the locator within each class. > Yes, local identifiers are worthy of discussion. So I think that local identifiers are acceptable, but solutions should always also provide global identifiers. The decision of which to use should be left to the end station/stack/user. > Again, I would like the process to be explicit, otherwise we will > probably ramble around and it will be hard to agree on whether we have > reached any agreements. Do you want to start specifically with the > class of solutions that includes ILNP, look specifically at "host" > identifiers, and look at implications/possibilities/requirements? > That would be fine with me. Again, I don't want this to devolve into another partisan bickering match. I would much rather talk about general classes (ala Bill's different strategies). Tony From tony.li@tony.li Wed Apr 22 09:03:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B933A6F3B for ; Wed, 22 Apr 2009 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tbHSvTcYkfj for ; Wed, 22 Apr 2009 09:03:41 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 0812F28C27C for ; Wed, 22 Apr 2009 09:03:40 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ibqV1b0020x6nqcAAg4wt2; Wed, 22 Apr 2009 16:04:56 +0000 Received: from [192.168.1.100] ([24.6.155.154]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id ig4v1b00N3L8a8Q8Yg4wbJ; Wed, 22 Apr 2009 16:04:56 +0000 Message-ID: <49EF3FEE.2090503@tony.li> Date: Wed, 22 Apr 2009 09:03:58 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> In-Reply-To: <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:03:42 -0000 Hi Bill, > How's that different from, say, cnn.com, aggregated with the other > Turner services and spread across two of Turner's three unicast > routes? If TCP was stable over anycast, they might actually be able to > drop one of those unicast routes. So, Turner is aggregating (hopefully) large blocks of end-hosts behind each of those prefixes. This aggregation is purely a network layer issue and is not tied to transport or applications. Anycast looks to be a pure application/service layer issue. Yes, ok, you COULD aggregate anycast for common services that have the same source. I don't see how that helps the general case of services that are supported by multiple sources (e.g., DNS, NTP). Those don't seem to aggregate at all. In some sense, you could draw the analogy between anycast and a promiscuous use of PI addresses. > Seems to me that the aggregability of services has more to do with the > size of the services set than it does with whether the service is > unicast or anycast. Big important web site = at least one more route > in the table. Who decides what's big and important? And how does that not end up in an international court (e.g., ICANN). If every web site ends up with a route, then it's game over. > I think of deterministic as "pick one direction" while > non-deterministic is "travel all valid directions." I'm open to a > better word choice. Non-determinism in the classical CS sense would be 'travel in the right direction' where the direction is determined without regard to the content of the packet and state in the network and yet somehow, the right decision is always made. I'd favor 'unicast' for "pick one direction" and 'multicast' for "pick all valid directions". > I had a discussion with a colleague earlier today. He was having a > problem with a mapping app on his web site going through a particular > proxy server that didn't support http keepalive. To render a map page > with all the plotted points, he would generate around 500 ssl http > requests. With keepalive this would generate around 30 ssl > connections. Without keepalive it generates 500 and runs so very much > slower. > > Where's the error here? The proxy that doesn't support keepalive? Or > the app that needs to generate 500 https queries in order to render a > web page? Which one do you zero in on and change? Having to have proxies (ALG's) in the network in the first place. Evil, evil, evil. Yes, I have to live behind one. > The upper layers set requirements on the routing layer in a manner the > routing layer can't handle efficiently. One answer is that we redesign > the routing layer. Another is that we alter the requirements. Ruling > either answer out of scope would, at the very best, be failing to > think outside the box. Ok, but asking the routing layer to defy the laws of physics (i.e., scale without aggregation) is unlikely to be productive. Tony From wherrin@gmail.com Wed Apr 22 10:27:42 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F343A6BAF for ; Wed, 22 Apr 2009 10:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AyHc8p5tGJD for ; Wed, 22 Apr 2009 10:27:41 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 3D60B3A6B08 for ; Wed, 22 Apr 2009 10:27:41 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so54726yxg.37 for ; Wed, 22 Apr 2009 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=S5905xSCQMTf4bhNIo9uGVmQsYpSvVChqFO/c9RR/RA=; b=TYFxtpaVNb0Sbi9ZU70ajaKgg7p2R2+U3YXjDydkoBO3BGxiKLOWb5twuubwPHSjpB uaR8yB9wONnf1goxoqTkIj1g7WeHKYjZoolbBfx7da0xa1KAaG8/j4FzGvfVRokQVsdy DS9fa7tXFMZPaIXwvvHu/07yx6/yTyVnfAn24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Gu0HGSeCjz+dJN2MgXxeRXZlBL3jfuYkhUNFeh+QDPlLSG0wthqTHE6spFHrgY39fX MVANtG22jKYuGs8ZYsqeWkvEePGarbKbvWDnWvS9s7CLiAGrfTFlBLkhyVNUlK945xrS amNRbUuk6bM2OBoEJ76/NgN+6wj0T7JWXHc6c= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.216.10 with SMTP id o10mr11664505ang.159.1240421338255; Wed, 22 Apr 2009 10:28:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2009 13:28:58 -0400 X-Google-Sender-Auth: e68017c1fb74b726 Message-ID: <3c3e3fca0904221028kfa93629q924cdd369e41791b@mail.gmail.com> From: William Herrin To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 17:27:42 -0000 On Wed, Apr 22, 2009 at 12:03 PM, Tony Li wrote: >> Big important web site =3D at least one more route >> in the table. > > Who decides what's big and important? Hi Tony, Historically, the people willing to pay the most money do. Like CNN. >> I think of deterministic as "pick one direction" while >> non-deterministic is "travel all valid directions." I'm open to a >> better word choice. > > I'd favor 'unicast' for "pick one direction" and 'multicast' for "pick al= l > valid directions". Then anycast is by definition unicast since you only pick one direction. Hence some unicast is anycast. Hence failing to support anycast in the architecture is a failure to completely support unicast. ;-) >> The upper layers set requirements on the routing layer in a manner the >> routing layer can't handle efficiently. One answer is that we redesign >> the routing layer. Another is that we alter the requirements. > > Ok, but asking the routing layer to defy the laws of physics (i.e., scale > without aggregation) is unlikely to be productive. Then we change the requirements. Eliminate the demand that the elements used for the next hop decision retain a constant association with the endpoints over time. I wonder how many people still disagree with that? On Wed, Apr 22, 2009 at 12:03 AM, Robin Whittle wrote: >> And as I mentioned, it's relatively trivial to get it to look >> precisely the same in each of the two major solution strategies >> as well. > > I think this is probably not true of Strategy B (core-edge > elimination, in which new host stack and perhaps application > functions do all the work and end-user networks never have their own > stable address space. Hi Robin, What's the difference between anycast and unicast? Is it a difference in the forwarding or data planes? Or is it a difference in how the respondent machine(s) understand the address? It's the latter of course. In strategy B, the host's understanding of each packet moves out of the packet forwarding system entirely and into the map used by the respective hosts. A strategy-B host literally doesn't care what layer-3 addresses were attached to the received packet. The address in the routing system only retains semantics associated with the forwarding process itself. So, as long as the mapping system adequately supports something that looks like anycast, the whole strategy B system does as well. On Tue, Apr 21, 2009 at 6:25 PM, wrote: > My question is: with anycast do we always understand the above, or could = it > also be any particular destination within the scope of an indicated remot= e > location=A0like a=A0different continent? Hi Heiner, I don't know. Some backbones currently have a limited ability to restrict advertisements by geography or topology using BGP communities but I'm not sure to what degree its used. > What do we understand by Anycast in the future ? Is it always the ingress= ? Ingress is actually two separate questions: 1. Is an anycast address only ever the respondent or does it also initiate communications? 2. Is the anycast address ever allowed to appear in the "source" position in the packet? Making existing UDP and TCP work requires #2. I haven't come up with a scenario where initiating communication from an anycast address is desirable. >> Would this have any hope of working right in an architecture that >> didn't accommodate anycast? How many such uses are out there, ready to >> impede the deployment of the unwary plan? > > Sorry, I don't understand what you are hereby saying. I'll simplify the design for the sake of the discussion. You have two sites: primary in New York (NY), disaster recovery in Tokyo (T). Each site has one Internet link, one router and one server. Sprint provides the Internet link to NY. Cogent provides the Internet link = to T. The NY router announces 1.2.3.0/24 via BGP at normal priority. The T router announces 1.2.3.0/24 after prepending the AS# 3 times, causing most of the other routers on the Internet to consider the T router more distant than the NY router. The two sites are normally linked together with a VPN traveling over the Internet using 5.6.7.8 on one side and 8.7.6.5 on the other, addresses provided by the respective ISPs. This functions as if there was a private line directly connected between the two routers. Ordinarily, the T router sends packets for 1.2.3.4 over the VPN to the NY router while the NY router sends packets for 1.2.3.4 to the NY server. If the VPN fails, the T router will send packets for 1.2.3.4 to the T server instead. If the NY server fails, the NY router will send packets for 1.2.3.4 over the VPN to the T router and the T router will send packets for 1.2.3.4 to the T server. Both servers answer to 1.2.3.4. Both return identical content. Now, lets look at what happens in this structure. In normal operation, 1.2.3.4 is a unicast address. Requests always route to the NY server. The T server is a hot standby that only becomes routed if the NY server fails. Something interesting happens during what's known as a "split brain" scenario. Let's say Sprint gets mad at Cogent and they depeer again. The VPN breaks and just like that, THE ADDRESS USAGE CONVERTS TO ANYCAST. Traffic from Sprint goes to the NY server, the only one it can see. Traffic from Cogent goes to the T server, the only one it can see. Traffic from the rest of the Internet reaches either of the servers depending on the length of the AS path as seen from the requester. So, in this disaster recovery scenario, the address usage changes back and forth between unicast and anycast depending on the state of the network. Two points here: 1. Folks using a design like this will be reluctant to use a routing system which does not support something functionally equivalent to anycast. And they tend not to be paupers. Money speaks and their money will impede the deployment of the new system. 2. Disaster Recovery (DR) sites are in high demand but folks find them difficult and expensive to implement. Even after going to the expense, DR's success rate is painfully low. Suppose our new architecture enables the above design without requiring support in the forwarding plane the way the above design does? Why then it would be cheap, and you could implement DR by renting a $50 virtual server in Tokyo instead of building a physical site. DR could be our killer app. Making DR cheap, accessible and easy would be a powerful motivator for deploying our new system. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From HeinerHummel@aol.com Wed Apr 22 14:34:39 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3763A6C2E for ; Wed, 22 Apr 2009 14:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.119 X-Spam-Level: X-Spam-Status: No, score=0.119 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siAqoHS7DCpQ for ; Wed, 22 Apr 2009 14:34:39 -0700 (PDT) Received: from imo-m13.mail.aol.com (imo-m13.mx.aol.com [64.12.143.101]) by core3.amsl.com (Postfix) with ESMTP id 55FFE3A68F2 for ; Wed, 22 Apr 2009 14:34:36 -0700 (PDT) Received: from imo-da02.mx.aol.com (imo-da02.mx.aol.com [205.188.169.200]) by imo-m13.mail.aol.com (v107.10) with ESMTP id RELAYIN3-449ef8d9a28b; Wed, 22 Apr 2009 17:35:22 -0400 Received: from HeinerHummel@aol.com by imo-da02.mx.aol.com (mail_out_v40_r1.5.) id z.cfc.54377355 (41812); Wed, 22 Apr 2009 17:35:05 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Wed, 22 Apr 2009 17:35:04 EDT To: bill@herrin.us, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240436104" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 205.188.169.200 Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:34:40 -0000 -------------------------------1240436104 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 22.04.2009 19:29:28 Westeurop=E4ische Normalzeit schrei= bt bill@herrin.us: DR could be our killer app. Making DR cheap, accessible and easy would be a powerful motivator for deploying our new system. Hi Bill, Motivations (=3Dkiller applications) to install the new architecture ? We= ll, I think my strategy C solution would have quite a few of favorable monetary aspects: If the RIB substitution required only to collect approx.3000 nodes and= twice or three times as many loose/strict links, and if the FIB substitutation required only 75 K entries, and if each each forwarding de= cission required only one or 3 table lookups, then I think that much less expensi= ve core routers would be required. So I don't worry just because LISP goes in lea= d. Heiner -------------------------------1240436104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
 
In einer eMail vom 22.04.2009 19:29:28 Westeurop=E4ische Normalzeit= schreibt bill@herrin.us:
DR could be our killer app. Making DR cheap, accessible and easy would
be a po= werful motivator for deploying our new system.
Hi Bill,
Motivations (=3Dkiller applications) to install the new architec= ture ? Well, I think my strategy C solution would have  quite a few of favorable monetary aspects: 
 
If the RIB substitution  required only to collect approx.3000 no= des and twice or three times as many loose/strict links, and if the FIB substitutation required only 75 K entries, and if each each forw= arding decission required only one or 3 table lookups, then I think that muc= h less expensive core routers would be required. So I don't worry just becau= se  LISP goes in lead.
 
Heiner
 
 
 
 
 -------------------------------1240436104-- From rw@firstpr.com.au Wed Apr 22 21:01:34 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DD93A6CBE for ; Wed, 22 Apr 2009 21:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5iR-bgLLXjM for ; Wed, 22 Apr 2009 21:01:33 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id ED2F128C2AF for ; Wed, 22 Apr 2009 21:01:31 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 638BF175D36; Thu, 23 Apr 2009 14:02:48 +1000 (EST) Message-ID: <49EFE7F1.1020108@firstpr.com.au> Date: Thu, 23 Apr 2009 14:00:49 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rrg@irtf.org References: <3c3e3fca0904221028kfa93629q924cdd369e41791b@mail.gmail.com> In-Reply-To: <3c3e3fca0904221028kfa93629q924cdd369e41791b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:01:34 -0000 Hi Bill, I will respond to what you wrote to me in the "Anycast in the core architecture - sep. OK; elim not?" thread and what you wrote about "Disaster Recovery" in a separate thread. - Robin From rw@firstpr.com.au Wed Apr 22 21:10:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BC13A6EA9 for ; Wed, 22 Apr 2009 21:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeOsWfzE7G6P for ; Wed, 22 Apr 2009 21:10:20 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 7987B3A6945 for ; Wed, 22 Apr 2009 21:10:19 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id E1DB3175D36; Thu, 23 Apr 2009 14:11:35 +1000 (EST) Message-ID: <49EFEA00.9080403@firstpr.com.au> Date: Thu, 23 Apr 2009 14:09:36 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> <49EE9718.9060100@firstpr.com.au> In-Reply-To: <49EE9718.9060100@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Anycast in the core architecture - sep. OK; elim not? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:10:23 -0000 Short version: Summarising and extending my previous message to include more about anycast with a core-edge separation scheme and to explore it with a core-edge elimination scheme. Replying to Bill about how global anycast would work with core-edge elimination. In summary: Global anycast has its uses, but it is highly unscalable, since there needs to be a separate prefix advertised in the DFZ for every set of anycast servers - for each anycast IP address. A core-edge separation scheme could achieve the same benefits, by using anycast *ETRs*. This has no benefits over the conventional BGP-based approach and is equally unscalable. A core-edge elimination scheme *might* be able to do global anycast too - but it would be more complex than with the conventional BGP approach. There would be no scaling benefits - it would be just as unscalable as the conventional BGP approach. However, a core-edge elimination scheme, once fully adopted, does not allow end-user networks to have their own PI prefixes. So it would not be possible to use the conventional BGP approach. I will write a separate message on Disaster Recovery. Hi Bill, To summarise and extend: http://www.ietf.org/mail-archive/web/rrg/current/msg04897.html For core-edge separation schemes: 1 - The routing system - the BGP-based DFZ and probably some other routers, plus the ITRs, ETRs etc. of the core-edge separation scheme - can't tell the difference between host unicast and host anycast. This is another way of saying they will work fine for packets for both scenarios. 2 - However, just host-anycast with a core-edge separation scheme does not have the same effect on packet flow in the DFZ as conventional BGP-based host anycast with each host having its own separate BGP router. The main, perhaps only, reasons people are interested in conventional BGP-based host anycast are (AFAIK) as follows. These are all dependent on the normal behaviour of the BGP routing system. a - "Shortest" (generally, in BGP terms) path to the nearest router which advertises the prefix of its anycast host. b - Automatic failure recovery as long as the router stops advertising the prefix if the one or more hosts using this prefix dies. If so, the other BGP routers will soon get the packets which would have gone to this one. c - Load sharing over many hosts, in geographically and topologically diverse sites, which gives the system a high capacity and a great resistance to failure without involving DNS in any way, since it always responds to the one IP address. This is also extremely important as a way of achieving high total bandwidth to survive DoS attacks with floods of incoming packets. It may also be desired and possible to: d - Imply something about sending host location from which of the anycast BGP routers got the packet (as you are doing with your project which you mentioned at the end of msg04894) - but AFAIK this information is not used for the most prominent BGP-based host anycast usage: root nameservers. Host-anycast with a core-edge separation scheme and a single (unicast) ETR (Fig 9 as noted below) involves no significant difference in the way packets traverse the DFZ compared to conventional BGP-based unicast (Fig 3). Fig 1 (msg04897) shows BGP-based host unicast - with two border routers advertising the prefix. This is ordinary operation for many hosts today, which use PA space on an ISP with two DFZ border routers each with its own upstream link to separate parts of the DFZ. Fig 3 shows core-edge separation with a unicast host and a unicast ETR, with two border routers advertising the ETR's prefix. This is likewise basic, ordinary, core-edge separation operation as with LISP, APT, Ivip or TRRP - where the ETR address is in a PA prefix of an ISP with two BRs. Fig 9 - if we ignore the bottom half - is just like Fig 3 with a unicast ETR, but there is host anycast at the one local network the ETR connects to. So using a core-edge separation scheme to do host-anycast with a single (unicast) ETR (rather than anycast ETRs) brings none of the benefits of conventional BGP-based anycast, because the ITR->ETR tunnel is conventional unicast. 3 - To achieve the goals listed above - a, b, c and perhaps d - with a core-edge separation scheme, it is necessary to have anycast *ETRs*. This is the only way of achieving the desired packet paths through the DFZ and of using the DFZ routers to automatically send the packet to the nearest router of an ETR which handles the EID (micronet) prefix of the multiple anycast hosts. Fig 11 shows conventional BGP-based host anycast: R2------R5------>DH1 / \ | SH---->R1 R4---R6 \ / | R3------R7------>DH2 | R9------R10----->DH3 / \ SH2----R12--R13 Four destination hosts, each \ / one anycast in a global sense. R14-----R11----->DH4 Fig 11 To achieve the same DFZ packet flow patterns with a core-edge separation scheme, you would use anycast ETRs as with Fig 8: ITRs ETRs R2------R5-->E1->DH1 / \ | Each of four ISPs has an SH-I1->R1 R4---R6 anycast ETR. So each ISP's \ / | router (R5, R7, R10 & R14) R3------R7-->E2->DH2 is advertising the same | prefix. R9------R10->E3->DH3 / \ SH2-I2-R12--R13 Four destination hosts, each \ / one anycast in a global sense. R14-----R11->E4->DH4 Fig 8 This is anycast ETRs (all with the same "RLOC" = Locator address) and anycast hosts (all with the same EID = Identifier = micronet address). You could also achieve the same DFZ packet paths with four identically anycast ETRs, each with a VPN or a dedicated link of some kind to a data centre: R2------R5-->E1 / \ | \ SH-I1->R1 R4---R6 \ \ / | \ R3------R7-->E2---\ | [Data center] R9------R10->E3---/ / \ / SH2-I2-R12--R13 / \ / / R14-----R11->E4 Fig 12 where you could have a single host, which is therefore globally unicast. You could also have multiple hosts on the same address at the data centre, and therefore locally anycast. Depending on how the data centre's router linked the VPNs to the hosts, you could make the system behave like Fig 8, or you could have all the incoming packets go to one router, which picks the "closest" (or however the IGP chooses the next hop) router of each of the locally anycast hosts. You could also have some kind of load distributor which behaves like a single host but spreads packets out to a server farm, ideally maintaining the same distribution over sessions, so TCP etc. works fine. 4 - So with a core-edge separation scheme, you can get the benefits of conventional BGP-based anycast, but only by using anycast ETRs. Whether or not these anycast ETRs use their own (anycast) hosts (Fig 8) or whether they link in some way to one or to multiple hosts (Fig 12) is a separate issue. 5 - Conventional BGP-based anycast (Fig 11) is even more unscalable than ordinary PI prefixes for end-user networks, for two reasons at least: A - Each router needs to withdraw the prefix if its host dies. Therefore, the prefix can only realistically be used by one host (or perhaps a load-balanced host farm), in which case the router still needs to withdraw the prefix from the DFZ as soon as the host or host farm dies. Therefore, the prefix can only be realistically used for a single host (or host farm) at each location. Maybe each such host uses multiple IP addresses, each of which is globally anycast, but whether they have one or multiple such addresses doesn't alter the fact that the router needs to stop advertising the entire prefix if the host or host farm dies. (Likewise, for Fig 12, if the VPN link dies.) Therefore, the prefix can't be shared by multiple end-user networks, or perhaps even by the one end-user network trying to run two separate anycast servers from each router - each such host (or host farm) needs its own prefix so the router can withdraw it if the host or host farm dies. B - Even if the above was not true, it is unlikely that two separate end-user networks would want to run their anycast hosts at exactly the same sites as some other end-user network. Therefore, conventional BGP-based anycast is just as unscalable as any other end-user PI prefix, plus the additional constraint that if the network wanted to run two anycast servers at each site, it would need to advertise two separate prefixes at each site. 6 - While a core-edge separation scheme *could* be used to achieve similar "anycast" packet flows in the DFZ, by using anycast ETRs, this is no more scalable than the conventional BGP-based host anycast, for reasons identical to those in point 5, but for which the term "host or host farm" is replaced by "ETR". 7 - So AFAIK, there is no benefit at all using a core-edge separation scheme with anycast ETRs, to achieve the same or similar DFZ packet flow patterns of conventional BGP-based anycast. The KISS principle therefore rules out the use of core-edge separation schemes to achieve the same DFZ packet flow benefits of conventional BGP- based anycast. 8 - If the potentially anycast hosts are in a single data centre, then you could use conventional BGP techniques as you do with your project (Fig 9) or you could use a core-edge separation scheme to do it (Figs 10 & 12) - but the KISS principle favours the conventional BGP approach. In short, a core-edge separation scheme can be used to achieve the same benefits of conventional BGP-based anycast and/or fancier VPN and data-centre based arrangements like your project. However, there are no scalability benefits in doing so, and the system would probably be more complex than using ordinary BGP methods. I didn't write anything specific about core-edge elimination schemes, in which the hosts have one or more, potentially unstable, "locator" addresses (much like a MIP Care of Address, I think) but in which the applications identify the hosts with persistent Identifier addresses and so are able to maintain sessions while each host: 1 - Is mobile - rapidly gaining and losing locator addresses. 2 - Is portable - the host retains it identifier address whenever a new ISP is used, giving the host a new locator address. 3 - Needs to use a previously unused locator address from ISP-2 due to the currently used one (from ISP-1) ceasing to function - for instance in multihoming service restoration. HIP is an example of a core-edge elimination scheme. HIP is not a practical solution to the routing scaling problem, because it involves host changes (stack and I think API and applications) to work, and since the multihoming, TE and portability it could bring only work with similarly HIP-upgraded hosts. Since all core-edge elimination schemes involve some new addressing arrangements (HIP uses a unique namespace for host identifiers) I think none of them are practical solutions to the routing scaling problem, since we must rely on voluntary adoption to introduce this solution to most and ideally all end-user networks over a period of years: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ Since AFAIK no-one else has done so, I will now try to imagine how a core-edge elimination scheme (as I understand it) could do something resembling conventional BGP-based anycast. There are no ITRs or ETRs in a core-edge elimination scheme. Just today's basic routing system, but with fancier hosts which can keep operating, maintain sessions etc., despite using one or more potentially unstable locator addresses. The only benefits of anycast, as far as I can see, are those listed above: a, b, c and perhaps d. To achieve these, you need to replicate the patterns of DFZ packet travel, in which packets typically travel to the "nearest" router of a functioning anycast host. This relies on BGP or whatever other routing systems are involved. To achieve this, a core-edge elimination scheme needs to have multiple routers advertising the same prefix (or at least a prefix which includes the "anycast" address). In the core-edge elimination scheme, this is a locator address. So all the "anycast" hosts need the same locator address. I will refer to the one or more ordinary hosts which is communicating with one or more of the "anycast" hosts as the Correspondent Host (CH). This has one or more, potentially unstable, unicast locator addresses and a single, globally unique, identifier. For any CH to be able to communicate with the one or more "anycast" hosts, it needs to be able to regard that set of hosts as behaving like one conventional host. (Unless perhaps the core-edge elimination scheme has special provisions for implementing something equivalent to anycast.) Therefore, all the "anycast" hosts must have the same identifier. This is because at any time, the CH could have its packets sent to a different "anycast" host than the one the packets were sent to a moment before. This could be due to: 1 - The CH starts sending packets from a different locator address. 2 - Something in the routing system changes, so the packets are now sent to a different router which is advertising the prefix of the "anycast" hosts. This includes changes due to of the "anycast" hosts going down, or coming up. Note that this precludes something which would ordinarily be acceptable for hosts in a core-edge elimination scheme: One of the "anycast" hosts changing its locator address and therefore requiring its router (or perhaps some other router) to advertise a different prefix for its new locator address. This can't work, because the only way this "anycast" scheme can achieve the desired pattern of packet flow in the DFZ is for all the hosts to have the same locator address. So it looks like you *could* use a core-edge elimination scheme to achieve similar DFZ packet flows as with conventional BGP-based anycast and so achieve goals a, b, c and perhaps d (with a VPN or some other link to a central data-centre). However, you would have to accept the following restrictions, at least: 1 - You have to organise all the hosts to have the same locator and identifier. (So how do you talk to them for admin purposes? Can a host have multiple identifiers, one of which is the same for all these hosts and another which is unique?) 2 - As with 5 A above, you need to devote an entire BGP prefix to this particular set of anycast servers. 3 - As noted below, you actually need an end-user network specific prefix, which is at odds with how a core-edge elimination scheme is supposed to work. Therefore, any attempt to use a core-edge elimination scheme for "anycast" is: 1 - Probably more complex and constrained than the conventional approach. 2 - Does not allow any scaling benefits which ordinarily come from a core-edge elimination scheme. 3 - Is just as unscalable as conventional BGP-based host anycast. The scaling benefits of a core-edge elimination scheme result from all hosts in end-user networks getting at least one address from each of their one or more ISPs - where those addresses always come from the large (lots of addresses = short prefix) prefixes which belong to the ISPs. In other words: end-user networks do not have their own prefixes and work perfectly well on PA addresses from the ISP's well aggregated (highly scalable) prefixes. For instance, one ISP site may have one or a few such prefixes which may have millions of IPv4 addresses or bazillions of IPv6 /64s. Each such prefix is a single entry in the DFZ routing table but supports the needs of potentially thousands, millions or whatever end-user networks. In summary, assuming the goals of "global host anycast" a, b, c and perhaps d: Conventional BGP approach as used today: Works fine. Requires a single prefix for each such set of anycast hosts (point 5 A above). Therefore, is unscalable to a high degree - even more so than an ordinary end-user PI prefix, since this end-user PI prefix for anycast hosts needs to be dedicated to the one set of hosts: the one set on a (typically) single IP address. Core-edge separation, using anycast ETRs. Works about as well as the conventional approach, but is equally unscalable for the same reasons. Since it is more complex, it is probably best to avoid it and use the conventional BGP approach instead. Core-edge elimination Could be made to work, but is more complex than the conventional approach and is just as bad in terms of scaling. However, if the Internet was somehow converted to a core-edge elimination approach, it would be impossible to do the conventional BGP approach, in which there was no distinction between identifier and locator (the IP address means both). So adoption of a core-edge elimination approach would probably make global anycasting more difficult than at present. In contrast, a core-edge separation scheme could do it, in a probably more difficult manner. - without getting in the way of using the simpler BGP approach. *** This is all assuming the core-edge separation scheme is not intended to prohibit end-user networks having their own conventional PI prefixes, as is required to do conventional BGP anycast or its anycast ETR equivalent. IOW, the "separation" is only partial and is not intended to ever be complete. I recall that a goal of APT (as currently defined - maybe this will change) is the eventual complete separation of the "core" address space (ISP prefixes for ITRs, ETRs and Default Mappers etc.) and the "edge" address space (EIDs for end-user network hosts). http://tools.ietf.org/html/draft-jen-apt-01#section-3 The definitions of "transit space" and "delivery space" imply a complete separation of the global unicast address space into two classes. So "transit" addresses are RLOCs for ITRs and ETRs and "delivery" space addresses are EIDs for end-user network hosts and their internal routers etc. The definitions include two separate routing scopes or "areas". I understand this as meaning complete separation, since it would be no route for a packet from any "transit" address to any "delivery" address or vice-versa. These would be two separate subsets, in various interspersed prefixes, in the current global unicast address range. I think this is an unnecessary and probably unachievable goal. Another aim of APT (IIRC, but I can't easily find a reference) is to improve security by somehow trusting packets sent from the "core" (transit) subset of the address space in a different manner from those sent from the "edge" (delivery) space. I think this would be very difficult to do robustly, since a single attacker with control of a host with an ISP's (transit) address could do whatever they liked in the "core". Ivip, and I think LISP, do not have a specific goal of complete separation, as does APT. So with Ivip and I think LISP, it would always be possible for an end-user network to use a PI address for a set of globally anycast hosts using the conventional BGP approach, or to use the prefix for the anycast ETR approach. It seems that any global use of anycast is inherently costly to the DFZ routing system - since it involves a specific prefix for every set of anycast servers. This is fine for a limited number of sets which are widely regarded as being important to everyone - such DNS root servers. However, if everyone and his dog (Aussie phrase) starts doing it, for purposes such as your project (end of msg04894) then the burden all these place on the DFZ control plane would come under increasing scrutiny. You wrote, in: http://www.ietf.org/mail-archive/web/rrg/current/msg04901.html > Hi Robin, > > What's the difference between anycast and unicast? Is it a > difference in the forwarding or data planes? Or is it a difference > in how the respondent machine(s) understand the address? > > It's the latter of course. Yes, but the reason most people want to do it on a global scale is because of the way the packets flow in the DFZ - to the "nearest" (in BGP terms) router advertising the prefix which encompasses an operational host. > In strategy B, Core-edge elimination schemes: http://bill.herrin.us/network/rrgarchitectures.html http://www.firstpr.com.au/ip/ivip/rrgarch/ http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 > the host's understanding of > each packet moves out of the packet forwarding system entirely and > into the map used by the respective hosts. Yes - the upper levels of the stack and all the applications don't care about the "locator" address with which packets are sent and received. All they care about is the "identifier" of the hosts concerned. > A strategy-B host literally > doesn't care what layer-3 addresses were attached to the received > packet. Like I said! > The address in the routing system only retains semantics > associated with the forwarding process itself. So, as long as the > mapping system adequately supports something that looks like > anycast, the whole strategy B system does as well. This is a rather mathematical, rule-based, way of looking at it - which doesn't seem to recognise some pertinent principles. AFAIK, the only reasons you want anycast on a global basis are those reasons a, b, c and perhaps d listed above in point 2. These all relate to the way the packets travel in the DFZ, which is determined by the conventional routing system and the *locator* (layer 3) destination address of the packets. So to achieve these benefits with a core-edge elimination scheme, all the routers need to advertise a prefix which contains the single *locator* IP address of all the anycast hosts AND (AFAIK) all those hosts need to have the same identifier. AFAIK, having multiple hosts with the same locator is a violation of the general principles behind core-edge elimination schemes. Likewise, perhaps even more so, is the concept of multiple hosts having the same identifier. Yet it brings you no benefits over the conventional BGP approach - and worse still, AFAIK, you with a core-edge elimination scheme in place and used by all hosts, you wont be able to use the conventional BGP approach. APT, it seems, once fully deployed, would also preclude the conventional BGP approach or the anycast ETR approach, unless you fashioned your end-user network as an ISP, got yourself an RLOC (core = transit) prefix and set up the equivalent of an ISP network, with Default Mappers ETRs and ITRs etc. in a unified manner somehow located at your several chosen sites. I will respond to what you wrote about disaster recovery in a separate thread. - Robin From wherrin@gmail.com Wed Apr 22 22:04:21 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA8C3A68CD for ; Wed, 22 Apr 2009 22:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8-V1LaSigkJ for ; Wed, 22 Apr 2009 22:04:20 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 862373A68B2 for ; Wed, 22 Apr 2009 22:04:20 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so232183and.37 for ; Wed, 22 Apr 2009 22:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hLNJFAf5VI3PrTgUcG//fBM+sa9MEnZcTpnEDZ+cEI8=; b=oXJwtKOuSR9L/ZElY2eyX3FQEOvaV0F9mwm+wfU5g5K5W9a/UFlR1b6zUxxOQMTmAK iINj0RFZhFL+7egWm+IJS16iStwMRsKRdHfYexKCpAym1/bhPUjuC3Fz2dshFMK7Xcr6 S5lQVg+7iBjMhj0fBpxPctZ9G/wVJ96xtVAmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wm70ZjNRvNpxSUOpaqn1nPLhfX6xhUPXYLsBGdxy+3kbDO7Joe8bqaLyRpiQw/vZFa Cb2n48k+vFdGK404KMb9Cq8akdVVbmQf6814v94HfDT5ppx6/NAvlUQo3hGf8RhzZBac J+ziqOM1GNqdNUFNEF/rmxkUU8HvwDodG5zB8= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.5.15 with SMTP id 15mr890525ane.50.1240463137278; Wed, 22 Apr 2009 22:05:37 -0700 (PDT) In-Reply-To: <49EFEA00.9080403@firstpr.com.au> References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> <49EE9718.9060100@firstpr.com.au> <49EFEA00.9080403@firstpr.com.au> Date: Thu, 23 Apr 2009 01:05:37 -0400 X-Google-Sender-Auth: cdcb667e37965cad Message-ID: <3c3e3fca0904222205idf6874ajed7db783b8e34495@mail.gmail.com> From: William Herrin To: Robin Whittle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: RRG Subject: Re: [rrg] Anycast in the core architecture - sep. OK; elim not? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 05:04:21 -0000 On Thu, Apr 23, 2009 at 12:09 AM, Robin Whittle wrote: > =A0 Core-edge separation, using anycast ETRs. > > =A0 =A0 =A0Works about as well as the conventional approach, but is > =A0 =A0 =A0equally unscalable for the same reasons. =A0Since it is more > =A0 =A0 =A0complex, it is probably best to avoid it and use the > =A0 =A0 =A0conventional BGP approach instead. Hi Robin, I think maybe you're missing the forest for the trees here. The functional equivalent of anycast in a strategy-A system is a 1-to-many address-to-ETR map where the ETRs in question are entries into distinct networks instead of entries into the same network. The anycasting functionality happens entirely in the ITR when it chooses the ETR. The ETR's character is that it has only one attachment in the topology, not multiple attachments. Giving the ETR multiple attachments would defeat the purpose. As for anycast ETRs, I haven't thought of a single sensible use case. > =A0 Core-edge elimination > > =A0 =A0 =A0Could be made to work, but is more complex than the > =A0 =A0 =A0conventional approach and is just as bad in terms of > =A0 =A0 =A0scaling. =A0 However, if the Internet was somehow converted > =A0 =A0 =A0to a core-edge elimination approach, it would be impossible > =A0 =A0 =A0to do the conventional BGP approach, in which there was no > =A0 =A0 =A0distinction between identifier and locator (the IP address > =A0 =A0 =A0means both). Strategy B is like strategy A except we replace layer 4 with a protocol suite that handles the ITR/ETR functionality internally, eliminating the need for ITRs and ETRs. The anycasting decision happens in the originating host, after which the packet travels (or fails to travel) to one specific network attachment associated with the destination. The origin may have selected from be different attachments for the same host or it could have been attachments for multiple hosts all of which are capable of responding to the service request. >The main, perhaps only, reasons people are interested in >conventional BGP-based host anycast are (AFAIK) as follows. >These are all dependent on the normal behaviour of the BGP >routing system. > >a - "Shortest" (generally, in BGP terms) path to the nearest > router which advertises the prefix of its anycast host. This is the "speed" case. The premise is that the closest one will have the shortest round trip time and the lowest probability of packet loss. >b - Automatic failure recovery as long as the router stops > advertising the prefix if the one or more hosts using > this prefix dies. If so, the other BGP routers will > soon get the packets which would have gone to this one. Yes. >c - Load sharing over many hosts, in geographically and > topologically diverse sites, which gives the system > a high capacity and a great resistance to failure > without involving DNS in any way, since it always > responds to the one IP address. This is also extremely > important as a way of achieving high total bandwidth > to survive DoS attacks with floods of incoming packets. Yes. Point being that while DNS would work for this in theory, in practice it runs into trouble. >It may also be desired and possible to: > >d - Imply something about sending host location from which > of the anycast BGP routers got the packet (as you are > doing with your project which you mentioned at the end > of msg04894) - but AFAIK this information is not used for > the most prominent BGP-based host anycast usage: root > nameservers. I suppose that's possible though I'm not sure what the use case is. It seems like much of the rest of what you wrote here is based on the faulty premise of having some kind of anycast ETRs. The only response I can offer is: of course anycast ETRs don't make sense. Anycast ITRs make sense. ITRs making anycast decisions while resolving the map make sense. But ETRs are supposed to be single points of attachment in the network topology; it wouldn't make any kind of sense for them to be anycast. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lear@cisco.com Thu Apr 23 00:47:09 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 162813A68FC for ; Thu, 23 Apr 2009 00:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.894 X-Spam-Level: X-Spam-Status: No, score=-9.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-CYBIOtC0mV for ; Thu, 23 Apr 2009 00:47:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 58B8D3A6A1D for ; Thu, 23 Apr 2009 00:46:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238976000"; d="scan'208";a="38948726" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Apr 2009 07:47:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3N7lgVE007317; Thu, 23 Apr 2009 09:47:42 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4438.cisco.com [10.61.81.85]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3N7lfNr019084; Thu, 23 Apr 2009 07:47:41 GMT Message-ID: <49F01D1D.70002@cisco.com> Date: Thu, 23 Apr 2009 09:47:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090414 Shredder/3.0b3pre MIME-Version: 1.0 To: Tony Li References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> <49EF3FEE.2090503@tony.li> In-Reply-To: <49EF3FEE.2090503@tony.li> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=906; t=1240472862; x=1241336862; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20Anycast=20in=20the=20core=20arc hitecture |Sender:=20; bh=s4Vgvi14IBZqwMPZ+Uz0DEyXhTJ/5dvWUUWsKGMXcXs=; b=GOVZhL7fKDt9cz+97pGIA6wf7KHFowMSl1dPt6181+5dNLqYoFNLxJr0Il b/5J5GOvQ34rRnYJn58VPWYfnojNkXTLOZAzAFvE0mNEEFR3kXJ2NalZD02j xWqGB9XMwu; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: RRG Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 07:47:09 -0000 On 4/22/09 6:03 PM, Tony Li wrote: > Anycast looks to be a pure application/service layer issue. Yes, ok, > you COULD aggregate anycast for common services that have the same > source. I don't see how that helps the general case of services that > are supported by multiple sources (e.g., DNS, NTP). Those don't seem > to aggregate at all. > At one point I pondered this idea. It would be to have several dozens of blocks of which people could choose one for their anycast service, based on what sorts of localities they wished to cover (and hence purchase service from). The problem is that the number of permutations of those localities gets large fast, and it also violates a rule I imposed on myself when thinking about the problem, that perhaps is worth sharing: Any solution should scale up with market competition. That one is arguably difficult to manage. From rw@firstpr.com.au Thu Apr 23 01:49:16 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226A528C6C8 for ; Thu, 23 Apr 2009 01:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_BACKHAIR_33=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+RAf4SWNq0y for ; Thu, 23 Apr 2009 01:49:13 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 6F63628C207 for ; Thu, 23 Apr 2009 01:49:12 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 900881755CA; Thu, 23 Apr 2009 18:50:29 +1000 (EST) Message-ID: <49F02B5E.20003@firstpr.com.au> Date: Thu, 23 Apr 2009 18:48:30 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> <49EE9718.9060100@firstpr.com.au> <49EFEA00.9080403@firstpr.com.au> <3c3e3fca0904222205idf6874ajed7db783b8e34495@mail.gmail.com> In-Reply-To: <3c3e3fca0904222205idf6874ajed7db783b8e34495@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] Adding a Distance Server for anycast / disaster recovery X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 08:49:16 -0000 Was: Re: [rrg] Anycast in the core architecture - sep. OK; elim not? Short version: We agree: anycast ETRs are of no value. Bill suggests that in a core edge separation scheme (Strategy A) in which there are potentially multiple ETR addresses, an ITR can choose an ETR in a way as to replicate the overall functionality of the current (unscalable) BGP-based anycast arrangement. I argue they can't, since they have no way of knowing the "distance" to the various ETRs. I suggest the concept of a local "Distance Server" which ITRs query to find out which ETR address is "closest". This gets a full feed of DFZ routes directly or indirectly from a nearby DFZ router. Its answer is the number of ASes in the most specific DFZ route which matches the queried ETR address. Then there will be a scalable way of doing host anycast and the "Disaster Recovery" arrangement. The same idea can be applied to the host stacks in core-edge elimination schemes (Strategy B) - if the mapping has multiple ETR addresses and instructions to pick the closest one, the host finds out which is closest from its local Distance Server. Ivip, as currently conceived, has only a single ETR address for each micronet. If this was changed to have potentially multiple ETR addresses then this would enable the same thing to occur as just described for LISP, APT and TRRP. The best approach would be to add the "Distance Server" function to the full database QSD Query Server function. Then, the QSD can return to the ITR a single ETR address which it chose as the closest of several. This involves no extra complexity in the ITR or the ITR<-->QSD query protocol. This same idea - integrating a Distance Server - could also be done for APT's DMs and for LISP-ALT's currently optional Map Resolvers. In this light, I will write more in the future about Bill's example of a "Disaster Recovery" arrangement. I am working on a message about this but will revise it in the light of the "Distance Server" idea. With BGP, and with existing core-edge separation techniques, I can find no scalable way of doing anycast or "Disaster Recovery" arrangements. However, by adding a "Distance Server" to these schemes, I think it could be done elegantly and perfectly scalably. Below my signature is a copy of what Bill wrote in msg04901 about "Disaster Recovery" and my attempt to create a diagram for it. Hi Bill, Thanks for your speedy and thoughtful reply. > I think maybe you're missing the forest for the trees here. The > functional equivalent of anycast in a strategy-A system is a 1-to-many > address-to-ETR map where the ETRs in question are entries into > distinct networks instead of entries into the same network. > The anycasting functionality happens entirely in the ITR when it > chooses the ETR. You could try to do this in LISP, APT or TRRP, where the mapping for one EID has multiple ETR addresses, but I foresee practical problems I will discuss below. I can't do this with Ivip as currently conceived, since the mapping for each micronet is a single ETR address. Still, I agree that anycast and disaster recovery are uses of the network we would very much like to do in a more scalable fashion than is currently possible. With OITRDs / PTRs we can make the core-edge separation scheme work for packets from all hosts - ideally with the OITRDs and PTRs widely scattered around the Net and therefore on-path, or close to on-path with the sending host to ETR path. > The ETR's character is that it has only one attachment in the > topology, not multiple attachments. Giving the ETR multiple > attachments would defeat the purpose. > > As for anycast ETRs, I haven't thought of a single sensible use case. I agree. I explored anycast ETRs in my previous messages and couldn't find a use for them which was any better than anycast hosts with ordinary BGP. >> Core-edge elimination >> >> Could be made to work, but is more complex than the >> conventional approach and is just as bad in terms of >> scaling. However, if the Internet was somehow converted >> to a core-edge elimination approach, it would be impossible >> to do the conventional BGP approach, in which there was no >> distinction between identifier and locator (the IP address >> means both). > > Strategy B is like strategy A except we replace layer 4 with a > protocol suite that handles the ITR/ETR functionality internally, > eliminating the need for ITRs and ETRs. I think this is a nifty way of describing it. A core-edge elimination architecture load every host with many more functions in its stack, not least crypto stuff to securely establish other hosts' true identity (Identifier). Also, AFAIK, no useful work can be done (at least with HIP) before there have been several packet exchanges to establish this identity. What is the equivalent of a single, ad-hoc, UDP packet in HIP? Doesn't it involve the two hosts fussing around before they can send a traffic packet, or trust its contents? I will write a fuller critique later, but wile I think the core-edge elimination division of labor is conceptually elegant, I think it places too much state, too much complexity etc. in the host. Also, especially for slow, expensive, radio links, the management traffic setting up these host-to-host associations will be economically expensive and will be slow, especially with higher packet loss rates on the radio link. > The anycasting decision > happens in the originating host, after which the packet travels (or > fails to travel) to one specific network attachment associated with > the destination. The origin may have selected from be different > attachments for the same host or it could have been attachments for > multiple hosts all of which are capable of responding to the service > request. OK, converting this into other terms, as I think suit a core-edge elimination scheme: The originating host (assume for the moment a unicast host = unique Identifier and unique Locator) may have selected from different Locators for the various remote hosts which perform the same function in a manner analogous to anycast: by having those remote hosts all having the same Identifier ... This requires multiple physical hosts to have the same identifier. Is this kosher in any core-edge elimination scheme to date? or it could have been attachments (Locators) for multiple hosts (each host has a unique identifier, so this is not really "anycast") all of which are capable of responding to the service request. The second half sounds like some mid-level stack arrangement. For instance, the application and higher part of the stack in host A, (assume unicast: a single host A with a single identifier A) is communicating with what the stack and application treat as a single, similar, (implicitly unicast) host B . . . but which is in fact implemented at a mid level in the stack by choosing one of multiple hosts with unique Locators and unique Identifiers, none of which are "B" but which somehow work together so they behave as a host with Identifier B. That sounds like it would require additional complexity in all hosts, including host A which never itself takes part in a set of "~anycast" hosts, but may sometimes need to communicate with such a set, presumably in a way which makes them resemble a single host as far as applications are concerned. I am sure it could be done - but it would involve more complexity in all hosts. >> The main, perhaps only, reasons people are interested in >> conventional BGP-based host anycast are (AFAIK) as follows. >> These are all dependent on the normal behaviour of the BGP >> routing system. >> >> a - "Shortest" (generally, in BGP terms) path to the nearest >> router which advertises the prefix of its anycast host. > > This is the "speed" case. The premise is that the closest one will > have the shortest round trip time and the lowest probability of packet > loss. Ahh - yes, not just speed but lower packet loss. >> b - Automatic failure recovery as long as the router stops >> advertising the prefix if the one or more hosts using >> this prefix dies. If so, the other BGP routers will >> soon get the packets which would have gone to this one. > > Yes. > >> c - Load sharing over many hosts, in geographically and >> topologically diverse sites, which gives the system >> a high capacity and a great resistance to failure >> without involving DNS in any way, since it always >> responds to the one IP address. This is also extremely >> important as a way of achieving high total bandwidth >> to survive DoS attacks with floods of incoming packets. > > Yes. Point being that while DNS would work for this in theory, in > practice it runs into trouble. > >> It may also be desired and possible to: >> >> d - Imply something about sending host location from which >> of the anycast BGP routers got the packet (as you are >> doing with your project which you mentioned at the end >> of msg04894) - but AFAIK this information is not used for >> the most prominent BGP-based host anycast usage: root >> nameservers. > > I suppose that's possible though I'm not sure what the use case is. OK - thanks for confirming this. > It seems like much of the rest of what you wrote here is based on the > faulty premise of having some kind of anycast ETRs. I agree they are faulty - I tried pretty hard to find a use for them and found none. > The only response > I can offer is: of course anycast ETRs don't make sense. I agree. > Anycast ITRs make sense. Yes - Ivip Open ITRs in the DFZ or LISP Proxy Tunnel Routers. > ITRs making anycast decisions while resolving the map make sense. They might . . . > But ETRs are supposed to be single points of attachment in the > network topology; it wouldn't make any kind of sense for them to be > anycast. I haven't found a use for anycast ETRs yet - and I probably won't, so I tend to agree. But we are designing these things and we can do what we like with our own creations. How would you achieve the goals agreed to above via LISP, APT or TRRP having the ITR choose between multiple ETR addresses? Current BGP-based anycast uses the natural behaviour of BGP routers to cause the packet to be forwarded to the "closest" border router which advertises the most specific matching prefix. BGP routers do this naturally - it is not a special function they work hard to achieve. Let's forget goal 'd' above for now - though it will be achieved fine without the sending host needing to do anything, just by the "anycast" or "disaster recovery" system knowing which site the packet was received at. Goal 'c' spreading the load over multiple servers, can easily be done with LISP. This includes having the servers physically scattered at different points in the Net. Simply have a number of ETR addresses, and the ITR choosing randomly from them. Still, the ITR has to somehow figure out which of these ETRs is working and (if this is a separate thing, which it not if the ETRs are in the end-user networks, as LISP currently assumes) which such ETRs can reach the destination host. LISP has some ways of doing this, but I think they are messy and expensive - which is why Ivip ITRs do not attempt to test reachability to the ETR, or through the ETR to the destination network. Part of how a LISP ITR might determine reachability might be testing to see if the ETR address has an entry in the FIB. It will have an entry if the ITR's RIB thinks it has a path to the BGP router (only one such router, since we have no anycast ETRs) which the RIB thinks is advertising the most specific prefix matching this ETR address. That will solve some problems, but it doesn't establish that the ETR is reachable. (But what of an ITR which is not actually a router? It would send a packet to the address in question and the packet may never get to any border router, since the prefix may not be advertised at all in BGP. Then, ideally, the ITR would get an ICMP destination host/network unreachable message. Then it would choose another ETR instead - but has it kept the packet? Probably not. How can it secure the ICMP message to stop DoS attacks? The traffic packet needs to carry a unique nonce in its LISP header, so there has to be a LISP header and a UDP header in front of that - but the ICMP spec doesn't ensure routers will actually send back enough of the original packet to carry this nonce . . . it only needs to send back the UDP header, IIRC, which precedes the LISP header.) Goal 'b' would probably be achieved by a suitable solution to the above problem - but I am yet to see it has been robustly and efficiently solved. How would a LISP, APT, or TRRP ITR achieve goals 'a'? This depends on BGP "distance". If the ITR is a BGP router, in the DFZ, then it will have the full DFZ routing table for its specific point in the network, and it will have "distance" metrics for each of its best paths. So the ITR part of the router could interrogate the RIB and figure out which of the various ETR addresses in the mapping has the BGP advertised prefix which is "closer". That is costly, but would work, for an ITR which is a full DFZ router, as would be PTRs. However it won't work at all for ITRs which are any of: Single homed BGP routers (not carrying the full DFZ table). Internal routers (no idea of the DFZ table). An ITR in a device which is not a router. So I disagree with your proposal that it is possible to use multiple ETR addresses in LISP, APT or TRRP to implement one of the crucial goals which is routinely achieved, without any extra effort, in conventional BGP-based anycast (which is admittedly unscalable). How would I do this stuff - the equivalent of BGP-based anycast or a similar function for the Disaster Recovery arrangement - with Ivip as currently conceived? Ivip can't do load balancing over multiple servers at different parts of the Net if they are all on the same IP address. It is necessary to do round-robin DNS for a given FQDN, such as to cause Correspondent Hosts (CH's as I will refer to the ordinary client host) to choose at random one of the IP addresses and stick with it for the session. Those multiple IP addresses are all SPI addresses and each one is in a separate micronet. If the servers are in one location, the load balancing will be between two or more ETRs in different ISPs, so the end-user network changes the mapping of each micronet to one ETR or the other, spreading the load accordingly. The same idea works fine if there are multiple servers in different physical locations. Round-robin SPI Separate addresses, each ETR for each assumed to be in server site its own micronet 3.3.3.0 45.68.23.1 3.3.3.1 3.3.3.2 32.67.21.7 3.3.3.3 3.3.3.4 21.62.92.7 3.3.3.5 3.3.3.6 65.98.21.4 3.3.3.7 With 800 active CHs, on average 100 chose a particular one of the 3.3.3.x SPI addresses which are returned by DNS. Each server site has hosts which respond to every address. Now by sending mapping changes, the end-user network can steer the overall burden of work in increments of ~1/8 of the total burden to its four sites. The most obvious way is the first two micronets are mapped to the first ETR address, the 3rd and 4th SPI addresses to the 2nd ETR etc. If a server site died, or became too busy, a real-time mapping change could direct one of both of the micronets to another server site. Assuming session-based protocols and the servers not sharing the session state, this switch would break sessions - but with an outage or overload, some or many or the sessions were dead anyway. Each site could be multihomed - and so could have two ETRs. Then it is possible to load-balance the inbound traffic for each site too. This looks like a good solution for goal 'c' - and with real-time control by the network administrators and/or some automated load balancing software it may well be more useful than the load balancing which is possible with LISP, APT or TRRP. Goal 'b' is achieved in the same way. The end-user network sends (or has a probing company send on its behalf) a mapping change if one of the sites goes down. The probing company would actually control the mapping and as long as all sites were found to be reachable, it would take instructions from the end-user network itself to achieve load balancing. More on this in a new section: "The actual source of mapping changes": http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf But how would Ivip achieve something like goal 'a' - having the packets sent to the "closest" operational ETR? Ivip can't do this at present - except by using anycast ETRs which suck and have no scaling benefits over conventional BPG approaches. But neither can LISP, APT or TRRP, unless perhaps the ITR is in the DFZ - and most ITRs will internal routers. How could a host in a core-edge elimination scheme do all this? I figure it could achieve 'c' and 'b' OK, but it has no access to the BGP information it needs to do anything like 'a'. So can we solve this problem by adding to all the schemes some kind of network service (maybe always available from some *anycast* address) by which an ITR or a core-edge elimination scheme host could send one or more IP addresses and get back some relative metrics about which one was "closer"? If we could do this, then we could do Disaster Recovery with generally optimal path-lengths (and therefore shortest times and lowest packet loss rates) as part of the scalable routing solution in a *scalable* fashion: that is without pushing more prefixes into the DFZ and in a responsive manner. I think this is well worth considering. It is a new idea to me, but it could be done, I am sure. Just have a bunch of "Distance Servers", or routers, or whatever, scattered around the local network, such as one or a few in every ISP network, or every end-user network, and or every small section of some big ISP or end-user network. Each one has its own global unicast IP address too. Each one also responds to some predetermined IP address in an "anycast" fashion. (Alternatively, we need some autoconfig arrangement for every ITR to find it.) The Distance Server has been configured to communicate with the nearest DFZ router. (Further work required if there are two DFZ routers and the IGP steers some packets to one and others to another.) Maybe the Distance Server simply pretends to be a BGP router and gets a full, continually updated, copy of the DFZ router's routes, complete with the lengths of all the routes it currently has. The Distance Server could act in some ways like a BGP router and so pass this on to other Distance Servers, in order not to load the DFZ router. Then when this Distance Server gets a query from an ITR about some ETR address, it matches it to the most specific BGP route and returns the "BGP distance", which is the number of ASes in that route's announcement. A nonce in the query is returned in the reply in order to secure the system. UDP queries and responses will be fine, so multiple local Distance Servers can be anycast. ITRs (or hosts in the case of core-edge elimination systems) would query Distance Servers with one or more ETR addresses and so be able to choose which ETR address was apparently "closer". This would work fine for any system in which a single EID's mapping included multiple ETR addresses: LISP, APT and TRRP. But what of Ivip, where there is currently a single ETR address for every micronet? The most obvious approach is to extend Ivip's mapping to an arbitrary number of ETR addresses. That could be done. Another approach would be to retain a single "ETR" address, but to make a certain range of addresses have a special meaning. These would be outside the global unicast address range, and so could never actually be ETR addresses. They would index into a separate set of mapping information and return multiple ETR addresses. Either way, Ivip could be modified to have multiple ETR addresses for each micronet. Ivip ITRs are already in communication with at least one local full database Query Server (QSD) perhaps via one or more optional caching query servers (QSCs), which I will ignore for now. The QSD can incorporate the functions of the Distance Server. So the QSD, directly or indirectly, gets DFZ route "distances" for whichever ISP or end-user network it is located within. As before, the ITR has a packet to send which it doesn't know the mapping of. It sends the destination address with a nonce to its local QSD. As before, if the QSD's copy of the mapping database for this micronet contains an ordinary ETR address, this is what is sent back to the ITR, along with the starting and ending address of the micronet and a caching time. (Within the caching time, the QSD will tell the ITR if the mapping for any of this micronet changes, to a new ETR address or if the micronet is split into multiple smaller micronets.) If the QSD finds an ETR address in the special range, then it looks up some other part of its mapping database to find the one or more real ETR addresses which correspond to this special ETR address. Then, via looking into its Distance Server sub-function, it determines which of these is "closest". Then it sends that ETR address to the ITR. This involves no extra complexity in the ITR, but adds some to the QSD. This sounds like a good division of labor. It also is in keeping with APT's Default Mapper (APT's equivalent of the QSD) which makes decisions for ITRs based on multiple ETR addresses, and only sends the answer to the ITR. This looks like a perfectly good way of enabling Ivip to achieve goal 'a' of the anycast / Disaster Recovery goals. It involves two extra sets of complexity and storage in the QSD, but that is fine. APT could do the same thing - integrated "Distance Server" functions into the Default Mapper and thereby have suitable mapping options instructing the DM to choose the "closest" ETR. LISP-ALT and TRRP have no local query server. So they would need a new network element: a Distance Server. The "Distance Server" could be integrated into LISP-ALT's Map Resolver function. - Robin http://www.ietf.org/mail-archive/web/rrg/current/msg04901.html > You have two sites: primary in New York (NY), disaster recovery in > Tokyo (T). Each site has one Internet link, one router and one > server. > > Sprint provides the Internet link to NY. Cogent provides the > Internet link to T. > > The NY router announces 1.2.3.0/24 via BGP at normal priority. > > The T router announces 1.2.3.0/24 after prepending the AS# 3 times, > causing most of the other routers on the Internet to consider the T > router more distant than the NY router. > > The two sites are normally linked together with a VPN traveling > over the Internet using 5.6.7.8 on one side and 8.7.6.5 on the > other, addresses provided by the respective ISPs. This functions as > if there was a private line directly connected between the two > routers. > > Ordinarily, the T router sends packets for 1.2.3.4 over the VPN to > the NY router while the NY router sends packets for 1.2.3.4 to the > NY server. > > If the VPN fails, the T router will send packets for 1.2.3.4 to the > T server instead. > > If the NY server fails, the NY router will send packets for 1.2.3.4 > over the VPN to the T router and the T router will send packets for > 1.2.3.4 to the T server. > > Both servers answer to 1.2.3.4. Both return identical content. [ Sprint 1.2.3.4 [ R2------R5----------[RNY]------------(SNY) [ / \ | ! 5.6.7.8 [ SH1--->R1 R4---R6 ! [ \ / | ! VPN (really via R5, R6, R4, R3, [ R3------R7 ! R9, R10) | ! | 1.2.3.4 ! 8.7.6.5 { R9------R10---------[RT]-------------(ST) { / \ / { SH2----R12--R13-/ { \ / { Cogent R14 From rw@firstpr.com.au Thu Apr 23 03:14:06 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216983A7217 for ; Thu, 23 Apr 2009 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAJKKr82YQQb for ; Thu, 23 Apr 2009 03:14:05 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 54AF13A71C8 for ; Thu, 23 Apr 2009 03:14:05 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 76B21175B4A; Thu, 23 Apr 2009 20:15:22 +1000 (EST) Message-ID: <49F03F43.5040101@firstpr.com.au> Date: Thu, 23 Apr 2009 20:13:23 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: RRG References: <3c3e3fca0904190913s72f519a8p3cab3ec22e73d379@mail.gmail.com> <49EB54EC.5060801@tony.li> <3c3e3fca0904191632n1b93b9fy48f3b94f4ce518bd@mail.gmail.com> <49EC0200.9060600@tony.li> <3c3e3fca0904201453i614ea451h58f09d50b09365c4@mail.gmail.com> <49ED604C.2020407@tony.li> <3c3e3fca0904211453pe3b51as1c282a495fa274d2@mail.gmail.com> <49EE9718.9060100@firstpr.com.au> <49EFEA00.9080403@firstpr.com.au> <3c3e3fca0904222205idf6874ajed7db783b8e34495@mail.gmail.com> <49F02B5E.20003@firstpr.com.au> In-Reply-To: <49F02B5E.20003@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Adding a Distance Server for anycast / disaster recovery X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 10:14:06 -0000 Olivier Bonaventure mentioned on the LISP list that the ALTO (Application-Layer Traffic Optimization) WG is working on something related to the "Distance Server" idea: http://tools.ietf.org/wg/alto/ http://www.ietf.org/html.charters/alto-charter.html http://tools.ietf.org/html/draft-ietf-alto-problem-statement-00 http://tools.ietf.org/html/draft-ietf-alto-reqs-00 I will read up on this. - Robin From swb@employees.org Thu Apr 23 04:06:44 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946EE3A7265 for ; Thu, 23 Apr 2009 04:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPh9CMisK9K0 for ; Thu, 23 Apr 2009 04:06:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7372228C174 for ; Thu, 23 Apr 2009 04:06:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,235,1238976000"; d="scan'208";a="42469142" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2009 11:07:56 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NB7usA025497; Thu, 23 Apr 2009 07:07:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3NB7uTU008063; Thu, 23 Apr 2009 11:07:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 07:07:55 -0400 Received: from cisco.com ([10.86.249.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 07:07:55 -0400 Date: Thu, 23 Apr 2009 07:07:47 -0400 From: Scott Brim To: Tony Li Message-ID: <20090423110747.GA42172@cisco.com> Mail-Followup-To: Scott Brim , Tony Li , rrg@irtf.org References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> <20090420193158.GH34560@cisco.com> <49EDEA85.6070307@tony.li> <20090421160414.GQ70118@cisco.com> <49EF3B04.4040901@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EF3B04.4040901@tony.li> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 23 Apr 2009 11:07:55.0516 (UTC) FILETIME=[C0C9B3C0:01C9C403] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:06:44 -0000 Excerpts from Tony Li on Wed, Apr 22, 2009 08:43:00AM -0700: > > Hi Scott, > >> Oh. Then I think we actually agree on procedure, but let's make it >> explicit: >> >> The goal is to figure out which classes of solutions are >> appropriate, and one input to that is to look at the implications >> each solution class has on properties of identifiers. > > Agree. > >> Some of us have been saying that you can't do "properties of >> identifiers" in general, you have to talk about which kinds of >> identifiers, in which context. I guess you agree. If so, sorry, I >> hadn't understood. > > No, I think it's reasonable to talk about the classes of solutions > and the reasonable properties of the (host, interface, stack, ...) > identifier that is bound to the locator within each class. This demonstrates my point: You are assuming the identifier of interest is one that is "bound to the locator", i.e. the thing that just the locator gets you to is what you want to describe in this exercise. In this case one could just as easily envision having identifiers of interest name things at a finer level of granularity, where a locator gets you to a particular device (possibly virtual) but initial packets must include both locator and identifier, so that when the packet arrives at the device named by the locator, the device can figure out which particular communication endpoint (named by the identifier) you want to talk to. The "identifier that is bound to the locator" could name the device but would not be interesting to us and would not be used in normal communications, only by device management. I'm happy to look at properties for identifiers that are "bound to locators" but let's not assume that each class has such things. Also some classes do not say anything about endpoint identifiers at all. >> Yes, local identifiers are worthy of discussion. > > So I think that local identifiers are acceptable, but solutions > should always also provide global identifiers. The decision of > which to use should be left to the end station/stack/user. > >> Again, I would like the process to be explicit, otherwise we will >> probably ramble around and it will be hard to agree on whether we >> have reached any agreements. Do you want to start specifically >> with the class of solutions that includes ILNP, look specifically >> at "host" identifiers, and look at >> implications/possibilities/requirements? That would be fine with >> me. > > Again, I don't want this to devolve into another partisan bickering > match. I would much rather talk about general classes (ala Bill's > different strategies). Well, let's try it but we'll have to watch out for implicit assumptions. ... and I beg people to come up with different names than "B.3". I'll never remember the mappings from the outline headings to what they actually describe. It's like referring to a paper by its footnote reference, e.g. [17]. Scott From irtf@tonistoev.info Thu Apr 23 06:52:57 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB43D3A71FE for ; Thu, 23 Apr 2009 06:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0BgmBypW6AZ for ; Thu, 23 Apr 2009 06:52:57 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id C875B3A6A69 for ; Thu, 23 Apr 2009 06:52:56 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LwzNT-0007au-IK for rrg@irtf.org; Thu, 23 Apr 2009 16:54:11 +0300 From: Toni Stoev To: IRTF RRG Date: Thu, 23 Apr 2009 16:54:08 +0300 User-Agent: KMail/1.9.9 References: <200904220242.32513.irtf@tonistoev.info> In-Reply-To: <200904220242.32513.irtf@tonistoev.info> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200904231654.08822.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] Numeric fully qualified identifier X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:52:57 -0000 Bi-directional numerical DNS Let us imagine a simple numeric fully qualified identifier: p.n where p and n are positive integers. p is the number of a provider issuing node numbers, n is the number of a node, issued by that provider. The role of p.n is to identify the specified node on the general network. Usage of this identifier for connection initiation I like to call inicast: Knowing identifier p.n we are heading for the node it identifies. Luckily, we've got our own identifier p.o with the same provider p. So, we send initial packet for p.n to p, we know p's locator. p knows locator of p.n and relays the packet that way. Duly, p.n receives the packet with our locator. Ready to communicate directly. This longest prefix match is also applied in cases with different providers and/or more levels. To know current locators, adjacent levels keep each other informed about any changes. On Wednesday 22 April 2009 02:42:32 Toni Stoev sent: > Summary > > I am offering a solution for identifier. > > The solution is a numeric-only variation of FQDN with mutual locator cognition between adjacent levels. > Innermost level numbers can be negotiated instead of assigned. > > > Let us first see conformance of this solution, and then consider any inherited restrictions. > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From pfrejborg@gmail.com Thu Apr 23 08:22:41 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A7A3A7293 for ; Thu, 23 Apr 2009 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHpAdIXcFlm3 for ; Thu, 23 Apr 2009 08:22:40 -0700 (PDT) Received: from mail-qy0-f123.google.com (mail-qy0-f123.google.com [209.85.221.123]) by core3.amsl.com (Postfix) with ESMTP id 5FB663A6928 for ; Thu, 23 Apr 2009 08:21:45 -0700 (PDT) Received: by qyk29 with SMTP id 29so1192909qyk.15 for ; Thu, 23 Apr 2009 08:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hgq5VqCucwPR0WbfKEmt9psI2k+kQA452CwLRSSPTis=; b=be4M9nPSC6JlwHHLzSXr8ZaqwNOozJ2eqxlFYf2Q+IUunEMtDWg5Kr/RGht/SfXLSu /IOEEFocnx25oTATxFpyc5AmKvKdUd7Igj3SFhC04dF9WRYn2+f0X6m1U94srQ+AwKb3 Fd8cHItve/AjsoPc+ySg6uQeBAmdn2QMK6tO4= 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 :content-type:content-transfer-encoding; b=TyAkVC5StWAaAbJCfuGsgEeUZ+k2UQWtAl5suTQcyAH4UADLTpHn+HcToxJrKfJXch 6gTkRBznXxL1YIjoRjTYTsKcSrpx7CF0kon/d/k9EuUbShI1j2IIaKkin0P4HddtvhOy tpTPuctSp+ihvHsOOPkid+DazeYnnoUpq05dQ= MIME-Version: 1.0 Received: by 10.229.84.201 with SMTP id k9mr572084qcl.84.1240500182556; Thu, 23 Apr 2009 08:23:02 -0700 (PDT) In-Reply-To: <20090423110747.GA42172@cisco.com> References: <49E559E0.2090302@tony.li> <49E66B2E.3000503@gmail.com> <49E965C0.5020503@tony.li> <20090420193158.GH34560@cisco.com> <49EDEA85.6070307@tony.li> <20090421160414.GQ70118@cisco.com> <49EF3B04.4040901@tony.li> <20090423110747.GA42172@cisco.com> Date: Thu, 23 Apr 2009 18:23:02 +0300 Message-ID: <5bc37fd40904230823xcde8de1w3d889581ffb19d2e@mail.gmail.com> From: Patrick Frejborg To: Scott Brim , Tony Li , rrg@irtf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [rrg] Next topic: properties of identifiers X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:22:41 -0000 Hi Scott and Tony, On Thu, Apr 23, 2009 at 2:07 PM, Scott Brim wrote: > Excerpts from Tony Li on Wed, Apr 22, 2009 08:43:00AM -0700: >> >> Hi Scott, >> >>> Oh. =A0Then I think we actually agree on procedure, but let's make it >>> explicit: >>> >>> =A0 The goal is to figure out which classes of solutions are >>> =A0 appropriate, and one input to that is to look at the implications >>> =A0 each solution class has on properties of identifiers. >> >> Agree. >> >>> Some of us have been saying that you can't do "properties of >>> identifiers" in general, you have to talk about which kinds of >>> identifiers, in which context. =A0I guess you agree. =A0If so, sorry, I >>> hadn't understood. >> >> No, I think it's reasonable to talk about the classes of solutions >> and =A0the reasonable properties of the (host, interface, stack, ...) >> identifier that is bound to the locator within each class. > > This demonstrates my point: You are assuming the identifier of > interest is one that is "bound to the locator", i.e. the thing that > just the locator gets you to is what you want to describe in this > exercise. =A0In this case one could just as easily envision having > identifiers of interest name things at a finer level of granularity, > where a locator gets you to a particular device (possibly virtual) but > initial packets must include both locator and identifier, so that when > the packet arrives at the device named by the locator, the device can > figure out which particular communication endpoint (named by the > identifier) you want to talk to. =A0The "identifier that is bound to the > locator" could name the device but would not be interesting to us and > would not be used in normal communications, only by device management. > > I'm happy to look at properties for identifiers that are "bound to > locators" but let's not assume that each class has such things. =A0Also > some classes do not say anything about endpoint identifiers at all. > I agree with Scott here. For 3.3.2.2. Identifier variants B2a Each host has a single identifer to which the locators are attached. This identifier is used by the layer-4/5 and higher protocols to compose the SID. IMHO, the identifier should not be bound to the locator. The reason is that you could create an Endpoint Layer - as discussed in the paper "Breaking Up the Transport Logjam=94 from http://conferences.sigcomm.org/hotnets/2008/papers/HotNets2008proceedings.p= df - between the network and transport layer in the stack. Then if the identifier is used in a similar way as a HTTP cookie (RFC2965) in the Endpoint Layer you might create a generic session state machine for every application when the underlying locator(s) are changing. So when a mobile client is changing its attachment point in Internet any application session (not only HTTP) could be continued though the locator(s) has changed - if the timers are allowing it. Another place where you could use the "Endpoint cookie"=3Didentifier is in multihoming. A site has two separate service providers that are offering two different Area Locators for the server that is using one Local Locator. In DNS the server have two records, ALOC1:LLOC and ALOC2:LLOC. The client is choosing ALOC1:LLOC for communication, session is established and the identifiers (Endpoint cookies) are exchanged but at some stage the session via ALOC1 fails. After a while the client notice that the session has stalled but in the DNS cache there is a second entry, ALOC2:LLOC. So the client stack decides to try ALOC2:LLOC instead and the connection is re-established with the help of the identifier (Endpoint cookie). Security issues arises, need to look into that and if somebody has ideas feel free to make proposals. -- patte From irtf@tonistoev.info Fri Apr 24 05:18:54 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36AD3A7378 for ; Fri, 24 Apr 2009 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba-qsmVvDpbk for ; Fri, 24 Apr 2009 05:18:53 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 2DA8D3A733C for ; Fri, 24 Apr 2009 05:18:52 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LxKO0-0000ET-LR for rrg@irtf.org; Fri, 24 Apr 2009 15:20:08 +0300 From: Toni Stoev To: IRTF RRG Date: Fri, 24 Apr 2009 15:20:06 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904241520.06338.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Procedure: ID X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 12:18:54 -0000 Do we need an Identity Research Group to explore various identity appplications or are we still focused on routing aspect? From swb@employees.org Fri Apr 24 07:53:32 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0753A688F for ; Fri, 24 Apr 2009 07:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhsu8gcjmB+A for ; Fri, 24 Apr 2009 07:53:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 827CE3A6836 for ; Fri, 24 Apr 2009 07:53:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1238976000"; d="scan'208";a="42643791" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2009 14:54:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3OEsnmQ012528 for ; Fri, 24 Apr 2009 10:54:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OEsnZ5000750 for ; Fri, 24 Apr 2009 14:54:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:54:48 -0400 Received: from cisco.com ([10.86.255.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:54:47 -0400 Date: Fri, 24 Apr 2009 10:54:37 -0400 From: Scott Brim To: rrg@irtf.org Message-ID: <20090424145437.GA83311@cisco.com> Mail-Followup-To: Scott Brim , rrg@irtf.org References: <200904241520.06338.irtf@tonistoev.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904241520.06338.irtf@tonistoev.info> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 24 Apr 2009 14:54:48.0095 (UTC) FILETIME=[9CEE2AF0:01C9C4EC] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [rrg] Procedure: ID X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:53:32 -0000 Excerpts from Toni Stoev on Fri, Apr 24, 2009 03:20:06PM +0300: > Do we need an Identity Research Group to explore various identity > appplications or are we still focused on routing aspect? Once upon a time "locator/identifier separation" referred to something that was expected to happen very close to IP forwarding -- most likely with whole-host identifiers carried in every packet. Our thinking evolved some, through the namespace research group and so on, and now we have more sophisticated ideas of what needs to be identified -- and even what kinds of identification functions are involved -- but the problem affects a lot of areas of the IRTF/IETF and there is no natural home for it right now. From irtf@tonistoev.info Fri Apr 24 10:13:07 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4F53A6B8F for ; Fri, 24 Apr 2009 10:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD4wLzHdxmvr for ; Fri, 24 Apr 2009 10:13:07 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id C48C63A684C for ; Fri, 24 Apr 2009 10:13:06 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LxOyj-00023u-Pd for rrg@irtf.org; Fri, 24 Apr 2009 20:14:21 +0300 From: Toni Stoev To: IRTF RRG Date: Fri, 24 Apr 2009 20:14:19 +0300 User-Agent: KMail/1.9.9 References: <200904241520.06338.irtf@tonistoev.info> <20090424145437.GA83311@cisco.com> In-Reply-To: <20090424145437.GA83311@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904242014.19573.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] Procedure: ID X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:13:07 -0000 On Friday 24 April 2009 17:54:37 Scott Brim sent: > Excerpts from Toni Stoev on Fri, Apr 24, 2009 03:20:06PM +0300: > > Do we need an Identity Research Group to explore various identity > > appplications or are we still focused on routing aspect? > > Once upon a time "locator/identifier separation" referred to something > that was expected to happen very close to IP forwarding -- most likely > with whole-host identifiers carried in every packet. Our thinking > evolved some, through the namespace research group and so on, and now > we have more sophisticated ideas of what needs to be identified -- and > even what kinds of identification functions are involved -- but the > problem affects a lot of areas of the IRTF/IETF and there is no > natural home for it right now. OK then, I am continuing posting on identity topic, regarding: - connection initiation; - link changeability and node mobility; - distribution of locator data across the general network. > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From HeinerHummel@aol.com Sun Apr 26 00:19:58 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E719B3A6E6B for ; Sun, 26 Apr 2009 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.107 X-Spam-Level: X-Spam-Status: No, score=0.107 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abh0gXOEJMcs for ; Sun, 26 Apr 2009 00:19:58 -0700 (PDT) Received: from imo-m25.mail.aol.com (imo-m25.mx.aol.com [64.12.137.6]) by core3.amsl.com (Postfix) with ESMTP id 08A9E3A6E06 for ; Sun, 26 Apr 2009 00:19:57 -0700 (PDT) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imo-m25.mail.aol.com (v107.10) with ESMTP id RELAYIN3-449f40b84249; Sun, 26 Apr 2009 03:21:40 -0400 Received: from HeinerHummel@aol.com by imo-da01.mx.aol.com (mail_out_v40_r1.5.) id 9.cc3.4455ed38 (39330) for ; Sun, 26 Apr 2009 03:21:09 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sun, 26 Apr 2009 03:21:09 EDT To: rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1240730469" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 205.188.169.199 Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 07:19:59 -0000 -------------------------------1240730469 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We should be honest with respect to Anycast. Particularly strategy C which is in favor of location-based routing by exploiting geographical metrics CANNOT do Anycast in the IETF-classical sense. That would be the squaring of the circle. But there are other ways to deal with Anycast - see the way how emergency calls (911) are handled in ITU-T technology ( I also remember XCAST :-). If other strategies had also their difficulties with Anycast I wouldn't blame either. No one can do magic things. There are several holy cow paradigms in IETF technology. Anycast should be the least holy one. Heiner -------------------------------1240730469 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
We should be honest with respect to Anycast.
 
Particularly strategy C which is in favor of location-based routing= by exploiting geographical metrics
CANNOT do Anycast in the IETF-classical sense. That would be the squa= ring of the circle.
But there are other ways to deal with Anycast - see the way how emerg= ency calls (911) are handled in ITU-T technology ( I also remember XCAST :-).
 
If other strategies had also their difficulties with Anycast I wouldn= 't blame either. No one can do magic things. There are several holy cow parad= igms in IETF technology. Anycast should be the least holy one.
 
Heiner
 
 -------------------------------1240730469-- From bortzmeyer@nic.fr Mon Apr 27 03:58:18 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517AA3A6967 for ; Mon, 27 Apr 2009 03:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx8v4+tl4NVo for ; Mon, 27 Apr 2009 03:58:17 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 1CD4A3A6911 for ; Mon, 27 Apr 2009 03:58:17 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 2913B1C010B for ; Mon, 27 Apr 2009 12:54:34 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 24E291C0020 for ; Mon, 27 Apr 2009 12:54:34 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 19DA9A1D9AE for ; Mon, 27 Apr 2009 12:54:34 +0200 (CEST) Date: Mon, 27 Apr 2009 12:54:34 +0200 From: Stephane Bortzmeyer To: rrg@irtf.org Message-ID: <20090427105434.GA32241@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 10:58:18 -0000 [Disclaimer: not involved with these people.] http://www.pouzinsociety.org/ The Pouzin Society's purpose is to provide a forum for developing viable solutions to the current Internet architecture crisis. Membership is open to qualified members of the networking community, both academic and commercial. Please send an email to info@pouzinsociety.org to introduce yourself and request more information. Through an ongoing series of meetings, collaborative efforts and publications, we seek to guide the emergence of a new network architecture that will support user needs for the decades to come. Please read our Challenge for Researchers and Challenge for Businesses and consider getting involved. Also, see "New society aims to 'save' the Internet" From tme@multicasttech.com Mon Apr 27 04:25:33 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042813A698A for ; Mon, 27 Apr 2009 04:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2wOUFj2uQeu for ; Mon, 27 Apr 2009 04:25:32 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id BCDB43A6840 for ; Mon, 27 Apr 2009 04:25:32 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1AF8B3ADC888; Mon, 27 Apr 2009 07:26:50 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Stephane Bortzmeyer In-Reply-To: <20090427105434.GA32241@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 07:26:49 -0400 References: <20090427105434.GA32241@nic.fr> X-Mailer: Apple Mail (2.930.3) Cc: rrg@irtf.org Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:25:33 -0000 On Apr 27, 2009, at 6:54 AM, Stephane Bortzmeyer wrote: > [Disclaimer: not involved with these people.] > Me neither, but note : John Day Founder Mike O'Dell Founder and Chair Chris Williams Evangelist Regards Marshall > http://www.pouzinsociety.org/ > > The Pouzin Society's purpose is to provide a forum for developing > viable solutions to the current Internet architecture > crisis. Membership is open to qualified members of the networking > community, both academic and commercial. Please send an email to > info@pouzinsociety.org to introduce yourself and request more > information. Through an ongoing series of meetings, collaborative > efforts and publications, we seek to guide the emergence of a new > network architecture that will support user needs for the decades to > come. > > Please read our Challenge for Researchers and Challenge for Businesses > and consider getting involved. > > > Also, see "New > society aims to 'save' the Internet" > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > Regards Marshall Eubanks CEO / AmericaFree.TV From surfer@mauigateway.com Mon Apr 27 16:25:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84E73A7003 for ; Mon, 27 Apr 2009 16:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8evYcHTq7zk for ; Mon, 27 Apr 2009 16:25:17 -0700 (PDT) Received: from omta0110.mta.everyone.net (imta-38.everyone.net [216.200.145.38]) by core3.amsl.com (Postfix) with ESMTP id 2E86B3A6FEA for ; Mon, 27 Apr 2009 16:25:17 -0700 (PDT) Received: from dm25.mta.everyone.net (sj1-slb03-gw2 [172.16.1.96]) by omta0110.mta.everyone.net (Postfix) with ESMTP id 7A09E63897F for ; Mon, 27 Apr 2009 17:02:25 -0700 (PDT) X-Eon-Dm: dm25 Received: by resin15.mta.everyone.net (EON-PICKUP) id resin15.49efb79c.20c36; Mon, 27 Apr 2009 16:26:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20090427162638.D066CEBB@resin15.mta.everyone.net> Date: Mon, 27 Apr 2009 16:26:38 -0700 From: "Scott Weeks" To: X-Eon-Sig: AQLAznNJ9j8u8TYmUQEAAAAB,f3932c5709c4b2b4e452d34831c63704 X-Originating-Ip: [72.234.200.113] Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: surfer@mauigateway.com List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 23:25:23 -0000 --- bortzmeyer@nic.fr wrote: From: Stephane Bortzmeyer http://www.pouzinsociety.org/ ----------------------------------------- It seems to be based on a book I have been reading lately: "Patterns in Network Architecture" by John Day. As I read through it I began to wonder if folks here have read it and how folks feel it relates to the various proposals on the list. scott --------------------- --------------------- --------------------- From tony.li@tony.li Mon Apr 27 20:47:23 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92553A6AD9 for ; Mon, 27 Apr 2009 20:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW7I1KCuQpRm for ; Mon, 27 Apr 2009 20:47:23 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 035303A6A8D for ; Mon, 27 Apr 2009 20:47:22 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id koql1b0030lTkoCABrol0x; Tue, 28 Apr 2009 03:48:45 +0000 Received: from [192.168.1.101] ([24.6.155.154]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id kroj1b0033L8a8Q8QrojpF; Tue, 28 Apr 2009 03:48:44 +0000 Message-ID: <49F5E370.2050900@tony.li> Date: Mon, 27 Apr 2009 09:55:12 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0904221028kfa93629q924cdd369e41791b@mail.gmail.com> In-Reply-To: <3c3e3fca0904221028kfa93629q924cdd369e41791b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] Anycast in the core architecture X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 03:47:23 -0000 Hi Bill, Sorry for the delay. The Real World intervened. ;-) >>> Big important web site = at least one more route >>> in the table. >> Who decides what's big and important? > Historically, the people willing to pay the most money do. Like CNN. Well, we've run that experiment. We've been unable to create a market for routing table slots. Handing them out any other way would seem to get us right back into the problem that we're trying to solve. > Then anycast is by definition unicast since you only pick one > direction. Hence some unicast is anycast. Hence failing to support > anycast in the architecture is a failure to completely support > unicast. ;-) We don't support any unaggregated (or insufficiently aggregated) unicast. What else is new? ;-) Tony From irtf@tonistoev.info Tue Apr 28 01:59:12 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15373A6A6F for ; Tue, 28 Apr 2009 01:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn++9Vrzpj4r for ; Tue, 28 Apr 2009 01:59:05 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 9C73B3A6FEA for ; Tue, 28 Apr 2009 01:59:05 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LyjAt-0001NT-O4 for rrg@irtf.org; Tue, 28 Apr 2009 12:00:23 +0300 From: Toni Stoev To: IRTF RRG Date: Tue, 28 Apr 2009 12:00:21 +0300 User-Agent: KMail/1.9.9 References: <20090427162638.D066CEBB@resin15.mta.everyone.net> In-Reply-To: <20090427162638.D066CEBB@resin15.mta.everyone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904281200.22156.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:59:12 -0000 =46rom readings on site I see no consideration of role-based architecture, = although the NewArch project has been mentioned. Currently I am considering IPC concept versus inter-node communication. Toni Stoev On Tuesday 28 April 2009 02:26:38 Scott Weeks sent: >=20 > --- bortzmeyer@nic.fr wrote: > From: Stephane Bortzmeyer >=20 > http://www.pouzinsociety.org/ > ----------------------------------------- >=20 >=20 > It seems to be based on a book I have been reading lately: "Patterns in N= etwork Architecture" by John Day. As I read through it I began to wonder i= f folks here have read it and how folks feel it relates to the various prop= osals on the list. >=20 > scott >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --------------------- > --------------------- > --------------------- > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From irtf@tonistoev.info Wed Apr 29 16:27:35 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819233A71BF for ; Wed, 29 Apr 2009 16:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4AME4CruTgI for ; Wed, 29 Apr 2009 16:27:34 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 6A4823A695C for ; Wed, 29 Apr 2009 16:27:34 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LzJCu-0007jh-Lp for rrg@irtf.org; Thu, 30 Apr 2009 02:28:52 +0300 From: Toni Stoev To: IRTF RRG Date: Thu, 30 Apr 2009 02:28:51 +0300 User-Agent: KMail/1.9.9 References: <20090427162638.D066CEBB@resin15.mta.everyone.net> <200904281200.22156.irtf@tonistoev.info> In-Reply-To: <200904281200.22156.irtf@tonistoev.info> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904300228.51953.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 23:27:35 -0000 Inter-node communication is winning on me. On Tuesday 28 April 2009 12:00:21 Toni Stoev sent: > From readings on site I see no consideration of role-based architecture, although the NewArch project has been mentioned. > Currently I am considering IPC concept versus inter-node communication. > > Toni Stoev > > > On Tuesday 28 April 2009 02:26:38 Scott Weeks sent: > > > > --- bortzmeyer@nic.fr wrote: > > From: Stephane Bortzmeyer > > > > http://www.pouzinsociety.org/ > > ----------------------------------------- > > > > > > It seems to be based on a book I have been reading lately: "Patterns in Network Architecture" by John Day. As I read through it I began to wonder if folks here have read it and how folks feel it relates to the various proposals on the list. > > > > scott > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------- > > --------------------- > > --------------------- > > _______________________________________________ > > 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 wherrin@gmail.com Wed Apr 29 17:51:43 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD45E3A6A44 for ; Wed, 29 Apr 2009 17:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLajOYO6xr47 for ; Wed, 29 Apr 2009 17:51:40 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 041143A7160 for ; Wed, 29 Apr 2009 17:51:19 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so928691and.37 for ; Wed, 29 Apr 2009 17:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=rh74CXIiaLazdt9au2wYkpCQ5TDRF5oBEHlRO5zrSk8=; b=IU5WBs/9no3i/9EqBZ2/cDKrHmhhXHbXV7ImhaCf4GjOXw+JNElYYZgf1QN83yc9PO NIO4gF6nXeIa1TiAuZaAlRsbBmb3NkT81SJHTCxenYjDXskxXRZt/wsAKSV8PScyXLY3 p+7Yo6E5er5A7HyMWkUbAFUYzt4V4CUVrCbNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=dRPY5qT1xzYgQ9WSqAOWugYI6pQl8TP7WmEswmmfFJZrxoP+K1tBlZacx27BSwcBAQ krddVNnzcntKWs5l04SqasBDW3KrqgnPCQgdfgoMgKKPTfyv7Oy16z6Pjz/yAWo0wqKf AaVkotQDrvHI8kawuyFm3SP/bBIwWZ4JSq/aQ= MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.100.202.8 with SMTP id z8mr1823176anf.151.1241052762263; Wed, 29 Apr 2009 17:52:42 -0700 (PDT) In-Reply-To: <20090427105434.GA32241@nic.fr> References: <20090427105434.GA32241@nic.fr> Date: Wed, 29 Apr 2009 20:52:41 -0400 X-Google-Sender-Auth: c13fa64799856d35 Message-ID: <3c3e3fca0904291752j21ba8525i886295c71a10c66c@mail.gmail.com> From: William Herrin To: rrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 00:51:43 -0000 > http://www.pouzinsociety.org/ As we consider radical changes to the Internet architecture, I would observe that there are a couple of things which are likely to remain true. 1) The communications which leave the host and move through the system will be in the form of packets of data of one sort or another. 2) Each computer in the path between the user's computer and the computer providing the service the user wants to access will receive a packet, consult a data structure to determine if and how to modify, combine and/or split the packet, consult a data structure to determine which next hop(s) to send the packet to, and then transmit the packet. I read http://02d7097.netsolhost.com/images/IPCPaper_Madrid_MattarJD1569144094.pdf . At first it seemed like a strategy-B variant but on a closer read it seems like Day wants to do something different at the forwarding layer too. I'm really not following how the n-layer DIFs go about forwarding packets. Now, I relate to a network protocol in terms of the linear, step-by-step action on individual packets. So, for someone who understands this IPC-based architecture proposal better than I do, I would ask the following question: Would you explain to me how the data packet gets from my machine to Google's machine, listing the changes in the packet at each hop and with particular attention to the nature and contents of the data structures consulted at each hop along the way? Here's an example of what I'm looking for using the the current Internet architecture as a basis: Source: Set the destination IP to Google's server. Consult the routing table which contains two routes: local LAN and Everything Else. Address matches Everything Else. Consult the ARP table for the ethernet MAC address of the next hop for everything else. Modify the packet inserting an Ethernet header at the front containing the destination MAC address of the router for Everything else. Transmit on the Ethernet. First Hop: Pick the destination IP address from the packet. Consult the routing table which contains a few routes including Everything Else. Address matches Everything Else. Consult the ARP table for the ethernet MAC address of the next hop for everything else. Modify the packet replacing the Ethernet header at the front with one containing the destination MAC address of the router for Everything else. Transmit on the Ethernet. Second hop: Repeat. Third hop: Pick the destination IP address from the packet. Consult the routing table which contains 300,000 routes including a route covering multiple servers at Google. Address matches the Google route. Consult the ARP table for the ethernet MAC address of the next hop for Google. Modify the packet replacing the Ethernet header at the front with one containing the destination MAC address of the router for Google. Transmit on the Ethernet. Fourth hop: Repeat. Fifth hop: Repeat. Sixth hop: Pick the destination IP address from the packet. Consult the routing table which contains a few routes including Everything Else. Address matches one of the others, the Google route. Consult the ARP table for the ethernet MAC address of the next hop for Google. Modify the packet replacing the Ethernet header at the front with one containing the destination MAC address of the router for Google. Transmit on the Ethernet. Seventh hop: Repeat. Eighth hop: Pick the destination IP address from the packet. Recognize the destination IP address as myself. Done. Thanks in advance, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From irtf@tonistoev.info Wed Apr 29 18:49:40 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B570B3A68E5 for ; Wed, 29 Apr 2009 18:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+fC2KPCyDK4 for ; Wed, 29 Apr 2009 18:49:40 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id DAA2C3A68AC for ; Wed, 29 Apr 2009 18:49:39 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LzLQQ-0003AM-QO for rrg@irtf.org; Thu, 30 Apr 2009 04:50:58 +0300 From: Toni Stoev To: IRTF RRG Date: Thu, 30 Apr 2009 04:50:58 +0300 User-Agent: KMail/1.9.9 References: <20090427105434.GA32241@nic.fr> <3c3e3fca0904291752j21ba8525i886295c71a10c66c@mail.gmail.com> In-Reply-To: <3c3e3fca0904291752j21ba8525i886295c71a10c66c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904300450.58188.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:49:40 -0000 Hey RRG, In a network of devices why would we route between processes? Toni From irtf@tonistoev.info Thu Apr 30 04:12:04 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7693628C2EF for ; Thu, 30 Apr 2009 04:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXMLaqRhzJNs for ; Thu, 30 Apr 2009 04:12:02 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 359D428C2EA for ; Thu, 30 Apr 2009 04:12:02 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LzUCf-0007tQ-O5 for rrg@irtf.org; Thu, 30 Apr 2009 14:13:21 +0300 From: Toni Stoev Date: Thu, 30 Apr 2009 14:13:20 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline To: IRTF RRG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200904301413.20693.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] More terminology X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:12:04 -0000 I propose basic definitions of a few terms: Term: network Definition: aggregate of interlinked objects Term: node Definition: object engaged in a network Term: link Definition: medium of communication between nodes From tme@americafree.tv Mon Apr 27 04:22:24 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707BB3A6B02 for ; Mon, 27 Apr 2009 04:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPHosxNxV0yC for ; Mon, 27 Apr 2009 04:22:23 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6E3553A6840 for ; Mon, 27 Apr 2009 04:22:23 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id F0D423ADC73B; Mon, 27 Apr 2009 07:23:43 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Stephane Bortzmeyer In-Reply-To: <20090427105434.GA32241@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 07:23:43 -0400 References: <20090427105434.GA32241@nic.fr> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Thu, 30 Apr 2009 08:03:42 -0700 Cc: rrg@irtf.org Subject: Re: [rrg] The Pouzin Society X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:22:24 -0000 On Apr 27, 2009, at 6:54 AM, Stephane Bortzmeyer wrote: > [Disclaimer: not involved with these people.] > Me neither, but note : John Day Founder Mike O'Dell Founder and Chair Chris Williams Evangelist Regards Marshall > http://www.pouzinsociety.org/ > > The Pouzin Society's purpose is to provide a forum for developing > viable solutions to the current Internet architecture > crisis. Membership is open to qualified members of the networking > community, both academic and commercial. Please send an email to > info@pouzinsociety.org to introduce yourself and request more > information. Through an ongoing series of meetings, collaborative > efforts and publications, we seek to guide the emergence of a new > network architecture that will support user needs for the decades to > come. > > Please read our Challenge for Researchers and Challenge for Businesses > and consider getting involved. > > > Also, see "New > society aims to 'save' the Internet" > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > Regards Marshall Eubanks CEO / AmericaFree.TV