From ietf@bartschnet.de Fri Nov 1 03:51:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19621E80B8 for ; Fri, 1 Nov 2013 03:51:20 -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.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6IofprXYpbn for ; Fri, 1 Nov 2013 03:51:15 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABDE21F9F96 for ; Fri, 1 Nov 2013 03:51:13 -0700 (PDT) Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VcCJr-0002gQ-Vx for lisp@ietf.org; Fri, 01 Nov 2013 11:51:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Nov 2013 11:51:11 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> Message-ID: <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:51:20 -0000 Am 2013-10-31 22:36, schrieb Geoff Huston: > On 31 Oct 2013, at 11:57 pm, Dino Farinacci > wrote: > >> Geoff, LISP can route the entire allocated address space (but just not >> requires it to be everywhere). So arguably, LISP can do this at much >> cheaper cost and complexity. >> >> The reason for a dedicated block is similar to why we have an address >> block for IPv4 and IPv6 multicast. To experiment to see if a >> hard-coded block can provide any interesting ideas. > > > On the LISP page I already see LISP using IPv4 and IPv6 blocks for > this experiment. So what have you found out already in terms of > "interesting ideas"? What do you think that a larger block would > inform you that is not possible with the existing block? > > (using /56 end site prefixes a /32 can accommodate 16,777,216 end > sites of course, and even at a 10% utilisation level thats 1.7 million > end sites. So I;'m kinds mystified why a .32 can't tell you about > scaling given that we are talking of the order of 10**6 end sites > within such a block.) The success of the internet is based on experiments which directly scaled into production (like the IP protocol by Cerf and Kahn). Remind the pain we have with the IPv4->IPv6-transition because there are not enough IPv4-addresses for the whole internet-community. If you just go for tiny experiments - like the last 6 years - LISP will never go on air for the internet-community. Currently AVM provides a great chance to go an air by integrating LISP into millions of consumer-routers 'til end of the year and we shouldn't scare them away by a never-ending experiment. If consumers adopt LISP, we'll need 10,000,000,000 prefixes within the next ten years. That means each public PITR will have to announce 10,000,000,000 BGP-routes to itself if consumers use random PI-prefixes from the global unicast space. Multiply the number of public PITRs necessary for such a deployment with 10,000,000,000 BGP-routes each and you'll realize LISP will either break the internet and go into decline or just be a limited luxury for big companies. Using a dedicated PI-prefix which can handle 10,000,000,000 subnets will reduce the BGP-routes a public PITR has to announce to ONE. So using 24 or 32 bits is way to less for the expected growth. I want to ask everyone on the list: Which facts prevent a scaling experiment with the aim of global production state? In my opinion a /16-EID-prefix is perfect for that goal. Best regards, Renne From sander@steffann.nl Fri Nov 1 05:48:50 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4458621E8277 for ; Fri, 1 Nov 2013 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9vu0p1uvtFu for ; Fri, 1 Nov 2013 05:48:49 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 2825721E8235 for ; Fri, 1 Nov 2013 05:45:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 2D52243; Fri, 1 Nov 2013 13:45:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BhX1FObP3Dt; Fri, 1 Nov 2013 13:45:48 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 39F443D; Fri, 1 Nov 2013 13:45:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sander Steffann In-Reply-To: <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> Date: Fri, 1 Nov 2013 13:45:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 12:48:50 -0000 Hi, > I want to ask everyone on the list: Which facts prevent a scaling = experiment with the aim of global production state? In my opinion a = /16-EID-prefix is perfect for that goal. The problem is in that what you describe depends on public PITRs, and we = have seen how badly that worked for 6to4 public relays. Running a public = relay costs money (equipment, maintenance, bandwidth), and when nobody = pays for them then we cannot expect any decent quality. And LISP will be = blamed and seen as an unreliable protocol, just like 6to4. Relying on = public relays is a very bad idea. Now, if some big tier-1 transit networks start running production = quality PxTRs (because PxTRs attract traffic, and their customers pay = for traffic) then I can see some possibilities. If the LISP traffic = volume increases then other networks might also start running PxTRs so = they don't have to pay their transits for it, and then we are getting = somewhere. But as long as 'public PxTR' means 'someone with good = intentions but no real responsibility' then this will be a dangerous = experiment for LISP... Cheers, Sander From ietf@bartschnet.de Fri Nov 1 06:03:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3653611E8301 for ; Fri, 1 Nov 2013 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1+FA0Z+8yFP for ; Fri, 1 Nov 2013 06:03:06 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id AC0AC21E8390 for ; Fri, 1 Nov 2013 05:57:46 -0700 (PDT) Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VcEIL-0005qp-4o; Fri, 01 Nov 2013 13:57:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 01 Nov 2013 13:57:45 +0100 From: Rene Bartsch To: Sander Steffann In-Reply-To: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:03:12 -0000 Am 2013-11-01 13:45, schrieb Sander Steffann: > Hi, > >> I want to ask everyone on the list: Which facts prevent a scaling >> experiment with the aim of global production state? In my opinion a >> /16-EID-prefix is perfect for that goal. > > The problem is in that what you describe depends on public PITRs, and > we have seen how badly that worked for 6to4 public relays. Running a > public relay costs money (equipment, maintenance, bandwidth), and when > nobody pays for them then we cannot expect any decent quality. And > LISP will be blamed and seen as an unreliable protocol, just like > 6to4. Relying on public relays is a very bad idea. > > Now, if some big tier-1 transit networks start running production > quality PxTRs (because PxTRs attract traffic, and their customers pay > for traffic) then I can see some possibilities. If the LISP traffic > volume increases then other networks might also start running PxTRs so > they don't have to pay their transits for it, and then we are getting > somewhere. But as long as 'public PxTR' means 'someone with good > intentions but no real responsibility' then this will be a dangerous > experiment for LISP... That's an important argument. We shouldn't rule out public PITRs because of the huge traffic to be expected, provide a /16 EID-block and hope it will attract operators of backbones and internet exchanges. Maybe we can define some Quality of Service rules for PITRs to discourage fun installations with low quality. Best regards, Renne From farinacci@gmail.com Fri Nov 1 07:36:44 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943721E83DF for ; Fri, 1 Nov 2013 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=1.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH0HUxTICwnk for ; Fri, 1 Nov 2013 07:36:23 -0700 (PDT) Received: from mail-gg0-f169.google.com (mail-gg0-f169.google.com [209.85.161.169]) by ietfa.amsl.com (Postfix) with ESMTP id D430521E80F0 for ; Fri, 1 Nov 2013 07:35:59 -0700 (PDT) Received: by mail-gg0-f169.google.com with SMTP id b5so1530309ggb.14 for ; Fri, 01 Nov 2013 07:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OSF1ck8P91scUaBICc2wu8XFPBg82j9diUmvD72Wo6Q=; b=zKmJAWL0+Cr2dRRO/omg5EAbbSXQ5EzuhsIcH9XlCywn2hMayx/8pKd/gIYBKokwYd HI+o5zyAzY5LOhlA0wT5Yrwyd8f+Z6bgqMSDTiEDqrwb4ICVr3XMbal4RF6T7jFzQwg+ tjfGhSRJBy59xRbo1We6dp4dH5CU5EE9OxA/fUE7zc19B8Gwc5S0NYtif/dapgcQK128 sFC+Aiw3y1u2XQLBw4NBf7uJeFJneEb/73u05oQOPGbIKcNAKvVGyX8SxPtaW2Cjo+73 hjTmqm3O+mQNWggGVF9wAs/ci05ENHCoa1lzQjzXgcPBzn3FxP+k49NFq8geIFnyCdlc RZvA== X-Received: by 10.236.220.40 with SMTP id n38mr695449yhp.85.1383316524176; Fri, 01 Nov 2013 07:35:24 -0700 (PDT) Received: from [172.20.10.3] (mobile-198-228-198-132.mycingular.net. [198.228.198.132]) by mx.google.com with ESMTPSA id h66sm4863934yhb.7.2013.11.01.07.35.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 07:35:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> Date: Fri, 1 Nov 2013 07:11:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:37:04 -0000 > If consumers adopt LISP, we'll need 10,000,000,000 prefixes within the = next ten years. That means each public PITR will have to announce = 10,000,000,000 BGP-routes to itself if consumers use random PI-prefixes = from the global unicast space. Multiply the number of public PITRs = necessary for such a=20 You are making it sound that LISP is requiring the need for 10 million = prefixes. If there are 10 million new sites added to the Internet, no = matter which technology you use to connect them, there will be 10 = million more addressable prefixes. And if they are indeed PI prefixes, = every core router will have to store them. With LISP the edges will = store probably 6 orders of magnitude less. And if I'm off with 6, then = say 5, but that is just a rounding error IMO. > deployment with 10,000,000,000 BGP-routes each and you'll realize LISP = will either break the internet and go into decline or just be a limited = luxury for big companies. Using a dedicated PI-prefix which can handle = 10,000,000,000 subnets will reduce the BGP-routes a public PITR has to = announce to ONE. So using 24 or 32 bits is way to less for the expected = growth. The PITRs will not have to advertise those. If a large portion of those = 10 million new sites are LISP sites then legacy sites may just want to = talk to them. When that demand comes, the PITRs will on path of the tail = legacy sites (the default path into the Internet), so those 10 million = won't need to be advertised. In fact, a PE router at an ISP would be a fine place to configure the = PITR. But the choice is left the ISP to design how it would want to = aggregate state, maybe 100 PE routers fan into 10 upstreams where that = is where the PITRs go. But I think a PE router can handle 1 million = routes today. They do it for the 1000s of VPNs they support. So this = isn't a stretch. Dino From farinacci@gmail.com Fri Nov 1 07:38:51 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378521E821A for ; Fri, 1 Nov 2013 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRruHN+btMzJ for ; Fri, 1 Nov 2013 07:38:51 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49CBD21E8383 for ; Fri, 1 Nov 2013 07:38:46 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id z6so1902110yhz.1 for ; Fri, 01 Nov 2013 07:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OHdYEW00Jsa+0nyCspv9m6kLYQawZuQtO85r9HpPl+Y=; b=LdbhNxLK7jvYdAGmX6eXv3c9uL2NRHnz7S8raEQ10oo8nXWWoNHkFK+FspL8FgzV4L KJWZZlLc9DobLWIB+EyJPEfcYS4inOx7XoANGIN+Osnk9F47AOP4+KBPzXVbtETiQpyz pPr9Ajbm9LciiO0Sgp9FkWT7j5Lcsup1g4Atev9bhtikRoo3d53EiYaPX6HZYDA3ss3X NkfMuKdqSUj76iJK3q33d86CcEnj4meSTE3aJv7Q7CTc32c3uIYCIKda7Io8VrBLCmXL Hp11h4Xly4wSGqkg5mEVgSFy+Ei9hjYMjFUXepT7zN1/77PI3obG7pEEKfPiz5wFbDFq O4Dw== X-Received: by 10.236.124.172 with SMTP id x32mr2489895yhh.59.1383316725661; Fri, 01 Nov 2013 07:38:45 -0700 (PDT) Received: from [172.20.10.3] (mobile-198-228-198-132.mycingular.net. [198.228.198.132]) by mx.google.com with ESMTPSA id h66sm4882225yhb.7.2013.11.01.07.38.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 07:38:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: <52734FA6.4040003@joelhalpern.com> Date: Fri, 1 Nov 2013 07:33:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:38:51 -0000 > I understand the importance of experimenting. But I am having trouble = getting my head around the possible value we want to explore. Color me = naive and stubborn, but individually so. >=20 > Thinking about the ITR code path, if there is no block: Many are thinking in this context. It is one but there are other things = WE COULD DO if we new a prefix was an EID. See below for some rough = examples. And please don't ask for detail, because this is initial = thinking. > Receive packet > check cache for destination > failing cache match, query for destination. And there could be a failed match if the destination address was not an = EID. Meaning this packet is coming to an ITR destined for a non-LISP = site (regardless if the source address is an EID or not). So the ITR = would have to query the mapping database. So let's break this down. If the source was an EID, one could say, "okay = since I'm doing the new stuff the delay for a lookup to a non-LISP = destination is the price I pay for getting multihoming for packets that = come back to me". If the source was not an EID, then the old user that = expects to go to a non-LISP site expects the packet loss or optimal = routing path to continue. And if it does not, then the new service hurt = existing users. Please note, this is when a site is bifurcated being a site that has = some partial EID allocations and partial hosts that have not changed. = And that either could send to EID or non-EID destinations. Yes, you could have a default PETR configured in the ITR so there is 0 = packet loss, but then you may get a suboptimal path. And packets from a = non-EID source to a non-EID destination could be inadvertently = encapsulated to the PETR. Then the PETR would decap and deliver the = packet based on a BGP path. I for one, would like to solve this problem. And I do not know if just a = well-known, hard-coded, EID-block will do it. > And the ITR code path if there is a block: > Receive packet > check cache for destiantion > failing cache match, check for destination in EID block > If in EID block, query > If not in EID block, query You are correct, but this box could be configured in way where the logic = could change: Receive packet If EID-block strict configured If destination in EID-block, send query Else forward natively Else Endif > Now, if everything is in the EID block, I understand that the last = step above becomes "just send". But that appears to be a = counter-factual assumption. >=20 > Yours, > Joel Having an EID block could help us in these scenarios as well: (1) The block or any more specifics should not have a native-forward = action in a Map-Reply returned by the mapping system. (2) The block or any more specifics should not be injected into BGP = without a special community indicating that only PITRs should be = advertising it. (3) If a destination that a NAT box receives has a source in this block, = that translation should not be done (because it is not needed). (4) If the source is in this block we know we cannot build RPF trees in = the core when the source sends multicast packets. (5) Maybe a special EID-block should indicate that this source host can = only talk IPv6 and that stretched layer-2 subnets are prohibited. So if = you hit a box that does VXLAN and LISP, that layer 3 LISP is used and we = don't move MAC frames across the underly and we certainly do not forward = ARP packet, broadcast frames, and link-local multicast. Now all these things can be put in the mapping database, and give us the = same answers but if we could keep load off the mapping database, this = would be a good thing, a scalability feature. Dino >=20 > On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>=20 >>> Actually, that use case is only helped by the EID block if you can >>> be sure that ALL the destination EIDs it will see will come from >>> the block. >>=20 >> I don't believe so. It could just an efficiency play for one versus >> the other. >>=20 >>> Which seems to be impossible to ensure in the general case. And >>> easy to achieve without an allocated block in many of the special >>> cases. >>=20 >> Well the EID could mean it is behind a NAT and that ITRs should >> encapsulate to an RTR. Maybe one that is used by a default map-cache >> entry or a distinguished key on the mapping database. >>=20 >> See there are sorts of things we could try. Again, "try" here means >> experimentation. >>=20 >> Look how the pilot network was easier to debug since we had >> 153.16.0.0/16 generically donated by Andrew Partan and how cisco has >> been renting 2610:d0::/32. >>=20 >> Dino >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From linda.dunbar@huawei.com Fri Nov 1 09:00:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5691411E831F for ; Fri, 1 Nov 2013 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoyBIFdwRXz8 for ; Fri, 1 Nov 2013 08:59:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E386411E822B for ; Fri, 1 Nov 2013 08:59:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXL54219; Fri, 01 Nov 2013 15:59:50 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 15:59:24 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 15:59:43 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 08:59:40 -0700 From: Linda Dunbar To: "lisp@ietf.org" Thread-Topic: Is there a dedicated control plane channel for interface to the Mapping system? Thread-Index: Ac7XG2CJjeSrlJICRiC1lRkWev1nVQ== Date: Fri, 1 Nov 2013 15:59:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFB18F@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.129] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BFB18Fdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:00:04 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BFB18Fdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LISP experts: Is there a dedicated control plane channel for interface to the Mapping sys= tem? Or if the interface to the mapping system is via the data plane? When the "Negative Map-Reply" is received by the requester, should the requ= ester drop the packets to the desired target? Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645BFB18Fdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LISP experts:

 

Is there a dedicated control plane channel for inter= face to the Mapping system? Or if the interface to the mapping system is vi= a the data plane?

 

When the “Negative Map-Reply” is receive= d by the requester, should the requester drop the packets to the desired ta= rget?

 

Thanks, Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645BFB18Fdfweml509mbxchi_-- From jnc@mercury.lcs.mit.edu Fri Nov 1 09:11:32 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1911E8210 for ; Fri, 1 Nov 2013 09:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyQhnmv9k-gi for ; Fri, 1 Nov 2013 09:11:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id CE36D21E8441 for ; Fri, 1 Nov 2013 09:10:55 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 854D018C198; Fri, 1 Nov 2013 12:10:54 -0400 (EDT) To: lisp@ietf.org Message-Id: <20131101161054.854D018C198@mercury.lcs.mit.edu> Date: Fri, 1 Nov 2013 12:10:54 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:11:32 -0000 > From: Linda Dunbar > Is there a dedicated control plane channel for interface to the Mapping > system? Or if the interface to the mapping system is via the data plane? If I understand your question, you're asking if anyone can ask the mapping system for a mapping, or can only ITRs do that? (The ITRs are, I assume, what you mean by 'data plane' - there is no wholly separate 'data plane' in LISP as there is in some designs, because xTRs also include control plane functions.) If so, the answer is 'yes, anyone can ask the mapping system for a mapping'. Also, I don't know if you've read: http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 but if not, you should at least read Part I, which will help you ask questions about LISP - that document is intended to be an easy, quick read. > When the "Negative Map-Reply" is received by the requester, should the > requester drop the packets to the desired target? No, that just means that that destination is not a LISP host/site (i.e. it does not have an {EID->RLOC} mapping), but rather is a 'legacy' host/site. So the ITR (which is a border router for the source site, just one enhanced with LISP functionality) should just forward traffic to that destination 'normally' (i.e. like any other IP router). Noel From jnc@mercury.lcs.mit.edu Fri Nov 1 09:17:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669F121E84CD for ; Fri, 1 Nov 2013 09:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrGjs9AGwFXg for ; Fri, 1 Nov 2013 09:17:51 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 46B2C21E844E for ; Fri, 1 Nov 2013 09:17:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C303E18C198; Fri, 1 Nov 2013 12:17:50 -0400 (EDT) To: lisp@ietf.org Message-Id: <20131101161750.C303E18C198@mercury.lcs.mit.edu> Date: Fri, 1 Nov 2013 12:17:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:17:56 -0000 PS: > From: Linda Dunbar > Is there a dedicated control plane channel for interface to the Mapping > system? Or if the interface to the mapping system is via the data plane? On re-reading this, I realized you're probably actually asking something on the order of 'can nodes interact with the Mapping System with ordinary IP packets, or can they only send LISP-encapsulated packets to it'. I honestly don't know the answer to that; I _think_ the spec calls for packets to the mapping system to be encapsulated (for historical kludgy reasons that I never liked, so I try not to think about this corner of the design), but whether a Map-Resolver would barf if it received an un-encapsulated Map-Request is probably an implementation-specific question. Noel From linda.dunbar@huawei.com Fri Nov 1 09:33:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A752F11E8210 for ; Fri, 1 Nov 2013 09:33:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSt1XMvCKKED for ; Fri, 1 Nov 2013 09:33:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1618711E8199 for ; Fri, 1 Nov 2013 09:33:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZT56216; Fri, 01 Nov 2013 16:33:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 16:32:42 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 16:33:08 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 09:33:04 -0700 From: Linda Dunbar To: Noel Chiappa , "lisp@ietf.org" Thread-Topic: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? Thread-Index: AQHO1x3oNU8yNlWWokmDcjMMix7dwJoQkI2g Date: Fri, 1 Nov 2013 16:33:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFB23A@dfweml509-mbx.china.huawei.com> References: <20131101161750.C303E18C198@mercury.lcs.mit.edu> In-Reply-To: <20131101161750.C303E18C198@mercury.lcs.mit.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:33:15 -0000 Noel,=20 Thank you very much for the answer. I was looking for this detail in the "d= raft-ietf-lisp-introduction-03".=20 Another question, does the response from MapServer have a cache timer assoc= iated? Or the requester can keep the response forever?=20 Since you are the editor to "draft-ietf-lisp-introduction-03", want to poin= t out that there is a typo "inferfaces" in Section 13.1.=20 Linda > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Friday, November 01, 2013 11:18 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] Is there a dedicated control plane channel for > interface to the Mapping system? >=20 > PS: >=20 > > From: Linda Dunbar >=20 > > Is there a dedicated control plane channel for interface to the > Mapping > > system? Or if the interface to the mapping system is via the data > plane? >=20 > On re-reading this, I realized you're probably actually asking > something on > the order of 'can nodes interact with the Mapping System with ordinary > IP > packets, or can they only send LISP-encapsulated packets to it'. >=20 > I honestly don't know the answer to that; I _think_ the spec calls for > packets to the mapping system to be encapsulated (for historical kludgy > reasons that I never liked, so I try not to think about this corner of > the > design), but whether a Map-Resolver would barf if it received an > un-encapsulated Map-Request is probably an implementation-specific > question. >=20 > Noel From jnc@mercury.lcs.mit.edu Fri Nov 1 09:57:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5776911E80DE for ; Fri, 1 Nov 2013 09:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5xQdgyf6ZBJ for ; Fri, 1 Nov 2013 09:56:59 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B611E8172 for ; Fri, 1 Nov 2013 09:56:56 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AAAFB18C0D0; Fri, 1 Nov 2013 12:56:52 -0400 (EDT) To: lisp@ietf.org Message-Id: <20131101165652.AAAFB18C0D0@mercury.lcs.mit.edu> Date: Fri, 1 Nov 2013 12:56:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:57:04 -0000 > From: Linda Dunbar > I was looking for this detail in the > "draft-ietf-lisp-introduction-03". Yes, I already had made a note to myself to cover this topic in the next revision... :-) The reason I hadn't should be obvious: I think the encapsulation is an ugly kludge, and so I prefer not to think about it! (And I also to cover your question about the proper response to a Negative reply...) > does the response from MapServer have a cache timer associated? Or the > requester can keep the response forever? Well, _normally_ the response an ITR sees (the Map-Reply containing the actual mapping) will come from an ETR, not from the Map-Server. (The Map-Server just knows who is authoritative for various chunks of the EID namespace, not what the actual mappings are. So they pass Map-Requests on to an appropriate ETR, which replies with the actual mapping.) I assume it's these responses you're talking about - or are you talking about Proxy Map-Replies, sent by a Map-Server which is acting as a proxy for an ETR? If the former, each mapping (i.e. {EID->RLOC(s)}) in a Map-Reply packet has its own TTL (see Section 6.1.4, RFC-6830), and if this is set, the ITR should discard/refresh the mapping after that interval. (There's also a discrete reserved value for 'keep as long as you'd like'.) If the latter, I _assume_ MS's set a similar timeout, but that's an assumption on my part, I'm not sure any document specifically discusses that point. > that there is a typo "inferfaces" in Section 13.1. Thanks! Got it. Noel From linda.dunbar@huawei.com Fri Nov 1 10:12:04 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44F911E81DB for ; Fri, 1 Nov 2013 10:12:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84VvsQT6uyGL for ; Fri, 1 Nov 2013 10:11:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1721E805D for ; Fri, 1 Nov 2013 10:11:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXL57941; Fri, 01 Nov 2013 17:11:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 17:11:28 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 17:11:53 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 10:11:47 -0700 From: Linda Dunbar To: Noel Chiappa Thread-Topic: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? Thread-Index: AQHO1yNcNU8yNlWWokmDcjMMix7dwJoQm7Hw Date: Fri, 1 Nov 2013 17:11:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFB30F@dfweml509-mbx.china.huawei.com> References: <20131101165652.AAAFB18C0D0@mercury.lcs.mit.edu> In-Reply-To: <20131101165652.AAAFB18C0D0@mercury.lcs.mit.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lisp@ietf.org" Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 17:12:05 -0000 Noel,=20 > -----Original Message----- > Well, _normally_ the response an ITR sees (the Map-Reply containing the > actual mapping) will come from an ETR, not from the Map-Server.=20 [Linda] There will be many ETRs, which ETR should ITR send requests? Does = ITR send requests to all ETRs?=20 That is same as TRILL's flooding to all egress edge nodes to resolve=20 Thanks, Linda From jnc@mercury.lcs.mit.edu Fri Nov 1 10:19:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A3B11E822C for ; Fri, 1 Nov 2013 10:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0UdhNgryqdU for ; Fri, 1 Nov 2013 10:19:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 845ED11E81DB for ; Fri, 1 Nov 2013 10:19:25 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3E1A018C195; Fri, 1 Nov 2013 13:19:25 -0400 (EDT) To: lisp@ietf.org Message-Id: <20131101171925.3E1A018C195@mercury.lcs.mit.edu> Date: Fri, 1 Nov 2013 13:19:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Is there a dedicated control plane channel for interface to the Mapping system? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 17:19:30 -0000 > From: Linda Dunbar > There will be many ETRs, which ETR should ITR send requests? Does ITR > send requests to all ETRs? No, ITRs normally do not send Map-Request packets directly to an ETR - or even a Map-Server. An ITR sends Map-Request packets to a Map-Resolver, which is its 'portal' into the mapping system. The Map-Resolver uses a distributed system called DDT to find the Map-Server(s) which are responsible for the block of address space the Map-Request is about. (This step may be avoided if the appropriate delegation information is cached after it was received in response to a prior request.) The Map-Resolver then sends the Map-Request to an appropriate Map-Server, which forwards it on to an appropriate ETR. Noel From rogerj@gmail.com Sat Nov 2 04:47:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F13B11E81E9 for ; Sat, 2 Nov 2013 04:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duQw3tufxovy for ; Sat, 2 Nov 2013 04:47:36 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 741DC11E8102 for ; Sat, 2 Nov 2013 04:47:35 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so469201wgh.1 for ; Sat, 02 Nov 2013 04:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ORwS6WZPOdKVKvf04choEF4ctmrfKdW+Ds/8skP/nfA=; b=rWjhz3CRbAex/NgyGDLA3Cn0S6u9GUCmiPQCNpZbcfllBi0G7kNeW3Zzv38/07cEvf sL77ewvp3eWrX5sjNZJ92vKv4d3BBO/oQ+cqSmN+w71/Knu2OnD24dmG40lyWp83UcEd M4+WR0ihFo27Dn75wBrojxpeGMraaAXujWuv0XXBkHxEBzpGfEiQqMSRg6ZE49eEluT1 e3d3mffcj4zM893ZnmFx8JfueXlsyymH08R3IXkdMsD2nmgBsVcT/KBfn4EjX3t0Bvww DU59BisA4aIseH9Dyk9L6RDpYXp9ggJVDoqROFgHoR/ZeEeYX9ZoUFd8ocwWlZl3lxwS G5Lg== MIME-Version: 1.0 X-Received: by 10.180.149.179 with SMTP id ub19mr5414416wib.43.1383392854566; Sat, 02 Nov 2013 04:47:34 -0700 (PDT) Received: by 10.216.213.72 with HTTP; Sat, 2 Nov 2013 04:47:34 -0700 (PDT) In-Reply-To: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> Date: Sat, 2 Nov 2013 12:47:34 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Sander Steffann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 11:47:37 -0000 On Fri, Nov 1, 2013 at 1:45 PM, Sander Steffann wrote: > Hi, > >> I want to ask everyone on the list: Which facts prevent a scaling experi= ment with the aim of global production state? In my opinion a /16-EID-prefi= x is perfect for that goal. > > The problem is in that what you describe depends on public PITRs, and we = have seen how badly that worked for 6to4 public relays. Running a public re= lay costs money (equipment, maintenance, bandwidth), and when nobody pays f= or them then we cannot expect any decent quality. And LISP will be blamed a= nd seen as an unreliable protocol, just like 6to4. Relying on public relays= is a very bad idea. This problem you're touching here is the interconnect, and interaction between LISP-world and legacy Internet (as I like to cal lit). We all agree that the 6to4 path will not work, or scale well. For the experiments we don't really need this interconnect either, and if the need arise the mgmt-draft can be used anyhow since it don't really care if there is interaction or not. However the eid-block draft do have some text on this, but it's probably not good enough to get it done properly. Any idea on how to address it better there? --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From jmh@joelhalpern.com Sat Nov 2 10:45:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535A11E8221 for ; Sat, 2 Nov 2013 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO6OqDs3qn6c for ; Sat, 2 Nov 2013 10:44:58 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id E08B211E821B for ; Sat, 2 Nov 2013 10:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9E6531C08B8; Sat, 2 Nov 2013 10:44:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from dhcp-b83d.meeting.ietf.org (dhcp-b83d.meeting.ietf.org [31.133.184.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 221941C0780; Sat, 2 Nov 2013 10:44:56 -0700 (PDT) Message-ID: <52753A16.5050906@joelhalpern.com> Date: Sat, 02 Nov 2013 13:44:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dino Farinacci References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 17:45:03 -0000 On the source side, the ITR had better know what EIDs it is working on behalf of (otherwise, it is a source for spoofed source address). So none of those cases seem to be affected by the allocation or non-allocation of a block. If we are going to do anything based on a block, we better make sure it can handle more than one block. Which means that at most we need a block for the duration of the test period. We do not need a block for the hoped for full success of LISP. If we really succeed, we can get an additional bigger block. Yours, Joel On 11/1/13 10:33 AM, Dino Farinacci wrote: >> I understand the importance of experimenting. But I am having >> trouble getting my head around the possible value we want to >> explore. Color me naive and stubborn, but individually so. >> >> Thinking about the ITR code path, if there is no block: > > Many are thinking in this context. It is one but there are other > things WE COULD DO if we new a prefix was an EID. See below for some > rough examples. And please don't ask for detail, because this is > initial thinking. > >> Receive packet check cache for destination failing cache match, >> query for destination. > > And there could be a failed match if the destination address was not > an EID. Meaning this packet is coming to an ITR destined for a > non-LISP site (regardless if the source address is an EID or not). So > the ITR would have to query the mapping database. > > So let's break this down. If the source was an EID, one could say, > "okay since I'm doing the new stuff the delay for a lookup to a > non-LISP destination is the price I pay for getting multihoming for > packets that come back to me". If the source was not an EID, then the > old user that expects to go to a non-LISP site expects the packet > loss or optimal routing path to continue. And if it does not, then > the new service hurt existing users. > > Please note, this is when a site is bifurcated being a site that has > some partial EID allocations and partial hosts that have not changed. > And that either could send to EID or non-EID destinations. > > Yes, you could have a default PETR configured in the ITR so there is > 0 packet loss, but then you may get a suboptimal path. And packets > from a non-EID source to a non-EID destination could be inadvertently > encapsulated to the PETR. Then the PETR would decap and deliver the > packet based on a BGP path. > > I for one, would like to solve this problem. And I do not know if > just a well-known, hard-coded, EID-block will do it. > >> And the ITR code path if there is a block: Receive packet check >> cache for destiantion failing cache match, check for destination in >> EID block If in EID block, query If not in EID block, query > > You are correct, but this box could be configured in way where the > logic could change: > > Receive packet If EID-block strict configured If destination in > EID-block, send query Else forward natively Else above with no EID-block check> Endif > >> Now, if everything is in the EID block, I understand that the last >> step above becomes "just send". But that appears to be a >> counter-factual assumption. >> >> Yours, Joel > > Having an EID block could help us in these scenarios as well: > > (1) The block or any more specifics should not have a native-forward > action in a Map-Reply returned by the mapping system. (2) The block > or any more specifics should not be injected into BGP without a > special community indicating that only PITRs should be advertising > it. (3) If a destination that a NAT box receives has a source in this > block, that translation should not be done (because it is not > needed). (4) If the source is in this block we know we cannot build > RPF trees in the core when the source sends multicast packets. (5) > Maybe a special EID-block should indicate that this source host can > only talk IPv6 and that stretched layer-2 subnets are prohibited. So > if you hit a box that does VXLAN and LISP, that layer 3 LISP is used > and we don't move MAC frames across the underly and we certainly do > not forward ARP packet, broadcast frames, and link-local multicast. > > Now all these things can be put in the mapping database, and give us > the same answers but if we could keep load off the mapping database, > this would be a good thing, a scalability feature. > > Dino > >> >> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>> >>>> Actually, that use case is only helped by the EID block if you >>>> can be sure that ALL the destination EIDs it will see will come >>>> from the block. >>> >>> I don't believe so. It could just an efficiency play for one >>> versus the other. >>> >>>> Which seems to be impossible to ensure in the general case. >>>> And easy to achieve without an allocated block in many of the >>>> special cases. >>> >>> Well the EID could mean it is behind a NAT and that ITRs should >>> encapsulate to an RTR. Maybe one that is used by a default >>> map-cache entry or a distinguished key on the mapping database. >>> >>> See there are sorts of things we could try. Again, "try" here >>> means experimentation. >>> >>> Look how the pilot network was easier to debug since we had >>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>> has been renting 2610:d0::/32. >>> >>> Dino >>> >> _______________________________________________ lisp mailing list >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp > > From farinacci@gmail.com Sat Nov 2 11:09:28 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCC811E8172 for ; Sat, 2 Nov 2013 11:09:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt1tUx+hCkr4 for ; Sat, 2 Nov 2013 11:09:27 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0492E11E8224 for ; Sat, 2 Nov 2013 11:09:23 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so9703499iej.36 for ; Sat, 02 Nov 2013 11:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LZXSrnDNi8/jtR5+LZxhHMrFmb90vYRwLpwNTCiVmLY=; b=z9Rm73/Xsq0C2YzUjMhCj665S85N5iz2YupbaOcasPtvMQetsbxT0KM0GLBI2TG3W3 xUjm9tNJQU4yUxlWlnTb/2MtPdTFCaut1RLOLcMofC+3poTZb2wJ5fyp6xXiB9ybaXag ktub2gcmFM+xNnhZhMabxCzhTLuUvlFFZmlSveVAbbOHTS55DVHIFtWAFz8KvwR1jwKV ajHN55L5L1H1H2f6RNykjhE56t+GtL8nwarDH+knDqI2ktrYzGcy4sAGoEwE6V37G/SC 3JbDybWTkDmH8SjJtTz40ncu+mTZbdsZUJ8GA2XE5D+vTfght7gJo5jJeMXjwnPRgKXc wfXQ== X-Received: by 10.50.20.99 with SMTP id m3mr6638576ige.54.1383415763489; Sat, 02 Nov 2013 11:09:23 -0700 (PDT) Received: from [172.19.131.126] ([12.130.122.100]) by mx.google.com with ESMTPSA id l7sm11291250igx.2.2013.11.02.11.09.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 11:09:22 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: <52753A16.5050906@joelhalpern.com> Date: Sat, 2 Nov 2013 11:09:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 18:09:29 -0000 So it appears that: (1) People are all for experimenting. (2) People may be all for allocating a block if it is not too large. So would it be easier to swallow if we just request a /32 or smaller = block.=20 Are we just arguing over size? If the experiment proves we need to do something in production, then we = go get larger blocks as Joel indicates. And if the experiment is = complete and say we don't need a well-known block, we return the /32. Dino On Nov 2, 2013, at 10:44 AM, Joel M. Halpern = wrote: > On the source side, the ITR had better know what EIDs it is working on = behalf of (otherwise, it is a source for spoofed source address). So = none of those cases seem to be affected by the allocation or = non-allocation of a block. >=20 > If we are going to do anything based on a block, we better make sure = it can handle more than one block. Which means that at most we need a = block for the duration of the test period. We do not need a block for = the hoped for full success of LISP. If we really succeed, we can get an = additional bigger block. >=20 > Yours, > Joel >=20 > On 11/1/13 10:33 AM, Dino Farinacci wrote: >>> I understand the importance of experimenting. But I am having >>> trouble getting my head around the possible value we want to >>> explore. Color me naive and stubborn, but individually so. >>>=20 >>> Thinking about the ITR code path, if there is no block: >>=20 >> Many are thinking in this context. It is one but there are other >> things WE COULD DO if we new a prefix was an EID. See below for some >> rough examples. And please don't ask for detail, because this is >> initial thinking. >>=20 >>> Receive packet check cache for destination failing cache match, >>> query for destination. >>=20 >> And there could be a failed match if the destination address was not >> an EID. Meaning this packet is coming to an ITR destined for a >> non-LISP site (regardless if the source address is an EID or not). So >> the ITR would have to query the mapping database. >>=20 >> So let's break this down. If the source was an EID, one could say, >> "okay since I'm doing the new stuff the delay for a lookup to a >> non-LISP destination is the price I pay for getting multihoming for >> packets that come back to me". If the source was not an EID, then the >> old user that expects to go to a non-LISP site expects the packet >> loss or optimal routing path to continue. And if it does not, then >> the new service hurt existing users. >>=20 >> Please note, this is when a site is bifurcated being a site that has >> some partial EID allocations and partial hosts that have not changed. >> And that either could send to EID or non-EID destinations. >>=20 >> Yes, you could have a default PETR configured in the ITR so there is >> 0 packet loss, but then you may get a suboptimal path. And packets >> from a non-EID source to a non-EID destination could be inadvertently >> encapsulated to the PETR. Then the PETR would decap and deliver the >> packet based on a BGP path. >>=20 >> I for one, would like to solve this problem. And I do not know if >> just a well-known, hard-coded, EID-block will do it. >>=20 >>> And the ITR code path if there is a block: Receive packet check >>> cache for destiantion failing cache match, check for destination in >>> EID block If in EID block, query If not in EID block, query >>=20 >> You are correct, but this box could be configured in way where the >> logic could change: >>=20 >> Receive packet If EID-block strict configured If destination in >> EID-block, send query Else forward natively Else > above with no EID-block check> Endif >>=20 >>> Now, if everything is in the EID block, I understand that the last >>> step above becomes "just send". But that appears to be a >>> counter-factual assumption. >>>=20 >>> Yours, Joel >>=20 >> Having an EID block could help us in these scenarios as well: >>=20 >> (1) The block or any more specifics should not have a native-forward >> action in a Map-Reply returned by the mapping system. (2) The block >> or any more specifics should not be injected into BGP without a >> special community indicating that only PITRs should be advertising >> it. (3) If a destination that a NAT box receives has a source in this >> block, that translation should not be done (because it is not >> needed). (4) If the source is in this block we know we cannot build >> RPF trees in the core when the source sends multicast packets. (5) >> Maybe a special EID-block should indicate that this source host can >> only talk IPv6 and that stretched layer-2 subnets are prohibited. So >> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used >> and we don't move MAC frames across the underly and we certainly do >> not forward ARP packet, broadcast frames, and link-local multicast. >>=20 >> Now all these things can be put in the mapping database, and give us >> the same answers but if we could keep load off the mapping database, >> this would be a good thing, a scalability feature. >>=20 >> Dino >>=20 >>>=20 >>> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>>>=20 >>>>> Actually, that use case is only helped by the EID block if you >>>>> can be sure that ALL the destination EIDs it will see will come >>>>> from the block. >>>>=20 >>>> I don't believe so. It could just an efficiency play for one >>>> versus the other. >>>>=20 >>>>> Which seems to be impossible to ensure in the general case. >>>>> And easy to achieve without an allocated block in many of the >>>>> special cases. >>>>=20 >>>> Well the EID could mean it is behind a NAT and that ITRs should >>>> encapsulate to an RTR. Maybe one that is used by a default >>>> map-cache entry or a distinguished key on the mapping database. >>>>=20 >>>> See there are sorts of things we could try. Again, "try" here >>>> means experimentation. >>>>=20 >>>> Look how the pilot network was easier to debug since we had >>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>>> has been renting 2610:d0::/32. >>>>=20 >>>> Dino >>>>=20 >>> _______________________________________________ lisp mailing list >>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>=20 >>=20 From ggx@gigix.net Sun Nov 3 14:30:22 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312C821E80D2 for ; Sun, 3 Nov 2013 14:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYLQdVA6-snI for ; Sun, 3 Nov 2013 14:30:17 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C421E80B7 for ; Sun, 3 Nov 2013 14:30:16 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz11so2120392bkb.30 for ; Sun, 03 Nov 2013 14:30:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BVPhMTgFuOvOYAW6jcBgoQBPV9P4rbb0ncwAIew32WY=; b=H8/wiZEtpP+NCMH2RCiyUzg2ZEyQG5XYJfUadMaJL+usHIJPo6MueefcOXUUfagppm CxpWMQft45jGt+KzvbttJ3VYJGBdw9ggAJp0Z4z7+xzx23rVZR3wyVE5NQeTViolHm0K PZ/R5PdeM/BgUWVU/C70n4Ik8JBJ9Nshz7S7orRiP3anbZGby/xs9ll+aUhl6gQbNUef Bj4AkgRScHiR4hUfHgcRpBRXVR+9DAmeFnVPj3Jy1ylYlB43Jbs5TBahz2QFGgqBQlWE Zh3NkDQUz8LZdXLaEI8cWWfaMAjM/mMtvoLffwR0jlp25kEIm74UlMt1IJjXuxGnQV9G RWFA== X-Gm-Message-State: ALoCoQk381CBzBtEP88VvnVoSj3ws99TfBoOrHBHrOxhOWm7itbV7SMQFfcvDejWMSXlxjIPJQrB X-Received: by 10.204.123.199 with SMTP id q7mr7659988bkr.10.1383517815716; Sun, 03 Nov 2013 14:30:15 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id a4sm12705345bko.11.2013.11.03.14.30.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:30:14 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> Date: Sun, 3 Nov 2013 14:30:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:30:23 -0000 Hi, I agree with Dino, if the issue is just the size let=92s reduce it and do some experiments. On the other hand, I do not understand we people here are trying to = reach a binary conclusion like =93EID Block is important and useful=94 = or =93EID Block is useless=94 even before doing any experimentation. IMHO this is not the most logical order. We should first experiment, = then we will have to know-how to make a decision. Exactly because there are different and opposite opinions let=92s the = technology itself, through experimentation, make the decision. =20 Luigi =20 On 2 Nov. 2013, at 11:09 , Dino Farinacci wrote: > So it appears that: >=20 > (1) People are all for experimenting. > (2) People may be all for allocating a block if it is not too large. >=20 > So would it be easier to swallow if we just request a /32 or smaller = block.=20 >=20 > Are we just arguing over size? >=20 > If the experiment proves we need to do something in production, then = we go get larger blocks as Joel indicates. And if the experiment is = complete and say we don't need a well-known block, we return the /32. >=20 > Dino >=20 > On Nov 2, 2013, at 10:44 AM, Joel M. Halpern = wrote: >=20 >> On the source side, the ITR had better know what EIDs it is working = on behalf of (otherwise, it is a source for spoofed source address). So = none of those cases seem to be affected by the allocation or = non-allocation of a block. >>=20 >> If we are going to do anything based on a block, we better make sure = it can handle more than one block. Which means that at most we need a = block for the duration of the test period. We do not need a block for = the hoped for full success of LISP. If we really succeed, we can get an = additional bigger block. >>=20 >> Yours, >> Joel >>=20 >> On 11/1/13 10:33 AM, Dino Farinacci wrote: >>>> I understand the importance of experimenting. But I am having >>>> trouble getting my head around the possible value we want to >>>> explore. Color me naive and stubborn, but individually so. >>>>=20 >>>> Thinking about the ITR code path, if there is no block: >>>=20 >>> Many are thinking in this context. It is one but there are other >>> things WE COULD DO if we new a prefix was an EID. See below for some >>> rough examples. And please don't ask for detail, because this is >>> initial thinking. >>>=20 >>>> Receive packet check cache for destination failing cache match, >>>> query for destination. >>>=20 >>> And there could be a failed match if the destination address was not >>> an EID. Meaning this packet is coming to an ITR destined for a >>> non-LISP site (regardless if the source address is an EID or not). = So >>> the ITR would have to query the mapping database. >>>=20 >>> So let's break this down. If the source was an EID, one could say, >>> "okay since I'm doing the new stuff the delay for a lookup to a >>> non-LISP destination is the price I pay for getting multihoming for >>> packets that come back to me". If the source was not an EID, then = the >>> old user that expects to go to a non-LISP site expects the packet >>> loss or optimal routing path to continue. And if it does not, then >>> the new service hurt existing users. >>>=20 >>> Please note, this is when a site is bifurcated being a site that has >>> some partial EID allocations and partial hosts that have not = changed. >>> And that either could send to EID or non-EID destinations. >>>=20 >>> Yes, you could have a default PETR configured in the ITR so there is >>> 0 packet loss, but then you may get a suboptimal path. And packets >>> from a non-EID source to a non-EID destination could be = inadvertently >>> encapsulated to the PETR. Then the PETR would decap and deliver the >>> packet based on a BGP path. >>>=20 >>> I for one, would like to solve this problem. And I do not know if >>> just a well-known, hard-coded, EID-block will do it. >>>=20 >>>> And the ITR code path if there is a block: Receive packet check >>>> cache for destiantion failing cache match, check for destination in >>>> EID block If in EID block, query If not in EID block, query >>>=20 >>> You are correct, but this box could be configured in way where the >>> logic could change: >>>=20 >>> Receive packet If EID-block strict configured If destination in >>> EID-block, send query Else forward natively Else >> above with no EID-block check> Endif >>>=20 >>>> Now, if everything is in the EID block, I understand that the last >>>> step above becomes "just send". But that appears to be a >>>> counter-factual assumption. >>>>=20 >>>> Yours, Joel >>>=20 >>> Having an EID block could help us in these scenarios as well: >>>=20 >>> (1) The block or any more specifics should not have a native-forward >>> action in a Map-Reply returned by the mapping system. (2) The block >>> or any more specifics should not be injected into BGP without a >>> special community indicating that only PITRs should be advertising >>> it. (3) If a destination that a NAT box receives has a source in = this >>> block, that translation should not be done (because it is not >>> needed). (4) If the source is in this block we know we cannot build >>> RPF trees in the core when the source sends multicast packets. (5) >>> Maybe a special EID-block should indicate that this source host can >>> only talk IPv6 and that stretched layer-2 subnets are prohibited. So >>> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used >>> and we don't move MAC frames across the underly and we certainly do >>> not forward ARP packet, broadcast frames, and link-local multicast. >>>=20 >>> Now all these things can be put in the mapping database, and give us >>> the same answers but if we could keep load off the mapping database, >>> this would be a good thing, a scalability feature. >>>=20 >>> Dino >>>=20 >>>>=20 >>>> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>>>>=20 >>>>>> Actually, that use case is only helped by the EID block if you >>>>>> can be sure that ALL the destination EIDs it will see will come >>>>>> from the block. >>>>>=20 >>>>> I don't believe so. It could just an efficiency play for one >>>>> versus the other. >>>>>=20 >>>>>> Which seems to be impossible to ensure in the general case. >>>>>> And easy to achieve without an allocated block in many of the >>>>>> special cases. >>>>>=20 >>>>> Well the EID could mean it is behind a NAT and that ITRs should >>>>> encapsulate to an RTR. Maybe one that is used by a default >>>>> map-cache entry or a distinguished key on the mapping database. >>>>>=20 >>>>> See there are sorts of things we could try. Again, "try" here >>>>> means experimentation. >>>>>=20 >>>>> Look how the pilot network was easier to debug since we had >>>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>>>> has been renting 2610:d0::/32. >>>>>=20 >>>>> Dino >>>>>=20 >>>> _______________________________________________ lisp mailing list >>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Sun Nov 3 14:32:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019C021F9DCE for ; Sun, 3 Nov 2013 14:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsgLuB+9flBA for ; Sun, 3 Nov 2013 14:32:15 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id E5F9F21E80D2 for ; Sun, 3 Nov 2013 14:32:14 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id u16so1019414bkz.35 for ; Sun, 03 Nov 2013 14:32:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=3HFvfxmYLTGn4gDBw9IWru9ZTmQHrL08kM1wrMVsuKc=; b=df9VFIsiQOsZZcY9BaiviG5Y047mmqjVxZHAH8SpC/+xM1Bx/yVLLOc09551tsOgMy xrdt7b/GOKbPnPHIp5quHUvGuiKmsGJPJ4O+k6CoZjobfZZNCS0EJDEbd+xHKV9w1S6A ZgEkhP02dZxwSjFBTPrbIcCA8+QvCmkKOX9JftAyB0UxNLKsIsrh8Vgv8eIaggqSl9B8 hjCPdLprduJL+CEVa0buuhxlAPFl2LF+QtlsSw0MuiA3ey0jF+Y9NLJcdyX/IjMjpNsB IQFWattWqZ26mbWcBxvT+QYkWPoUcmpHoQzoMu5oMWR2W96IQk41NawCW5HWWG1qCdPo H61w== X-Gm-Message-State: ALoCoQkuOvvllHFtgLdTPjvX+71WylWYYwnK8qZYe73YdGBhYDy8dLaZN4D/X1nv4LMjLLF+mvNu X-Received: by 10.205.3.7 with SMTP id nw7mr2258636bkb.26.1383517933852; Sun, 03 Nov 2013 14:32:13 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id on10sm12715490bkb.13.2013.11.03.14.32.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:32:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: Date: Sun, 3 Nov 2013 14:32:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> To: Sander Steffann X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:32:20 -0000 On 1 Nov. 2013, at 05:45 , Sander Steffann wrote: > Hi, >=20 >> I want to ask everyone on the list: Which facts prevent a scaling = experiment with the aim of global production state? In my opinion a = /16-EID-prefix is perfect for that goal. >=20 > The problem is in that what you describe depends on public PITRs, and = we have seen how badly that worked for 6to4 public relays. Running a = public relay costs money (equipment, maintenance, bandwidth), and when = nobody pays for them then we cannot expect any decent quality. And LISP = will be blamed and seen as an unreliable protocol, just like 6to4. = Relying on public relays is a very bad idea. Hi Sander, you are right. But IMHO this is one possible economic model. What about third parties selling MR/MS services which include also PxTRs = services? Luigi >=20 > Now, if some big tier-1 transit networks start running production = quality PxTRs (because PxTRs attract traffic, and their customers pay = for traffic) then I can see some possibilities. If the LISP traffic = volume increases then other networks might also start running PxTRs so = they don't have to pay their transits for it, and then we are getting = somewhere. But as long as 'public PxTR' means 'someone with good = intentions but no real responsibility' then this will be a dangerous = experiment for LISP... >=20 > Cheers, > Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From sander@steffann.nl Sun Nov 3 14:35:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03F821F9B9F for ; Sun, 3 Nov 2013 14:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXqfeI9Dvdj0 for ; Sun, 3 Nov 2013 14:35:36 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 2588F11E8205 for ; Sun, 3 Nov 2013 14:35:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6D5B846; Sun, 3 Nov 2013 23:35:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGldJn75LMna; Sun, 3 Nov 2013 23:35:31 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 4FCFC3D; Sun, 3 Nov 2013 23:35:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sander Steffann In-Reply-To: <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> Date: Sun, 3 Nov 2013 23:35:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:35:37 -0000 Hi, > you are right. But IMHO this is one possible economic model. >=20 > What about third parties selling MR/MS services which include also = PxTRs services? That is exactly what I am doing (oh, well, no real customers yet, but = working on that :-). For the PxTR services such a third party would then = only announce the block(s) used by his own customers though. Providing = free transit for the whole EID block would get kind of expensive if LISP = takes off... Cheers! Sander From ggx@gigix.net Sun Nov 3 14:43:55 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE68B21E80F9 for ; Sun, 3 Nov 2013 14:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vBGSd4+U3Hi for ; Sun, 3 Nov 2013 14:43:49 -0800 (PST) Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42411E8199 for ; Sun, 3 Nov 2013 14:43:49 -0800 (PST) Received: by mail-bk0-f42.google.com with SMTP id w16so292552bkz.29 for ; Sun, 03 Nov 2013 14:43:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hdlUaCumb2UH7Vg6eAu+czFq+o1b/rAIzi7I9KYY9Tk=; b=QuNWMUfeyvSVHzFS27PDqnIucixlTzEhKrHe2RQesH0dn7O7+fX+oAnpC7EB0E0cRM e6CkHXhbHzb3KuESloIjIWyb4xccLot9r0PrOHmbnpdF557ppBI1XDHStNPNyD3aLBkw DigZflywmF9lQkyV0Qcb4bdxYSLHsUdPVh4+3SuFQHSnTstp9Xj9dBWyOmhhW9XBIGQR MfqjMaTxpScj7YyyCVazWLXk7NXXsa2HeYLTxkf0kxH+kYyNPiFu3WY/I9pqR9fqmizK H9cFxWrGQBFJL5AGAAzqMzgfm0w4B1Vk1EhU7dwmTCanPdmWev0fdZvhcoR4u5oo9yOH L0nQ== X-Gm-Message-State: ALoCoQnicPERfPpAfWs7Udi0Ya5gZ3qsHGInQT1o0MOjnvqOLuNkVX3SaH32BMPj3n8nh3BMGwIQ X-Received: by 10.205.15.72 with SMTP id pt8mr7417624bkb.17.1383518628570; Sun, 03 Nov 2013 14:43:48 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id l5sm12724294bko.7.2013.11.03.14.43.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:43:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BC0D8A57-127A-4233-B643-A36C4B4245AD" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: Date: Sun, 3 Nov 2013 14:43:43 -0800 Message-Id: <532212FF-F504-4AD2-B23D-244E90071448@gigix.net> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:43:55 -0000 --Apple-Mail=_BC0D8A57-127A-4233-B643-A36C4B4245AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Nov. 2013, at 07:33 , Dino Farinacci wrote: >> And the ITR code path if there is a block: >> Receive packet >> check cache for destiantion >> failing cache match, check for destination in EID block >> If in EID block, query >> If not in EID block, query >=20 > You are correct, but this box could be configured in way where the = logic could change: >=20 > Receive packet > If EID-block strict configured > If destination in EID-block, send query > Else forward natively > Else > > Endif You can also do more complex thing. During the resolution delay (the = time a map-reply comes back) you can have different policies depending = on the destination.=20 For instance, if it is an EID block you can send toward a PITR or drop = if you think that PITR adds too much path stretch.=20 Or during the resolution delay of a non-EID block destination you = forward toward a PETR or just natively. Luigi= --Apple-Mail=_BC0D8A57-127A-4233-B643-A36C4B4245AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 1 Nov. 2013, at 07:33 , Dino = Farinacci <farinacci@gmail.com> = wrote:
And the ITR code path if there is a = block:
Receive packet
check cache for destiantion
failing cache = match, check for destination in EID block
If in EID block, = query
If not in EID block, query

You are correct, = but this box could be configured in way where the logic could = change:

Receive packet
If EID-block strict = configured
   If destination in EID-block, send = query
   Else forward = natively
Else
   <do what Joel said above with = no EID-block check>
Endif

You =  can also do more complex thing. During the resolution delay (the = time a map-reply comes back) you can have different policies depending = on the destination. 

For instance, if it = is an EID block you can send toward a PITR or drop if you think that = PITR adds too much path stretch. 
Or during the = resolution delay of a non-EID block destination you forward toward a = PETR or just = natively.

Luigi
= --Apple-Mail=_BC0D8A57-127A-4233-B643-A36C4B4245AD-- From ggx@gigix.net Sun Nov 3 14:46:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C1C21E80D2 for ; Sun, 3 Nov 2013 14:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osMgl01Nokc8 for ; Sun, 3 Nov 2013 14:46:25 -0800 (PST) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id D4BAE21E80E6 for ; Sun, 3 Nov 2013 14:46:24 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w14so2558065bkz.36 for ; Sun, 03 Nov 2013 14:46:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ZYQ/njkEsw6ac8+ikCeP5vDv8JTES8ROGMmNuMNwOJg=; b=IDqMy88MHfd3gZk33vp7bu5z4zUBzttVRvHcMEhPJQZlV7oR+WfCQcCeRggZtzqS+P UQdZMmz6mwFGJOjuk/rNMPMCerd2j40yN7kCJxujfyPXaiUzDJ4sjeh9OjQ0OUd6YHCt H9V0JznJHdxYPuxcS53AMalj5bV/GvO6FyW6+aAsk4r7YiyVYBeUL42Y+4MnJp2O+E7A DvOTGiaNEj+ShhGnz/3Yqvz/IpbrTTP2gC8WFcLM2geijjur4qMlxIMuS4yFrTdS2A5D oQ91hHFrOSJ44gsi0mhMTgFWlHT27+s2zNsx7iNkGI86zC3QscF5sD78Y/+rxlak1FvQ 5TnA== X-Gm-Message-State: ALoCoQn6sB2vEG981mfveSRHZQWT8BGYvgmibEjJMUdJP3NEKDPFvYh6Az4BSso0fnpEzgGxvLV2 X-Received: by 10.205.71.193 with SMTP id yl1mr8124bkb.45.1383518783779; Sun, 03 Nov 2013 14:46:23 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id qe6sm12727458bkb.5.2013.11.03.14.46.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:46:22 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> Date: Sun, 3 Nov 2013 14:46:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:46:31 -0000 On 3 Nov. 2013, at 14:35 , Sander Steffann wrote: > Hi, >=20 >> you are right. But IMHO this is one possible economic model. >>=20 >> What about third parties selling MR/MS services which include also = PxTRs services? >=20 > That is exactly what I am doing (oh, well, no real customers yet, but = working on that :-). For the PxTR services such a third party would then = only announce the block(s) used by his own customers though. Providing = free transit for the whole EID block would get kind of expensive if LISP = takes off=85 =85. or an opportunity to have =93peering=94 agreements with other PxTR = providers ;-) L. >=20 > Cheers! > Sander >=20 From ggx@gigix.net Sun Nov 3 14:48:48 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6718121E80D2 for ; Sun, 3 Nov 2013 14:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wTz+DCMHJRy for ; Sun, 3 Nov 2013 14:48:43 -0800 (PST) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id D193A21F9D8D for ; Sun, 3 Nov 2013 14:48:39 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w14so2514874bkz.8 for ; Sun, 03 Nov 2013 14:48:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nFg9hKcKtqwnWpFmBXLmw09yC3Dk2eX3srWzg+bGRb8=; b=fT/UtQbPAXKdii+NV+TDCR/0SMC2xtlbf+uomo2oiFGXigR2XUVyecmPCPjuwzGlE0 CXZbtr/NRQhDh7NyfcjZEG1I9A24y7gFCvcwQn7i4q8FZZo++DRXP0cGv4GDJzA+DDjC vpzns7RNWOOZsk6pSg4jrs+SYoLvD9OxB9UQYaIQslcpCCyfe4BpWW01cookTeWbDOVH vqGuX+rYI3BoeZie0oPsHhCdTaBDcKUSyQ3MFmVcCsVvvo+DUai2/onnsPWBOKNHHoxU sewabbVQtghuJhxuF4Zp+dtQCIgECzwW/kYnykY8E5+VgWp1qtWW99Eo9WUF7OWsdtSQ keTQ== X-Gm-Message-State: ALoCoQmNW46xtGxqzENh0YJnJ2fCiZVQLtNmX65DMGTzewTdcp1D6r7ulbXjI0ElOrSKJX7Td7f3 X-Received: by 10.205.15.72 with SMTP id pt8mr7423643bkb.17.1383518918848; Sun, 03 Nov 2013 14:48:38 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id w9sm12741378bkn.12.2013.11.03.14.48.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:48:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <20131031222916.2EEAA18C180@mercury.lcs.mit.edu> Date: Sun, 3 Nov 2013 14:48:34 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20131031222916.2EEAA18C180@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:48:48 -0000 On 31 Oct. 2013, at 15:29 , Noel Chiappa wrote: >> From: Geoff Huston > >> On the LISP page I already see LISP using IPv4 and IPv6 blocks for this >> experiment. > > Sorry, which blocks do you see being used for the 'facial EIDs' experiment? > (And which page is it you're looking at, to see this?) Hi Geoff, I am also curious about which block you talk about. Can you explain more? L. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Sun Nov 3 14:52:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8622E21E80EC for ; Sun, 3 Nov 2013 14:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rplol5Y-u92s for ; Sun, 3 Nov 2013 14:52:36 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56B21E80F9 for ; Sun, 3 Nov 2013 14:52:35 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so1717561bkz.39 for ; Sun, 03 Nov 2013 14:52:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uGJpXMXmckKWMw6CbWb6Hj9bRi3gjSrClr32wGVIyc8=; b=MwKDsSsbatdUJ7C5g1KtEquKPl448U4yN0uFeCseWGeGk/ar16B7/M3E+jzW20JJSo y51YLT3htFgeNAoBswJYAPGsAjjgzNWxIYlyxOfgUz+eHtFYO0LnCOahxAsuEyWHwbRW TU/+kxHXOZbNkHar9FVjPcoVvxztxPq0+/tLh6gNzDfElXK2UuvKBTKDE7pVGl+X4PLm TuMbkPJmsa4DAvlrbwx8e18UwJLP2fMAgc81XCi9MG4sFu8WNFqEn4oHx0PkYYfOVmUb uD+91IK6zxkHfOsMu90yeN6scd08HPMmtdhkQTBXA+n566arozZzU4EfxDCNQ4qKjJDL 4BYA== X-Gm-Message-State: ALoCoQkUcd7n4ffz5dZ0mM02x2/+cfBbln7QKh/ocaxqH/drzlAzJVmR6X8AbpzQj/4MnPYmJTdD X-Received: by 10.204.230.17 with SMTP id jk17mr4831443bkb.6.1383519154552; Sun, 03 Nov 2013 14:52:34 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id a4sm12745721bko.11.2013.11.03.14.52.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:52:33 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <87ED0701-79BC-4BA4-97F0-054EABAAB696@steffann.nl> Date: Sun, 3 Nov 2013 14:52:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <87ED0701-79BC-4BA4-97F0-054EABAAB696@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1816) Cc: Noel Chiappa , LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:52:41 -0000 Hi, On 31 Oct. 2013, at 09:31 , Sander Steffann wrote: >> I'll explain one experiment and will be crystal ear about it.=20 >>=20 >> (1) We want to have a LISP site send to both LISP sites and not LISP = sites.=20 >> (2) We want an ITR to do mapping database lookups when the = destination address is an EID.=20 >> (3) We want the ITR to forward packet s by doing a traditional FIB = lookup when the destination is not an EID.=20 >=20 > I understand what the technical idea is. There are already EIDs out = there (including my own network) that are not in any special prefix. = Therefore "address is in special prefix" !=3D "address is an EID=94. That is not correct. With an EID block you would have: Address in special prefix =3D=3D address is an EID Address not in special prefix !=3D is not an EID Basically if it is n the special block you know it is an EID, if it is = not in the special block you have no idea and you have to check. Luigi > Unless you break LISP for already existing sites I don't see how = having a special prefix is going to help in (correctly) determining = whether an address is an EID. >=20 >> Good Zen? >=20 > Sorry, still not (yet?) liking this idea. > Sander >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ggx@gigix.net Sun Nov 3 14:59:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21321E811C for ; Sun, 3 Nov 2013 14:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y99gN1QkJ86y for ; Sun, 3 Nov 2013 14:59:20 -0800 (PST) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id AD7A521E80EC for ; Sun, 3 Nov 2013 14:59:16 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w14so2516726bkz.8 for ; Sun, 03 Nov 2013 14:59:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=oQukREjFiIv9BVnKuuVoWEXwODI5UbH0NlNMKjaH97Q=; b=GIbPqrQ8r/d+H68TgzZeHk/tFC2+mCvFuQ9U01C9abb5ZvwO8y+KbbxnTrNfgUMNY3 FitQjHGcrkt452XL+cfgd2Mg4t+GuHzlLNRjA06ZMcPqp0/cdRTYBszgb9ZaajJNLct0 tSTyZcYBKlZsLMK4oH3nek722AxkcXNvPa6P+zyjPvdPt9QORYC91adlY4NtCQA9sTbg nvJ7LlCrBE68YcgGBCs5GOTlBkCo7dHL+N23dixTBU+Av8cX87qtceHZEPZfNjShLpJQ Z1PSwESSmA6uzHe2JOFVhQLm3UN4W0+R2kUiSZ/rm1oN9IzDbPorlsWgqQUJ7JmylQSS Xrdg== X-Gm-Message-State: ALoCoQmg6RzrjO+KY+I2DnXIQKDihyMNEkhe3bnRHnxnQxcJGvxAXCp4cvFwHQQ4Q4ht7R6oU8fU X-Received: by 10.204.171.17 with SMTP id f17mr799460bkz.38.1383519549306; Sun, 03 Nov 2013 14:59:09 -0800 (PST) Received: from dhcp-ac50.meeting.ietf.org (dhcp-ac50.meeting.ietf.org. [31.133.172.80]) by mx.google.com with ESMTPSA id pk7sm12749701bkb.2.2013.11.03.14.59.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 14:59:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D9628FFC-7769-4CD3-857A-63E826EE7673" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> Date: Sun, 3 Nov 2013 14:59:04 -0800 Message-Id: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1816) Cc: Noel Chiappa , LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:59:25 -0000 --Apple-Mail=_D9628FFC-7769-4CD3-857A-63E826EE7673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Geoff, Let=92s try to be constructive here, because I have no problem agreeing = that the text of the document can be improved, but would be helpful to = know where. You complain about unclear text, but your comments look like being on = the same unclear line ;-) On 30 Oct. 2013, at 22:02 , Geoff Huston wrote: [snip] >=20 > BGP is a huge success - it appears to route 100% of the address space. = If LISP=20 > becomes a huge success then why wouldn't it route 100% of the address = space, just > as BGP does today? And if it withers and dies then any dedicated = address > allocation will be too much at that point in time. If this is all = about an=20 > _experiment_ under some form of experimental constraint then what are = the > bounds of the experiment? What do you mean exactly by bounds?=20 IMO the real limit is to avoid indicting any more pain in the BGP = infrastructure. > What happens at the end of the experiment? Worst case in 3 years the block is back in the free pool.=20 > Why would there=20 > be a continuing need to corral LISP into its own dedicated corner of = the address > space? Is there something about scaling LISP to a full unicast routing = scale that > simply does not work? Or is corralling of LISP into a dedicated block = of addresses > unnecessary? Noel and Dino gave you long answers on these, I just agree with them. > Why do I feel that this experiment has not been well thought through? Help us to clarify, what we did exactly miss? Or what is the big lack we = did not cover? Thanks Luigi > Or if it has, then it seems to me that the mapping of parameters of = the proposed > experiment into the words in the two drafts relating to this proposed = action > is still lacking. >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_D9628FFC-7769-4CD3-857A-63E826EE7673 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Geoff,

Let=92s try to be constructive here, = because I have no problem agreeing that the text of the document can be = improved, but would be helpful to know = where.

You complain about unclear text, = but your comments look like being on the same unclear line = ;-)

On 30 Oct. 2013, at 22:02 , Geoff = Huston <gih@apnic.net> = wrote:

[snip]


BGP is a huge success - it appears = to route 100% of the address space. If LISP 
becomes a huge success = then why wouldn't it route 100% of the address space, just
as BGP = does today? And if it withers and dies then any dedicated = address
allocation will be too much at that point in time. If this is = all about an 
_experiment_ under some = form of  experimental constraint then what are the
bounds of the = experiment?

What do you mean = exactly by bounds? 

IMO the real limit is = to avoid indicting any more pain in the BGP = infrastructure.


What happens at the end of the = experiment?

Worst case in 3 years = the block is back in the free pool. 

Why would there 
be a continuing need to = corral LISP into its own dedicated corner of the address
space? Is = there something about scaling LISP to a full unicast routing scale = that
simply does not work? Or is corralling of LISP into a dedicated = block  of = addresses
unnecessary?

Noel and = Dino gave you long answers on these, I just agree with = them.


Why do I feel that this experiment has = not been well thought = through?

Help us to clarify, = what we did exactly miss? Or what is the big lack we did not = cover?

Thanks

Luigi


Or if = it has, then it seems to me that the mapping of parameters of the = proposed
experiment into the words in the two drafts relating to this = proposed action
is still = lacking.

regards,

   Geoff




_______________________________________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/m= ailman/listinfo/lisp

= --Apple-Mail=_D9628FFC-7769-4CD3-857A-63E826EE7673-- From farinacci@gmail.com Sun Nov 3 15:05:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7979B11E8243 for ; Sun, 3 Nov 2013 15:05:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kMxcXNlNW+1 for ; Sun, 3 Nov 2013 15:05:17 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6526E21E80ED for ; Sun, 3 Nov 2013 15:05:17 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so6169756pab.24 for ; Sun, 03 Nov 2013 15:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gGWdhA0fT1On9mwRBN7QmShhUda62MnYX0XkooJRu38=; b=diWBezi1ASi2x/fuawwxy+q5go+osmsenatNG4mR4MmGVOBhPWIhWN2X6br0Z9qFU7 Z9DdCchwDt1lW4DeveIvjzstgZrgLGoXncB7PvIWg1ZlLZVfrD/zSrbd3kmB8Ik2lzuW aeb8vShdTBKaJSYQKjanWIpjg/EnQe/8q3wy1zbVv92YlvWg4e+7f0GA4zXRMHG0swuZ xTd1HjDoQJ4/Pjn2P4vv2Zmdg4kpGbNOhSClmcOz0mfcO9PosAETT1PfnsUyNGXpbK3t rXY6SoPrrreo5HilJWoSZxYcUZqMLdK4uRvxu5Ign3YOPQGVCQVmlAd/3OhZXXySbejc QUrw== X-Received: by 10.68.216.35 with SMTP id on3mr14839297pbc.86.1383519917119; Sun, 03 Nov 2013 15:05:17 -0800 (PST) Received: from [10.45.166.251] ([156.39.10.22]) by mx.google.com with ESMTPSA id v4sm24233092pbq.31.2013.11.03.15.05.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:05:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: <532212FF-F504-4AD2-B23D-244E90071448@gigix.net> Date: Sun, 3 Nov 2013 15:05:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93E7EE83-35A0-498C-8137-97AEA0D160C7@gmail.com> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <532212FF-F504-4AD2-B23D-244E90071448@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:05:18 -0000 > For instance, if it is an EID block you can send toward a PITR or drop = if you think that PITR adds too much path stretch.=20 > Or during the resolution delay of a non-EID block destination you = forward toward a PETR or just natively. This is a good point, becasue if you just look in the BGP RIB to = determine if something is NOT an EID, then one could be mistaken if = PITRs are injecing EID-prefixes into the BGP RIB. Dino From farinacci@gmail.com Sun Nov 3 15:06:43 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6411E824A for ; Sun, 3 Nov 2013 15:06:43 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enKre75TEzdF for ; Sun, 3 Nov 2013 15:06:42 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8354C21E80FF for ; Sun, 3 Nov 2013 15:06:41 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so6183751pab.5 for ; Sun, 03 Nov 2013 15:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=krT4Le6XrhHBxuNtpcunTA+jmb7zBcvzxmags2XOhjo=; b=Xykkw9HwpwfghZ9H39O9JJXDsXHfh09RQ3cMRFxKVxKt9Lh8dcv2CDdqEzsStCbKOs tvQqEYmRbMyUMLnOMmHO7NIteMrv7ay0glmGoJ9xL9CrdCqgjNkAyEAPygb3oQ4m5VA3 g9e0Bj4MTIcvZTDWP54/rI4zeLnc4E4cwalknNxcs4YFWQ5cg+eNTYsTjZbsThCSgbOy THWslPezFj3gapQgGEx21Aj7FZ3SK0vOkHEb8ThgmFulg1xPff3DbPORWV1X+GkpmLB7 aLIkBWw2/r1ty/WzPEpEI5dtrT87yMqVrnSeVD7xYTRoV3HFh3JwYIcTTbcYf5aezw4e dEVw== X-Received: by 10.66.144.102 with SMTP id sl6mr14579035pab.96.1383520001109; Sun, 03 Nov 2013 15:06:41 -0800 (PST) Received: from [10.45.166.251] ([156.39.10.22]) by mx.google.com with ESMTPSA id uw6sm24250628pbc.8.2013.11.03.15.06.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:06:40 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: Date: Sun, 3 Nov 2013 15:06:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <59E678A4-ADD0-493C-A7B7-66BCAFDCCADE@gmail.com> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <87ED0701-79BC-4BA4-97F0-054EABAAB696@steffann.nl> To: Luigi Iannone X-Mailer: Apple Mail (2.1816) Cc: Noel Chiappa , LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:06:43 -0000 > That is not correct. With an EID block you would have: >=20 > Address in special prefix =3D=3D address is an EID >=20 > Address not in special prefix !=3D is not an EID Luigi, I would say if Address is not a special prefix, it may be an EID = but you can only find out by doing a mapping database lookup. > Basically if it is n the special block you know it is an EID, if it is = not in the special block you have no idea and you have to check. Right, true. Dino From jmh@joelhalpern.com Sun Nov 3 15:10:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90A21E8116 for ; Sun, 3 Nov 2013 15:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZaO+Mn153JE for ; Sun, 3 Nov 2013 15:10:15 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5164721E8126 for ; Sun, 3 Nov 2013 15:10:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 29C581C249C2; Sun, 3 Nov 2013 15:10:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-bc2c.meeting.ietf.org (dhcp-bc2c.meeting.ietf.org [31.133.188.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8FCF21C249BD; Sun, 3 Nov 2013 15:10:09 -0800 (PST) Message-ID: <5276D7D0.1020302@joelhalpern.com> Date: Sun, 03 Nov 2013 18:10:08 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Luigi Iannone , Dino Farinacci References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> In-Reply-To: <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:10:20 -0000 I believe (although I do not know for certain) that if we increase the length as suggested we will have a much easier time getting a block to experiment with. Yours, Joel On 11/3/13 5:30 PM, Luigi Iannone wrote: > Hi, > > I agree with Dino, > > if the issue is just the size let’s reduce it and do some experiments. > > On the other hand, I do not understand we people here are trying to reach a binary conclusion like “EID Block is important and useful” or “EID Block is useless” even before doing any experimentation. > > IMHO this is not the most logical order. We should first experiment, then we will have to know-how to make a decision. > > Exactly because there are different and opposite opinions let’s the technology itself, through experimentation, make the decision. > > Luigi > > > On 2 Nov. 2013, at 11:09 , Dino Farinacci wrote: > >> So it appears that: >> >> (1) People are all for experimenting. >> (2) People may be all for allocating a block if it is not too large. >> >> So would it be easier to swallow if we just request a /32 or smaller block. >> >> Are we just arguing over size? >> >> If the experiment proves we need to do something in production, then we go get larger blocks as Joel indicates. And if the experiment is complete and say we don't need a well-known block, we return the /32. >> >> Dino >> >> On Nov 2, 2013, at 10:44 AM, Joel M. Halpern wrote: >> >>> On the source side, the ITR had better know what EIDs it is working on behalf of (otherwise, it is a source for spoofed source address). So none of those cases seem to be affected by the allocation or non-allocation of a block. >>> >>> If we are going to do anything based on a block, we better make sure it can handle more than one block. Which means that at most we need a block for the duration of the test period. We do not need a block for the hoped for full success of LISP. If we really succeed, we can get an additional bigger block. >>> >>> Yours, >>> Joel >>> >>> On 11/1/13 10:33 AM, Dino Farinacci wrote: >>>>> I understand the importance of experimenting. But I am having >>>>> trouble getting my head around the possible value we want to >>>>> explore. Color me naive and stubborn, but individually so. >>>>> >>>>> Thinking about the ITR code path, if there is no block: >>>> >>>> Many are thinking in this context. It is one but there are other >>>> things WE COULD DO if we new a prefix was an EID. See below for some >>>> rough examples. And please don't ask for detail, because this is >>>> initial thinking. >>>> >>>>> Receive packet check cache for destination failing cache match, >>>>> query for destination. >>>> >>>> And there could be a failed match if the destination address was not >>>> an EID. Meaning this packet is coming to an ITR destined for a >>>> non-LISP site (regardless if the source address is an EID or not). So >>>> the ITR would have to query the mapping database. >>>> >>>> So let's break this down. If the source was an EID, one could say, >>>> "okay since I'm doing the new stuff the delay for a lookup to a >>>> non-LISP destination is the price I pay for getting multihoming for >>>> packets that come back to me". If the source was not an EID, then the >>>> old user that expects to go to a non-LISP site expects the packet >>>> loss or optimal routing path to continue. And if it does not, then >>>> the new service hurt existing users. >>>> >>>> Please note, this is when a site is bifurcated being a site that has >>>> some partial EID allocations and partial hosts that have not changed. >>>> And that either could send to EID or non-EID destinations. >>>> >>>> Yes, you could have a default PETR configured in the ITR so there is >>>> 0 packet loss, but then you may get a suboptimal path. And packets >>>> from a non-EID source to a non-EID destination could be inadvertently >>>> encapsulated to the PETR. Then the PETR would decap and deliver the >>>> packet based on a BGP path. >>>> >>>> I for one, would like to solve this problem. And I do not know if >>>> just a well-known, hard-coded, EID-block will do it. >>>> >>>>> And the ITR code path if there is a block: Receive packet check >>>>> cache for destiantion failing cache match, check for destination in >>>>> EID block If in EID block, query If not in EID block, query >>>> >>>> You are correct, but this box could be configured in way where the >>>> logic could change: >>>> >>>> Receive packet If EID-block strict configured If destination in >>>> EID-block, send query Else forward natively Else >>> above with no EID-block check> Endif >>>> >>>>> Now, if everything is in the EID block, I understand that the last >>>>> step above becomes "just send". But that appears to be a >>>>> counter-factual assumption. >>>>> >>>>> Yours, Joel >>>> >>>> Having an EID block could help us in these scenarios as well: >>>> >>>> (1) The block or any more specifics should not have a native-forward >>>> action in a Map-Reply returned by the mapping system. (2) The block >>>> or any more specifics should not be injected into BGP without a >>>> special community indicating that only PITRs should be advertising >>>> it. (3) If a destination that a NAT box receives has a source in this >>>> block, that translation should not be done (because it is not >>>> needed). (4) If the source is in this block we know we cannot build >>>> RPF trees in the core when the source sends multicast packets. (5) >>>> Maybe a special EID-block should indicate that this source host can >>>> only talk IPv6 and that stretched layer-2 subnets are prohibited. So >>>> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used >>>> and we don't move MAC frames across the underly and we certainly do >>>> not forward ARP packet, broadcast frames, and link-local multicast. >>>> >>>> Now all these things can be put in the mapping database, and give us >>>> the same answers but if we could keep load off the mapping database, >>>> this would be a good thing, a scalability feature. >>>> >>>> Dino >>>> >>>>> >>>>> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>>>>> >>>>>>> Actually, that use case is only helped by the EID block if you >>>>>>> can be sure that ALL the destination EIDs it will see will come >>>>>>> from the block. >>>>>> >>>>>> I don't believe so. It could just an efficiency play for one >>>>>> versus the other. >>>>>> >>>>>>> Which seems to be impossible to ensure in the general case. >>>>>>> And easy to achieve without an allocated block in many of the >>>>>>> special cases. >>>>>> >>>>>> Well the EID could mean it is behind a NAT and that ITRs should >>>>>> encapsulate to an RTR. Maybe one that is used by a default >>>>>> map-cache entry or a distinguished key on the mapping database. >>>>>> >>>>>> See there are sorts of things we could try. Again, "try" here >>>>>> means experimentation. >>>>>> >>>>>> Look how the pilot network was easier to debug since we had >>>>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>>>>> has been renting 2610:d0::/32. >>>>>> >>>>>> Dino >>>>>> >>>>> _______________________________________________ lisp mailing list >>>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From gih902@gmail.com Sun Nov 3 15:34:45 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010C011E8254 for ; Sun, 3 Nov 2013 15:34:45 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H-IpNMsJb9D for ; Sun, 3 Nov 2013 15:34:44 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DFB3B11E813A for ; Sun, 3 Nov 2013 15:34:43 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id x18so4935630lbi.16 for ; Sun, 03 Nov 2013 15:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/+taBGB2bCHw6mpRzUfFml+qj7Ou8XvRcl477OLBgmE=; b=XMV3aC8dz5bqzBQs+a1m9Yg1IlZx1c+scj+3ywFMOtzTsE8Qq3ynvKfka9gBE8M4sR AmhUSMjeD0cNmnytrwRz+TK2GweK+xzPUryntdKFfg6bEdUaiTPguU0Vl03GPs4t6NgZ lbEIeNZmJAta9CAipytpnbbu0CM/irlDfK3rF9OkfWoy0+QXZ9QTjZ9ozswMOK/W8jiX cDTlBPPYh0lhqZJF4rhUrol9NH+60iZ8OqVC/sFEIOHbn5iKZST2PjUWgYOynyyVFyuf 2J66a/qFw1N5l2wOXS4UNChbb4BiwZ7vEvACb+X6jpHOdOmhDj3kqDk7XRqWjd+5U/VU psPA== X-Received: by 10.152.9.2 with SMTP id v2mr2029laa.40.1383521682843; Sun, 03 Nov 2013 15:34:42 -0800 (PST) Received: from dhcp-b07f.meeting.ietf.org (dhcp-b07f.meeting.ietf.org. [31.133.176.127]) by mx.google.com with ESMTPSA id a9sm20012575lae.9.2013.11.03.15.34.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:34:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Geoff Huston In-Reply-To: <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> Date: Mon, 4 Nov 2013 10:34:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <41A7CEBF-71E5-419A-A418-2E74A9618B01@gmail.com> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Sun, 03 Nov 2013 15:38:01 -0800 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:34:45 -0000 On 3 Nov 2013, at 5:09 am, Dino Farinacci wrote: > So it appears that: >=20 > (1) People are all for experimenting. > (2) People may be all for allocating a block if it is not too large. >=20 > So would it be easier to swallow if we just request a /32 or smaller = block.=20 >=20 > Are we just arguing over size? >=20 (speaking personally) Yes. > If the experiment proves we need to do something in production, then = we go get larger blocks as Joel indicates. And if the experiment is = complete and say we don't need a well-known block, we return the /32. >=20 And that is something that I would be perfectly comfortable with. Geoff From ggx@gigix.net Sun Nov 3 15:58:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DE021E80D2 for ; Sun, 3 Nov 2013 15:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DxAFAS9W+J3 for ; Sun, 3 Nov 2013 15:58:09 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8589121E8118 for ; Sun, 3 Nov 2013 15:58:05 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id mx11so104515bkb.3 for ; Sun, 03 Nov 2013 15:58:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zTI/tyancxOLmHCRcc8RMoWwwgyqx/slo42Gy3/LXmg=; b=Z3ZUrcxOsyXSHsJSViF6HxDurIJpvjxgdsoCqvzDNxqkMIljE9FC+mFTmVY1IljpZ4 EL3Hu0fophr7whNd7IigdRsyihw1hEQI1MpAcqoRqG4TOQFJIX3KFQ6mw8tWhqtjJWGu jBxeqQS7IqLVoMvQwurNO01SHXv8L1UBedzJn9ZTltAj42gZ5RUCVy/K4ZshuOs1LcUd Aw5NU15rJYAOmXw1t8hwyOF23XwCi3GbC6yyKzCqrYVB3dbTRy4GlEpY4gxUaDjRyYfo mhURyqocau3cOXmZDl7YVwoAdcdVFGBrk1H2I6cy24+mPeWhVyeGq/U5d4HecPtcPAM9 /kOQ== X-Gm-Message-State: ALoCoQmXfMZUGe9Za/gDMVhQwFtxdLvbsInC3FRvPxj+XaNId/UPojZG3vlmi5AWrzclLJYMyCHT X-Received: by 10.205.20.74 with SMTP id qn10mr62279bkb.46.1383523082872; Sun, 03 Nov 2013 15:58:02 -0800 (PST) Received: from dhcp-9c46.meeting.ietf.org (dhcp-9c46.meeting.ietf.org. [31.133.156.70]) by mx.google.com with ESMTPSA id l5sm12858370bko.7.2013.11.03.15.58.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:58:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9FC1E656-F4FE-400F-A39A-13C36E26F4DB" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Luigi Iannone In-Reply-To: <1DCE82D6-625E-47A0-94D6-9883ED37E038@gmail.com> Date: Sun, 3 Nov 2013 15:57:58 -0800 Message-Id: <02A7B906-890A-469D-B04A-D317E4E660F9@gigix.net> References: <20131031222916.2EEAA18C180@mercury.lcs.mit.edu> <1DCE82D6-625E-47A0-94D6-9883ED37E038@gmail.com> To: Geoff Huston X-Mailer: Apple Mail (2.1816) Cc: Noel Chiappa , LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:58:15 -0000 --Apple-Mail=_9FC1E656-F4FE-400F-A39A-13C36E26F4DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 3 Nov. 2013, at 15:40 , Geoff Huston wrote: >=20 > On 4 Nov 2013, at 9:48 am, Luigi Iannone wrote: >=20 >>=20 >> On 31 Oct. 2013, at 15:29 , Noel Chiappa = wrote: >>=20 >>>> From: Geoff Huston >>>=20 >>>> On the LISP page I already see LISP using IPv4 and IPv6 blocks for = this >>>> experiment.=20 >>>=20 >>> Sorry, which blocks do you see being used for the 'facial EIDs' = experiment? >>> (And which page is it you're looking at, to see this?) >>=20 >> Hi Geoff, >>=20 >> I am also curious about which block you talk about. >>=20 >> Can you explain more? >>=20 >> L. >=20 >=20 > http://www.lisp4.net/beta-network/prefixes/ Geoff, these are prefixes that people use in the lisp-beta network, but they = should be confused with =93prefixes assigned to LISP=94. There is someone paying for these prefixes to allow a large community to = do experiments.=20 They are not bound in any specific manner to the LISP technology. The EID block has a totally different reason and scope. Luigi --Apple-Mail=_9FC1E656-F4FE-400F-A39A-13C36E26F4DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 3 Nov. 2013, at 15:40 , Geoff = Huston <gih902@gmail.com> = wrote:


On 4 Nov 2013, at 9:48 am, = Luigi Iannone <ggx@gigix.net> = wrote:


On 31 Oct. 2013, at 15:29 , = Noel Chiappa <jnc@mercury.lcs.mit.edu> = wrote:

From: = Geoff Huston <gih@apnic.net>

On the LISP page I already see LISP using IPv4 = and IPv6 blocks for this
experiment. 

Sorry, = which blocks do you see being used for the 'facial EIDs' = experiment?
(And which page is it you're looking at, to see = this?)

Hi Geoff,

I am also curious about = which block you talk about.

Can you explain = more?

L.


http://www.lisp4.net/= beta-network/prefixes/

Geoff,

these are prefixes that people use in the lisp-beta = network, but they should be confused with =93prefixes assigned to = LISP=94.

There is someone paying for these = prefixes to allow a large community to do = experiments. 

They are not bound in any = specific manner to the LISP technology.

The EID = block has a totally different reason and = scope.

Luigi


<= /body>= --Apple-Mail=_9FC1E656-F4FE-400F-A39A-13C36E26F4DB-- From farinacci@gmail.com Sun Nov 3 15:58:55 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF95A21E80DC for ; Sun, 3 Nov 2013 15:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgYbDjfIQ+jt for ; Sun, 3 Nov 2013 15:58:55 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id AA36F21E8118 for ; Sun, 3 Nov 2013 15:58:52 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id x10so5986472pdj.40 for ; Sun, 03 Nov 2013 15:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mcIa32tYF7jgRRabFf1+LeT0NWYK/rOOi8KN3HBsKS8=; b=EGciWc4AWBSfBhcENEjx6aTpCSgbaoPNoPO+/j3yN5vsVnjSQlU+otOGPNKuQwRAQ0 /TBNbn7xjeNww1biFHJHFr29dtBTkYxoyXFcK2kdetJTSXeVnCQyRdqmMmtl6L41A/lJ LF7ogFoPPjzUOaU0Al/6MS8UvZa384Q3SebuwtJSpy08X3LR7PsikY364sC5WSqTM5RR DpEYYZC3s5EtjaMV6wTQLijmHCpCRioKuiT/boRbE0gnyN+pPAKbgT2vmZIwVPOCFtot 0n1zwQwrrTZgmATXhIrUoepBMitxW0bNh8riBidmKHfUOjEeJDDGzIkoU8CQC9NHoH60 4hVg== X-Received: by 10.66.170.138 with SMTP id am10mr14637157pac.51.1383523132400; Sun, 03 Nov 2013 15:58:52 -0800 (PST) Received: from [10.6.164.76] (mobile-166-137-177-001.mycingular.net. [166.137.177.1]) by mx.google.com with ESMTPSA id zq10sm28777513pab.6.2013.11.03.15.58.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:58:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B511) In-Reply-To: <41A7CEBF-71E5-419A-A418-2E74A9618B01@gmail.com> Date: Sun, 3 Nov 2013 15:58:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2ADB02-08FC-4285-B231-DCF2A7F2A46B@gmail.com> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> <41A7CEBF-71E5-419A-A418-2E74A9618B01@gmail.com> To: Geoff Huston Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:58:55 -0000 Thanks for reply Geoff.=20 Closer to rough consensus, Dino > On Nov 3, 2013, at 3:34 PM, Geoff Huston wrote: >=20 >=20 >> On 3 Nov 2013, at 5:09 am, Dino Farinacci wrote: >>=20 >> So it appears that: >>=20 >> (1) People are all for experimenting. >> (2) People may be all for allocating a block if it is not too large. >>=20 >> So would it be easier to swallow if we just request a /32 or smaller bloc= k.=20 >>=20 >> Are we just arguing over size? >=20 > (speaking personally) Yes. >=20 >=20 >> If the experiment proves we need to do something in production, then we g= o get larger blocks as Joel indicates. And if the experiment is complete and= say we don't need a well-known block, we return the /32. >=20 >=20 > And that is something that I would be perfectly comfortable with. >=20 >=20 > Geoff >=20 >=20 From darlewis@cisco.com Sun Nov 3 16:30:50 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4E21E80A3 for ; Sun, 3 Nov 2013 16:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKVr+UVZFTTQ for ; Sun, 3 Nov 2013 16:30:45 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1B411E8256 for ; Sun, 3 Nov 2013 16:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=857; q=dns/txt; s=iport; t=1383525045; x=1384734645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SweH6MMdf7sqhceSmYpK7slm7tBPB6C67uRwtZr7nA8=; b=HItiLVxbFQLNQMRf1xdqzgElEnDnUfvZtkjIIwEoWS5tGoOEP8zS2060 OqMZ0mGZj6adFaTBN7I6LFUj8W0XWykRZ4DZEhbAl/og9L4kI+BtGKtZn wOZe1S8NssB1q1nvSncXjVHOWDkxbQdLroKMRJ+hBULJjd10pKN6ZSp8+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFvqdlKtJV2Y/2dsb2JhbABZgweBC79PgRoWdIIlAQEBAwF5EAIBCA4KLjIlAgQOBYd7Br1PjyUzB4MggQ4DmAqSCYMmgio X-IronPort-AV: E=Sophos;i="4.93,628,1378857600"; d="scan'208";a="280156636" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 04 Nov 2013 00:30:44 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA40Ui8J026907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 00:30:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 18:30:44 -0600 From: "Darrel Lewis (darlewis)" To: Luigi Iannone Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO2PUZC5Jl8rx8B0O7KJbwOz1stw== Date: Mon, 4 Nov 2013 00:30:44 +0000 Message-ID: <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> In-Reply-To: <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.184] Content-Type: text/plain; charset="Windows-1252" Content-ID: <88261EB18F8C2B4495C67B46A3D95777@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:30:51 -0000 On Nov 3, 2013, at 2:46 PM, Luigi Iannone wrote: >=20 > On 3 Nov. 2013, at 14:35 , Sander Steffann wrote: >=20 >> Hi, >>=20 >>> you are right. But IMHO this is one possible economic model. >>>=20 >>> What about third parties selling MR/MS services which include also PxTR= s services? >>=20 >> That is exactly what I am doing (oh, well, no real customers yet, but wo= rking on that :-). For the PxTR services such a third party would then only= announce the block(s) used by his own customers though. Providing free tra= nsit for the whole EID block would get kind of expensive if LISP takes off= =85 >=20 > =85. or an opportunity to have =93peering=94 agreements with other PxTR p= roviders ;-) We see just this (peering) happening between LISP Service Providers in the = US now. -Darrel From sander@steffann.nl Mon Nov 4 00:36:57 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889B21E813B for ; Mon, 4 Nov 2013 00:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyZDdymuI12j for ; Mon, 4 Nov 2013 00:36:50 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id 14B4F21E8136 for ; Mon, 4 Nov 2013 00:36:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 450CD45; Mon, 4 Nov 2013 09:36:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d39rc+vIKxCI; Mon, 4 Nov 2013 09:36:32 +0100 (CET) Received: from [IPv6:2a00:8640:1::5fe:6f10:3802:e9a2] (unknown [IPv6:2a00:8640:1:0:5fe:6f10:3802:e9a2]) by mail.sintact.nl (Postfix) with ESMTPSA id 0B4553D; Mon, 4 Nov 2013 09:36:32 +0100 (CET) References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63AD59A6-0888-4D66-B3A7-983637F94452@steffann.nl> X-Mailer: iPhone Mail (11B511) From: Sander Steffann Date: Mon, 4 Nov 2013 09:36:32 +0100 To: "Darrel Lewis (darlewis)" Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 08:36:57 -0000 Hi,=20 > We see just this (peering) happening between LISP Service Providers in the= US now. What exactly do you mean with 'peering' in this context? Cheers, Sander From pvinci@VinciConsulting.com Mon Nov 4 05:30:21 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFE911E81B9 for ; Mon, 4 Nov 2013 05:30:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFkjTAmQPfMd for ; Mon, 4 Nov 2013 05:30:15 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 567C811E80E6 for ; Mon, 4 Nov 2013 05:30:13 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 08:30:12 -0500 From: Paul Vinciguerra To: Luigi Iannone , Dino Farinacci Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO1kx0dbIlM3ai102Unv4UnHEzj5oPNeSAgAAERoCAABVugIAAZg6AgAB+owCAAIDagIABx8wAgAAG0ICAAev8AIAAlAWY Date: Mon, 4 Nov 2013 13:30:11 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807CB19B6E56@NYDC-EXCH01.vinci-consulting-corp.local> References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com>, <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> In-Reply-To: <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.119.75.106] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:30:21 -0000 I think this issue here is that the request is for a solution without a pro= blem.=0A= =0A= If you want to do experiments, lobby cisco to create a configuration option= of a list of, say "known-EID 153.16.224.0/20". =0A= =0A= That can be configured for these experiments.=0A= =0A= I have unused EID space, I am sure Sander and Cisco do as well. I have offe= red address space since we met back in Orlando.=0A= =0A= Once there is a track record and a real need for a block, then we have that= much more evidence to support a future request. If the experiments can be= done this way, then the block wasn't actually needed in the first place.= =0A= =0A= But the way this is positioned, "LISP" wants an address block. I am not su= re what that means. Is it the working group? Is it Cisco? Who is going to b= e the gatekeeper? Who will decide what experiments have or do not have meri= t to use part of the block.=0A= =0A= To float a real life LISP example:=0A= =0A= We are part of another LISP experiment, the DDT. DDT is a great technology= enhancement, not for the database indexing aspect, but for map-server peer= ing that allows for a more resilient topology. I am all for experimentatio= n. =0A= =0A= The public DDT roots experiment is a great example of such gating. Cisco i= s the gatekeeper here. Their DDT clients only allow for 4 roots per AFI. = And its filled by the gang of four: Cisco, InTouch, Us (Vinci Consulting/VX= Net), and Verisign. I was there when Mike Gibbs identified this over a yea= r and a half ago and was assured it would be expanded. It's still the same= today. Whether this is intentional control being influenced by the vendor= , or just a lack of resources, the outcome to the end user is the same. De= pending on your relationship to the vendor, you can choose your position as= to the reasons why. =0A= =0A= So I come back to my original question: Why do you need this block?=0A= =0A= Is is that you don't want to "rent" addresses? =0A= I would submit that this debate has cost all our employers more than any bl= ock would cost for a decade. =0A= =0A= Is it that the group doesn't want to renumber in the future? =0A= State it. I think the group gets credibility for admitting it.=0A= =0A= Is it going to minimize changes to the code?=0A= Any experiment _is_ a code change, no?=0A= =0A= Is the performance of a single large prefix orders of magnitude better that= a handful of configured prefixes? =0A= You all would know that much better than I would. =0A= =0A= I personally think that more will get done with small agile groups that wou= ld be empowered to try something on their own and succeed or fail quickly, = rather than this large command/control structure that requires merit to be = proven before the experiment to show the merit of the experiment being trie= d.=0A= =0A= Paul=0A= =0A= ________________________________________=0A= From: lisp-bounces@ietf.org [lisp-bounces@ietf.org] on behalf of Luigi Iann= one [ggx@gigix.net]=0A= Sent: Sunday, November 03, 2013 5:30 PM=0A= To: Dino Farinacci=0A= Cc: LISP mailing list list=0A= Subject: Re: [lisp] LISP EID Block Size=0A= =0A= Hi,=0A= =0A= I agree with Dino,=0A= =0A= if the issue is just the size let=92s reduce it and do some experiments.=0A= =0A= On the other hand, I do not understand we people here are trying to reach a= binary conclusion like =93EID Block is important and useful=94 or =93EID B= lock is useless=94 even before doing any experimentation.=0A= =0A= IMHO this is not the most logical order. We should first experiment, then w= e will have to know-how to make a decision.=0A= =0A= Exactly because there are different and opposite opinions let=92s the techn= ology itself, through experimentation, make the decision.=0A= =0A= Luigi=0A= =0A= From darlewis@cisco.com Mon Nov 4 06:45:21 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97121F9A5F for ; Mon, 4 Nov 2013 06:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXlIJAjQ1WMT for ; Mon, 4 Nov 2013 06:45:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A632311E817A for ; Mon, 4 Nov 2013 06:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1383576287; x=1384785887; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mGJGw3otEnA1o1EbSgyfH2N0l5N3eS5z4TUJtxGEtBg=; b=mKUQ1PJ2OByZT2TwxXrH2JEsHY6xnDg2zBDf90AqWlFZ+GbKtfdWoafC +8pWgj2VyHKAdtjAzqb1PriU+M9OuNXfgcDKaovh+D6cXzYz8f6UuZZa1 2mxE+I/q+DHpKtlEVshEefQGD2EtVg+Q0zYqNswl7fIWNNca2mfFuNaJR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMqxd1KtJV2Y/2dsb2JhbABZgweBC789gScWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWHewa+Oo8lMweDIIEOA5gKkgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="280378094" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 04 Nov 2013 14:44:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA4Eikem009366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:44:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:44:46 -0600 From: "Darrel Lewis (darlewis)" To: Sander Steffann Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO2PUZC5Jl8rx8B0O7KJbwOz1stw== Date: Mon, 4 Nov 2013 14:44:46 +0000 Message-ID: <08606A12-FC35-4F10-B984-EA39103077B2@cisco.com> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> <63AD59A6-0888-4D66-B3A7-983637F94452@steffann.nl> In-Reply-To: <63AD59A6-0888-4D66-B3A7-983637F94452@steffann.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.141] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 14:45:21 -0000 On Nov 4, 2013, at 12:36 AM, Sander Steffann wrote: > Hi,=20 >=20 >> We see just this (peering) happening between LISP Service Providers in t= he US now. >=20 > What exactly do you mean with 'peering' in this context? If a given PxTR provider is responsible for originating EID prefixes into t= he DFZ on behalf of their subscribers (LISP Mapping and Proxy services cust= omers) want to widen their footprint/capacity of transit of Proxy-ITRs, the= y can agree to exchange these EID-prefixes and announce them on each other'= s behalf. So if LISP Mapping/Proxy Provider Foo is originating 172.16.1.0/20 and LISP= Mapping/Proxy Provider Bar is originating 10.1.1.0/22, and they come to an= bilateral agreement to share Proxy-ITR capacity they can agree to peer (vi= a, for example, eBGP multi-hop) and propagate the prefixes that that the ot= her is originating. Note that the origin AS for these two EID prefixes rem= ains Foo and Bar's respectively. Today some providers are redistributing registered EID prefixes directly vi= a their map-servers, and some are using static routes independent of redist= ribution for origination. (I prefer the latter, but YMMV.) -Darrel= From darlewis@cisco.com Mon Nov 4 06:47:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3071F21E8195 for ; Mon, 4 Nov 2013 06:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOMcAyn2f5e1 for ; Mon, 4 Nov 2013 06:47:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 163E121E8198 for ; Mon, 4 Nov 2013 06:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8286; q=dns/txt; s=iport; t=1383576402; x=1384786002; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h52GpJLZRSpmTGR9XvQNKbsBTbp/mZmitsNhHFjllB0=; b=NCJiHcJEZpr/Gn/LSGYC6EnhOsHCtAYAqGiYhUMwFRPpZ/gnxt8Jwd/3 mVoW0Tta2K+EVgot5fHo3WCZ+EGVf3K+vG+ZNuSdxW0GwzO4gx6omG/zN Q17AteTWOxzC4CVSTbO7rYnIp8+inUUokOJKAIexwrUnwLWfHY/5mUPOA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEqyd1KtJV2c/2dsb2JhbABZgwc4U789gScWdIIlAQEBAwEBAQFrCwULAgEIGC4hBgslAgQOBRSHWwMJBg20OA2JZwSMaII9MweDIIEOA5QrgXSBa4xShTeDJoIq X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="277393791" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2013 14:46:40 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA4EkdBa004528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:46:39 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:46:38 -0600 From: "Darrel Lewis (darlewis)" To: "Joel M. Halpern" Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO2WyqC5Jl8rx8B0O7KJbwOz1stw== Date: Mon, 4 Nov 2013 14:46:38 +0000 Message-ID: References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <52728FCF.2060603@joelhalpern.com> <52734FA6.4040003@joelhalpern.com> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> <5276D7D0.1020302@joelhalpern.com> In-Reply-To: <5276D7D0.1020302@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.141] Content-Type: text/plain; charset="Windows-1252" Content-ID: <07EE529E7342514A8FE6A75CC7D13C76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 14:47:09 -0000 As I think Geof pointed out, if we increase the length to /32 we can use ex= isting allocation policies for experimentation. -Darrel On Nov 3, 2013, at 3:10 PM, Joel M. Halpern wrote: > I believe (although I do not know for certain) that if we increase the le= ngth as suggested we will have a much easier time getting a block to experi= ment with. >=20 > Yours, > Joel >=20 > On 11/3/13 5:30 PM, Luigi Iannone wrote: >> Hi, >>=20 >> I agree with Dino, >>=20 >> if the issue is just the size let=92s reduce it and do some experiments. >>=20 >> On the other hand, I do not understand we people here are trying to reac= h a binary conclusion like =93EID Block is important and useful=94 or =93EI= D Block is useless=94 even before doing any experimentation. >>=20 >> IMHO this is not the most logical order. We should first experiment, the= n we will have to know-how to make a decision. >>=20 >> Exactly because there are different and opposite opinions let=92s the te= chnology itself, through experimentation, make the decision. >>=20 >> Luigi >>=20 >>=20 >> On 2 Nov. 2013, at 11:09 , Dino Farinacci wrote: >>=20 >>> So it appears that: >>>=20 >>> (1) People are all for experimenting. >>> (2) People may be all for allocating a block if it is not too large. >>>=20 >>> So would it be easier to swallow if we just request a /32 or smaller bl= ock. >>>=20 >>> Are we just arguing over size? >>>=20 >>> If the experiment proves we need to do something in production, then we= go get larger blocks as Joel indicates. And if the experiment is complete = and say we don't need a well-known block, we return the /32. >>>=20 >>> Dino >>>=20 >>> On Nov 2, 2013, at 10:44 AM, Joel M. Halpern wrot= e: >>>=20 >>>> On the source side, the ITR had better know what EIDs it is working on= behalf of (otherwise, it is a source for spoofed source address). So none= of those cases seem to be affected by the allocation or non-allocation of = a block. >>>>=20 >>>> If we are going to do anything based on a block, we better make sure i= t can handle more than one block. Which means that at most we need a block= for the duration of the test period. We do not need a block for the hoped= for full success of LISP. If we really succeed, we can get an additional = bigger block. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 11/1/13 10:33 AM, Dino Farinacci wrote: >>>>>> I understand the importance of experimenting. But I am having >>>>>> trouble getting my head around the possible value we want to >>>>>> explore. Color me naive and stubborn, but individually so. >>>>>>=20 >>>>>> Thinking about the ITR code path, if there is no block: >>>>>=20 >>>>> Many are thinking in this context. It is one but there are other >>>>> things WE COULD DO if we new a prefix was an EID. See below for some >>>>> rough examples. And please don't ask for detail, because this is >>>>> initial thinking. >>>>>=20 >>>>>> Receive packet check cache for destination failing cache match, >>>>>> query for destination. >>>>>=20 >>>>> And there could be a failed match if the destination address was not >>>>> an EID. Meaning this packet is coming to an ITR destined for a >>>>> non-LISP site (regardless if the source address is an EID or not). So >>>>> the ITR would have to query the mapping database. >>>>>=20 >>>>> So let's break this down. If the source was an EID, one could say, >>>>> "okay since I'm doing the new stuff the delay for a lookup to a >>>>> non-LISP destination is the price I pay for getting multihoming for >>>>> packets that come back to me". If the source was not an EID, then the >>>>> old user that expects to go to a non-LISP site expects the packet >>>>> loss or optimal routing path to continue. And if it does not, then >>>>> the new service hurt existing users. >>>>>=20 >>>>> Please note, this is when a site is bifurcated being a site that has >>>>> some partial EID allocations and partial hosts that have not changed. >>>>> And that either could send to EID or non-EID destinations. >>>>>=20 >>>>> Yes, you could have a default PETR configured in the ITR so there is >>>>> 0 packet loss, but then you may get a suboptimal path. And packets >>>>> from a non-EID source to a non-EID destination could be inadvertently >>>>> encapsulated to the PETR. Then the PETR would decap and deliver the >>>>> packet based on a BGP path. >>>>>=20 >>>>> I for one, would like to solve this problem. And I do not know if >>>>> just a well-known, hard-coded, EID-block will do it. >>>>>=20 >>>>>> And the ITR code path if there is a block: Receive packet check >>>>>> cache for destiantion failing cache match, check for destination in >>>>>> EID block If in EID block, query If not in EID block, query >>>>>=20 >>>>> You are correct, but this box could be configured in way where the >>>>> logic could change: >>>>>=20 >>>>> Receive packet If EID-block strict configured If destination in >>>>> EID-block, send query Else forward natively Else >>>> above with no EID-block check> Endif >>>>>=20 >>>>>> Now, if everything is in the EID block, I understand that the last >>>>>> step above becomes "just send". But that appears to be a >>>>>> counter-factual assumption. >>>>>>=20 >>>>>> Yours, Joel >>>>>=20 >>>>> Having an EID block could help us in these scenarios as well: >>>>>=20 >>>>> (1) The block or any more specifics should not have a native-forward >>>>> action in a Map-Reply returned by the mapping system. (2) The block >>>>> or any more specifics should not be injected into BGP without a >>>>> special community indicating that only PITRs should be advertising >>>>> it. (3) If a destination that a NAT box receives has a source in this >>>>> block, that translation should not be done (because it is not >>>>> needed). (4) If the source is in this block we know we cannot build >>>>> RPF trees in the core when the source sends multicast packets. (5) >>>>> Maybe a special EID-block should indicate that this source host can >>>>> only talk IPv6 and that stretched layer-2 subnets are prohibited. So >>>>> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used >>>>> and we don't move MAC frames across the underly and we certainly do >>>>> not forward ARP packet, broadcast frames, and link-local multicast. >>>>>=20 >>>>> Now all these things can be put in the mapping database, and give us >>>>> the same answers but if we could keep load off the mapping database, >>>>> this would be a good thing, a scalability feature. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>>=20 >>>>>> On 10/31/13 7:19 PM, Dino Farinacci wrote: >>>>>>>>=20 >>>>>>>> Actually, that use case is only helped by the EID block if you >>>>>>>> can be sure that ALL the destination EIDs it will see will come >>>>>>>> from the block. >>>>>>>=20 >>>>>>> I don't believe so. It could just an efficiency play for one >>>>>>> versus the other. >>>>>>>=20 >>>>>>>> Which seems to be impossible to ensure in the general case. >>>>>>>> And easy to achieve without an allocated block in many of the >>>>>>>> special cases. >>>>>>>=20 >>>>>>> Well the EID could mean it is behind a NAT and that ITRs should >>>>>>> encapsulate to an RTR. Maybe one that is used by a default >>>>>>> map-cache entry or a distinguished key on the mapping database. >>>>>>>=20 >>>>>>> See there are sorts of things we could try. Again, "try" here >>>>>>> means experimentation. >>>>>>>=20 >>>>>>> Look how the pilot network was easier to debug since we had >>>>>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco >>>>>>> has been renting 2610:d0::/32. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>> _______________________________________________ lisp mailing list >>>>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From pvinci@VinciConsulting.com Mon Nov 4 07:22:35 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361E121E81CE for ; Mon, 4 Nov 2013 07:22:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9Tc-7BuMbJd for ; Mon, 4 Nov 2013 07:22:30 -0800 (PST) Received: from exchange.vinci-consulting-corp.com (exchange.vinci-consulting-corp.com [38.125.5.16]) by ietfa.amsl.com (Postfix) with ESMTP id 556FF11E826C for ; Mon, 4 Nov 2013 07:22:29 -0800 (PST) Received: from NYDC-EXCH01.vinci-consulting-corp.local ([::1]) by NYDC-EXCH01.vinci-consulting-corp.local ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 10:22:23 -0500 From: Paul Vinciguerra To: "Darrel Lewis (darlewis)" , Sander Steffann Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO1Yb6dbIlM3ai102Unv4UnHEzj5oOhLaAgACE1oCAAJD5AIAA3giAgAAgBYCAA9lAAIAAAPQAgAADAgCAAB0tAIAAh7wAgABm4gD//7PwoA== Date: Mon, 4 Nov 2013 15:22:22 +0000 Message-ID: <6E5736BD68F770449C74FBAD975F807CB19B77BE@NYDC-EXCH01.vinci-consulting-corp.local> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> <63AD59A6-0888-4D66-B3A7-983637F94452@steffann.nl> <08606A12-FC35-4F10-B984-EA39103077B2@cisco.com> In-Reply-To: <08606A12-FC35-4F10-B984-EA39103077B2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.119.75.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:22:35 -0000 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of D= arrel > Lewis (darlewis) > Sent: Monday, November 04, 2013 9:45 AM > To: Sander Steffann > Cc: LISP mailing list list > Subject: Re: [lisp] LISP EID Block Size >=20 >=20 > On Nov 4, 2013, at 12:36 AM, Sander Steffann wrote: >=20 > > Hi, > > > >> We see just this (peering) happening between LISP Service Providers in= the US > now. > > > > What exactly do you mean with 'peering' in this context? >=20 > If a given PxTR provider is responsible for originating EID prefixes into= the DFZ > on behalf of their subscribers (LISP Mapping and Proxy services customers= ) want > to widen their footprint/capacity of transit of Proxy-ITRs, they can agre= e to > exchange these EID-prefixes and announce them on each other's behalf. >=20 > So if LISP Mapping/Proxy Provider Foo is originating 172.16.1.0/20 and LI= SP > Mapping/Proxy Provider Bar is originating 10.1.1.0/22, and they come to a= n > bilateral agreement to share Proxy-ITR capacity they can agree to peer (v= ia, for > example, eBGP multi-hop) and propagate the prefixes that that the other i= s > originating. Note that the origin AS for these two EID prefixes remains = Foo and > Bar's respectively. >=20 > Today some providers are redistributing registered EID prefixes directly = via their > map-servers, and some are using static routes independent of redistributi= on for > origination. (I prefer the latter, but YMMV.) [PV]=20 Darrel, I am unaware of any providers in the US doing this. I would welcome any in= troductions on your part :)=20 Paul >=20 > -Darrel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From gih902@gmail.com Sun Nov 3 15:40:46 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE21221E8133 for ; Sun, 3 Nov 2013 15:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CUAwfagoQQ8 for ; Sun, 3 Nov 2013 15:40:46 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A599121E8148 for ; Sun, 3 Nov 2013 15:40:44 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w14so2567898bkz.36 for ; Sun, 03 Nov 2013 15:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G+txYS/4MgD0nGfGdeIL0Cn0QgDHi7rgITvAvRDXOTg=; b=KRR9oDK+w6T2x5qoA/3FXENSLMW7gGCJ/FNpSAVYqx1Clz9Z6RFVsOI/kuQGimenGo oN4MEKTA+14OqQ9CMCviioXhv9rpBruSlEXHiFq82Ow/tkJWL6yXVyqLSRyB3QMYorde ckl9klm0q2xhiOLmAm72O9muNXgkoO0duvdJ0iJ2krrDL6O0bV94e36b3SLPJsG1juvv qNxVR3ZCoym0v1vQ24oJJ7zWvpBop/uFE8kcy4Ja3NLuKX4Uba0rD5iJhdW2pOwu/DR3 WjtNxlFfIAGVSJ87M7Tyepj8pgt17igQBwd7lsoHaQ+FPBlBkBzwXkrQy+P7xrhDRGuL h0IA== X-Received: by 10.204.68.142 with SMTP id v14mr7461223bki.18.1383522043635; Sun, 03 Nov 2013 15:40:43 -0800 (PST) Received: from ?IPv6:2001:67c:370:176:523:2ef8:895c:10f8? ([2001:67c:370:176:523:2ef8:895c:10f8]) by mx.google.com with ESMTPSA id qg7sm12827455bkb.6.2013.11.03.15.40.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 15:40:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Geoff Huston In-Reply-To: Date: Mon, 4 Nov 2013 10:40:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DCE82D6-625E-47A0-94D6-9883ED37E038@gmail.com> References: <20131031222916.2EEAA18C180@mercury.lcs.mit.edu> To: Luigi Iannone X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Mon, 04 Nov 2013 08:07:49 -0800 Cc: Noel Chiappa , LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 23:40:47 -0000 On 4 Nov 2013, at 9:48 am, Luigi Iannone wrote: >=20 > On 31 Oct. 2013, at 15:29 , Noel Chiappa = wrote: >=20 >>> From: Geoff Huston >>=20 >>> On the LISP page I already see LISP using IPv4 and IPv6 blocks for = this >>> experiment.=20 >>=20 >> Sorry, which blocks do you see being used for the 'facial EIDs' = experiment? >> (And which page is it you're looking at, to see this?) >=20 > Hi Geoff, >=20 > I am also curious about which block you talk about. >=20 > Can you explain more? >=20 > L. http://www.lisp4.net/beta-network/prefixes/ From darlewis@cisco.com Mon Nov 4 09:12:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47F221E81BA for ; Mon, 4 Nov 2013 09:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+1GZaP4GQtQ for ; Mon, 4 Nov 2013 09:11:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1048E11E8325 for ; Mon, 4 Nov 2013 09:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=510; q=dns/txt; s=iport; t=1383584893; x=1384794493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CM2z0SWTNDgNTuuCQUGSr9Yj2g09wJp2+s07TJ1mHJs=; b=aLTor9ZyihHrdMeZ83oPzbTenlkro7iYmQfkmz1OIxL2LqIgyNqk3LVC nrKpjX3/qm7nzppgynr/tZjFYa2q6sQ6/1KtqFkaZxZmOo1bKbssi4CsX 5GLSuFJBaow7sW9HeyDSMDhWQCpvsJMixIH0XyMItyzY0i5uKkMnuN8Ih I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAMjTd1KtJXG8/2dsb2JhbABZgweBC78+gSkWdIIlAQEBAwE6PxACAQgOKBAyJQIEDgWHewa+VY8lMweDIIEOA5gKkgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,633,1378857600"; d="scan'208";a="280467095" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2013 17:08:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA4H84Qe000306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 17:08:04 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 11:08:03 -0600 From: "Darrel Lewis (darlewis)" To: Paul Vinciguerra Thread-Topic: [lisp] LISP EID Block Size Thread-Index: AQHO2PUZC5Jl8rx8B0O7KJbwOz1stw== Date: Mon, 4 Nov 2013 17:08:03 +0000 Message-ID: References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> <3C9E1CFD-642E-4590-92BB-E1E5F65F8B02@steffann.nl> <92D11F1F-CED7-4A98-B45F-FD91727624FE@gigix.net> <2BEFEBB6-AD3F-4493-8628-21F273D3CAB2@cisco.com> <63AD59A6-0888-4D66-B3A7-983637F94452@steffann.nl> <08606A12-FC35-4F10-B984-EA39103077B2@cisco.com> <6E5736BD68F770449C74FBAD975F807CB19B77BE@NYDC-EXCH01.vinci-consulting-corp.local> In-Reply-To: <6E5736BD68F770449C74FBAD975F807CB19B77BE@NYDC-EXCH01.vinci-consulting-corp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <87FFC35CEA52AB4A818C87363C8290A0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:12:01 -0000 On Nov 4, 2013, at 7:22 AM, Paul Vinciguerra w= rote: >> Today some providers are redistributing registered EID prefixes directly= via their >> map-servers, and some are using static routes independent of redistribut= ion for >> origination. (I prefer the latter, but YMMV.) > [PV]=20 > Darrel, >=20 > I am unaware of any providers in the US doing this. I would welcome any = introductions on your part :)=20 >=20 Sure, I'll talk to you off list. -Darrel From terry.manderson@icann.org Wed Nov 6 16:54:26 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589521E81B9 for ; Wed, 6 Nov 2013 16:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfkQAhZ7PxBj for ; Wed, 6 Nov 2013 16:54:21 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05421F9F5B for ; Wed, 6 Nov 2013 16:54:21 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 6 Nov 2013 16:54:20 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Wed, 6 Nov 2013 16:54:17 -0800 Thread-Topic: [lisp] Vancouver agenda items? Thread-Index: Ac7bU+Smv5GhwjMLTVCghECzmyAX4g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3466666457_8367751" MIME-Version: 1.0 Subject: Re: [lisp] Vancouver agenda items? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:54:26 -0000 --B_3466666457_8367751 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit WG REMINDER, Slides please presenters. I have received a couple, but certainly not all. This is important for remote participants, so while you may use you own device to present during the WG - that doesn't help anyone following remotely. Cheers Terry On 30/10/13 9:09 PM, "Terry Manderson" wrote: >All, > >A draft agenda has been uploaded to >https://datatracker.ietf.org/meeting/88/agenda/lisp/ > >If you see that you have been omitted from the agenda, and you requested a >slice: > Firstly, you have my apologies as I have an out of control email inbox. > (bad inbox, BAD) > > Secondly, please drop me a note. > >Presenters, please have slides to me by 5pm Wednesday the 6th Nov. > >For others still trying to make up their minds - I would urge you to email >sooner rather than later so Joel and I have time to review additional time >requests. > >Cheers >Terry > >On 18/10/13 5:39 PM, "Joel M. Halpern" wrote: > >>The LISP session is scheduled for Thursday morning from 9 till 11:30. >>We have received a few requests for agenda items. If anyone would like >>a slot and has not contact us for this meeting, please notify the chairs >>as to what the topic is, what the relevant draft is, and how much time >>you would like. >> >>Thank you, >>Joel and Terry >>_______________________________________________ >>lisp mailing list >>lisp@ietf.org >>https://www.ietf.org/mailman/listinfo/lisp --B_3466666457_8367751 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFGMvWbik0DMJqGGMsrhuBpA0k/HYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTEwNzAwNTQxN1owDQYJKoZIhvcNAQEBBQAEggEARGLqTym0 uDQSyOs46MhBfsSyfl3rBr/P5LvT9Va0WhJ1ED9XAN4Uc+OaIp2WqQe2kNjM8kWK44pY/HhY 3tDXBCxbM4Hkd7BnAKWC/vA/a50AdJGudF/GzpXq1QquEEBt5fVjHQIMJXg7jvYgxwRlxX9P ndaStZVCT3h+N67HbB8TfQCF7qE7AWG6c1hnuvj9MNDQlLe3n3i0kr7Ex7DRhfi50OGsPQpS QWT6CTDo/PEURVcWiCXPy4AswbB9SdLSxoxHoFeiG/mIZrX/dxAGtbwV/Nuhb2em/sydzgNb oB//zLwukqEloQiK1jG2QC6Pq6z+FrON6EAsqOj+NRcapA== --B_3466666457_8367751-- From ietf@bartschnet.de Thu Nov 7 06:56:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886E321E81F5 for ; Thu, 7 Nov 2013 06:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBxK3ZXTJPss for ; Thu, 7 Nov 2013 06:56:10 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2516B21E81D6 for ; Thu, 7 Nov 2013 06:56:09 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VeR0B-0004gw-JW for lisp@ietf.org; Thu, 07 Nov 2013 15:56:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 2013 15:56:07 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: <6752bcb45fda573d866b35ef0bb5e616@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] Android feature request for LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:56:21 -0000 I've created a LISP feature request for Android (http://code.google.com/p/android/issues/detail?id=61794). Please second that feature request with your names and companies showing it's a serious feature request to encourage Google to implement LISP into Android! :-) -- Best regards, Rene Bartsch, B. Sc. Informatics From ietf@bartschnet.de Thu Nov 7 07:02:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730C521E8234 for ; Thu, 7 Nov 2013 07:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_40=-0.185, HELO_EQ_DE=0.35, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjGX6qbRBH03 for ; Thu, 7 Nov 2013 07:02:15 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79821E823C for ; Thu, 7 Nov 2013 07:01:43 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VeR5O-0005uP-Ls for lisp@ietf.org; Thu, 07 Nov 2013 16:01:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 2013 16:01:30 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] =?utf-8?q?LISP_support_in_Linux_kernel=3F?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:02:25 -0000 Hi, are there any ongoing attempts to integrate LISP into the network stack of the Linux-kernel? That way we'd gain a foothold in most smartphones, tablets, embedded devices and Linux-servers/-desktops. -- Best regards, Rene Bartsch, B. Sc. Informatics From ietf@bartschnet.de Thu Nov 7 07:12:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC40521E8263 for ; Thu, 7 Nov 2013 07:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1t2oi86uFUI for ; Thu, 7 Nov 2013 07:11:55 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id E13F221E8261 for ; Thu, 7 Nov 2013 07:11:53 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VeRFP-0007jt-SD; Thu, 07 Nov 2013 16:11:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 2013 16:11:51 +0100 From: Rene Bartsch To: Luigi Iannone In-Reply-To: <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <8119249a5b4cb0604726fa7560538cf3@bartschnet.de> <82F5CF42-2E3A-444A-8449-39B01C0B2C3B@gigix.net> Message-ID: <31d13c04ea2cda6fc5cc28bcf88ce558@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Cc: LISP mailing list list Subject: Re: [lisp] LISP EID Block Size X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:12:00 -0000 Am 2013-11-03 23:32, schrieb Luigi Iannone: > On 1 Nov. 2013, at 05:45 , Sander Steffann wrote: > >> Hi, >> >>> I want to ask everyone on the list: Which facts prevent a scaling >>> experiment with the aim of global production state? In my opinion a >>> /16-EID-prefix is perfect for that goal. >> >> The problem is in that what you describe depends on public PITRs, and >> we have seen how badly that worked for 6to4 public relays. Running a >> public relay costs money (equipment, maintenance, bandwidth), and when >> nobody pays for them then we cannot expect any decent quality. And >> LISP will be blamed and seen as an unreliable protocol, just like >> 6to4. Relying on public relays is a very bad idea. > > Hi Sander, > > you are right. But IMHO this is one possible economic model. > > What about third parties selling MR/MS services which include also > PxTRs services? > > Luigi What about a dual approach? Third parties for highly reliable PxTRs and long-term integration of public PxTRs in the ISP-/backbone infrastructure to handle mass deployment for consumer roaming and IP portability. Today we have number porting between providers for phone numbers. Why not having global IP porting for consumers with a lifetime LISP-PI-prefix ...? Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From ljakab@ac.upc.edu Thu Nov 7 07:53:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B060911E8165 for ; Thu, 7 Nov 2013 07:53:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLqV-KPV9Iwp for ; Thu, 7 Nov 2013 07:53:48 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9512511E810F for ; Thu, 7 Nov 2013 07:53:47 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rA7FrhI0007424; Thu, 7 Nov 2013 16:53:44 +0100 Received: from dhcp-10-61-98-41.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) by gw.ac.upc.edu (Postfix) with ESMTP id 1F0AE6B0237; Thu, 7 Nov 2013 16:52:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Lori Jakab In-Reply-To: <6752bcb45fda573d866b35ef0bb5e616@bartschnet.de> Date: Thu, 7 Nov 2013 17:53:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6752bcb45fda573d866b35ef0bb5e616@bartschnet.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] Android feature request for LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:53:52 -0000 Hi Rene, While not integrated deep into the Android operating system, there is an = open source project implementing LISP for Android:http://lispmob.org/ = Not sure if you're already familiar with it, but you may want to take a = look. HTH, -Lori On Nov 7, 2013, at 4:56 PM, Rene Bartsch wrote: > I've created a LISP feature request for Android = (http://code.google.com/p/android/issues/detail?id=3D61794). >=20 > Please second that feature request with your names and companies = showing it's a serious feature request to encourage Google to implement = LISP into Android! :-) >=20 >=20 > --=20 > Best regards, >=20 > Rene Bartsch, B. Sc. Informatics > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Thu Nov 7 07:54:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D0821E809B for ; Thu, 7 Nov 2013 07:54:42 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFKnGS4EP8RB for ; Thu, 7 Nov 2013 07:54:36 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 976AF11E810F for ; Thu, 7 Nov 2013 07:54:35 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rA7FsWTU007747; Thu, 7 Nov 2013 16:54:32 +0100 Received: from dhcp-10-61-98-41.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) by gw.ac.upc.edu (Postfix) with ESMTP id E18376B0237; Thu, 7 Nov 2013 16:53:29 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Lori Jakab In-Reply-To: Date: Thu, 7 Nov 2013 17:54:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A3F3CE5-360C-4B63-8D1D-56AB6122BDED@ac.upc.edu> References: To: Rene Bartsch X-Mailer: Apple Mail (2.1508) Cc: lisp@ietf.org Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:54:42 -0000 Hello again :) Not to sound like a broken record :P, this is also not exactly what = you're asking for, but there is an implementation of LISP for the Open = vSwitch (OvS) project, which is a widely open source virtual switch. = The OvS project has a kernel data plane module, which is part of the = Linux kernel. There are two versions of this kernel module: one is part = of the Open vSwitch software distribution, the other is part of the = official Linux kernel. The second version typically lags behind in = terms of features, and currently has no LISP support. There is an = effort underway to change that. -Lori On Nov 7, 2013, at 5:01 PM, Rene Bartsch wrote: > Hi, >=20 > are there any ongoing attempts to integrate LISP into the network = stack of the Linux-kernel? >=20 > That way we'd gain a foothold in most smartphones, tablets, embedded = devices and Linux-servers/-desktops. >=20 > --=20 > Best regards, >=20 > Rene Bartsch, B. Sc. Informatics >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From xuxiaohu@huawei.com Thu Nov 7 10:11:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4611E825C; Thu, 7 Nov 2013 10:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=2.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZhN3nHCGUfB; Thu, 7 Nov 2013 10:11:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 611AE21E81C2; Thu, 7 Nov 2013 10:08:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ62628; Thu, 07 Nov 2013 18:08:22 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 18:07:40 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 18:08:22 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 02:08:14 +0800 From: Xuxiaohu To: "l3vpn@ietf.org" Thread-Topic: Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 Thread-Index: Ac7b4Ko9s6ZYJuKKSlmTI20ULf2POw== Date: Thu, 7 Nov 2013 18:08:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lisp@ietf.org" Subject: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:11:19 -0000 Hi co-author of this draft, As I had mentioned at the mic, the mechanism proposed in this draft needs t= o consider the prefix overlapping issue which has been considered and addre= ssed by LISP. To Ron, The default route on the spoke can not be resorted to address the potential= issue caused by the prefix overlapping issue. The reason is that it's the = longest-matching route 10/8, rather than the default route is used to route= the packet destined for 10.10.10.10, in the case where a route for 10/8 ha= s been returned to that spoke due to a request from that spoke for the long= est-matching route for a given host address 10.0.0.1. As a result, the tra= ffic for 10.10.10.10 would be forwarded to the nexthop for 10/8 which in tu= rn forward that traffic according to a more spefic route for 10.10.10.10. T= his is suboptimal. Assume the traffic volume for the destination of 10.10.1= 0.10 is high, how to trigger a requtst for a "real" direct route to 10.10.1= 0.10 if there exists a host route for 10.10.10.10/32 at the hub? One possib= le way is to always request a more specific route until a host route for th= e destination of the received packet is found at the spoke. Since this issue has been disccussed at LISP WG many years before. I copy t= his email to LISP as well. Best regards, Xiaohu= From acabello@ac.upc.edu Thu Nov 7 13:02:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E69911E81B3 for ; Thu, 7 Nov 2013 13:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhCuZF2tBiZ5 for ; Thu, 7 Nov 2013 13:02:08 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id D35D711E80D9 for ; Thu, 7 Nov 2013 13:02:07 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rA7L259J018422 for ; Thu, 7 Nov 2013 22:02:05 +0100 Received: from [192.168.0.200] (unknown [46.27.20.114]) by gw.ac.upc.edu (Postfix) with ESMTP id 895096B0237 for ; Thu, 7 Nov 2013 22:01:02 +0100 (CET) Message-ID: <527BFFC9.3050203@ac.upc.edu> Date: Thu, 07 Nov 2013 22:02:01 +0100 From: Albert Cabellos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:02:13 -0000 Hi You might be interested in http://lispmob.org This is a user-space linux implementation of LISP, we interface with the kernel through tun/tap and netlink. With this architecture we have a common code-base for linux, android and openwrt (embedded devices). From our experience we have found that it is easier to support several platforms from the user-space. Pretty much any linux "thing" has netlink and tun/tap, so supporting a new platform should be straightforward, in most cases just re-compiling. We actually used to have a data-plane lisp kernel module, the module is still public at the github lispmob repository. Regards Albert On 07/11/2013 16:01, Rene Bartsch wrote: > Hi, > > are there any ongoing attempts to integrate LISP into the network > stack of the Linux-kernel? > > That way we'd gain a foothold in most smartphones, tablets, embedded > devices and Linux-servers/-desktops. > From arnatal@ac.upc.edu Thu Nov 7 13:13:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431C221E816E for ; Thu, 7 Nov 2013 13:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE3E6Rf+xnTr for ; Thu, 7 Nov 2013 13:13:51 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 779B621E809F for ; Thu, 7 Nov 2013 13:13:51 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rA7LDos8018763 for ; Thu, 7 Nov 2013 22:13:50 +0100 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by gw.ac.upc.edu (Postfix) with ESMTP id B8C676B0237 for ; Thu, 7 Nov 2013 22:12:47 +0100 (CET) Received: by mail-lb0-f173.google.com with SMTP id w7so917037lbi.18 for ; Thu, 07 Nov 2013 13:13:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=23maReXAWma9O1FDIq6xzQ0DKhV6QjPldusMwA6b+qo=; b=m/OSlTL/ceE2NBVbhSkID6OAoIMW3FhGdYn5g1SjtPLJgWToeSmrWwSMVhPu1P+EpI etjsutshzzCbkGztWhwgTg16S0qnjo793EOE6iE30TjSh8yCL6G7iugEbuE6LPZpQky7 n6WgB/QqEkGVBD/bUUmQ5HPE17pw2ylfGAX9a95yOis/Xgv8iQjtplejd7wCBAXequRT Eoz2B5LuZ+jJJdH0ChPlpLeFpoFcU/re2hNjctQxulQebGnLA+pbEtvZFGGi5wXwZZXj 0BGAefRSZS8qrifSfMnWRlKrz3F5z6Vc40ALlkfWW0ATB4fSrLOHHFh9wu8BMvDXvzrJ aMZA== X-Received: by 10.152.225.161 with SMTP id rl1mr2891340lac.38.1383858829377; Thu, 07 Nov 2013 13:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.78.3 with HTTP; Thu, 7 Nov 2013 13:13:29 -0800 (PST) In-Reply-To: <527BFFC9.3050203@ac.upc.edu> References: <527BFFC9.3050203@ac.upc.edu> From: Alberto Rodriguez-Natal Date: Thu, 7 Nov 2013 22:13:29 +0100 Message-ID: To: Albert Cabellos Content-Type: multipart/alternative; boundary=001a113490faf1c61c04ea9cbd56 Cc: "lisp@ietf.org list" Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:13:56 -0000 --001a113490faf1c61c04ea9cbd56 Content-Type: text/plain; charset=ISO-8859-1 For your convenience, here is a pointer to the github that Albert just mentioned: https://github.com/LISPmob/lispmob/tree/release-0.2 Folders "lisp_int" and "lisp_mod" contain the LISPmob kernel code. Thanks, Alberto On Thu, Nov 7, 2013 at 10:02 PM, Albert Cabellos wrote: > Hi > > You might be interested in http://lispmob.org > > This is a user-space linux implementation of LISP, we interface with the > kernel through tun/tap and netlink. With this architecture we have a common > code-base for linux, android and openwrt (embedded devices). > > From our experience we have found that it is easier to support several > platforms from the user-space. Pretty much any linux "thing" has netlink > and tun/tap, so supporting a new platform should be straightforward, in > most cases just re-compiling. > > We actually used to have a data-plane lisp kernel module, the module is > still public at the github lispmob repository. > > Regards > > Albert > > On 07/11/2013 16:01, Rene Bartsch wrote: > >> Hi, >> >> are there any ongoing attempts to integrate LISP into the network stack >> of the Linux-kernel? >> >> That way we'd gain a foothold in most smartphones, tablets, embedded >> devices and Linux-servers/-desktops. >> >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a113490faf1c61c04ea9cbd56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For your convenience, here is a pointer to the g= ithub that Albert just mentioned:

https://github.com/LISPmob/lispmob/tree/relea= se-0.2

Folders "lisp_int" and "lisp_mod" contain the= LISPmob kernel code.

Thanks,
Alberto


On Thu, Nov 7, 2013 at = 10:02 PM, Albert Cabellos <acabello@ac.upc.edu> wrote:
Hi

You might be interested in http://lispmob.org

This is a user-space linux implementation of LISP, we interface with the ke= rnel through tun/tap and netlink. With this architecture we have a common c= ode-base for linux, android and openwrt (embedded devices).

>From our experience we have found that it is easier to support several plat= forms from the user-space. Pretty much any linux "thing" has netl= ink and tun/tap, so supporting a new platform should be straightforward, in= most cases just re-compiling.

We actually used to have a data-plane lisp kernel module, the module is sti= ll public at the github lispmob repository.

Regards

Albert

On 07/11/2013 16:01, Rene Bartsch wrote:
Hi,

are there any ongoing attempts to integrate LISP into the network stack of = the Linux-kernel?

That way we'd gain a foothold in most smartphones, tablets, embedded de= vices and Linux-servers/-desktops.


_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--001a113490faf1c61c04ea9cbd56-- From ietf@bartschnet.de Thu Nov 7 15:22:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2611E8278 for ; Thu, 7 Nov 2013 15:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agej4DFT6Kke for ; Thu, 7 Nov 2013 15:21:59 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 4366621E80BE for ; Thu, 7 Nov 2013 15:21:58 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VeYth-0008Ka-8N for lisp@ietf.org; Fri, 08 Nov 2013 00:21:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 2013 00:21:57 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: <527BFFC9.3050203@ac.upc.edu> References: <527BFFC9.3050203@ac.upc.edu> Message-ID: <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] =?utf-8?q?LISP_support_in_Linux_kernel=3F?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:22:04 -0000 Am 2013-11-07 22:02, schrieb Albert Cabellos: > Hi > > You might be interested in http://lispmob.org > > This is a user-space linux implementation of LISP, we interface with > the kernel through tun/tap and netlink. With this architecture we have > a common code-base for linux, android and openwrt (embedded devices). > > From our experience we have found that it is easier to support several > platforms from the user-space. Pretty much any linux "thing" has > netlink and tun/tap, so supporting a new platform should be > straightforward, in most cases just re-compiling. In my opinion LISPmob is a great project for experimenting, but for mass deployment it should be implemented in all devices by default - and the Linux-kernel is the most common layer of most internet-capable devices. ;-) Is there any chance LISPmob will work on Android without rooting? Maybe via VPN-API in 4.x? How is the roadmap for NAT-support? As my current router model does not support LISP, I wanted to cascade a Mikrotik Routerboard 493G (http://wiki.openwrt.org/toh/mikrotik/rb493g), but that's impossible as long as LISP can't traverse the NAT on the main router. German cellular providers use carrier grade NAT, so LISPmob can't be used on Android as long as it doesn't support NAT. Renne From arnatal@ac.upc.edu Thu Nov 7 16:09:16 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9741711E829A for ; Thu, 7 Nov 2013 16:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuQocZDcf7LE for ; Thu, 7 Nov 2013 16:09:11 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id B972D11E828F for ; Thu, 7 Nov 2013 16:09:10 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rA8099Sb023748 for ; Fri, 8 Nov 2013 01:09:09 +0100 Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by gw.ac.upc.edu (Postfix) with ESMTP id 786DE6B0285 for ; Fri, 8 Nov 2013 01:08:06 +0100 (CET) Received: by mail-la0-f50.google.com with SMTP id eo20so1071860lab.37 for ; Thu, 07 Nov 2013 16:09:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sRoQx0O6BNxL0KwgxDAnKnu0Ma1RvSs0lAEpITk+DjI=; b=gwK7RJpmveAI98TuYdHGZ/mCSBFp47XS28Vg+JU91sdqKQYxDi9TS8JzEe+P1S+v/U o4eNJUnKIrKIJu5kPC3H/JmULNz1ZpbGmqrjSv+qitkTNcuGYeBqHdXkBPmzkQUon36d NYFDZ7sm+0H0LQNoOKosTpQaQWPx2x3mQK+s+iRoBlEcRNJjYiHF5KqcPHbdylJchYMs lH5xwoO8F2Vc+0czpP67WCMu69voi1XAdlmqUWICSCt2iKBWJo/+PWTQUzY3jRmGid4x OLwd2YIwGS/+fydlOOLtvs1vL4X/v8+jgoD7cT83eYrEnBwsRlKQAP3UiPi2uE+SLLUQ XmmQ== X-Received: by 10.152.37.169 with SMTP id z9mr8285128laj.5.1383869348387; Thu, 07 Nov 2013 16:09:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.78.3 with HTTP; Thu, 7 Nov 2013 16:08:47 -0800 (PST) In-Reply-To: <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> References: <527BFFC9.3050203@ac.upc.edu> <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> From: Alberto Rodriguez-Natal Date: Fri, 8 Nov 2013 01:08:47 +0100 Message-ID: To: Rene Bartsch Content-Type: multipart/alternative; boundary=089e01494052ed214204ea9f30a6 Cc: "lisp@ietf.org list" Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:09:16 -0000 --089e01494052ed214204ea9f30a6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 8, 2013 at 12:21 AM, Rene Bartsch wrote: > Am 2013-11-07 22:02, schrieb Albert Cabellos: > > Hi >> >> You might be interested in http://lispmob.org >> >> This is a user-space linux implementation of LISP, we interface with >> the kernel through tun/tap and netlink. With this architecture we have >> a common code-base for linux, android and openwrt (embedded devices). >> >> From our experience we have found that it is easier to support several >> platforms from the user-space. Pretty much any linux "thing" has >> netlink and tun/tap, so supporting a new platform should be >> straightforward, in most cases just re-compiling. >> > > In my opinion LISPmob is a great project for experimenting, but for mass > deployment it should be implemented in all devices by default - and the > Linux-kernel is the most common layer of most internet-capable devices. ;-) > > Is there any chance LISPmob will work on Android without rooting? Maybe > via VPN-API in 4.x? > We are looking into it, but at this point the only available option is to run LISPmob on rooted devices... > > How is the roadmap for NAT-support? As my current router model does not > support LISP, I wanted to cascade a Mikrotik Routerboard 493G ( > http://wiki.openwrt.org/toh/mikrotik/rb493g), but that's impossible as > long as LISP can't traverse the NAT on the main router. German cellular > providers use carrier grade NAT, so LISPmob can't be used on Android as > long as it doesn't support NAT. > > LISPmob for Android already supports NAT traversal. You can find the latest code here: https://github.com/LISPmob/lispmob/tree/android We expect to offer a binary version (Android APK) on lispmob.org soon. Thanks, Alberto > Renne > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --089e01494052ed214204ea9f30a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Nov 8, 2013 at 12:21 AM, Rene Bartsch <= ;ietf@bartschnet.de= > wrote:
Am 2013-11-07 22:02, schr= ieb Albert Cabellos:

Hi

You might be interested in http://lispmob.org

This is a user-space linux implementation of LISP, we interface with
the kernel through tun/tap and netlink. With this architecture we have
a common code-base for linux, android and openwrt (embedded devices).

>From our experience we have found that it is easier to support several
platforms from the user-space. Pretty much any linux "thing" has<= br> netlink and tun/tap, so supporting a new platform should be
straightforward, in most cases just re-compiling.

In my opinion LISPmob is a great project for experimenting, but for mass de= ployment it should be implemented in all devices by default - and the Linux= -kernel is the most common layer of most internet-capable devices. ;-)

Is there any chance LISPmob will work on Android without rooting? Maybe via= VPN-API in 4.x?

We are looking into it= , but at this point the only available option is to run LISPmob on rooted d= evices...

How is the roadmap for NAT-support? As my current router model does not sup= port LISP, I wanted to cascade a Mikrotik Routerboard 493G (http://wiki.open= wrt.org/toh/mikrotik/rb493g), but that's impossible as long = as LISP can't traverse the NAT on the main router. German cellular prov= iders use carrier grade NAT, so LISPmob can't be used on Android as lon= g as it doesn't support NAT.

LISPmob for Android already supports NAT traversal. Y= ou can find the latest code here:

https://github.com/LISPmob/lispmob/tree/android

Thanks,
= Alberto
=A0
Renne


_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--089e01494052ed214204ea9f30a6-- From ietf@bartschnet.de Fri Nov 8 04:16:31 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42421E80B8 for ; Fri, 8 Nov 2013 04:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zMej6rrjTxR for ; Fri, 8 Nov 2013 04:16:25 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by ietfa.amsl.com (Postfix) with ESMTP id CF8DD11E8128 for ; Fri, 8 Nov 2013 04:16:24 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Vekz7-00017l-BL for lisp@ietf.org; Fri, 08 Nov 2013 13:16:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 2013 13:16:21 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 12:16:31 -0000 Hi, in the last week I proposed the idea of personal life-time EID-prefixes. What worried me most was a infrastructure (LIRs?) to assign EID-prefixes to natural persons. Now, I have an idea to solve the assignment problem: EIDs hashed of public RSA-keys. Each device can generate a 4096-bit RSA-key pair and use a 128-bit hash of the public RSA-key as EID. Using 128 bit would allow to blend in the hashed EID into the IPv6 address space. Security would also be improved as the RSA-key pair can be used to authenticate a device by calculating if the EID matches the public RSA-key of the device and the EID-RLOC-mapping entry on the map servers can be signed with the RSA-key pair of the device. Currently I'm considering the following two solutions: 1. /32 IPv6-prefix + 96-bit hash, low risk of EID collisions but bloats mapping tables, suitable for single mobile devices 2. /8 IPv6-prefix + 56-bit hash, high risk of EID collisions but goes easy on mapping tables, suitable for a /64 subnet behind a PxTR 3. Both Please comment the idea. Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From ietf@bartschnet.de Fri Nov 8 07:14:32 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9032E21E8140 for ; Fri, 8 Nov 2013 07:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B2--JPTW66t for ; Fri, 8 Nov 2013 07:14:26 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6EA21E8164 for ; Fri, 8 Nov 2013 07:14:26 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VenlR-0003D3-40 for lisp@ietf.org; Fri, 08 Nov 2013 16:14:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 2013 16:14:25 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: References: Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:14:32 -0000 Meanwhile I'm considering whether using a /64 EID-prefix with CGA addresses is the easier solution for 1.) It provides the following features for a single EID: - self-assigned - no registration necessary - no fees - static - public - globally roamable - provider-independent - EID-RLOC-mapping may be signed - hosts can be authenticated - the exchange of symmetric stream ciphers can be secured using the CGA-RSA-keys (e.g. by IPSec) It does not support the following features: - routable subnets Open questions: - can EID-RLOC mappings be signed/is there a data field in the distributed LISP-database structure for a signature? - allow the LISP-RFCs a LISP-site to contact a map server without authentication key and the map server checks only if the EID-RLOC-mapping is signed correctly before publishing? - how can (public) PITRs be encouraged to publish BGP-routes for a CGA-EID to themselves? - how can map servers be encouraged to provide a public service for anonymous users with self-assigned CGA-EIDs? Renne Am 2013-11-08 13:16, schrieb Rene Bartsch: > Hi, > > in the last week I proposed the idea of personal life-time > EID-prefixes. What worried me most was a infrastructure (LIRs?) to > assign EID-prefixes to natural persons. > > Now, I have an idea to solve the assignment problem: EIDs hashed of > public RSA-keys. > > Each device can generate a 4096-bit RSA-key pair and use a 128-bit > hash of the public RSA-key as EID. Using 128 bit would allow to blend > in the hashed EID into the IPv6 address space. > > Security would also be improved as the RSA-key pair can be used to > authenticate a device by calculating if the EID matches the public > RSA-key of the device and the EID-RLOC-mapping entry on the map > servers can be signed with the RSA-key pair of the device. > > Currently I'm considering the following two solutions: > > 1. /32 IPv6-prefix + 96-bit hash, low risk of EID collisions but > bloats mapping tables, suitable for single mobile devices > 2. /8 IPv6-prefix + 56-bit hash, high risk of EID collisions but goes > easy on mapping tables, suitable for a /64 subnet behind a PxTR > 3. Both > > Please comment the idea. > > Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From ietf@bartschnet.de Fri Nov 8 07:53:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C5611E81A3 for ; Fri, 8 Nov 2013 07:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdXBZ-m17BT7 for ; Fri, 8 Nov 2013 07:53:15 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id DF2A411E8184 for ; Fri, 8 Nov 2013 07:53:14 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VeoMy-00061p-NQ for lisp@ietf.org; Fri, 08 Nov 2013 16:53:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 2013 16:53:12 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: References: Message-ID: <3eaed7aec328a071504a4acf32a0dfbe@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:53:21 -0000 We can call such an EID "CGEID" or "Cryptographically Generated Endpoint IDentifier"! ;-) Renne Am 2013-11-08 16:14, schrieb Rene Bartsch: > Meanwhile I'm considering whether using a /64 EID-prefix with CGA > addresses is the easier solution for 1.) > > It provides the following features for a single EID: > > - self-assigned > - no registration necessary > - no fees > - static > - public > - globally roamable > - provider-independent > - EID-RLOC-mapping may be signed > - hosts can be authenticated > - the exchange of symmetric stream ciphers can be secured using the > CGA-RSA-keys (e.g. by IPSec) > > > It does not support the following features: > > - routable subnets > > > Open questions: > > - can EID-RLOC mappings be signed/is there a data field in the > distributed LISP-database structure for a signature? > - allow the LISP-RFCs a LISP-site to contact a map server without > authentication key and the map server checks only if the > EID-RLOC-mapping is signed correctly before publishing? > - how can (public) PITRs be encouraged to publish BGP-routes for a > CGA-EID to themselves? > - how can map servers be encouraged to provide a public service for > anonymous users with self-assigned CGA-EIDs? > > > Renne > > > > > Am 2013-11-08 13:16, schrieb Rene Bartsch: >> Hi, >> >> in the last week I proposed the idea of personal life-time >> EID-prefixes. What worried me most was a infrastructure (LIRs?) to >> assign EID-prefixes to natural persons. >> >> Now, I have an idea to solve the assignment problem: EIDs hashed of >> public RSA-keys. >> >> Each device can generate a 4096-bit RSA-key pair and use a 128-bit >> hash of the public RSA-key as EID. Using 128 bit would allow to blend >> in the hashed EID into the IPv6 address space. >> >> Security would also be improved as the RSA-key pair can be used to >> authenticate a device by calculating if the EID matches the public >> RSA-key of the device and the EID-RLOC-mapping entry on the map >> servers can be signed with the RSA-key pair of the device. >> >> Currently I'm considering the following two solutions: >> >> 1. /32 IPv6-prefix + 96-bit hash, low risk of EID collisions but >> bloats mapping tables, suitable for single mobile devices >> 2. /8 IPv6-prefix + 56-bit hash, high risk of EID collisions but goes >> easy on mapping tables, suitable for a /64 subnet behind a PxTR >> 3. Both >> >> Please comment the idea. >> >> Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From ietf@bartschnet.de Fri Nov 8 09:05:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B711E81A6 for ; Fri, 8 Nov 2013 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0e1R8wVQyW8 for ; Fri, 8 Nov 2013 09:05:53 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2811E80DC for ; Fri, 8 Nov 2013 09:05:52 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VepV7-00014c-9r for lisp@ietf.org; Fri, 08 Nov 2013 18:05:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Nov 2013 18:05:41 +0100 From: Rene Bartsch To: lisp@ietf.org In-Reply-To: <3eaed7aec328a071504a4acf32a0dfbe@bartschnet.de> References: <3eaed7aec328a071504a4acf32a0dfbe@bartschnet.de> Message-ID: <2624d125eecd41d8b129c4dd59ba0413@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:05:59 -0000 Another topic for the open questions list: - how to manage reverse DNS for CGEIDs? Can we provide some kind of LISP-MAP->DNS-proxy acting as PrimaryDNS? Is it possible a LISP-site can provide a RDNS-name for CGEID via the LISP mapping system for that proxy? Renne Am 2013-11-08 16:53, schrieb Rene Bartsch: > We can call such an EID "CGEID" or "Cryptographically Generated > Endpoint IDentifier"! ;-) > > Renne > > > Am 2013-11-08 16:14, schrieb Rene Bartsch: >> Meanwhile I'm considering whether using a /64 EID-prefix with CGA >> addresses is the easier solution for 1.) >> >> It provides the following features for a single EID: >> >> - self-assigned >> - no registration necessary >> - no fees >> - static >> - public >> - globally roamable >> - provider-independent >> - EID-RLOC-mapping may be signed >> - hosts can be authenticated >> - the exchange of symmetric stream ciphers can be secured using the >> CGA-RSA-keys (e.g. by IPSec) >> >> >> It does not support the following features: >> >> - routable subnets >> >> >> Open questions: >> >> - can EID-RLOC mappings be signed/is there a data field in the >> distributed LISP-database structure for a signature? >> - allow the LISP-RFCs a LISP-site to contact a map server without >> authentication key and the map server checks only if the >> EID-RLOC-mapping is signed correctly before publishing? >> - how can (public) PITRs be encouraged to publish BGP-routes for a >> CGA-EID to themselves? >> - how can map servers be encouraged to provide a public service for >> anonymous users with self-assigned CGA-EIDs? >> >> >> Renne >> >> >> >> >> Am 2013-11-08 13:16, schrieb Rene Bartsch: >>> Hi, >>> >>> in the last week I proposed the idea of personal life-time >>> EID-prefixes. What worried me most was a infrastructure (LIRs?) to >>> assign EID-prefixes to natural persons. >>> >>> Now, I have an idea to solve the assignment problem: EIDs hashed of >>> public RSA-keys. >>> >>> Each device can generate a 4096-bit RSA-key pair and use a 128-bit >>> hash of the public RSA-key as EID. Using 128 bit would allow to blend >>> in the hashed EID into the IPv6 address space. >>> >>> Security would also be improved as the RSA-key pair can be used to >>> authenticate a device by calculating if the EID matches the public >>> RSA-key of the device and the EID-RLOC-mapping entry on the map >>> servers can be signed with the RSA-key pair of the device. >>> >>> Currently I'm considering the following two solutions: >>> >>> 1. /32 IPv6-prefix + 96-bit hash, low risk of EID collisions but >>> bloats mapping tables, suitable for single mobile devices >>> 2. /8 IPv6-prefix + 56-bit hash, high risk of EID collisions but >>> goes >>> easy on mapping tables, suitable for a /64 subnet behind a PxTR >>> 3. Both >>> >>> Please comment the idea. >>> >>> Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From farinacci@gmail.com Fri Nov 8 20:04:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFFA21E80DB for ; Fri, 8 Nov 2013 20:04:30 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgpsmSWVCWRH for ; Fri, 8 Nov 2013 20:04:29 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C36B711E80E2 for ; Fri, 8 Nov 2013 20:04:29 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ld10so3108442pab.10 for ; Fri, 08 Nov 2013 20:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i/crgnICT5HCp/K7l6m0rWpSok7idulOeOHNxRdSAds=; b=XxkuTGfdCAURL4xDLJuCOLzW9My/UqfHeWG3Bv0Sbz8/j1nxCwuH2lt5mrDkSmJ5sM MXGTX4QF50T+DtksgKSH5QWRFB9L09SUuoRREX7epOkZ+Mu2XelhhML0G7fFnIA3DF00 3hmyymnVry2O6i79YP5Q7q4seUCNtT79HsKOYx9CcQvJpzHsqgtWTS0ylOZeV9WyG3mu 9yCjfLM3uJZ6dtoV/Uvk3UuE4486uwvfshJmlx4H+gv6eF+Mlu0Nn96dUNyLCHIbNAxI pyKgJ0017z4YAOZ45kuRWoyNqlG7JhQmTmePUqsNNGQbgpEKvdkjLw+RSO+RxzeIO8Xf b9+A== X-Received: by 10.66.139.166 with SMTP id qz6mr19374781pab.88.1383969869411; Fri, 08 Nov 2013 20:04:29 -0800 (PST) Received: from [172.20.10.3] (mobile-198-228-212-167.mycingular.net. [198.228.212.167]) by mx.google.com with ESMTPSA id fb3sm15568545pbc.29.2013.11.08.20.04.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 20:04:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Dino Farinacci In-Reply-To: Date: Fri, 8 Nov 2013 20:04:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rene Bartsch X-Mailer: Apple Mail (2.1816) Cc: LISP mailing list list Subject: Re: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 04:04:30 -0000 This is similar to HIP's HIT based addresses. I think it is an = interesting idea and you should persue it by writing up a draft. Dino On Nov 8, 2013, at 4:16 AM, Rene Bartsch wrote: > Hi, >=20 > in the last week I proposed the idea of personal life-time = EID-prefixes. What worried me most was a infrastructure (LIRs?) to = assign EID-prefixes to natural persons. >=20 > Now, I have an idea to solve the assignment problem: EIDs hashed of = public RSA-keys. >=20 > Each device can generate a 4096-bit RSA-key pair and use a 128-bit = hash of the public RSA-key as EID. Using 128 bit would allow to blend in = the hashed EID into the IPv6 address space. >=20 > Security would also be improved as the RSA-key pair can be used to = authenticate a device by calculating if the EID matches the public = RSA-key of the device and the EID-RLOC-mapping entry on the map servers = can be signed with the RSA-key pair of the device. >=20 > Currently I'm considering the following two solutions: >=20 > 1. /32 IPv6-prefix + 96-bit hash, low risk of EID collisions but = bloats mapping tables, suitable for single mobile devices > 2. /8 IPv6-prefix + 56-bit hash, high risk of EID collisions but goes = easy on mapping tables, suitable for a /64 subnet behind a PxTR > 3. Both >=20 > Please comment the idea. >=20 > Renne >=20 >=20 > --=20 > Best regards, >=20 > Rene Bartsch, B. Sc. Informatics > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rraszuk@gmail.com Fri Nov 8 22:09:43 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4721E80CE; Fri, 8 Nov 2013 22:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opFBj5Qg5Xuj; Fri, 8 Nov 2013 22:09:42 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 953A211E8160; Fri, 8 Nov 2013 22:09:41 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id to1so3079256ieb.9 for ; Fri, 08 Nov 2013 22:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L16BtakHYi+idkJHq8NzBQUMMDRqeAN3yPqQ8I2j7hA=; b=XBazWsUIJcYeHP24Dgsaf52WNCw0CewDHj+3CWaTmW4eP+F5O9KPMNjonGtH+c2QUa KRnt1zXIPUhKEr3W2FxzfNCozfD2J5GwtMWTU8OQfa99g6zR5CDqS164UEpg2REzsuki MBRpofML5+gbY0N9RBN6AiGoyCvk+IWv768TrSUUtl+GDI8hATFNJsdDtszeMSvpcu+6 Fg3uhL+uj2a6xa1IWHXFIcIxtIOtrQI2qQPjc2Xd4f7yfbpxCC5Muk+es7u26+Pm/+iN Fic+dE88le3ODPQ6pU9G6FK+5ltVYc2gABC1NoZVBzIa28dti9wLbO9gPAsxe/xrUgJN lhUg== MIME-Version: 1.0 X-Received: by 10.50.117.103 with SMTP id kd7mr5458527igb.4.1383977381336; Fri, 08 Nov 2013 22:09:41 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 8 Nov 2013 22:09:41 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> Date: Sat, 9 Nov 2013 07:09:41 +0100 X-Google-Sender-Auth: IgepLOYW2K6lmNJ0NygwMRG9hqE Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=ISO-8859-1 Cc: "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:09:44 -0000 Hi Xiaohu, While you are asking Ron directly you are cc-ing the lists so let me clarify your observation .. In each L3VPN context each PE advertise set of routes towards other PEs. Those routes are most often advertised via RR. I have never seen the case where RR or set of RRs would in any sort summarize routes more then PEs advertise. So if site has a host with the address of 10.10.10.10 which our high bandwith flow is destined to PE (or PEs) connected to such site will advertise the most specific subnet possible to reach 10.10.10.10. And that is all what is needed here. Based on the request from the v-spoke RR will return the longest match which will have next hop pointing to one of PEs connected the end site. I see really no problem there. If customer/provider on purpose enforced that to get to 10.10.10.10 you need to traverse some other site (for example DMZ/firewall/service XYZ) that is on purpose and we MUST honor it. This draft RFC7024 can not modify such routing enforced by customer. Best, R. PS. I see no relation to LISP here ;) From xuxiaohu@huawei.com Fri Nov 8 22:37:08 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD411E8100; Fri, 8 Nov 2013 22:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.156 X-Spam-Level: * X-Spam-Status: No, score=1.156 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+GDoHxjiECY; Fri, 8 Nov 2013 22:37:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE911E80E7; Fri, 8 Nov 2013 22:37:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB71257; Sat, 09 Nov 2013 06:36:58 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 06:36:53 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 06:36:57 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 14:36:49 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 Thread-Index: AQHO3RJNFCbVoFDJaEyCzaQ7NJc1dJocbSd8 Date: Sat, 9 Nov 2013 06:36:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.237] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" , "lisp@ietf.org" Subject: [lisp] =?gb2312?b?tPC4tDogIFByZWZpeCBvdmVybGFwcGluZyBpc3N1ZSBm?= =?gb2312?b?b3IJZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0w?= =?gb2312?b?MA==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:37:08 -0000 SGkgUm9iZXJ0LA0KDQpBcyBsb25nIGFzIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgb2YgcHJlZml4 IG92ZXJsYXBwaW5nIHdpdGhpbiBhIGdpdmVuIFZQTiBpbnN0YW5jZSwgdGhlIG1lY2hhbmlzbSBk ZWZpbmVkIGluIHRoaXMgZHJhZnQgd291bGQgZW5jb3VudGVyIHRoZSBzYW1lIHByb2JsZW0gdGhh dCBMSVNQIGhhZCBldmVyIGVuY291bnRlcmVkLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbGlzcC1ib3Vu Y2VzQGlldGYub3JnIFtsaXNwLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9iZXJ0IFJhc3p1ayBb cm9iZXJ0QHJhc3p1ay5uZXRdDQq3osvNyrG85DogMjAxM8TqMTHUwjnI1SAxNDowOQ0KytW8/sjL OiBYdXhpYW9odQ0Ks63LzTogbDN2cG5AaWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNCtb3zOI6IFJl OiBbbGlzcF0gUHJlZml4IG92ZXJsYXBwaW5nIGlzc3VlIGZvciAgICAgZHJhZnQtYm9uaWNhLWwz dnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0wMA0KDQpIaSBYaWFvaHUsDQoNCldoaWxlIHlvdSBh cmUgYXNraW5nIFJvbiBkaXJlY3RseSB5b3UgYXJlIGNjLWluZyB0aGUgbGlzdHMgc28gbGV0IG1l DQpjbGFyaWZ5IHlvdXIgb2JzZXJ2YXRpb24gLi4NCg0KSW4gZWFjaCBMM1ZQTiBjb250ZXh0IGVh Y2ggUEUgYWR2ZXJ0aXNlIHNldCBvZiByb3V0ZXMgdG93YXJkcyBvdGhlcg0KUEVzLiBUaG9zZSBy b3V0ZXMgYXJlIG1vc3Qgb2Z0ZW4gYWR2ZXJ0aXNlZCB2aWEgUlIuDQoNCkkgaGF2ZSBuZXZlciBz ZWVuIHRoZSBjYXNlIHdoZXJlIFJSIG9yIHNldCBvZiBSUnMgd291bGQgaW4gYW55IHNvcnQNCnN1 bW1hcml6ZSByb3V0ZXMgbW9yZSB0aGVuIFBFcyBhZHZlcnRpc2UuDQoNClNvIGlmIHNpdGUgaGFz IGEgaG9zdCB3aXRoIHRoZSBhZGRyZXNzIG9mIDEwLjEwLjEwLjEwIHdoaWNoIG91ciBoaWdoDQpi YW5kd2l0aCBmbG93IGlzIGRlc3RpbmVkIHRvIFBFIChvciBQRXMpIGNvbm5lY3RlZCB0byBzdWNo IHNpdGUgd2lsbA0KYWR2ZXJ0aXNlIHRoZSBtb3N0IHNwZWNpZmljIHN1Ym5ldCBwb3NzaWJsZSB0 byByZWFjaCAxMC4xMC4xMC4xMC4NCg0KQW5kIHRoYXQgaXMgYWxsIHdoYXQgaXMgbmVlZGVkIGhl cmUuDQoNCkJhc2VkIG9uIHRoZSByZXF1ZXN0IGZyb20gdGhlIHYtc3Bva2UgUlIgd2lsbCByZXR1 cm4gdGhlIGxvbmdlc3QgbWF0Y2gNCndoaWNoIHdpbGwgaGF2ZSBuZXh0IGhvcCBwb2ludGluZyB0 byBvbmUgb2YgUEVzIGNvbm5lY3RlZCB0aGUgZW5kDQpzaXRlLiBJIHNlZSByZWFsbHkgbm8gcHJv YmxlbSB0aGVyZS4NCg0KSWYgY3VzdG9tZXIvcHJvdmlkZXIgb24gcHVycG9zZSBlbmZvcmNlZCB0 aGF0IHRvIGdldCB0byAxMC4xMC4xMC4xMA0KeW91IG5lZWQgdG8gdHJhdmVyc2Ugc29tZSBvdGhl ciBzaXRlIChmb3IgZXhhbXBsZSBETVovZmlyZXdhbGwvc2VydmljZQ0KWFlaKSB0aGF0IGlzIG9u IHB1cnBvc2UgYW5kIHdlIE1VU1QgaG9ub3IgaXQuIFRoaXMgZHJhZnQgUkZDNzAyNCBjYW4NCm5v dCBtb2RpZnkgc3VjaCByb3V0aW5nIGVuZm9yY2VkIGJ5IGN1c3RvbWVyLg0KDQpCZXN0LA0KUi4N Cg0KUFMuIEkgc2VlIG5vIHJlbGF0aW9uIHRvIExJU1AgaGVyZSA7KQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNw QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3A= From rraszuk@gmail.com Fri Nov 8 22:51:24 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4D911E811A; Fri, 8 Nov 2013 22:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.337 X-Spam-Level: ** X-Spam-Status: No, score=2.337 tagged_above=-999 required=5 tests=[AWL=-3.580, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QsZezjIWclp; Fri, 8 Nov 2013 22:51:24 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1751E11E80E7; Fri, 8 Nov 2013 22:51:24 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id x13so2111742ief.7 for ; Fri, 08 Nov 2013 22:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LpT0wQJp9yzpLSzyP1TH6OJ82UNc4U1DsAis6QAohxY=; b=Qfj6pgT3Le2cu9wgAKlZlJHVgw7yD5K3XCXUq279/3s+dfXML0iEf+UrL5QkcTXDwV suEU8MrKPcoOisewJoQbhqCn2cd0goQzPM1CIKwso4+Zf1zs3wZmktkk4FSDxcs8Gnsq ktHjpq3MGfeQq0cBjBwCvq540HJasHWyCbTqN/eL+lrjF+605yY7lD7ZR6xrHUjcsfSB Ncz4A0jX3qnrul5+N6PoJvqph6E3Mx17zAPu+iSuwtiWMMEWSTyLlwVFCjpF6vyHXajI oQgMGW8okSXyTAbS30EF33KkgPNVmHDXbdbs6+lSQ56XdFcVvXDhKOi/dFnC9AZ4C6V1 QjnQ== MIME-Version: 1.0 X-Received: by 10.50.11.67 with SMTP id o3mr5413949igb.55.1383979883407; Fri, 08 Nov 2013 22:51:23 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 8 Nov 2013 22:51:23 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> Date: Sat, 9 Nov 2013 07:51:23 +0100 X-Google-Sender-Auth: lCtlMaDR1taUpKMga_jkEg1mRX4 Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] =?gb2312?b?tPC4tDogIFByZWZpeCBvdmVybGFwcGluZyBpc3N1ZSBm?= =?gb2312?b?b3IgZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVm?= =?gb2312?b?aXhlcy0wMA==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:51:24 -0000 Hi Xiaohu, Prefix overlap within VPN is either on purpose injected into given VPN or is due to VPN misconfiguration. Detection or mitigation of this as far as I can see is outside of scope of this draft. LISP operates in global space, this draft operates in VPN space. Those spaces while seemingly similar in reality have very different routing characteristics. Best, R. On Sat, Nov 9, 2013 at 7:36 AM, Xuxiaohu wrote: > Hi Robert, > > As long as there is a possibility of prefix overlapping within a given VP= N instance, the mechanism defined in this draft would encounter the same pr= oblem that LISP had ever encountered. > > Best regards, > Xiaohu > ________________________________________ > =B7=A2=BC=FE=C8=CB: lisp-bounces@ietf.org [lisp-bounces@ietf.org] =B4=FA= =B1=ED Robert Raszuk [robert@raszuk.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 14:09 > =CA=D5=BC=FE=C8=CB: Xuxiaohu > =B3=AD=CB=CD: l3vpn@ietf.org; lisp@ietf.org > =D6=F7=CC=E2: Re: [lisp] Prefix overlapping issue for draft-bonica-l3= vpn-orf-covering-prefixes-00 > > Hi Xiaohu, > > While you are asking Ron directly you are cc-ing the lists so let me > clarify your observation .. > > In each L3VPN context each PE advertise set of routes towards other > PEs. Those routes are most often advertised via RR. > > I have never seen the case where RR or set of RRs would in any sort > summarize routes more then PEs advertise. > > So if site has a host with the address of 10.10.10.10 which our high > bandwith flow is destined to PE (or PEs) connected to such site will > advertise the most specific subnet possible to reach 10.10.10.10. > > And that is all what is needed here. > > Based on the request from the v-spoke RR will return the longest match > which will have next hop pointing to one of PEs connected the end > site. I see really no problem there. > > If customer/provider on purpose enforced that to get to 10.10.10.10 > you need to traverse some other site (for example DMZ/firewall/service > XYZ) that is on purpose and we MUST honor it. This draft RFC7024 can > not modify such routing enforced by customer. > > Best, > R. > > PS. I see no relation to LISP here ;) > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Fri Nov 8 23:01:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941021E80EB; Fri, 8 Nov 2013 23:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foRZGnIdKLjd; Fri, 8 Nov 2013 23:01:17 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7780A21E8056; Fri, 8 Nov 2013 23:01:17 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id up7so3087729pbc.26 for ; Fri, 08 Nov 2013 23:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7tSiBRhWisFQRRUlBSxMWs4k2gFYKU+wjVuP/b5dRlk=; b=FS/DgN7WwH++tkhd+DOut1e+k/bli9morUGjx/PYBb2cnNlkqYptC7qv9m3DbfqmMV xl1vJVVUg1rru0nBELICozcTTvJGa/urM2wGS9j1jJv1QWwQpplnjldzIQjqNaLHA40Z TkrmsZ4MBJ/S9EhBwjt6AUEXFA2Z8IVucwQpeX7sVtfojBWZlOKPTGRzBAn7eNGxuoRl A/drU5cZCl2/fN30pigWPDDPGgVUSRVLmKUm6uE8J+8pXSGmAt/8IwnP4pVKCFebfD8A aoAIxDhabHKAgHWvZ4WGUaYmipVal63McYEb4muT2htekHSkbLTuh3fTjdyjtXJW3kVV jt/A== X-Received: by 10.66.150.41 with SMTP id uf9mr20010959pab.108.1383980477124; Fri, 08 Nov 2013 23:01:17 -0800 (PST) Received: from [10.9.48.204] (mobile-166-137-184-163.mycingular.net. [166.137.184.163]) by mx.google.com with ESMTPSA id rv9sm16620580pbc.4.2013.11.08.23.01.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 23:01:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B511) In-Reply-To: Date: Fri, 8 Nov 2013 23:01:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CDF7688-E52D-4CCD-B813-FD46BBFBB3EA@gmail.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> To: Robert Raszuk Cc: Xuxiaohu , "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] =?utf-8?b?562U5aSNOiAgUHJlZml4IG92ZXJsYXBwaW5nIGlzc3VlIGZv?= =?utf-8?q?r_draft-bonica-l3vpn-orf-covering-prefixes-00?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 07:01:18 -0000 Can you guys give us context. Robert, you didn't copy lisp@ietf.org with the= original message/claim from Xiaohu.=20 Dino > On Nov 8, 2013, at 10:51 PM, Robert Raszuk wrote: >=20 > Hi Xiaohu, >=20 > Prefix overlap within VPN is either on purpose injected into given VPN > or is due to VPN misconfiguration. >=20 > Detection or mitigation of this as far as I can see is outside of > scope of this draft. >=20 > LISP operates in global space, this draft operates in VPN space. Those > spaces while seemingly similar in reality have very different routing > characteristics. >=20 > Best, > R. >=20 >> On Sat, Nov 9, 2013 at 7:36 AM, Xuxiaohu wrote: >> Hi Robert, >>=20 >> As long as there is a possibility of prefix overlapping within a given VP= N instance, the mechanism defined in this draft would encounter the same pro= blem that LISP had ever encountered. >>=20 >> Best regards, >> Xiaohu >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: lisp-bounces@ietf.org [lisp-bounces@ietf.org= ] =E4=BB=A3=E8=A1=A8 Robert Raszuk [robert@raszuk.net] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B411=E6=9C=889=E6=97=A5 1= 4:09 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu >> =E6=8A=84=E9=80=81: l3vpn@ietf.org; lisp@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [lisp] Prefix overlapping issue for draft-bon= ica-l3vpn-orf-covering-prefixes-00 >>=20 >> Hi Xiaohu, >>=20 >> While you are asking Ron directly you are cc-ing the lists so let me >> clarify your observation .. >>=20 >> In each L3VPN context each PE advertise set of routes towards other >> PEs. Those routes are most often advertised via RR. >>=20 >> I have never seen the case where RR or set of RRs would in any sort >> summarize routes more then PEs advertise. >>=20 >> So if site has a host with the address of 10.10.10.10 which our high >> bandwith flow is destined to PE (or PEs) connected to such site will >> advertise the most specific subnet possible to reach 10.10.10.10. >>=20 >> And that is all what is needed here. >>=20 >> Based on the request from the v-spoke RR will return the longest match >> which will have next hop pointing to one of PEs connected the end >> site. I see really no problem there. >>=20 >> If customer/provider on purpose enforced that to get to 10.10.10.10 >> you need to traverse some other site (for example DMZ/firewall/service >> XYZ) that is on purpose and we MUST honor it. This draft RFC7024 can >> not modify such routing enforced by customer. >>=20 >> Best, >> R. >>=20 >> PS. I see no relation to LISP here ;) >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From xuxiaohu@huawei.com Sat Nov 9 08:34:00 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83821E80DB; Sat, 9 Nov 2013 08:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=-1.834, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USs9kYlM7Jx0; Sat, 9 Nov 2013 08:33:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4EB621E80D8; Sat, 9 Nov 2013 08:33:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB96029; Sat, 09 Nov 2013 16:33:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 16:33:02 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 16:33:50 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sun, 10 Nov 2013 00:33:46 +0800 From: Xuxiaohu To: Dino Farinacci , Robert Raszuk Thread-Topic: =?gb2312?B?W2xpc3BdILTwuLQ6ICBQcmVmaXggb3ZlcmxhcHBpbmcgaXNzdWUgZm9yIGRy?= =?gb2312?Q?aft-bonica-l3vpn-orf-covering-prefixes-00?= Thread-Index: AQHO3RmH5ngqah8fpUS6wDlz3mGrZJodGG+7 Date: Sat, 9 Nov 2013 16:33:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C9E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> , <7CDF7688-E52D-4CCD-B813-FD46BBFBB3EA@gmail.com> In-Reply-To: <7CDF7688-E52D-4CCD-B813-FD46BBFBB3EA@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.9] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" , "lisp@ietf.org" Subject: [lisp] =?gb2312?b?tPC4tDogILTwuLQ6ICBQcmVmaXggb3ZlcmxhcHBpbmcg?= =?gb2312?b?aXNzdWUgZm9yIGRyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctcHJl?= =?gb2312?b?Zml4ZXMtMDA=?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 16:34:01 -0000 SGkgRGlubywNCg0KdGhlIGZvbGxvd2luZyBpcyB0aGUgb3JpZ2luYWwgZW1haWw6DQoNCisrKysr KysrKysrKysrKysrKysrKysrKw0KSGkgY28tYXV0aG9yIG9mIHRoaXMgZHJhZnQsDQoNCkFzIEkg aGFkIG1lbnRpb25lZCBhdCB0aGUgbWljLCB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIGluIHRoaXMg ZHJhZnQgbmVlZHMgdG8gY29uc2lkZXIgdGhlIHByZWZpeCBvdmVybGFwcGluZyBpc3N1ZSB3aGlj aCBoYXMgYmVlbiBjb25zaWRlcmVkIGFuZCBhZGRyZXNzZWQgYnkgTElTUC4NCg0KVG8gUm9uLA0K DQpUaGUgZGVmYXVsdCByb3V0ZSBvbiB0aGUgc3Bva2UgY2FuIG5vdCBiZSByZXNvcnRlZCB0byBh ZGRyZXNzIHRoZSBwb3RlbnRpYWwgaXNzdWUgY2F1c2VkIGJ5IHRoZSBwcmVmaXggb3ZlcmxhcHBp bmcgaXNzdWUuIFRoZSByZWFzb24gaXMgdGhhdCBpdCdzIHRoZSBsb25nZXN0LW1hdGNoaW5nIHJv dXRlIDEwLzgsIHJhdGhlciB0aGFuIHRoZSBkZWZhdWx0IHJvdXRlIGlzIHVzZWQgdG8gcm91dGUg dGhlIHBhY2tldCBkZXN0aW5lZCBmb3IgMTAuMTAuMTAuMTAsIGluIHRoZSBjYXNlIHdoZXJlIGEg cm91dGUgZm9yIDEwLzggaGFzIGJlZW4gcmV0dXJuZWQgdG8gdGhhdCBzcG9rZSBkdWUgdG8gYSBy ZXF1ZXN0IGZyb20gdGhhdCBzcG9rZSBmb3IgdGhlIGxvbmdlc3QtbWF0Y2hpbmcgcm91dGUgZm9y IGEgZ2l2ZW4gaG9zdCBhZGRyZXNzIDEwLjAuMC4xLiAgQXMgYSByZXN1bHQsIHRoZSB0cmFmZmlj IGZvciAxMC4xMC4xMC4xMCB3b3VsZCBiZSBmb3J3YXJkZWQgdG8gdGhlIG5leHRob3AgZm9yIDEw Lzggd2hpY2ggaW4gdHVybiBmb3J3YXJkIHRoYXQgdHJhZmZpYyBhY2NvcmRpbmcgdG8gYSBtb3Jl IHNwZWZpYyByb3V0ZSBmb3IgMTAuMTAuMTAuMTAuIFRoaXMgaXMgc3Vib3B0aW1hbC4gQXNzdW1l IHRoZSB0cmFmZmljIHZvbHVtZSBmb3IgdGhlIGRlc3RpbmF0aW9uIG9mIDEwLjEwLjEwLjEwIGlz IGhpZ2gsIGhvdyB0byB0cmlnZ2VyIGEgcmVxdXRzdCBmb3IgYSAicmVhbCIgZGlyZWN0IHJvdXRl IHRvIDEwLjEwLjEwLjEwIGlmIHRoZXJlIGV4aXN0cyBhIGhvc3Qgcm91dGUgZm9yIDEwLjEwLjEw LjEwLzMyIGF0IHRoZSBodWI/IE9uZSBwb3NzaWJsZSB3YXkgaXMgdG8gYWx3YXlzIHJlcXVlc3Qg YSBtb3JlIHNwZWNpZmljIHJvdXRlIHVudGlsIGEgaG9zdCByb3V0ZSBmb3IgdGhlIGRlc3RpbmF0 aW9uIG9mIHRoZSByZWNlaXZlZCBwYWNrZXQgaXMgZm91bmQgYXQgdGhlIHNwb2tlLg0KDQpTaW5j ZSB0aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2NjdXNzZWQgYXQgTElTUCBXRyBtYW55IHllYXJzIGJl Zm9yZS4gSSBjb3B5IHRoaXMgZW1haWwgdG8gTElTUCBhcyB3ZWxsLg0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0KKysrKysrKysrKysrKysrKysrKysrKysrKysNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBsaXNwLWJvdW5jZXNAaWV0Zi5vcmcg W2xpc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBEaW5vIEZhcmluYWNjaSBbZmFyaW5hY2NpQGdt YWlsLmNvbV0NCreiy83KsbzkOiAyMDEzxOoxMdTCOcjVIDE1OjAxDQrK1bz+yMs6IFJvYmVydCBS YXN6dWsNCrOty806IFh1eGlhb2h1OyBsM3ZwbkBpZXRmLm9yZzsgbGlzcEBpZXRmLm9yZw0K1vfM 4jogUmU6IFtsaXNwXSC08Li0OiAgUHJlZml4IG92ZXJsYXBwaW5nIGlzc3VlIGZvciBkcmFmdC1i b25pY2EtbDN2cG4tb3JmLWNvdmVyaW5nLXByZWZpeGVzLTAwDQoNCkNhbiB5b3UgZ3V5cyBnaXZl IHVzIGNvbnRleHQuIFJvYmVydCwgeW91IGRpZG4ndCBjb3B5IGxpc3BAaWV0Zi5vcmcgd2l0aCB0 aGUgb3JpZ2luYWwgbWVzc2FnZS9jbGFpbSBmcm9tIFhpYW9odS4NCg0KRGlubw0KDQoNCj4gT24g Tm92IDgsIDIwMTMsIGF0IDEwOjUxIFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5l dD4gd3JvdGU6DQo+DQo+IEhpIFhpYW9odSwNCj4NCj4gUHJlZml4IG92ZXJsYXAgd2l0aGluIFZQ TiBpcyBlaXRoZXIgb24gcHVycG9zZSBpbmplY3RlZCBpbnRvIGdpdmVuIFZQTg0KPiBvciBpcyBk dWUgdG8gVlBOIG1pc2NvbmZpZ3VyYXRpb24uDQo+DQo+IERldGVjdGlvbiBvciBtaXRpZ2F0aW9u IG9mIHRoaXMgYXMgZmFyIGFzIEkgY2FuIHNlZSBpcyBvdXRzaWRlIG9mDQo+IHNjb3BlIG9mIHRo aXMgZHJhZnQuDQo+DQo+IExJU1Agb3BlcmF0ZXMgaW4gZ2xvYmFsIHNwYWNlLCB0aGlzIGRyYWZ0 IG9wZXJhdGVzIGluIFZQTiBzcGFjZS4gVGhvc2UNCj4gc3BhY2VzIHdoaWxlIHNlZW1pbmdseSBz aW1pbGFyIGluIHJlYWxpdHkgaGF2ZSB2ZXJ5IGRpZmZlcmVudCByb3V0aW5nDQo+IGNoYXJhY3Rl cmlzdGljcy4NCj4NCj4gQmVzdCwNCj4gUi4NCj4NCj4+IE9uIFNhdCwgTm92IDksIDIwMTMgYXQg NzozNiBBTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gSGkgUm9i ZXJ0LA0KPj4NCj4+IEFzIGxvbmcgYXMgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSBvZiBwcmVmaXgg b3ZlcmxhcHBpbmcgd2l0aGluIGEgZ2l2ZW4gVlBOIGluc3RhbmNlLCB0aGUgbWVjaGFuaXNtIGRl ZmluZWQgaW4gdGhpcyBkcmFmdCB3b3VsZCBlbmNvdW50ZXIgdGhlIHNhbWUgcHJvYmxlbSB0aGF0 IExJU1AgaGFkIGV2ZXIgZW5jb3VudGVyZWQuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gWGlh b2h1DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiC3orz+ yMs6IGxpc3AtYm91bmNlc0BpZXRmLm9yZyBbbGlzcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJv YmVydCBSYXN6dWsgW3JvYmVydEByYXN6dWsubmV0XQ0KPj4gt6LLzcqxvOQ6IDIwMTPE6jEx1MI5 yNUgMTQ6MDkNCj4+IMrVvP7IyzogWHV4aWFvaHUNCj4+ILOty806IGwzdnBuQGlldGYub3JnOyBs aXNwQGlldGYub3JnDQo+PiDW98ziOiBSZTogW2xpc3BdIFByZWZpeCBvdmVybGFwcGluZyBpc3N1 ZSBmb3IgICAgIGRyYWZ0LWJvbmljYS1sM3Zwbi1vcmYtY292ZXJpbmctcHJlZml4ZXMtMDANCj4+ DQo+PiBIaSBYaWFvaHUsDQo+Pg0KPj4gV2hpbGUgeW91IGFyZSBhc2tpbmcgUm9uIGRpcmVjdGx5 IHlvdSBhcmUgY2MtaW5nIHRoZSBsaXN0cyBzbyBsZXQgbWUNCj4+IGNsYXJpZnkgeW91ciBvYnNl cnZhdGlvbiAuLg0KPj4NCj4+IEluIGVhY2ggTDNWUE4gY29udGV4dCBlYWNoIFBFIGFkdmVydGlz ZSBzZXQgb2Ygcm91dGVzIHRvd2FyZHMgb3RoZXINCj4+IFBFcy4gVGhvc2Ugcm91dGVzIGFyZSBt b3N0IG9mdGVuIGFkdmVydGlzZWQgdmlhIFJSLg0KPj4NCj4+IEkgaGF2ZSBuZXZlciBzZWVuIHRo ZSBjYXNlIHdoZXJlIFJSIG9yIHNldCBvZiBSUnMgd291bGQgaW4gYW55IHNvcnQNCj4+IHN1bW1h cml6ZSByb3V0ZXMgbW9yZSB0aGVuIFBFcyBhZHZlcnRpc2UuDQo+Pg0KPj4gU28gaWYgc2l0ZSBo YXMgYSBob3N0IHdpdGggdGhlIGFkZHJlc3Mgb2YgMTAuMTAuMTAuMTAgd2hpY2ggb3VyIGhpZ2gN Cj4+IGJhbmR3aXRoIGZsb3cgaXMgZGVzdGluZWQgdG8gUEUgKG9yIFBFcykgY29ubmVjdGVkIHRv IHN1Y2ggc2l0ZSB3aWxsDQo+PiBhZHZlcnRpc2UgdGhlIG1vc3Qgc3BlY2lmaWMgc3VibmV0IHBv c3NpYmxlIHRvIHJlYWNoIDEwLjEwLjEwLjEwLg0KPj4NCj4+IEFuZCB0aGF0IGlzIGFsbCB3aGF0 IGlzIG5lZWRlZCBoZXJlLg0KPj4NCj4+IEJhc2VkIG9uIHRoZSByZXF1ZXN0IGZyb20gdGhlIHYt c3Bva2UgUlIgd2lsbCByZXR1cm4gdGhlIGxvbmdlc3QgbWF0Y2gNCj4+IHdoaWNoIHdpbGwgaGF2 ZSBuZXh0IGhvcCBwb2ludGluZyB0byBvbmUgb2YgUEVzIGNvbm5lY3RlZCB0aGUgZW5kDQo+PiBz aXRlLiBJIHNlZSByZWFsbHkgbm8gcHJvYmxlbSB0aGVyZS4NCj4+DQo+PiBJZiBjdXN0b21lci9w cm92aWRlciBvbiBwdXJwb3NlIGVuZm9yY2VkIHRoYXQgdG8gZ2V0IHRvIDEwLjEwLjEwLjEwDQo+ PiB5b3UgbmVlZCB0byB0cmF2ZXJzZSBzb21lIG90aGVyIHNpdGUgKGZvciBleGFtcGxlIERNWi9m aXJld2FsbC9zZXJ2aWNlDQo+PiBYWVopIHRoYXQgaXMgb24gcHVycG9zZSBhbmQgd2UgTVVTVCBo b25vciBpdC4gVGhpcyBkcmFmdCBSRkM3MDI0IGNhbg0KPj4gbm90IG1vZGlmeSBzdWNoIHJvdXRp bmcgZW5mb3JjZWQgYnkgY3VzdG9tZXIuDQo+Pg0KPj4gQmVzdCwNCj4+IFIuDQo+Pg0KPj4gUFMu IEkgc2VlIG5vIHJlbGF0aW9uIHRvIExJU1AgaGVyZSA7KQ0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+PiBs aXNwQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xp c3ANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bGlzcCBtYWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpsaXNwIG1haWxpbmcgbGlzdA0KbGlzcEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNw From lucy.yong@huawei.com Sun Nov 10 23:01:18 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1321E80D3; Sun, 10 Nov 2013 23:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-2.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBqLY0dMq70L; Sun, 10 Nov 2013 23:01:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3122721E80C5; Sun, 10 Nov 2013 23:01:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXT15417; Mon, 11 Nov 2013 07:01:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 07:01:01 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 07:01:10 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Sun, 10 Nov 2013 23:00:59 -0800 From: Lucy yong To: Robert Raszuk , Xuxiaohu Thread-Topic: ??: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 Thread-Index: AQHO3Rgk0EGAccVZrEOtrYlS51WxCpofmj4A Date: Mon, 11 Nov 2013 07:00:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EC235@dfweml509-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.129] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] ??: Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 07:01:19 -0000 V2hlbiByZXF1ZXN0aW5nIGNvdmVyaW5nIHByZWZpeCwgaXQgaGFzIHRoZSBjaGFuY2UgdGhhdCBh IHByZWZpeCBtYXkgYXBwbHkgdG8gbW9yZSB0aGFuIG9uIFZQTiBzaXRlIGluIHRoZSBlbnZpcm9u bWVudCBvZiBWTSBtb2JpbGl0eS4gSWYgd2UganVzdCByZXF1ZXN0IGEgaG9zdCBvciBhIHNldCBv ZiBob3N0IGFkZHJlc3NlcywgYW5kIGdpdmUgdGhlIHJ1bGUgdGhhdCBvbmx5IFBFcyB0aGF0IGhh cyB0aGUgaG9zdCByb3V0ZSByZXBsaWVzIHRoZSByZXF1ZXN0LiBUaGlzIG1heSBhZGRyZXNzIHRo ZSBpc3N1ZSwgaXNuJ3QgaXQ/IE90aGVyd2lzZSwgZHVlIHRvIHRoZSByZXNwb25zZSB0aW1lIGRp ZmZlcmVuY2UsIHRoZSBpbmdyZXNzIFBFIG1heSBzZW5kIHRoZSBwYWNrZXQgdG8gdGhlIHdyb25n IFBFLCBpc24ndCBpdD8gQnV0IGlmIFBFIGRvZXMgbm90IGhhdmUgaG9zdCBhZGRyZXNzIHZpc2li aWxpdHksIHRoaXMgd2lsbCBub3Qgd29yay4gDQoNCklNTzogV2UgbmVlZCBhIHNvbHV0aW9uIHRv IHdvcmsgdy8gb3Igdy9vIFJSLg0KDQpMdWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJl ciAwOSwgMjAxMyAxMjo1MSBBTQ0KVG86IFh1eGlhb2h1DQpDYzogbDN2cG5AaWV0Zi5vcmc7IGxp c3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiA/PzogW2xpc3BdIFByZWZpeCBvdmVybGFwcGluZyBp c3N1ZSBmb3IgZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0wMA0KDQpI aSBYaWFvaHUsDQoNClByZWZpeCBvdmVybGFwIHdpdGhpbiBWUE4gaXMgZWl0aGVyIG9uIHB1cnBv c2UgaW5qZWN0ZWQgaW50byBnaXZlbiBWUE4gb3IgaXMgZHVlIHRvIFZQTiBtaXNjb25maWd1cmF0 aW9uLg0KDQpEZXRlY3Rpb24gb3IgbWl0aWdhdGlvbiBvZiB0aGlzIGFzIGZhciBhcyBJIGNhbiBz ZWUgaXMgb3V0c2lkZSBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0Lg0KDQpMSVNQIG9wZXJhdGVzIGlu IGdsb2JhbCBzcGFjZSwgdGhpcyBkcmFmdCBvcGVyYXRlcyBpbiBWUE4gc3BhY2UuIFRob3NlIHNw YWNlcyB3aGlsZSBzZWVtaW5nbHkgc2ltaWxhciBpbiByZWFsaXR5IGhhdmUgdmVyeSBkaWZmZXJl bnQgcm91dGluZyBjaGFyYWN0ZXJpc3RpY3MuDQoNCkJlc3QsDQpSLg0KDQpPbiBTYXQsIE5vdiA5 LCAyMDEzIGF0IDc6MzYgQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToN Cj4gSGkgUm9iZXJ0LA0KPg0KPiBBcyBsb25nIGFzIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgb2Yg cHJlZml4IG92ZXJsYXBwaW5nIHdpdGhpbiBhIGdpdmVuIFZQTiBpbnN0YW5jZSwgdGhlIG1lY2hh bmlzbSBkZWZpbmVkIGluIHRoaXMgZHJhZnQgd291bGQgZW5jb3VudGVyIHRoZSBzYW1lIHByb2Js ZW0gdGhhdCBMSVNQIGhhZCBldmVyIGVuY291bnRlcmVkLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFhpYW9odQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ILei vP7IyzogbGlzcC1ib3VuY2VzQGlldGYub3JnIFtsaXNwLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g Um9iZXJ0IFJhc3p1ayANCj4gW3JvYmVydEByYXN6dWsubmV0XQ0KPiC3osvNyrG85DogMjAxM8Tq MTHUwjnI1SAxNDowOQ0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IGwzdnBuQGlldGYub3Jn OyBsaXNwQGlldGYub3JnDQo+INb3zOI6IFJlOiBbbGlzcF0gUHJlZml4IG92ZXJsYXBwaW5nIGlz c3VlIGZvciAgICAgZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0wMA0K Pg0KPiBIaSBYaWFvaHUsDQo+DQo+IFdoaWxlIHlvdSBhcmUgYXNraW5nIFJvbiBkaXJlY3RseSB5 b3UgYXJlIGNjLWluZyB0aGUgbGlzdHMgc28gbGV0IG1lIA0KPiBjbGFyaWZ5IHlvdXIgb2JzZXJ2 YXRpb24gLi4NCj4NCj4gSW4gZWFjaCBMM1ZQTiBjb250ZXh0IGVhY2ggUEUgYWR2ZXJ0aXNlIHNl dCBvZiByb3V0ZXMgdG93YXJkcyBvdGhlciANCj4gUEVzLiBUaG9zZSByb3V0ZXMgYXJlIG1vc3Qg b2Z0ZW4gYWR2ZXJ0aXNlZCB2aWEgUlIuDQo+DQo+IEkgaGF2ZSBuZXZlciBzZWVuIHRoZSBjYXNl IHdoZXJlIFJSIG9yIHNldCBvZiBSUnMgd291bGQgaW4gYW55IHNvcnQgDQo+IHN1bW1hcml6ZSBy b3V0ZXMgbW9yZSB0aGVuIFBFcyBhZHZlcnRpc2UuDQo+DQo+IFNvIGlmIHNpdGUgaGFzIGEgaG9z dCB3aXRoIHRoZSBhZGRyZXNzIG9mIDEwLjEwLjEwLjEwIHdoaWNoIG91ciBoaWdoIA0KPiBiYW5k d2l0aCBmbG93IGlzIGRlc3RpbmVkIHRvIFBFIChvciBQRXMpIGNvbm5lY3RlZCB0byBzdWNoIHNp dGUgd2lsbCANCj4gYWR2ZXJ0aXNlIHRoZSBtb3N0IHNwZWNpZmljIHN1Ym5ldCBwb3NzaWJsZSB0 byByZWFjaCAxMC4xMC4xMC4xMC4NCj4NCj4gQW5kIHRoYXQgaXMgYWxsIHdoYXQgaXMgbmVlZGVk IGhlcmUuDQo+DQo+IEJhc2VkIG9uIHRoZSByZXF1ZXN0IGZyb20gdGhlIHYtc3Bva2UgUlIgd2ls bCByZXR1cm4gdGhlIGxvbmdlc3QgbWF0Y2ggDQo+IHdoaWNoIHdpbGwgaGF2ZSBuZXh0IGhvcCBw b2ludGluZyB0byBvbmUgb2YgUEVzIGNvbm5lY3RlZCB0aGUgZW5kIA0KPiBzaXRlLiBJIHNlZSBy ZWFsbHkgbm8gcHJvYmxlbSB0aGVyZS4NCj4NCj4gSWYgY3VzdG9tZXIvcHJvdmlkZXIgb24gcHVy cG9zZSBlbmZvcmNlZCB0aGF0IHRvIGdldCB0byAxMC4xMC4xMC4xMCANCj4geW91IG5lZWQgdG8g dHJhdmVyc2Ugc29tZSBvdGhlciBzaXRlIChmb3IgZXhhbXBsZSBETVovZmlyZXdhbGwvc2Vydmlj ZQ0KPiBYWVopIHRoYXQgaXMgb24gcHVycG9zZSBhbmQgd2UgTVVTVCBob25vciBpdC4gVGhpcyBk cmFmdCBSRkM3MDI0IGNhbiANCj4gbm90IG1vZGlmeSBzdWNoIHJvdXRpbmcgZW5mb3JjZWQgYnkg Y3VzdG9tZXIuDQo+DQo+IEJlc3QsDQo+IFIuDQo+DQo+IFBTLiBJIHNlZSBubyByZWxhdGlvbiB0 byBMSVNQIGhlcmUgOykNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbGlzcCBtYWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg== From ietf@bartschnet.de Mon Nov 11 01:14:49 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041AD11E8217 for ; Mon, 11 Nov 2013 01:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3kfQm0tzufy for ; Mon, 11 Nov 2013 01:14:31 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7623011E8132 for ; Mon, 11 Nov 2013 01:05:27 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VfnQw-0001HY-VL for lisp@ietf.org; Mon, 11 Nov 2013 10:05:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Nov 2013 10:05:22 +0100 From: Rene Bartsch To: LISP mailing list list In-Reply-To: References: Message-ID: <32d7838454b70dc8430c24a9f4a967fb@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] Personal EID hashed of public RSA-key X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 09:14:49 -0000 Am 2013-11-09 05:04, schrieb Dino Farinacci: > This is similar to HIP's HIT based addresses. I think it is an > interesting idea and you should persue it by writing up a draft. Yes, I think it's time to dare my first draft. ;-) Can you point me to documentation about writing a formal draft? Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From rraszuk@gmail.com Mon Nov 11 01:30:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BB21F9F62; Mon, 11 Nov 2013 01:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQMCzOyPWv+A; Mon, 11 Nov 2013 01:30:00 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 79E5B21E805D; Mon, 11 Nov 2013 01:21:20 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id to1so1580472ieb.17 for ; Mon, 11 Nov 2013 01:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/NTlicejbVSdFASX6OVAogGPNRnUMJbA5HDHrbT1qfg=; b=0u7rJ7778djfWV6KwMogrVwVZR+oO7EWLKzbJzCP150vscVtGYfBZXaHy/RDBFp1vf Yss+xBPUocquP+fkIpZ1DubZ7IxE7BNfBcDiBgXDuMXZKg1RSmkRYOnK0M28zk/ZhiWA BvONlOZlC3f/GiKEtN959ekTVnGyVo4I3FAn7gBi6JaNOoOrzYxgnAijBBc8vyP6baKk wpQW+g59SQBjb3xe5hqdzORaxxCv8elaQ352F0MPpbCFmcpCG3TwA1s1y4yNq4n1KJoT j1W1DTGkldJm+/ZP9gnEn3/EfNQK1CfHavHKeJlTPjwfkuexSMW85eziveD09luTZ1qT lJ2g== MIME-Version: 1.0 X-Received: by 10.50.117.103 with SMTP id kd7mr11948359igb.4.1384161663066; Mon, 11 Nov 2013 01:21:03 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Mon, 11 Nov 2013 01:21:03 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452EC235@dfweml509-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EC235@dfweml509-mbx.china.huawei.com> Date: Mon, 11 Nov 2013 10:21:03 +0100 X-Google-Sender-Auth: 1jakTFtjAvaDvs3fMW9dkThO4Lw Message-ID: From: Robert Raszuk To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Xuxiaohu , "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] ??: Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 09:30:04 -0000 Hi Lucy, Proposed solution works within a VPN context. It is not a general design at this point. I am actually looking what would be the optimal encoding to address the VPN case particulary RFC7024 optimality as well as possibly to also allow for other applications. Enforcing to request host address will not work as PEs do not carry host routes for VPNs .... at least those which are properly configured :) Site addresses are advertised in blocks. Of course if site consists of single tenant VM that would be host address - but this is rather special case for one solution space. To your point of sending to "wrong PE" I do not really see that. At most it may be suboptimal PE for some duration of time ... not wrong one. And the case will self-cure when more specific get's advertised anyway. Best regards, R. On Mon, Nov 11, 2013 at 8:00 AM, Lucy yong wrote: > When requesting covering prefix, it has the chance that a prefix may appl= y to more than on VPN site in the environment of VM mobility. If we just re= quest a host or a set of host addresses, and give the rule that only PEs th= at has the host route replies the request. This may address the issue, isn'= t it? Otherwise, due to the response time difference, the ingress PE may se= nd the packet to the wrong PE, isn't it? But if PE does not have host addre= ss visibility, this will not work. > > IMO: We need a solution to work w/ or w/o RR. > > Lucy > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of= Robert Raszuk > Sent: Saturday, November 09, 2013 12:51 AM > To: Xuxiaohu > Cc: l3vpn@ietf.org; lisp@ietf.org > Subject: Re: ??: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-o= rf-covering-prefixes-00 > > Hi Xiaohu, > > Prefix overlap within VPN is either on purpose injected into given VPN or= is due to VPN misconfiguration. > > Detection or mitigation of this as far as I can see is outside of scope o= f this draft. > > LISP operates in global space, this draft operates in VPN space. Those sp= aces while seemingly similar in reality have very different routing charact= eristics. > > Best, > R. From ietf@bartschnet.de Mon Nov 11 02:28:40 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6011E8156 for ; Mon, 11 Nov 2013 02:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_50=0.001, HELO_EQ_DE=0.35, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9u5v-XPi8nV for ; Mon, 11 Nov 2013 02:28:35 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7B81811E8141 for ; Mon, 11 Nov 2013 02:28:35 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VfojR-0005zx-DN for lisp@ietf.org; Mon, 11 Nov 2013 11:28:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Nov 2013 11:28:33 +0100 From: Rene Bartsch To: "lisp@ietf.org list" In-Reply-To: References: <527BFFC9.3050203@ac.upc.edu> <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> Message-ID: <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] =?utf-8?q?LISP_support_in_Linux_kernel=3F?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:28:40 -0000 Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >> LISPmob for Android already supports NAT traversal. You can find the > latest code here: > > https://github.com/LISPmob/lispmob/tree/android > > We expect to offer a binary version (Android APK) on lispmob.org soon. How is the state of the Debian-version? Does it support NAT? Does ist support multiple EIDs on one RLOC? -- Best regards, Rene Bartsch, B. Sc. Informatics From alopez@ac.upc.edu Mon Nov 11 02:44:20 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC29221E820E for ; Mon, 11 Nov 2013 02:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ilKOx76y-4r for ; Mon, 11 Nov 2013 02:44:16 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E84A621E820A for ; Mon, 11 Nov 2013 02:44:15 -0800 (PST) Received: from [147.83.35.39] (pcmatali.ac.upc.es [147.83.35.39]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rABAiCKx009538; Mon, 11 Nov 2013 11:44:12 +0100 Message-ID: <5280B4FC.1070901@ac.upc.edu> Date: Mon, 11 Nov 2013 11:44:12 +0100 From: =?ISO-8859-1?Q?Albert_L=F3pez?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Rene Bartsch , "lisp@ietf.org list" References: <527BFFC9.3050203@ac.upc.edu> <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> In-Reply-To: <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:44:21 -0000 We tested with Ubuntu but it should work in any linux implementation. It supports NAT-traversal but only with one EID and one RLOC. If you don't require NAT, then multiple EIDs and multiple RLOCs are supported. Regards Albert L. On 11/11/2013 11:28 AM, Rene Bartsch wrote: > Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >>> LISPmob for Android already supports NAT traversal. You can find the >> latest code here: >> >> https://github.com/LISPmob/lispmob/tree/android >> >> We expect to offer a binary version (Android APK) on lispmob.org soon. > > How is the state of the Debian-version? Does it support NAT? Does ist > support multiple EIDs on one RLOC? > From ietf@bartschnet.de Mon Nov 11 02:57:16 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD521E8083 for ; Mon, 11 Nov 2013 02:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuynuCuODcVB for ; Mon, 11 Nov 2013 02:57:10 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB411E820A for ; Mon, 11 Nov 2013 02:57:01 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VfpAw-0001j5-2F for lisp@ietf.org; Mon, 11 Nov 2013 11:56:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 11 Nov 2013 11:56:58 +0100 From: Rene Bartsch To: "lisp@ietf.org list" In-Reply-To: <5280B4FC.1070901@ac.upc.edu> References: "\" <527BFFC9.3050203@ac.upc.edu>" <6189626e2a63a3cadc35ace3326052ad@bartschnet.de>" <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> <5280B4FC.1070901@ac.upc.edu> Message-ID: <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] =?utf-8?q?LISP_support_in_Linux_kernel=3F?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:57:17 -0000 Unfortunately I've one location with an AVM Fritz!Box 7390, which seems to have a LISP-bug, and one location with an AVM Fritz!Box 7330SL, which doesn't support LISP, yet. I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and /48-IPv6 of LISP Beta-Network). Unfortunately more and more german ISPs switch to Dual-Stack Lite which renders LISPmob unusable for routers unless multiple EIDs are possible with NAT. Regards, Renne Am 2013-11-11 11:44, schrieb Albert López: > We tested with Ubuntu but it should work in any linux implementation. > It supports NAT-traversal but only with one EID and one RLOC. If you > don't require NAT, then multiple EIDs and multiple RLOCs are > supported. > > Regards > > Albert L. > > On 11/11/2013 11:28 AM, Rene Bartsch wrote: >> Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >>>> LISPmob for Android already supports NAT traversal. You can find the >>> latest code here: >>> >>> https://github.com/LISPmob/lispmob/tree/android >>> >>> We expect to offer a binary version (Android APK) on lispmob.org >>> soon. >> >> How is the state of the Debian-version? Does it support NAT? Does ist >> support multiple EIDs on one RLOC? >> -- Best regards, Rene Bartsch, B. Sc. Informatics From alopez@ac.upc.edu Mon Nov 11 03:31:11 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6A921E80C7 for ; Mon, 11 Nov 2013 03:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jyWQJc21xW4 for ; Mon, 11 Nov 2013 03:31:06 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7111E8160 for ; Mon, 11 Nov 2013 03:31:05 -0800 (PST) Received: from [147.83.35.39] (pcmatali.ac.upc.es [147.83.35.39]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rABBV4o0011344; Mon, 11 Nov 2013 12:31:04 +0100 Message-ID: <5280BFF7.4070500@ac.upc.edu> Date: Mon, 11 Nov 2013 12:31:03 +0100 From: =?UTF-8?B?QWxiZXJ0IEzDs3Bleg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Rene Bartsch , "lisp@ietf.org list" , LISPmob References: "\" <527BFFC9.3050203@ac.upc.edu>" <6189626e2a63a3cadc35ace3326052ad@bartschnet.de>" <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> <5280B4FC.1070901@ac.upc.edu> <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> In-Reply-To: <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> Content-Type: multipart/alternative; boundary="------------010500010007080206010306" Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 11:31:11 -0000 This is a multi-part message in MIME format. --------------010500010007080206010306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sorry for the misunderstood. In the previous mail I refer that when LISPmob is behind NAT, it could only have configured one IPv4 or one IPv6 EID **prefix**. I hope this could feed your requirements. Regards Albert On 11/11/2013 11:56 AM, Rene Bartsch wrote: > Unfortunately I've one location with an AVM Fritz!Box 7390, which > seems to have a LISP-bug, and one location with an AVM Fritz!Box > 7330SL, which doesn't support LISP, yet. > > I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard > RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not > possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and > /48-IPv6 of LISP Beta-Network). Unfortunately more and more german > ISPs switch to Dual-Stack Lite which renders LISPmob unusable for > routers unless multiple EIDs are possible with NAT. > > Regards, > > Renne > > Am 2013-11-11 11:44, schrieb Albert López: >> We tested with Ubuntu but it should work in any linux implementation. >> It supports NAT-traversal but only with one EID and one RLOC. If you >> don't require NAT, then multiple EIDs and multiple RLOCs are >> supported. >> >> Regards >> >> Albert L. >> >> On 11/11/2013 11:28 AM, Rene Bartsch wrote: >>> Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >>>>> LISPmob for Android already supports NAT traversal. You can find the >>>> latest code here: >>>> >>>> https://github.com/LISPmob/lispmob/tree/android >>>> >>>> We expect to offer a binary version (Android APK) on lispmob.org soon. >>> >>> How is the state of the Debian-version? Does it support NAT? Does >>> ist support multiple EIDs on one RLOC? >>> > -- Albert López CCABA System Administrator Universitat Politècnica de Catalunya Telf: 93 4017182 --------------010500010007080206010306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Sorry for the misunderstood. In the previous mail I refer that when LISPmob is behind NAT, it could only have configured one IPv4 or one IPv6 EID *prefix*. I hope this could feed your requirements.

Regards

Albert

On 11/11/2013 11:56 AM, Rene Bartsch wrote:
Unfortunately I've one location with an AVM Fritz!Box 7390, which seems to have a LISP-bug, and one location with an AVM Fritz!Box 7330SL, which doesn't support LISP, yet.

I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and /48-IPv6 of LISP Beta-Network). Unfortunately more and more german ISPs switch to Dual-Stack Lite which renders LISPmob unusable for routers unless multiple EIDs are possible with NAT.

Regards,

Renne

Am 2013-11-11 11:44, schrieb Albert López:
We tested with Ubuntu but it should work in any linux implementation.
It supports NAT-traversal but only with one EID and one RLOC. If you
don't require NAT, then multiple EIDs and multiple RLOCs are
supported.

Regards

Albert L.

On 11/11/2013 11:28 AM, Rene Bartsch wrote:
Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal:
LISPmob for Android already supports NAT traversal. You can find the
latest code here:

https://github.com/LISPmob/lispmob/tree/android

We expect to offer a binary version (Android APK) on lispmob.org soon.

How is the state of the Debian-version? Does it support NAT? Does ist support multiple EIDs on one RLOC? 




-- 
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182
--------------010500010007080206010306-- From Juergen.Strasser@a1telekom.at Mon Nov 11 04:08:25 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAB911E8149 for ; Mon, 11 Nov 2013 04:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.07 X-Spam-Level: ** X-Spam-Status: No, score=2.07 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM5fnLdlIIoZ for ; Mon, 11 Nov 2013 04:08:21 -0800 (PST) Received: from mxout.a1telekom.at (mxout.a1telekom.at [193.187.235.26]) by ietfa.amsl.com (Postfix) with ESMTP id 272C421F9DB4 for ; Mon, 11 Nov 2013 04:08:20 -0800 (PST) From: =?utf-8?B?U3RyYXNzZXIgSsO8cmdlbg==?= To: Rene Bartsch , "lisp@ietf.org list" Thread-Topic: [lisp] LISP support in Linux kernel? Thread-Index: AQHO3sjNVQs69f6fakOPPhosyzjheJofx5UAgAADkQCAACQJMA== Date: Mon, 11 Nov 2013 12:08:42 +0000 Message-ID: <5D2370BC6C95CF4FAE74B9B3BE1EFA2FD01D0934@a1telekom.at> References: "\" <527BFFC9.3050203@ac.upc.edu>" <6189626e2a63a3cadc35ace3326052ad@bartschnet.de>" <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> <5280B4FC.1070901@ac.upc.edu> <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> In-Reply-To: <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.140.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Johannes Kuhn \(jkuhn@cisco.com\)" Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:08:25 -0000 RGVhciBSZW7DqSwNCg0KaWYgeW91IGhhdmUgYSBnZXJtYW4gQVZNIEZCRjczOTAsIHRoYW4gTElT UCBjYXBhYmxlIEZXIDA2LjAwIHdhcyByZWxlYXNlIGFwcC4gMiBXZWVrcyBhZ28NCg0KSWYgeW91 IGhhdmUgYW4gaW50ZXJuYXRpb25hbCBib3gsIEkgY2FuIGhlbHAgeW91IHdpdGggYW4gRlcgdXBn cmFkZSwgaWYgeW91IGdpdmUgbWUgcmVtb3RlIGFjY2VzcyAod2l0aCBhIGRlZGVjYXRlZCBhY2Nv dW50IHdoaWNoIHlvdSBjYW4gbG9nIGxhdGVyIG9uKQ0KSSdtIG5vdCBhbGxvd2VkIHRvIHNoYXJl IHRoaXMgbmV3IEZpcm13YXJlIHB1YmxpYw0KDQpBbGwgdGhlIGJlc3QgZnJvbSBWaWVubmEsDQoN Cg0KSW5nLiBKw7xyZ2VuIFN0cmFzc2VyDQpTZXJ2aWNlIE5ldHdvcmsgUGxhbm5pbmcNCkNvbW11 bmljYXRpb24gU2VydmljZXMNCg0KQTEgVGVsZWtvbSBBdXN0cmlhIEFHDQpMYXNzYWxsZXN0cmHD n2UgOSAxMDIwIFdpZW4NCk0gICArNDMgNjY0IDY2IDI3MzA5DQpGICAgKzQzIDUwIDY2NCA5IDI3 MzA5DQpAICAganVlcmdlbi5zdHJhc3NlckBBMXRlbGVrb20uYXQNCg0KQTEubmV0DQpGYWNlYm9v ay5BMS5uZXQNCg0KRmlybWVuc2l0eiBXaWVuIEZOOiAyODA1NzFmDQpIYW5kZWxzZ2VyaWNodCBX aWVuDQoNCg0KDQpFaW5mYWNoIFBhcGllciBzcGFyZW4uIEVpbmZhY2ggYW4gZGllIFVtd2VsdCBk ZW5rZW4uDQoNCg0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9u OiBsaXNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmddIElt IEF1ZnRyYWcgdm9uIFJlbmUgQmFydHNjaA0KR2VzZW5kZXQ6IE1vbnRhZywgMTEuIE5vdmVtYmVy IDIwMTMgMTE6NTcNCkFuOiBsaXNwQGlldGYub3JnIGxpc3QNCkJldHJlZmY6IFJlOiBbbGlzcF0g TElTUCBzdXBwb3J0IGluIExpbnV4IGtlcm5lbD8NCg0KVW5mb3J0dW5hdGVseSBJJ3ZlIG9uZSBs b2NhdGlvbiB3aXRoIGFuIEFWTSBGcml0eiFCb3ggNzM5MCwgd2hpY2ggc2VlbXMgdG8gaGF2ZSBh IExJU1AtYnVnLCBhbmQgb25lIGxvY2F0aW9uIHdpdGggYW4gQVZNIEZyaXR6IUJveCA3MzMwU0ws IHdoaWNoIGRvZXNuJ3Qgc3VwcG9ydCBMSVNQLCB5ZXQuDQoNCkkgY29uc2lkZXJlZCB1c2luZyBt eSBVYnVudHUgMTIuMDQgTFRTLU5BUyBvciBhIE1pa3JvdGlrIFJvdXRlcmJvYXJkIFJCNDkzRyB3 aXRoIE9wZW5XUlQgYmVoaW5kIHRoZSBGcml0eiFCb3ggNzMzMFNMLCBidXQgdGhhdCdzIG5vdCBw b3NzaWJsZSB1bmxlc3MgTElTUG1vYiBzdXBwb3J0cyBOQVQgd2l0aCBtdWx0aXBsZSBFSURzICgv MjgtSVB2NCBhbmQgLzQ4LUlQdjYgb2YgTElTUCBCZXRhLU5ldHdvcmspLiBVbmZvcnR1bmF0ZWx5 IG1vcmUgYW5kIG1vcmUgZ2VybWFuIElTUHMgc3dpdGNoIHRvIER1YWwtU3RhY2sgTGl0ZSB3aGlj aCByZW5kZXJzIExJU1Btb2IgdW51c2FibGUgZm9yIHJvdXRlcnMgdW5sZXNzIG11bHRpcGxlIEVJ RHMgYXJlIHBvc3NpYmxlIHdpdGggTkFULg0KDQpSZWdhcmRzLA0KDQpSZW5uZQ0KDQpBbSAyMDEz LTExLTExIDExOjQ0LCBzY2hyaWViIEFsYmVydCBMw7NwZXo6DQo+IFdlIHRlc3RlZCB3aXRoIFVi dW50dSBidXQgaXQgc2hvdWxkIHdvcmsgaW4gYW55IGxpbnV4IGltcGxlbWVudGF0aW9uLg0KPiBJ dCBzdXBwb3J0cyBOQVQtdHJhdmVyc2FsIGJ1dCBvbmx5IHdpdGggb25lIEVJRCBhbmQgb25lIFJM T0MuIElmIHlvdSANCj4gZG9uJ3QgcmVxdWlyZSBOQVQsIHRoZW4gbXVsdGlwbGUgRUlEcyBhbmQg bXVsdGlwbGUgUkxPQ3MgYXJlIA0KPiBzdXBwb3J0ZWQuDQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBB bGJlcnQgTC4NCj4gDQo+IE9uIDExLzExLzIwMTMgMTE6MjggQU0sIFJlbmUgQmFydHNjaCB3cm90 ZToNCj4+IEFtIDIwMTMtMTEtMDggMDE6MDgsIHNjaHJpZWIgQWxiZXJ0byBSb2RyaWd1ZXotTmF0 YWw6DQo+Pj4+IExJU1Btb2IgZm9yIEFuZHJvaWQgYWxyZWFkeSBzdXBwb3J0cyBOQVQgdHJhdmVy c2FsLiBZb3UgY2FuIGZpbmQgDQo+Pj4+IHRoZQ0KPj4+IGxhdGVzdCBjb2RlIGhlcmU6DQo+Pj4g DQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL0xJU1Btb2IvbGlzcG1vYi90cmVlL2FuZHJvaWQNCj4+ PiANCj4+PiBXZSBleHBlY3QgdG8gb2ZmZXIgYSBiaW5hcnkgdmVyc2lvbiAoQW5kcm9pZCBBUEsp IG9uIGxpc3Btb2Iub3JnIA0KPj4+IHNvb24uDQo+PiANCj4+IEhvdyBpcyB0aGUgc3RhdGUgb2Yg dGhlIERlYmlhbi12ZXJzaW9uPyBEb2VzIGl0IHN1cHBvcnQgTkFUPyBEb2VzIGlzdCANCj4+IHN1 cHBvcnQgbXVsdGlwbGUgRUlEcyBvbiBvbmUgUkxPQz8NCj4+IA0KDQotLQ0KQmVzdCByZWdhcmRz LA0KDQpSZW5lIEJhcnRzY2gsIEIuIFNjLiBJbmZvcm1hdGljcw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpc3AgbWFpbGluZyBsaXN0DQpsaXNwQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCg== From sm@resistor.net Mon Nov 11 12:25:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2F11E8145 for ; Mon, 11 Nov 2013 12:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4v0zSKXk1DJ for ; Mon, 11 Nov 2013 12:25:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 134AF11E8137 for ; Mon, 11 Nov 2013 12:25:11 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rABKORhT021666; Mon, 11 Nov 2013 12:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384201508; bh=LN4NmPiYy62dD+SwUg7yYrsSgZdyPwsXzY5ILujO/VY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e3rTGIhW8iiK7LMD8EUXGce/VyTrI9AG0zuP+ts8HZ7qEIx8KD7JFmmvAkE54eOba 6LKCZw8GI88on2tVLmomaiVAIMvn79HcI28DX+U9Jx17Cny0GtBhvCiiz3kwBrpeON MNtZXX/Um1RW2Q7xODBgNchLqxAWya+5t0yGJVYo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384201508; i=@resistor.net; bh=LN4NmPiYy62dD+SwUg7yYrsSgZdyPwsXzY5ILujO/VY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jWMdqn7a5+RiCxahdkkr11iBu8vaCTC7hPyZc6HTUSHsgaymLd84lnyFvmUTjtX+t CMzVIDSAXRv9IC6pV3HRSUHLvaQq0vTCck3vNQ/W3I8M/VOqFTpSp9GB2KHoKOtCvC FwQdbAQ7Klf3BjdtD8SFWTj0fXaRnMdJvfh9nni8= Message-Id: <6.2.5.6.2.20131111122315.0bdca1d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 11 Nov 2013 12:24:17 -0800 To: Rene Bartsch From: SM In-Reply-To: <32d7838454b70dc8430c24a9f4a967fb@bartschnet.de> References: <32d7838454b70dc8430c24a9f4a967fb@bartschnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: lisp@ietf.org Subject: [lisp] Writing a formal draft (was: Personal EID hashed of public RSA-key) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:25:13 -0000 Hi Rene, At 01:05 11-11-2013, Rene Bartsch wrote: >Can you point me to documentation about writing a formal draft? http://www.youtube.com/watch?v=Bj3G1fyDo_Y Regards, -sm From lucy.yong@huawei.com Mon Nov 11 13:31:11 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ACC21E809D; Mon, 11 Nov 2013 13:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOPr5Yist7Fw; Mon, 11 Nov 2013 13:31:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D74EC21E8090; Mon, 11 Nov 2013 13:31:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXT83593; Mon, 11 Nov 2013 21:31:03 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:30:51 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:31:02 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 13:30:54 -0800 From: Lucy yong To: Robert Raszuk Thread-Topic: ??: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 Thread-Index: AQHO3Rgk0EGAccVZrEOtrYlS51WxCpofmj4AgACwXYCAAELFIA== Date: Mon, 11 Nov 2013 21:30:53 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ECC2F@dfweml509-mbx.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EC235@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Xuxiaohu , "l3vpn@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] ??: Prefix overlapping issue for draft-bonica-l3vpn-orf-covering-prefixes-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:31:11 -0000 Hi Robert, Please see inline. -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Monday, November 11, 2013 3:21 AM To: Lucy yong Cc: Xuxiaohu; l3vpn@ietf.org; lisp@ietf.org Subject: Re: ??: [lisp] Prefix overlapping issue for draft-bonica-l3vpn-orf= -covering-prefixes-00 Hi Lucy, Proposed solution works within a VPN context. It is not a general design at= this point. I am actually looking what would be the optimal encoding to address the VPN= case particulary RFC7024 optimality as well as possibly to also allow for = other applications. [Lucy] that is great to hear. Glad to work together on the solution. Enforcing to request host address will not work as PEs do not carry host ro= utes for VPNs .... at least those which are properly configured :) Site addresses are advertised in blocks. Of course if site consists of s= ingle tenant VM that would be host address - but this is rather special cas= e for one solution space. [Lucy] Agree. My use cases are in DC and for VN overlay now. So requesting = host address works there. But not work if PE does not have the host visibil= ity. Our goal should target to address both cases. If it runs into too comp= lex in BGP environment, we can scale back. Love to hear your proposal. To your point of sending to "wrong PE" I do not really see that. At most it= may be suboptimal PE for some duration of time ... not wrong one. And the = case will self-cure when more specific get's advertised anyway. [Lucy] This is what I mean. Agree that "suboptimal PE" only happens in a sh= ort period. Regards, Lucy Best regards, R. On Mon, Nov 11, 2013 at 8:00 AM, Lucy yong wrote: > When requesting covering prefix, it has the chance that a prefix may appl= y to more than on VPN site in the environment of VM mobility. If we just re= quest a host or a set of host addresses, and give the rule that only PEs th= at has the host route replies the request. This may address the issue, isn'= t it? Otherwise, due to the response time difference, the ingress PE may se= nd the packet to the wrong PE, isn't it? But if PE does not have host addre= ss visibility, this will not work. > > IMO: We need a solution to work w/ or w/o RR. > > Lucy > > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf=20 > Of Robert Raszuk > Sent: Saturday, November 09, 2013 12:51 AM > To: Xuxiaohu > Cc: l3vpn@ietf.org; lisp@ietf.org > Subject: Re: ??: [lisp] Prefix overlapping issue for=20 > draft-bonica-l3vpn-orf-covering-prefixes-00 > > Hi Xiaohu, > > Prefix overlap within VPN is either on purpose injected into given VPN or= is due to VPN misconfiguration. > > Detection or mitigation of this as far as I can see is outside of scope o= f this draft. > > LISP operates in global space, this draft operates in VPN space. Those sp= aces while seemingly similar in reality have very different routing charact= eristics. > > Best, > R. From ietf@bartschnet.de Tue Nov 12 11:52:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89A21E8064 for ; Tue, 12 Nov 2013 11:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtZ13pgwB+Dr for ; Tue, 12 Nov 2013 11:51:59 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id C46E321E8095 for ; Tue, 12 Nov 2013 11:51:58 -0800 (PST) Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VgK0D-0006zD-3h for lisp@ietf.org; Tue, 12 Nov 2013 20:51:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 12 Nov 2013 20:51:57 +0100 From: Rene Bartsch To: "lisp@ietf.org list" In-Reply-To: <5D2370BC6C95CF4FAE74B9B3BE1EFA2FD01D0934@a1telekom.at> References: "\"\\\" " "<527BFFC9.3050203@ac.upc.edu>\" \"" <6189626e2a63a3cadc35ace3326052ad@bartschnet.de>\" <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> <5280B4FC.1070901@ac.upc.edu> "<9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de>\"" <5D2370BC6C95CF4FAE74B9B3BE1EFA2FD01D0934@a1telekom.at> Message-ID: <6ec12535e429cc5bcba2c0217dc001ca@bartschnet.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: Re: [lisp] =?utf-8?q?LISP_support_in_Linux_kernel=3F?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:52:03 -0000 It's a german version already running 84.06.00. Strangely it shows the network addresses of the IPv4- and IPv6-networks (LISP Beta-Network) instead of the first usable host address as new public IPs of the Fritz!Box. Hosts in the LAN cannot connect with the internet. I sent support data nearly a week ago to AVM and hope they'll find the reason as there is no real LISP-logging in the Fritz!Box. Best regards, Renne Am 2013-11-11 13:08, schrieb Strasser Jürgen: > Dear René, > > if you have a german AVM FBF7390, than LISP capable FW 06.00 was > release app. 2 Weeks ago > > If you have an international box, I can help you with an FW upgrade, > if you give me remote access (with a dedecated account which you can > log later on) > I'm not allowed to share this new Firmware public > > All the best from Vienna, > > > Ing. Jürgen Strasser > Service Network Planning > Communication Services > > A1 Telekom Austria AG > Lassallestraße 9 1020 Wien > M +43 664 66 27309 > F +43 50 664 9 27309 > @ juergen.strasser@A1telekom.at > > A1.net > Facebook.A1.net > > Firmensitz Wien FN: 280571f > Handelsgericht Wien > > > > Einfach Papier sparen. Einfach an die Umwelt denken. > > > > > > -----Ursprüngliche Nachricht----- > Von: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] Im Auftrag > von Rene Bartsch > Gesendet: Montag, 11. November 2013 11:57 > An: lisp@ietf.org list > Betreff: Re: [lisp] LISP support in Linux kernel? > > Unfortunately I've one location with an AVM Fritz!Box 7390, which > seems to have a LISP-bug, and one location with an AVM Fritz!Box > 7330SL, which doesn't support LISP, yet. > > I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard > RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not > possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and > /48-IPv6 of LISP Beta-Network). Unfortunately more and more german > ISPs switch to Dual-Stack Lite which renders LISPmob unusable for > routers unless multiple EIDs are possible with NAT. > > Regards, > > Renne > > Am 2013-11-11 11:44, schrieb Albert López: >> We tested with Ubuntu but it should work in any linux implementation. >> It supports NAT-traversal but only with one EID and one RLOC. If you >> don't require NAT, then multiple EIDs and multiple RLOCs are >> supported. >> >> Regards >> >> Albert L. >> >> On 11/11/2013 11:28 AM, Rene Bartsch wrote: >>> Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >>>>> LISPmob for Android already supports NAT traversal. You can find >>>>> the >>>> latest code here: >>>> >>>> https://github.com/LISPmob/lispmob/tree/android >>>> >>>> We expect to offer a binary version (Android APK) on lispmob.org >>>> soon. >>> >>> How is the state of the Debian-version? Does it support NAT? Does ist >>> support multiple EIDs on one RLOC? >>> > > -- > Best regards, > > Rene Bartsch, B. Sc. Informatics > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Best regards, Rene Bartsch, B. Sc. Informatics From bmuszynski@gatesecure.net Tue Nov 12 12:18:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD321E80C4 for ; Tue, 12 Nov 2013 12:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIDD4vCbmwAF for ; Tue, 12 Nov 2013 12:18:06 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB621E80B4 for ; Tue, 12 Nov 2013 12:18:04 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wp4so4451591obc.22 for ; Tue, 12 Nov 2013 12:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gatesecure.net; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jFvfC3cGP7QP/dMYGEonkqO9oBZHIfG6Dq3eUHbb+qk=; b=VeW0rU9RuXhZmfJcAVcgKO7v0aFvRDnbRXluwu4L1ZiUJphOwrq22n0Lso5Ci6aYNO zhxLIn+nEaIUd0Bo3WQ0W4WLI5oqzQzfsOlcz4ko11NVJBNjvAU/dBNNQJiDKyrvAkfg 42xqFhPbAWXmej1UK9fZf2S5rJ03VDHDrf95Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jFvfC3cGP7QP/dMYGEonkqO9oBZHIfG6Dq3eUHbb+qk=; b=kYiQGeBEqWXAEx/+7Ilztgje7rg0Esbcm7nhrV56sPzdmjAI71Iwrx4+wNxou5O0IB XOqgoZ/Hcq1w/v0dCooIagKayrs/SZ371KItEPHrFmbbqsKRKcVAiRSnGags+B56iKkb 7PhJRcUm3nSLRWCatfFum7J1koSdA67Z9t2SEYekpFuevTiiru6bwmjOnfr5EbUEp2SQ jCfksw8ZP6MDDb7q70k1VvGOwWpmwadl/yT8xlo5yTZn0eCaOr2jgHfE4tZm3eaZ29Ew HkjId6O7khzsTY8K8oKoYoP6rS7HUo1NqLT+JmVpSZYglYbkHWbe8SgeDEmgp0LEdx4l 5hGg== X-Gm-Message-State: ALoCoQn+3QDABH8SX80mgt4g69JWJR/HETRd0Sox2tyJ7X+vo06OCSKPpaKF0Y4uGEpDfqUbPh8f MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr32711521obm.14.1384287484464; Tue, 12 Nov 2013 12:18:04 -0800 (PST) Sender: bmuszynski@gatesecure.net Received: by 10.60.90.100 with HTTP; Tue, 12 Nov 2013 12:18:04 -0800 (PST) In-Reply-To: <6ec12535e429cc5bcba2c0217dc001ca@bartschnet.de> References: <527BFFC9.3050203@ac.upc.edu> <6189626e2a63a3cadc35ace3326052ad@bartschnet.de> <8b7688ac6b4fcef7c04a261c7b8e2459@bartschnet.de> <5280B4FC.1070901@ac.upc.edu> <9f45d65bb60458d8c6321efe528fa3b7@bartschnet.de> <5D2370BC6C95CF4FAE74B9B3BE1EFA2FD01D0934@a1telekom.at> <6ec12535e429cc5bcba2c0217dc001ca@bartschnet.de> Date: Tue, 12 Nov 2013 21:18:04 +0100 X-Google-Sender-Auth: z-AnDJvqkBy3vlQJbUkZJwwfAMI Message-ID: From: Bartosz Muszynski To: Rene Bartsch Content-Type: multipart/alternative; boundary=001a11c3235ac765c104eb008b54 Cc: "lisp@ietf.org list" Subject: Re: [lisp] LISP support in Linux kernel? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:20:12 -0000 --001a11c3235ac765c104eb008b54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rene, this bug is fixed internally at AVM and will go probably into the next firmware update the next days. Our setup is to tunnel everything "after LISP" into a native IPv4 GRE-tunnel and as a "partial" workaround we used an EID-prefix .128/25, so that we can avoid masquerading as far as possible. Another option is probably to do a source/destination IP rewrite via iptables if this is possible for you. Best regards, Bartosz On Tue, Nov 12, 2013 at 8:51 PM, Rene Bartsch wrote: > It's a german version already running 84.06.00. Strangely it shows the > network addresses of the IPv4- and IPv6-networks (LISP Beta-Network) > instead of the first usable host address as new public IPs of the > Fritz!Box. Hosts in the LAN cannot connect with the internet. > > I sent support data nearly a week ago to AVM and hope they'll find the > reason as there is no real LISP-logging in the Fritz!Box. > > Best regards, > > Renne > > > Am 2013-11-11 13:08, schrieb Strasser J=FCrgen: > > Dear Ren=E9, >> >> if you have a german AVM FBF7390, than LISP capable FW 06.00 was >> release app. 2 Weeks ago >> >> If you have an international box, I can help you with an FW upgrade, >> if you give me remote access (with a dedecated account which you can >> log later on) >> I'm not allowed to share this new Firmware public >> >> All the best from Vienna, >> >> >> Ing. J=FCrgen Strasser >> Service Network Planning >> Communication Services >> >> A1 Telekom Austria AG >> Lassallestra=DFe 9 1020 Wien >> M +43 664 66 27309 >> F +43 50 664 9 27309 >> @ juergen.strasser@A1telekom.at >> >> A1.net >> Facebook.A1.net >> >> Firmensitz Wien FN: 280571f >> Handelsgericht Wien >> >> >> >> Einfach Papier sparen. Einfach an die Umwelt denken. >> >> >> >> >> >> -----Urspr=FCngliche Nachricht----- >> Von: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] Im Auftrag >> von Rene Bartsch >> Gesendet: Montag, 11. November 2013 11:57 >> An: lisp@ietf.org list >> Betreff: Re: [lisp] LISP support in Linux kernel? >> >> Unfortunately I've one location with an AVM Fritz!Box 7390, which >> seems to have a LISP-bug, and one location with an AVM Fritz!Box >> 7330SL, which doesn't support LISP, yet. >> >> I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard >> RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not >> possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and >> /48-IPv6 of LISP Beta-Network). Unfortunately more and more german >> ISPs switch to Dual-Stack Lite which renders LISPmob unusable for >> routers unless multiple EIDs are possible with NAT. >> >> Regards, >> >> Renne >> >> Am 2013-11-11 11:44, schrieb Albert L=F3pez: >> >>> We tested with Ubuntu but it should work in any linux implementation. >>> It supports NAT-traversal but only with one EID and one RLOC. If you >>> don't require NAT, then multiple EIDs and multiple RLOCs are >>> supported. >>> >>> Regards >>> >>> Albert L. >>> >>> On 11/11/2013 11:28 AM, Rene Bartsch wrote: >>> >>>> Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal: >>>> >>>>> LISPmob for Android already supports NAT traversal. You can find >>>>>> the >>>>>> >>>>> latest code here: >>>>> >>>>> https://github.com/LISPmob/lispmob/tree/android >>>>> >>>>> We expect to offer a binary version (Android APK) on lispmob.org >>>>> soon. >>>>> >>>> >>>> How is the state of the Debian-version? Does it support NAT? Does ist >>>> support multiple EIDs on one RLOC? >>>> >>>> >> -- >> Best regards, >> >> Rene Bartsch, B. Sc. Informatics >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > -- > Best regards, > > Rene Bartsch, B. Sc. Informatics > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a11c3235ac765c104eb008b54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Rene,

this bug is fixed internally at AVM a= nd will go probably into the next firmware update the next days. Our setup = is to tunnel everything "after LISP" into a native IPv4 GRE-tunne= l and as a "partial" workaround we used an EID-prefix .128/25, so= that we can avoid masquerading as far as possible. Another option is proba= bly to do a source/destination IP rewrite via iptables if this is possible = for you.

Best regards,
Bartosz

=
On Tue, Nov 12, 2013 at 8:51 PM, Rene Bartsc= h <ietf@bartschnet.de> wrote:
It's a german version already running 84= .06.00. Strangely it shows the network addresses of the IPv4- and IPv6-netw= orks (LISP Beta-Network) instead of the first usable host address as new pu= blic IPs of the Fritz!Box. Hosts in the LAN cannot connect with the interne= t.

I sent support data nearly a week ago to AVM and hope they'll find the = reason as there is no real LISP-logging in the Fritz!Box.

Best regards,

Renne


Am 2013-11-11 13:08, schrieb Strasser J=FCrgen:

Dear Ren=E9,

if you have a german AVM FBF7390, than LISP capable FW 06.00 was
release app. 2 Weeks ago

If you have an international box, I can help you with an FW upgrade,
if you give me remote access (with a dedecated account which you can
log later on)
I'm not allowed to share this new Firmware public

All the best from Vienna,


Ing. J=FCrgen Strasser
Service Network Planning
Communication Services

A1 Telekom Austria AG
Lassallestra=DFe 9 1020 Wien
M =A0 +43 664 66 27309
F =A0 +43 50 664 9 27309
@ =A0 juergen.strasser@A1telekom.at

A1.net
Facebook.A1.net
Firmensitz Wien FN: 280571f
Handelsgericht Wien



Einfach Papier sparen. Einfach an die Umwelt denken.





-----Urspr=FCngliche Nachricht-----
Von: lisp-bounce= s@ietf.org [mailto:lisp-bounces@ietf.org] Im Auftrag
von Rene Bartsch
Gesendet: Montag, 11. November 2013 11:57
An: lisp@ietf.org li= st
Betreff: Re: [lisp] LISP support in Linux kernel?

Unfortunately I've one location with an AVM Fritz!Box 7390, which
seems to have a LISP-bug, and one location with an AVM Fritz!Box
7330SL, which doesn't support LISP, yet.

I considered using my Ubuntu 12.04 LTS-NAS or a Mikrotik Routerboard
RB493G with OpenWRT behind the Fritz!Box 7330SL, but that's not
possible unless LISPmob supports NAT with multiple EIDs (/28-IPv4 and
/48-IPv6 of LISP Beta-Network). Unfortunately more and more german
ISPs switch to Dual-Stack Lite which renders LISPmob unusable for
routers unless multiple EIDs are possible with NAT.

Regards,

Renne

Am 2013-11-11 11:44, schrieb Albert L=F3pez:
We tested with Ubuntu but it should work in any linux implementation.
It supports NAT-traversal but only with one EID and one RLOC. If you
don't require NAT, then multiple EIDs and multiple RLOCs are
supported.

Regards

Albert L.

On 11/11/2013 11:28 AM, Rene Bartsch wrote:
Am 2013-11-08 01:08, schrieb Alberto Rodriguez-Natal:
LISPmob for Android already supports NAT traversal. You can find
the
latest code here:

https://github.com/LISPmob/lispmob/tree/android

We expect to offer a binary version (Android APK) on lispmob.org
soon.

How is the state of the Debian-version? Does it support NAT? Does ist
support multiple EIDs on one RLOC?


--
Best regards,

Rene Bartsch, B. Sc. Informatics
_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--
Best regards,

Rene Bartsch, B. Sc. Informatics
_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--001a11c3235ac765c104eb008b54-- From lucy.yong@huawei.com Tue Nov 12 12:25:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8E21E80F9; Tue, 12 Nov 2013 12:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHg9FU4g4R7N; Tue, 12 Nov 2013 12:25:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9AB21F9C6A; Tue, 12 Nov 2013 12:25:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE73950; Tue, 12 Nov 2013 20:25:31 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 20:24:33 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 20:25:29 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 12:25:24 -0800 From: Lucy yong To: "l2vpn@ietf.org" , "l3vpn@ietf.org" , "lisp@ietf.org" , "trill@ietf.org" Thread-Topic: New Version Notification for draft-yong-nvo3-nve-01.txt Thread-Index: AQHO39Rm8NXMttcE5UeGJuimDcGum5oh/RIggAAMXZA= Date: Tue, 12 Nov 2013 20:25:23 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ED194@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [lisp] FW: New Version Notification for draft-yong-nvo3-nve-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:25:54 -0000 VGhpcyBpcyBmb3IgdGhvc2Ugd2hvIGFyZSBub3QgaW4gTlZPMyBtYWlsaW5nIGxpc3QuIFNpbmNl IHRoZXJlIGFyZSBwb3RlbnRpYWwgdG8gdXNlIGwydnBuLCBsM3ZwbiwgbGlzcCwgdHJpbGwgc29s dXRpb24gZm9yIE5WTzMsIGl0IGlzIGJlbmVmaWNpYWwgdG8gbGV0IHRoZXNlIGNvbW11bml0aWVz IGF3YXJlIG9mIHRoaXMgZHJhZnQuDQoNClNvcnJ5IGlmIHRob3NlIGdldCBtdWx0aXBsZSBvZiB0 aGlzLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTHVjeSB5b25nIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTo0NCBQTQ0K VG86IG52bzNAaWV0Zi5vcmcNClN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXlvbmctbnZvMy1udmUtMDEudHh0DQoNCkhlbGxvIE5WTzMgQ29tbXVuaXR5LA0K DQpUaGlzIGlzIGEgbmV3IGRyYWZ0LiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBOVkUgZGF0YSBw bGFuZSBmdW5jdGlvbmFsaXR5LiBUaGVzZSBmdW5jdGlvbmFsaXR5IHNwZWNpZmljYXRpb25zIGFy ZSBuZWNlc3NhcnkgZm9yIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gYW4gTlZFIGFuZCBp dHMgYXR0YWNoZWQgdGVuYW50IHN5c3RlbXMgYW5kIGJldHdlZW4gdGhlIE5WRXMuIFRoZSBkYXRh IHBsYW5lIGZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgaW5kZXBl bmRlbnQgb2YgTlZFIG9yIE5WTzMgY29udHJvbCBwbGFuZSBmdW5jdGlvbmFsaXR5LiBIb3dldmVy IHRoZSBzcGVjaWZpY2F0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGNhbiBzdXBwb3J0IGFueSBjb250 cm9sIHBsYW5lIHNvbHV0aW9uIGFuZCBhcmUgaGVscGZ1bCBpbiB0aGUgY29udHJvbCBwbGFuZSBw cm90b2NvbCBkZXZlbG9wbWVudC4NCg0KV2UgbG92ZSB0byBoZWFyIHBlb3BsZSBmZWVkYmFja3Mg b24gdGhlIGRyYWZ0LiBTb21lIHNlY3Rpb25zIGluIHRoZSBkcmFmdCBhcmUgbm90IGNvbXBsZXRl ZCB5ZXQgYW5kIHdpbGwgYmUgdXBkYXRlZCBpbiBuZXh0IHZlcnNpb24uDQoNClJlZ2FyZHMsDQpM dWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2Rh eSwgTm92ZW1iZXIgMTIsIDIwMTMgMTI6MjQgUE0NClRvOiBMdWN5IHlvbmcNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW9uZy1udm8zLW52ZS0wMS50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW9uZy1udm8zLW52ZS0wMS50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWN5IFlvbmcgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXlvbmctbnZvMy1udmUNClJldmlz aW9uOgkgMDENClRpdGxlOgkJIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gRWRnZSAoTlZFKQ0KQ3Jl YXRpb24gZGF0ZToJIDIwMTMtMTEtMTENCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAxNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC15b25nLW52bzMtbnZlLTAxLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvbmctbnZvMy1udmUN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW9uZy1u dm8zLW52ZS0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC15b25nLW52bzMtbnZlLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFZGdlIChOVkUpIGRhdGEgcGxhbmUN CiAgIGZ1bmN0aW9uYWxpdHkgZm9yIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheXMgKE5W TzMpLiBUaGVzZQ0KICAgZnVuY3Rpb25hbGl0eSBzcGVjaWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5 IGZvciB0aGUgaW50ZXJvcGVyYWJpbGl0eQ0KICAgYmV0d2VlbiBhbiBOVkUgYW5kIGl0cyBhdHRh Y2hlZCB0ZW5hbnQgc3lzdGVtcyBhbmQgYmV0d2VlbiB0aGUgTlZFcy4NCg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From rbonica@juniper.net Thu Nov 14 07:41:22 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7711E8136 for ; Thu, 14 Nov 2013 07:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.365 X-Spam-Level: X-Spam-Status: No, score=-98.365 tagged_above=-999 required=5 tests=[AWL=-5.414, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPKqRppeCrTv for ; Thu, 14 Nov 2013 07:41:16 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id AEABE11E8141 for ; Thu, 14 Nov 2013 07:41:15 -0800 (PST) Received: from mail33-db9-R.bigfish.com (10.174.16.248) by DB9EHSOBE006.bigfish.com (10.174.14.69) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 15:41:14 +0000 Received: from mail33-db9 (localhost [127.0.0.1]) by mail33-db9-R.bigfish.com (Postfix) with ESMTP id B08216019F; Thu, 14 Nov 2013 15:41:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z579eh5109hz9371Ic89bh542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h941hd24hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail33-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(51704005)(54356001)(66066001)(46102001)(53806001)(74502001)(4396001)(65816001)(74316001)(80022001)(74662001)(47736001)(79102001)(83072001)(80976001)(54316002)(224303002)(49866001)(56776001)(63696002)(31966008)(47446002)(74876001)(47976001)(33646001)(19580395003)(85306002)(50986001)(74366001)(19580405001)(83322001)(81816001)(76482001)(81686001)(69226001)(74706001)(51856001)(81542001)(56816003)(76576001)(59766001)(87266001)(76786001)(81342001)(76796001)(77982001)(77096001)(87936001)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail33-db9 (localhost.localdomain [127.0.0.1]) by mail33-db9 (MessageSwitch) id 1384443672396438_27094; Thu, 14 Nov 2013 15:41:12 +0000 (UTC) Received: from DB9EHSMHS002.bigfish.com (unknown [10.174.16.242]) by mail33-db9.bigfish.com (Postfix) with ESMTP id 5B83D3E008F; Thu, 14 Nov 2013 15:41:12 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS002.bigfish.com (10.174.14.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 15:41:12 +0000 Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 15:41:11 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 14 Nov 2013 15:41:09 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.67]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.67]) with mapi id 15.00.0785.001; Thu, 14 Nov 2013 15:41:09 +0000 From: Ronald Bonica To: Xuxiaohu , Dino Farinacci , Robert Raszuk Thread-Topic: =?gb2312?B?W2xpc3BdILTwuLQ6ICBQcmVmaXggb3ZlcmxhcHBpbmcgaXNzdWUgZm9yIGRy?= =?gb2312?Q?aft-bonica-l3vpn-orf-covering-prefixes-00?= Thread-Index: AQHO3RmJfdeBnPesvU+7EKtw46Oi3podGLeAgAZIHYA= Date: Thu, 14 Nov 2013 15:41:08 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227588@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BF1@NKGEML512-MBS.china.huawei.com> , <7CDF7688-E52D-4CCD-B813-FD46BBFBB3EA@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C9E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C9E@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0030839EEE Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "lisp@ietf.org" Subject: Re: [lisp] =?gb2312?b?tPC4tDogIFByZWZpeCBvdmVybGFwcGluZyBpc3N1ZSBm?= =?gb2312?b?b3IgZHJhZnQtYm9uaWNhLWwzdnBuLW9yZi1jb3ZlcmluZy1wcmVmaXhlcy0w?= =?gb2312?b?MA==?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:41:22 -0000 Rm9sa3MsDQoNCkF0IHRoZSBMSVNQIGNoYWlyJ3MgcmVxdWVzdCwgSSB3aWxsIHJlc3BvbmQgb24g dGhlIEwzVlBOIG1haWxpbmcgbGlzdCBvbmx5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBs M3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+IE9mIFh1eGlhb2h1DQo+IFNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAwOSwgMjAx MyAxMTozNCBBTQ0KPiBUbzogRGlubyBGYXJpbmFjY2k7IFJvYmVydCBSYXN6dWsNCj4gQ2M6IGwz dnBuQGlldGYub3JnOyBsaXNwQGlldGYub3JnDQo+IFN1YmplY3Q6ILTwuLQ6IFtsaXNwXSC08Li0 OiBQcmVmaXggb3ZlcmxhcHBpbmcgaXNzdWUgZm9yIGRyYWZ0LWJvbmljYS0NCj4gbDN2cG4tb3Jm LWNvdmVyaW5nLXByZWZpeGVzLTAwDQo+IA0KPiBIaSBEaW5vLA0KPiANCj4gdGhlIGZvbGxvd2lu ZyBpcyB0aGUgb3JpZ2luYWwgZW1haWw6DQo+IA0KPiArKysrKysrKysrKysrKysrKysrKysrKysN Cj4gSGkgY28tYXV0aG9yIG9mIHRoaXMgZHJhZnQsDQo+IA0KPiBBcyBJIGhhZCBtZW50aW9uZWQg YXQgdGhlIG1pYywgdGhlIG1lY2hhbmlzbSBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0DQo+IG5lZWRz IHRvIGNvbnNpZGVyIHRoZSBwcmVmaXggb3ZlcmxhcHBpbmcgaXNzdWUgd2hpY2ggaGFzIGJlZW4N Cj4gY29uc2lkZXJlZCBhbmQgYWRkcmVzc2VkIGJ5IExJU1AuDQo+IA0KPiBUbyBSb24sDQo+IA0K PiBUaGUgZGVmYXVsdCByb3V0ZSBvbiB0aGUgc3Bva2UgY2FuIG5vdCBiZSByZXNvcnRlZCB0byBh ZGRyZXNzIHRoZQ0KPiBwb3RlbnRpYWwgaXNzdWUgY2F1c2VkIGJ5IHRoZSBwcmVmaXggb3Zlcmxh cHBpbmcgaXNzdWUuIFRoZSByZWFzb24gaXMNCj4gdGhhdCBpdCdzIHRoZSBsb25nZXN0LW1hdGNo aW5nIHJvdXRlIDEwLzgsIHJhdGhlciB0aGFuIHRoZSBkZWZhdWx0DQo+IHJvdXRlIGlzIHVzZWQg dG8gcm91dGUgdGhlIHBhY2tldCBkZXN0aW5lZCBmb3IgMTAuMTAuMTAuMTAsIGluIHRoZSBjYXNl DQo+IHdoZXJlIGEgcm91dGUgZm9yIDEwLzggaGFzIGJlZW4gcmV0dXJuZWQgdG8gdGhhdCBzcG9r ZSBkdWUgdG8gYSByZXF1ZXN0DQo+IGZyb20gdGhhdCBzcG9rZSBmb3IgdGhlIGxvbmdlc3QtbWF0 Y2hpbmcgcm91dGUgZm9yIGEgZ2l2ZW4gaG9zdCBhZGRyZXNzDQo+IDEwLjAuMC4xLiAgQXMgYSBy ZXN1bHQsIHRoZSB0cmFmZmljIGZvciAxMC4xMC4xMC4xMCB3b3VsZCBiZSBmb3J3YXJkZWQNCj4g dG8gdGhlIG5leHRob3AgZm9yIDEwLzggd2hpY2ggaW4gdHVybiBmb3J3YXJkIHRoYXQgdHJhZmZp YyBhY2NvcmRpbmcgdG8NCj4gYSBtb3JlIHNwZWZpYyByb3V0ZSBmb3IgMTAuMTAuMTAuMTAuIFRo aXMgaXMgc3Vib3B0aW1hbC4gQXNzdW1lIHRoZQ0KPiB0cmFmZmljIHZvbHVtZSBmb3IgdGhlIGRl c3RpbmF0aW9uIG9mIDEwLjEwLjEwLjEwIGlzIGhpZ2gsIGhvdyB0bw0KPiB0cmlnZ2VyIGEgcmVx dXRzdCBmb3IgYSAicmVhbCIgZGlyZWN0IHJvdXRlIHRvIDEwLjEwLjEwLjEwIGlmIHRoZXJlDQo+ IGV4aXN0cyBhIGhvc3Qgcm91dGUgZm9yIDEwLjEwLjEwLjEwLzMyIGF0IHRoZSBodWI/IE9uZSBw b3NzaWJsZSB3YXkgaXMNCj4gdG8gYWx3YXlzIHJlcXVlc3QgYSBtb3JlIHNwZWNpZmljIHJvdXRl IHVudGlsIGEgaG9zdCByb3V0ZSBmb3IgdGhlDQo+IGRlc3RpbmF0aW9uIG9mIHRoZSByZWNlaXZl ZCBwYWNrZXQgaXMgZm91bmQgYXQgdGhlIHNwb2tlLg0KPiANCj4gU2luY2UgdGhpcyBpc3N1ZSBo YXMgYmVlbiBkaXNjY3Vzc2VkIGF0IExJU1AgV0cgbWFueSB5ZWFycyBiZWZvcmUuIEkNCj4gY29w eSB0aGlzIGVtYWlsIHRvIExJU1AgYXMgd2VsbC4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlh b2h1DQo+IA0KPiArKysrKysrKysrKysrKysrKysrKysrKysrKw0KPiANCg0K From jmh@joelhalpern.com Sun Nov 17 01:27:42 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821AC11E8982; Sun, 17 Nov 2013 01:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pooC9p356zOh; Sun, 17 Nov 2013 01:27:37 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 379F511E89EC; Sun, 17 Nov 2013 01:25:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5AA721BC4BB7; Sun, 17 Nov 2013 01:25:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id AD73A1BC4B57; Sun, 17 Nov 2013 01:25:44 -0800 (PST) Message-ID: <52888B96.4080804@joelhalpern.com> Date: Sun, 17 Nov 2013 04:25:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: <20131116192109.11370.23437.idtracker@ietfa.amsl.com> In-Reply-To: <20131116192109.11370.23437.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131116192109.11370.23437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: NOMCOM - final call for feedback, nominee list X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 09:27:42 -0000 Please look at the lists, and provide what concrete feedback you can. Yours, Joel -------- Original Message -------- Subject: NOMCOM - final call for feedback, nominee list Date: Sat, 16 Nov 2013 11:21:09 -0800 From: NomCom Chair 2013 Reply-To: ietf@ietf.org, nomcom13@ietf.org To: IETF Announcement List CC: wgchairs@ietf.org Help the Nomcom: this is the last call for general feedback on nominees. This email includes the willing nominee list for your convenience, as per RFC 5680. WG chairs, please forward this email to your WGs. WARNING - DO NOT reply to this email with feedback - the announcement tool provides an unpredictable Reply-To field. You may send mail to nomcom13, but please do continue reading for additional info. The deadline is midnight (any timezone) Wed Nov 20. Enter your feedback into the encrypted nomcom tool at: https://datatracker.ietf.org/nomcom/2013/feedback/ All feedback is confidential. Select individual nominees, or select an area (e.g. INT Multiple) if you want to give feedback on multiple nominees for that area in one entry. The Nomcom will greatly appreciate your concrete and detailed thoughts on nominees. You need to have a datatracker account in order to enter feedback. This is the site to access either to create a datatracker account or to reset the password on an existing account: https://datatracker.ietf.org/accounts/ As we announced last week, we are sharing the names of the willing nominees in this email, as part of our use of RFC 5680 Open List in this nomcom cycle. These names (appearing at the end of the email) have been available within the datatracker since our first call for feedback; we hope some people will be extra encouraged to provide feedback by seeing the names prior to datatracker login. All your feedback must be entered in the encrypted nomcom site (or mailed to nomcom-chair-2013@ietf.org or nomcom13@ietf.org). You may ask the chair or any another nomcom member to submit your feedback without your name attached, if you would prefer. Again, your feedback is absolutely confidential, however delivered. Thanks very much from all of us for your time and for helping the Nomcom to do the best possible job. Also enormous thanks to the willing nominees. Names below. Allison for the Nomcom APP Joe Hildebrand Barry Leiba (incumbent) Yoshiro Yoneya INT Donald Eastlake Wesley George Brian Haberman (incumbent) Ole Troan OPS Benoit Claise (incumbent) Linda Dunbar Victor Kuarsingh Bill Manning RAI Ben Campbell Alissa Cooper Keith Drage Dan Romascanu RTG Loa Andersson Alia Atlas Deborah Brungard Stewart Bryant (incumbent) Donald Eastlake Susan Hares Keyur Patel SEC Derek Atkins Donald Eastlake Jeff Hodges Leif Johansson Alexey Melnikov Kathleen Moriarty Eric Rescorla TSV Martin Stiemerling (incumbent) Dave Taht IAB Bernard Aboba (incumbent) Loa Andersson Alias Atlas Mary Barnes Marc Blanchet (incumbent) Ross Callon (incumbent) Hago Dafalla Linda Dunbar Roni Even Jim Gettys Ted Hardie Susan Hares Joe Hildebrand Sheng Jiang Eliot Lear (incumbent) Larry Masinter S. Moonesamy Kathleen Moriarty Kaveh Ranjbar Robert Sparks Tina Tsou Brian Trammell IAOC/IETF Trust Glenn Deen Tobias Gondrom Chris Griffiths (incumbent) John Levine Tina Tsou From terry.manderson@icann.org Tue Nov 19 15:23:45 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94251AE175 for ; Tue, 19 Nov 2013 15:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtaILIi97Zls for ; Tue, 19 Nov 2013 15:23:44 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4CF1AE138 for ; Tue, 19 Nov 2013 15:23:44 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 19 Nov 2013 15:23:37 -0800 From: Terry Manderson To: LISP mailing list list Date: Tue, 19 Nov 2013 15:23:34 -0800 Thread-Topic: WGLC draft-ietf-lisp-threats-08 Thread-Index: Ac7lfl+DoqYKc0UKQD6mzLFKb2Kbsw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3467784214_28087175" MIME-Version: 1.0 Subject: [lisp] WGLC draft-ietf-lisp-threats-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:23:46 -0000 --B_3467784214_28087175 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have requested a work group last call. Here starts a 14 day last call for this document, the last call will end on Wednesday 4th December 2013. You will find its text here: http://tools.ietf.org/html/draft-ietf-lisp-threats-08 Please review this WG item and provide any last comments. Cheers Terry --B_3467784214_28087175 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFMVfVRH3s6ufIaq584n+jGPNX7rfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTExOTIzMjMzNFowDQYJKoZIhvcNAQEBBQAEggEAMXKa/xsz jpiA+86xYYN/resfQIKuauquOOjqGbjRgo7DwkEfrZVRlA/C8hHLoI57QdYPRfDjpv9TSFto QWf6vwpkwnP/1FVMPgVX4VK+Q6CbDPLDaNGXp73Ce8ACAJAQq1DT3MdrGmgwcxkZ5OjHfMWn HKx+Pzccwb7YGc+1fE0u55WIWbJaL/6QEJW/69P7CjaweL5VWcJuP8vd7tHrwGX8tuEig5Fg lZwlr1TQYPf+IODRtuHbpvgJWav1x2ufki72kI5ZmK50o9hNVM/Ul8GGCzF0Syt6knvt1rRB Yo72wx9jwL7VLyJaVFDXv1mwakOC+pLEO44wjPNm1FtWjg== --B_3467784214_28087175-- From terry.manderson@icann.org Tue Nov 19 15:25:34 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF31AE175 for ; Tue, 19 Nov 2013 15:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zp_ZzqnJavU for ; Tue, 19 Nov 2013 15:25:33 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E73C51AE138 for ; Tue, 19 Nov 2013 15:25:32 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 19 Nov 2013 15:25:26 -0800 From: Terry Manderson To: LISP mailing list list Date: Tue, 19 Nov 2013 15:25:22 -0800 Thread-Topic: Confirming consensus on draft-ietf-lisp-introduction Thread-Index: Ac7lfqCgllrSR/mgSKG2cmtDcBskdA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3467784322_28070488" MIME-Version: 1.0 Subject: [lisp] Confirming consensus on draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:25:35 -0000 --B_3467784322_28070488 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, During the meeting in Vancouver the in-room consensus was to NOT split the document into two. This email is to confirm same on the WG mailing list. If you do not agree with the consensus from the IETF88 LISP WG meeting AND have a substantive argument as to why - please speak up. You have until midnight Monday 26th November (UTC), after that I intend to issue a last call as per WG in-room discussion. Cheers Terry --B_3467784322_28070488 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFNJOuJVmjvoVYk/mnJMwjAkMg75uMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTExOTIzMjUyMlowDQYJKoZIhvcNAQEBBQAEggEANA//PZWg vz27E0M/TF1CAmLQb2DT46ECypSrbUCKOE2YCP2WAV8Wo2/UOPY6S8kGReDSu2jYB/JfzGud vY+605vB1JAFUIK7Bhvg4EIfmj7okJWhNoX6WmYjbdneucUSuZRHS3kjpN5SrWehXT/2BA9l ZhPUudkcE5x0QIF1TBmadtMcwWQW6LGXSltlw3LW6jYj8/pESiVYKnIpHe5ldwszxkoZbgRJ uVRbiUZNLlH3Gq0WzShdqc5NxRp5QH8spr3VAkmdm4frjCbKvmPDnzuB5G24T/esAA8pk23k RxYUX85gYDukKj3Uc8PV+DHzmIM9ISNdIFJaNgITY4WoSA== --B_3467784322_28070488-- From terry.manderson@icann.org Tue Nov 19 15:25:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448FD1AE1DF for ; Tue, 19 Nov 2013 15:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLrWDYHLfKYZ for ; Tue, 19 Nov 2013 15:25:45 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id E44821AE1CC for ; Tue, 19 Nov 2013 15:25:45 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 19 Nov 2013 15:25:39 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 19 Nov 2013 15:25:36 -0800 Thread-Topic: draft-iannone-eid-block-mgmnt-03 Thread-Index: Ac7lfqiG4koC00XrRx6CJaM4OplYNA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3467784336_28112090" MIME-Version: 1.0 Subject: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 23:25:47 -0000 --B_3467784336_28112090 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit In Vancouver the chairs received a request for the following document to be adopted as a WG item. http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 Here starts a 14 day call for adoption, this call will end on Wednesday the 4th December, 2013. Please email the WG list stating that you either accept, or not accept, the item. If you email to support the acceptance of this document as a WG item, please also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry --B_3467784336_28112090 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFKjP985bmPU+dX7RBRlminKv3B7DMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTExOTIzMjUzNlowDQYJKoZIhvcNAQEBBQAEggEAZjieLpL5 SXJOKSmWYm6C0nG7mPC9AKHAPu5XccNUFmiMkAB7Hxr3kLL9oujtkcOZRsTT+tqbaXKA7H2M HH7vmfybK/42XKFLXHxSYhJWiqa2a9/iuZmCLxfUoiWBPs8mUVwh5+6ulIFNGeK77CAvQc15 PcodzccW5bRZxvf6AFv0RTjnVISoGk5O8w8GD3/c9orep0+5+Xknzo140mJC06lI2HlnNc/u rQ35ZgMNcbsWmEeBfEvFcTUzpQbkG7BGN4ALQe1vHsjw1g7x3qScz4qJ6yJAmkGkCIl2NIho EXXkKFnq+dhP/TsylZzZrhzsuXJqMXjjSlV9EuRFsI+TbA== --B_3467784336_28112090-- From fmaino@cisco.com Tue Nov 19 16:06:37 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388341AE21E for ; Tue, 19 Nov 2013 16:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qomDEkUVCm7x for ; Tue, 19 Nov 2013 16:06:35 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6B1AE212 for ; Tue, 19 Nov 2013 16:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2337; q=dns/txt; s=iport; t=1384905990; x=1386115590; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ZnlYKfVV2x4goU35Z0GfHLHL/VG1SFJ51WH40nSEG+c=; b=d+b80aK+p0gGnvEA7M75qYed0oGIKbS4CU65/t9CDKb5jIwiF16asPIY K38LoRpACkqjd9Qtk/9OqogiJ/97X9B5NDQ2KKDa8kB33j7cXGv7ZMhLZ s69j8X5M12rIb9Tfe8/wlsAE5HQJ9B/s2Y4aeniEYrxph6vauxmy1jWWi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAEL8i1KrRDoH/2dsb2JhbABZgwc4wAuBFhZ0giUBAQEEAQEBawoRCwQBEwkWDwkDAgECARUwEwYCAQGHfA6/eRMEjgsRAYFBFoQcA4lCjlCGP4tOg0kbgTU X-IronPort-AV: E=Sophos;i="4.93,732,1378857600"; d="scan'208,217";a="98201991" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Nov 2013 00:06:27 +0000 Received: from [10.21.95.68] (sjc-vpn5-1860.cisco.com [10.21.95.68]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAK06Pdm005041 for ; Wed, 20 Nov 2013 00:06:25 GMT Message-ID: <528BFD01.1060401@cisco.com> Date: Tue, 19 Nov 2013 16:06:25 -0800 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010604030106010906060305" Subject: Re: [lisp] Confirming consensus on draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 00:06:37 -0000 This is a multi-part message in MIME format. --------------010604030106010906060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit confirm. Fabio On 11/19/13, 3:25 PM, Terry Manderson wrote: > All, > > During the meeting in Vancouver the in-room consensus was to NOT split the > document into two. > > This email is to confirm same on the WG mailing list. > > If you do not agree with the consensus from the IETF88 LISP WG meeting AND > have a substantive argument as to why - please speak up. > > You have until midnight Monday 26th November (UTC), after that I intend to > issue a last call as per WG in-room discussion. > > Cheers > Terry > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------010604030106010906060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
confirm.

Fabio

On 11/19/13, 3:25 PM, Terry Manderson wrote:
All,

During the meeting in Vancouver the in-room consensus was to NOT split the
document into two.

This email is to confirm same on the WG mailing list.

If you do not agree with the consensus from the IETF88 LISP WG meeting AND
have a substantive argument as to why - please speak up.

You have until midnight Monday 26th November (UTC), after that I intend to
issue a last call as per WG in-room discussion.

Cheers
Terry



_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------010604030106010906060305-- From fmaino@cisco.com Tue Nov 19 16:08:30 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54601AE151 for ; Tue, 19 Nov 2013 16:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6y5Uh2Qbjf8 for ; Tue, 19 Nov 2013 16:08:29 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E31AE212 for ; Tue, 19 Nov 2013 16:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2925; q=dns/txt; s=iport; t=1384906103; x=1386115703; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=TojxKOvnb9lQ3OmS4GQqbv6v74GgcvXKg9vbEompPu0=; b=JjH+BytFBajzJ9yYlPCubyCLcORbDo667fWQDvDIDHpi5MCi+uLGX4GB 5PmevKPXIiHcuQps1zIlSFbBO8w91ZoK2xoLJbz0Pb3+8qf3v49Qv0l9n C/WSTdskRthpAGdDh5ps6Xnc0maVWh3z4x5uhuFZBvPa70OMtbGaB9ih7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEL8i1KrRDoG/2dsb2JhbABZgwc4wAuBFhZ0giUBAQEEAQEBGlEbCwQUCSUPAhYwEwYCAQGHfA6/eReOCxEBgUEWhBwDiUKOUIEvhRCLToNJG4E1 X-IronPort-AV: E=Sophos;i="4.93,732,1378857600"; d="scan'208,217";a="98202072" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 20 Nov 2013 00:08:23 +0000 Received: from [10.21.95.68] (sjc-vpn5-1860.cisco.com [10.21.95.68]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAK08LUR020652 for ; Wed, 20 Nov 2013 00:08:21 GMT Message-ID: <528BFD75.60905@cisco.com> Date: Tue, 19 Nov 2013 16:08:21 -0800 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070303030809070106040008" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 00:08:30 -0000 This is a multi-part message in MIME format. --------------070303030809070106040008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I support adoption, and I'm willing to review. Fabio On 11/19/13, 3:25 PM, Terry Manderson wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------070303030809070106040008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I support adoption, and I'm willing to review.

Fabio

On 11/19/13, 3:25 PM, Terry Manderson wrote:
In Vancouver the chairs received a request for the following document to be
adopted as a WG item.

http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03

Here starts a 14 day call for adoption, this call will end on
Wednesday the 4th December, 2013.

Please email the WG list stating that you either accept, or not accept, the
item.

If you email to support the acceptance of this document as a WG item,
please
also indicate if you are able and willing to either contribute to, or
review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.

Cheers
Terry




_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--------------070303030809070106040008-- From farinacci@gmail.com Tue Nov 19 20:08:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665791AE2D6 for ; Tue, 19 Nov 2013 20:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwBLa-ZqcRBS for ; Tue, 19 Nov 2013 20:08:01 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA31AE2D2 for ; Tue, 19 Nov 2013 20:08:01 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kx10so2955743pab.22 for ; Tue, 19 Nov 2013 20:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egN5VOhidCgb2K3IHcD1Ud9RZzWMKQuAbXLzwfqu+J0=; b=pq3sFcX5s7ujFCv/ktGGiixOa75OpAJLUDILqRn2QDnLulYTesuiNRN5nBnhnANstd 3HFpyXpEl/bbFKRZ1/BYlOOFl3JIfVwtZqhj4872rNLrBmxJC5kwcjBvlMyifTYjE/Db MS37GEnYt6R+BIh9he9ywiJoCtiTGf/BYC3rPjFbEPnhjTg97x0RS6z3MLFsDSHtSl1W Hl86qa2RgrNEfFCAg6FyzuOzizUGVciKDxP+It9DqdElIESsBdCOjxuCWLso9dPGbMl8 EL/UnofatCXlFThbP+CcHqjaS5bhcWHIGS7BtmCySxFOS3t2a6ySaMyJybo3CWvYo76w F7Bg== X-Received: by 10.66.152.11 with SMTP id uu11mr11750807pab.124.1384920475287; Tue, 19 Nov 2013 20:07:55 -0800 (PST) Received: from [10.79.171.128] (mobile-166-137-187-105.mycingular.net. [166.137.187.105]) by mx.google.com with ESMTPSA id yi10sm38927940pab.8.2013.11.19.20.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 20:07:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B511) In-Reply-To: Date: Tue, 19 Nov 2013 20:07:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <258DF03C-A82E-4ED7-B3D4-CF5696E3DF90@gmail.com> References: To: Terry Manderson Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 04:08:03 -0000 Accept.=20 Dino=20 > On Nov 19, 2013, at 3:25 PM, Terry Manderson w= rote: >=20 > In Vancouver the chairs received a request for the following document to b= e > adopted as a WG item. >=20 > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. >=20 > Please email the WG list stating that you either accept, or not accept, th= e > item. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately= . >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From lori@lispmob.org Tue Nov 19 23:22:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18651A1F1A for ; Tue, 19 Nov 2013 23:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuhpVG_lMr1m for ; Tue, 19 Nov 2013 23:22:07 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id EB45C1AE36F for ; Tue, 19 Nov 2013 23:22:06 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rAK7Jjes009824; Wed, 20 Nov 2013 08:19:45 +0100 Received: from [10.81.80.7] (unknown [89.123.97.194]) by gw.ac.upc.edu (Postfix) with ESMTP id 236E36B0237; Wed, 20 Nov 2013 08:18:14 +0100 (CET) Message-ID: <528C6290.8070000@lispmob.org> Date: Wed, 20 Nov 2013 09:19:44 +0200 From: Lori Jakab Organization: LISPmob MIME-Version: 1.0 To: Terry Manderson , "lisp@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:22:09 -0000 I support the adoption of the document as a working group item. -Lori On 11/20/2013 01:25 AM, Terry Manderson wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From damien.saucez@gmail.com Tue Nov 19 23:49:05 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4E1AC49D for ; Tue, 19 Nov 2013 23:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-A46UEA-X4a for ; Tue, 19 Nov 2013 23:49:03 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 444601AC4A5 for ; Tue, 19 Nov 2013 23:49:03 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id a1so8765284wgh.0 for ; Tue, 19 Nov 2013 23:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BsTVCPRkq7zMQOeBqJnSQZldNj92z7KiFQPAbtUNwyw=; b=baqcjUUEo8Z6mdSbGpFs8qjfj3SSYzhilDhujEXloIf+mWrrXyuTLKe6Mc5aMmH99n i+NPxh+18Un2/WGu76LF1bC+icDScTD8+TRwGXkWDoMPrjYN85HRQ41m11FHCLMF7f1k cpnRzOShegEjUJ/mz1HTbE5bZvVNAOJ08s+7+FikutqZaMsWGsiRIJRiWSGSJpKSNNa7 b1nhSH0JJb4fQUjQPM0KFMAj8h/JRHzTMrB6o4apQOVxST7/iUvxY+kkWN+tLcWXhv3N ZpLQWfxJM906rQxqXIaP9j0my9CfKaYijkSXzxaVCkKFfjG7WDRmHvlP1t972bigiyIi 8IRg== X-Received: by 10.180.24.6 with SMTP id q6mr24465502wif.0.1384933736371; Tue, 19 Nov 2013 23:48:56 -0800 (PST) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id dz5sm13488144wib.7.2013.11.19.23.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:48:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Damien Saucez In-Reply-To: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> Date: Wed, 20 Nov 2013 08:48:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:49:05 -0000 Dino, Sorry for the delay, I see this proposition just now. Do you propose this capability in the context of VPN and/or NSC? I would have a question, if there is capability, it means that there is a possibility to meet no capability so in this case what is replied? An record with 0 locators? no answer? a special answer saying "bad luck no match for the capability"? If 0 locators then it is a negative reply but conceptually this is not a negative reply. If no answer, then the requester will keep continuing sending requests. If a new message, what kind of message? Thanks, Damien Saucez On 12 Sep 2013, at 20:29, Dino Farinacci wrote: > So wouldn't be useful if an ITR which sends a Map-Request to the = mapping system, could say "I know Mr. ETR that you have registered a = bunch of stuff to the mapping system, but can you return just the stuff = I care about and more importantly the stuff I support in my = implementation?". >=20 > So I was thinking (and talking to several others about this), if we = could have a Capabilities Type LCAF that is encoded in an address field = of the Map-Request. I would like to propose that it get encoded in the = ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs = list could tell a Map-Replier what they support. >=20 > I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >=20 > It would be required of every implementation to support the = Capabilities Type LCAF if nothing else would be supported. That would = get the implementations to do the general parsing work so they could = skip over LCAFs they don't understand and get to the ones they do = understand while conveying what they support. >=20 > Also I find that this may be useful for this world of multiple = encapsulations. Rather than register UDP port numbers, a decapsulator = could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, = VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). >=20 > The Capabilities Type LCAF could also be used by the mapping system. = So when an ETR sends an Info-Request, an Info-Reply from the map-server = could tell the registering system what LCAFs it supported. Ditto, for = asking map-resolvers what types of EID encodings they could support = (maybe the mapping system can support more LCAF encodings then the = map-resolvers, so you can choose a different map-resolver if you wanted = more). >=20 > And arguably, the Capabilities Type LCAF could be put in RLOC-probes. = It could go anywhere with the address you wanted to encode as a 2-tuple. >=20 > Comments? >=20 > If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. And also comment if you think we should = go with the JSON Data Model Type for -03 or put it into -04 with perhaps = this Capabilities LCAF. >=20 > Thanks, > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Tue Nov 19 23:49:09 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75471AE0FD for ; Tue, 19 Nov 2013 23:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo1uK5yRGLMt for ; Tue, 19 Nov 2013 23:49:08 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id F09211AE36F for ; Tue, 19 Nov 2013 23:49:07 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so6657599wes.38 for ; Tue, 19 Nov 2013 23:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BsTVCPRkq7zMQOeBqJnSQZldNj92z7KiFQPAbtUNwyw=; b=baqcjUUEo8Z6mdSbGpFs8qjfj3SSYzhilDhujEXloIf+mWrrXyuTLKe6Mc5aMmH99n i+NPxh+18Un2/WGu76LF1bC+icDScTD8+TRwGXkWDoMPrjYN85HRQ41m11FHCLMF7f1k cpnRzOShegEjUJ/mz1HTbE5bZvVNAOJ08s+7+FikutqZaMsWGsiRIJRiWSGSJpKSNNa7 b1nhSH0JJb4fQUjQPM0KFMAj8h/JRHzTMrB6o4apQOVxST7/iUvxY+kkWN+tLcWXhv3N ZpLQWfxJM906rQxqXIaP9j0my9CfKaYijkSXzxaVCkKFfjG7WDRmHvlP1t972bigiyIi 8IRg== X-Received: by 10.194.170.133 with SMTP id am5mr5116801wjc.42.1384933741329; Tue, 19 Nov 2013 23:49:01 -0800 (PST) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id dz5sm13488144wib.7.2013.11.19.23.49.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:49:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Damien Saucez In-Reply-To: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> Date: Wed, 20 Nov 2013 08:48:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:49:10 -0000 Dino, Sorry for the delay, I see this proposition just now. Do you propose this capability in the context of VPN and/or NSC? I would have a question, if there is capability, it means that there is a possibility to meet no capability so in this case what is replied? An record with 0 locators? no answer? a special answer saying "bad luck no match for the capability"? If 0 locators then it is a negative reply but conceptually this is not a negative reply. If no answer, then the requester will keep continuing sending requests. If a new message, what kind of message? Thanks, Damien Saucez On 12 Sep 2013, at 20:29, Dino Farinacci wrote: > So wouldn't be useful if an ITR which sends a Map-Request to the = mapping system, could say "I know Mr. ETR that you have registered a = bunch of stuff to the mapping system, but can you return just the stuff = I care about and more importantly the stuff I support in my = implementation?". >=20 > So I was thinking (and talking to several others about this), if we = could have a Capabilities Type LCAF that is encoded in an address field = of the Map-Request. I would like to propose that it get encoded in the = ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs = list could tell a Map-Replier what they support. >=20 > I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >=20 > It would be required of every implementation to support the = Capabilities Type LCAF if nothing else would be supported. That would = get the implementations to do the general parsing work so they could = skip over LCAFs they don't understand and get to the ones they do = understand while conveying what they support. >=20 > Also I find that this may be useful for this world of multiple = encapsulations. Rather than register UDP port numbers, a decapsulator = could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, = VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). >=20 > The Capabilities Type LCAF could also be used by the mapping system. = So when an ETR sends an Info-Request, an Info-Reply from the map-server = could tell the registering system what LCAFs it supported. Ditto, for = asking map-resolvers what types of EID encodings they could support = (maybe the mapping system can support more LCAF encodings then the = map-resolvers, so you can choose a different map-resolver if you wanted = more). >=20 > And arguably, the Capabilities Type LCAF could be put in RLOC-probes. = It could go anywhere with the address you wanted to encode as a 2-tuple. >=20 > Comments? >=20 > If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. And also comment if you think we should = go with the JSON Data Model Type for -03 or put it into -04 with perhaps = this Capabilities LCAF. >=20 > Thanks, > Dino > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Tue Nov 19 23:52:39 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4195F1AC421 for ; Tue, 19 Nov 2013 23:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr1zKuPIfZIC for ; Tue, 19 Nov 2013 23:52:38 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C5DE71AC497 for ; Tue, 19 Nov 2013 23:52:37 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id n12so8760920wgh.10 for ; Tue, 19 Nov 2013 23:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7y4i+XEgjyIwi8BFrJJd0psZfJUjVuX/SSPHFv0axhw=; b=lOlLGfluszabezLmzzBASWNh0YIzLYg0/2tBTc78arJDo2mPZuCHBKc2QyDdNI+vt6 FLB4NW0+e22zxilzKz8OUC1Fu+B1CO+Sx4AlwLJNOMe/AbzqN72/a8UhwxFuKQmx0BbV wIntSk3G/Ej15p8Zz6HgffaiKbVPvIAvRY6y0PFs8rZMPo+9AnmjXklM2v9fEsTdCljW w5HxJ8jc6syfgUFYQR4MNNYnYrf/EBf1XwKPF8nNtp+Mrp4Mctb0/bEPMiuMZ+25bRAm gs5CYFk/o8QlVSe4bHRE3cV9C1OcBRScdchbFzKWnwaCwYowfKRl+Q/f6klE7Bq/7t5b u6yg== X-Received: by 10.180.198.170 with SMTP id jd10mr9302699wic.65.1384933951095; Tue, 19 Nov 2013 23:52:31 -0800 (PST) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id ll10sm13510971wic.9.2013.11.19.23.52.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:52:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Damien Saucez In-Reply-To: Date: Wed, 20 Nov 2013 08:52:30 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6AECA802-4024-4A67-9C3A-35FAE365D7E0@gmail.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:52:39 -0000 I support the adoption of this document as WG doc. Damien Saucez On 20 Nov 2013, at 00:25, Terry Manderson wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Sharon@Contextream.com Tue Nov 19 23:59:06 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF721AE385 for ; Tue, 19 Nov 2013 23:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO8KNWZfAwki for ; Tue, 19 Nov 2013 23:59:04 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) by ietfa.amsl.com (Postfix) with ESMTP id 69BA61AE383 for ; Tue, 19 Nov 2013 23:59:04 -0800 (PST) Received: from DB3PR06MB153.eurprd06.prod.outlook.com (10.141.1.140) by DB3PR06MB155.eurprd06.prod.outlook.com (10.141.1.146) with Microsoft SMTP Server (TLS) id 15.0.800.7; Wed, 20 Nov 2013 07:58:56 +0000 Received: from DB3PR06MB153.eurprd06.prod.outlook.com ([169.254.11.36]) by DB3PR06MB153.eurprd06.prod.outlook.com ([169.254.11.36]) with mapi id 15.00.0825.006; Wed, 20 Nov 2013 07:58:56 +0000 From: Sharon Barkai To: Terry Manderson Thread-Topic: [lisp] draft-iannone-eid-block-mgmnt-03 Thread-Index: AQHO5cZcK5URtRumKE2R6bmhpJ+zrw== Date: Wed, 20 Nov 2013 07:58:56 +0000 Message-ID: <61D7EEAC-9A58-4182-AD4B-855D32431BDE@Contextream.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.214.96.27] x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(24454002)(2656002)(74876001)(87266001)(15975445006)(74366001)(74706001)(19580405001)(83716003)(81342001)(83322001)(81686001)(56816003)(15202345003)(80976001)(81542001)(77096001)(82746002)(76796001)(31966008)(74662001)(76786001)(47446002)(63696002)(54356001)(74502001)(51856001)(53806001)(36756003)(80022001)(65816001)(66066001)(81816001)(49866001)(33656001)(69226001)(47736001)(50986001)(87936001)(19580395003)(54316002)(59766001)(79102001)(47976001)(85306002)(56776001)(4396001)(76482001)(46102001)(77982001)(83072001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB155; H:DB3PR06MB153.eurprd06.prod.outlook.com; CLIP:108.214.96.27; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:59:06 -0000 Support. We may see OTT lisp overlay carriers spawn to use it. Looking forward to the nfv nvo lisp drafts getting into this excellent pion= eering Wg.. Perhaps after the next interim :) --szb On Nov 19, 2013, at 3:25 PM, "Terry Manderson" = wrote: In Vancouver the chairs received a request for the following document to be adopted as a WG item. http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 Here starts a 14 day call for adoption, this call will end on Wednesday the 4th December, 2013. Please email the WG list stating that you either accept, or not accept, the item. If you email to support the acceptance of this document as a WG item, please also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From fcoras@ac.upc.edu Wed Nov 20 02:01:58 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47E1AE3CE for ; Wed, 20 Nov 2013 02:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdtF0_W-rxAu for ; Wed, 20 Nov 2013 02:01:55 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 299F31AD8F2 for ; Wed, 20 Nov 2013 02:01:54 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rAKA1mIX014870; Wed, 20 Nov 2013 11:01:48 +0100 Received: from [147.83.130.43] (dhcp7.ccaba.upc.edu [147.83.130.43]) by gw.ac.upc.edu (Postfix) with ESMTP id 5B9B46B0237; Wed, 20 Nov 2013 11:00:17 +0100 (CET) Message-ID: <528C8888.7070709@ac.upc.edu> Date: Wed, 20 Nov 2013 11:01:44 +0100 From: Florin Coras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:01:58 -0000 I support the adoption of this document as working group item. Florin On 11/20/2013 12:25 AM, Terry Manderson wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vimoreno@cisco.com Wed Nov 20 04:11:50 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043971ADE88 for ; Wed, 20 Nov 2013 04:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmi0a0b8rxAW for ; Wed, 20 Nov 2013 04:11:42 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7A51AD8F1 for ; Wed, 20 Nov 2013 04:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=957; q=dns/txt; s=iport; t=1384949493; x=1386159093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wnqm/kDyNYsvUhyE1ackYie2X9dtn+DUftqQCGr4GzQ=; b=IbsJAAnxtIMPkUFs+FSOmOlKfUnyc96gDLHs/PirbW77VNVzjGXUujS/ 4sxy9MYDNo6cUCxQJ+SN56ojlmd81No2wUKOoR3Yu0x+JiLMQASg7cQdq ni3YEaSJKmWdOj3PGx7Q8248E0EPZcAO8CfE0XyVjEeOK6Mm1wg2V68y1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF2mjFKtJV2a/2dsb2JhbABZgwc4vzmBFxZ0giUBAQEDAQEBARodNAsFCwIBCBgeECcLJQIEDgWHewYNwEoXjgsRAYEHMweDIIESA5gSgS+QXoMogXE X-IronPort-AV: E=Sophos;i="4.93,736,1378857600"; d="scan'208";a="889281" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 20 Nov 2013 12:11:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAKCBWwh016306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 12:11:32 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 06:11:32 -0600 From: "Victor Moreno (vimoreno)" To: Terry Manderson Thread-Topic: [lisp] draft-iannone-eid-block-mgmnt-03 Thread-Index: AQHO5emmzVBCYo4AN0uO1SwDdLzSjg== Date: Wed, 20 Nov 2013 12:11:32 +0000 Message-ID: <204BF777-EC05-45B1-9BC3-CAA9A989FA9E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:11:50 -0000 Support, review Victor > On Nov 19, 2013, at 3:25 PM, "Terry Manderson" wrote: >=20 > In Vancouver the chairs received a request for the following document to = be > adopted as a WG item. >=20 > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. >=20 > Please email the WG list stating that you either accept, or not accept, t= he > item. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriatel= y. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Wed Nov 20 04:41:51 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333941ADF69 for ; Wed, 20 Nov 2013 04:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FrXZqLwjTZP for ; Wed, 20 Nov 2013 04:41:50 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFFE1ADF5D for ; Wed, 20 Nov 2013 04:41:50 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CD2B618C147; Wed, 20 Nov 2013 07:41:43 -0500 (EST) To: lisp@ietf.org Message-Id: <20131120124143.CD2B618C147@mercury.lcs.mit.edu> Date: Wed, 20 Nov 2013 07:41:43 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:41:51 -0000 > From: Damien Saucez > I would have a question, if there is capability, it means that there is > a possibility to meet no capability so in this case what is replied? > ... > If 0 locators then it is a negative reply but conceptually this is not > a negative reply. If no answer, then the requester will keep continuing > sending requests. Good points. In general, I don't think we should keep tweaking Map-Request and Map-Reply messages 'because they are there'. If we need to extend semantics, let's do it right. > If a new message, what kind of message? The has been some discussion about adding a new message-type to fill a variety of roles which involve transferring information around (e.g. dynamically loading configuration information such as default PxTRs into small xTRs, a la DHCP, instead of having to manuall configure them). This would seem to naturally fall into that general classification? Noel From arnatal@ac.upc.edu Wed Nov 20 08:57:22 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFB51AE00E for ; Wed, 20 Nov 2013 08:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAPDC5Rh1Rr3 for ; Wed, 20 Nov 2013 08:57:20 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE81AE004 for ; Wed, 20 Nov 2013 08:57:20 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id rAKGvDLk030413 for ; Wed, 20 Nov 2013 17:57:13 +0100 Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by gw.ac.upc.edu (Postfix) with ESMTP id BA01A6B0283 for ; Wed, 20 Nov 2013 17:55:41 +0100 (CET) Received: by mail-lb0-f179.google.com with SMTP id l4so5150350lbv.10 for ; Wed, 20 Nov 2013 08:57:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u4UfcnCz0oJzbTly8NfB3jUSFrmqB8G0mArWtrPEEMM=; b=DAMz5yJpnQK+kgHpMy5lD+ELEeS7SXuvdrjltpp4/q58r/sjvQM+TLcc3cTlBiWJ3N dyJyV+taRXv47tuqIksENHhvQbS7lqhSJfkOAA5KcYJ4xilJ2mvyLcAXXXNpOJFAoZhx pO1nj5XddSdLNgehyGqVZOVMqBQHJ3fmlv5F1pFoWxsabsbv+Th91BN+2zZQr0g1O1oX 9oOAwi1EUUwWRigDN9+kymZaqwUqlk7DkQTQV0LlftXHciKXmmW58dFr8Lr6VtTkvIMl +dOGQUSmyM7h9dPcz4v2LCSXNlnr6oqbq7L+XhNl2BkDiOkHFTEDXo++RzklAu/Tbi96 JYbw== MIME-Version: 1.0 X-Received: by 10.152.30.99 with SMTP id r3mr1158464lah.25.1384966632284; Wed, 20 Nov 2013 08:57:12 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 20 Nov 2013 08:57:12 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 20 Nov 2013 08:57:12 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 17:57:12 +0100 Message-ID: From: Alberto Rodriguez-Natal To: Terry Manderson Content-Type: multipart/alternative; boundary=089e0160a7c824a8d404eb9eacd4 Cc: "lisp@ietf.org list" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 16:57:22 -0000 --089e0160a7c824a8d404eb9eacd4 Content-Type: text/plain; charset=ISO-8859-1 I support the acceptance of this document as a WG item On 19 Nov 2013 15:26, "Terry Manderson" wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --089e0160a7c824a8d404eb9eacd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I support the acceptance of this document as a WG item

On 19 Nov 2013 15:26, "Terry Manderson"= ; <terry.manderson@icann.or= g> wrote:
In Vancouver the chairs received a request for the following document to be=
adopted as a WG item.

http://tools.ietf.org/html/draft-iannone-lisp-eid-block= -mgmnt-03

Here starts a 14 day call for adoption, this call will end on
Wednesday the 4th December, 2013.

Please email the WG list stating that you either accept, or not accept, the=
item.

If you email to support the acceptance of this document as a WG item,
please
also indicate if you are able and willing to either contribute to, or
review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.=

Cheers
Terry


_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--089e0160a7c824a8d404eb9eacd4-- From mgibbs@verisign.com Wed Nov 20 09:13:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD97C1AE0FA for ; Wed, 20 Nov 2013 09:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x37swfVLqcTj for ; Wed, 20 Nov 2013 09:13:40 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 20B131AE091 for ; Wed, 20 Nov 2013 09:13:19 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUoztqE+DLXzJWOGkuBqSNtTeNGJHBxMw@postini.com; Wed, 20 Nov 2013 09:13:33 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAKHDBYX006293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 12:13:12 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 20 Nov 2013 12:13:11 -0500 From: "Gibbs, Michael" To: Terry Manderson Thread-Topic: [lisp] draft-iannone-eid-block-mgmnt-03 Thread-Index: AQHO5hPIQ8UPMcLep0y8HKb9ySindQ== Date: Wed, 20 Nov 2013 17:13:08 +0000 Message-ID: <844EC2C3-DA30-44FB-906B-5141EF8BB0CF@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:13:41 -0000 I support the acceptance of this document as a WG item Mike Gibbs Sent from my iPhone > On Nov 19, 2013, at 3:25 PM, "Terry Manderson" wrote: >=20 > In Vancouver the chairs received a request for the following document to = be > adopted as a WG item. >=20 > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. >=20 > Please email the WG list stating that you either accept, or not accept, t= he > item. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriatel= y. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From farinacci@gmail.com Wed Nov 20 10:17:17 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22041AE4F7 for ; Wed, 20 Nov 2013 10:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvmoxFVW2uhk for ; Wed, 20 Nov 2013 10:17:15 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5061AE0D8 for ; Wed, 20 Nov 2013 10:17:15 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kx10so3864559pab.8 for ; Wed, 20 Nov 2013 10:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5AwiYl3ED10FGsCLajlk3dbQiI3mBBXikc+AAD1vbbY=; b=MqXobbkMu7IK2X/0tnU4Qy+vHfOeMNtVXxXYOZ9+Tc07zMkh8DMTDl80wzBZFODGpJ 4HBoI6OP13/05v8pyMWr5/aXVp0Jk4QgzskEFN6N78o0qU73R8CaIKp3PxqOODKEgLya SLtwk1OBYsGrP1pJlSjqXz0GHTQYPLy8SJ1ZpQwUalFzZB7rYc2D9GV/se9Si6o06Mcv t+3nPFUd3zkFQuYSCIlmSGRxVSboomHF+x3oQnKhy63dMW8Hym5odgJ1XqBCLZWT2DG9 XUwgWcAnYX5PYGmLoUkDnveO1noIJQzct8Ih5XnkMn0Z27qxQvASazHj9TBdeoUV3hNc vVuQ== X-Received: by 10.66.161.1 with SMTP id xo1mr2037954pab.146.1384971429157; Wed, 20 Nov 2013 10:17:09 -0800 (PST) Received: from [192.168.1.101] ([207.145.253.66]) by mx.google.com with ESMTPSA id tu6sm39476187pbc.41.2013.11.20.10.17.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 10:17:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: Date: Wed, 20 Nov 2013 10:17:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7246C17C-43FA-4F81-A0C7-11D4B5FE2637@gmail.com> References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> To: Damien Saucez X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:17:18 -0000 > Dino, >=20 > Sorry for the delay, I see this proposition just now. >=20 > Do you propose this capability in the context of VPN and/or NSC? I didn't have anything specific in mind. I just wanted an ITR/ETR pair = to know if they could do a feature and what to do if one supported the = feature and the other one did not. > I would have a question, if there is capability, it means that there > is a possibility to meet no capability so in this case what is > replied? An record with 0 locators? no answer? a special answer Always reply, but state what you support so the capabilities bits can be = compared at the ITR to see what is in common. > saying "bad luck no match for the capability"? If 0 locators then it There is always a baseline for what you support. That is what is in RFC = 6830. So if an ITR wanted Geo-Coordinates returned in a RLOC-record, and = the ETR did not support that, it would return an RLOC-record with a = single-tuple (with just an AFI-encoded RLOC address) versus the = two-tuple (with the AFI-encoded RLOC address and the LCAF-encoded = Geo-Coordinates). And then the ITR would just encapsulate to the RLOC as = it does today. > is a negative reply but conceptually this is not a negative reply. If > no answer, then the requester will keep continuing sending requests. > If a new message, what kind of message? There is no need for a new message. That would complicate matters and = create more combinations to deal with when receiving responses. Dino >=20 > Thanks, >=20 > Damien Saucez >=20 > On 12 Sep 2013, at 20:29, Dino Farinacci wrote: >=20 >> So wouldn't be useful if an ITR which sends a Map-Request to the = mapping system, could say "I know Mr. ETR that you have registered a = bunch of stuff to the mapping system, but can you return just the stuff = I care about and more importantly the stuff I support in my = implementation?". >>=20 >> So I was thinking (and talking to several others about this), if we = could have a Capabilities Type LCAF that is encoded in an address field = of the Map-Request. I would like to propose that it get encoded in the = ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs = list could tell a Map-Replier what they support. >>=20 >> I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >>=20 >> It would be required of every implementation to support the = Capabilities Type LCAF if nothing else would be supported. That would = get the implementations to do the general parsing work so they could = skip over LCAFs they don't understand and get to the ones they do = understand while conveying what they support. >>=20 >> Also I find that this may be useful for this world of multiple = encapsulations. Rather than register UDP port numbers, a decapsulator = could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, = VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). >>=20 >> The Capabilities Type LCAF could also be used by the mapping system. = So when an ETR sends an Info-Request, an Info-Reply from the map-server = could tell the registering system what LCAFs it supported. Ditto, for = asking map-resolvers what types of EID encodings they could support = (maybe the mapping system can support more LCAF encodings then the = map-resolvers, so you can choose a different map-resolver if you wanted = more). >>=20 >> And arguably, the Capabilities Type LCAF could be put in RLOC-probes. = It could go anywhere with the address you wanted to encode as a 2-tuple. >>=20 >> Comments? >>=20 >> If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. And also comment if you think we should = go with the JSON Data Model Type for -03 or put it into -04 with perhaps = this Capabilities LCAF. >>=20 >> Thanks, >> Dino >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From jmh@joelhalpern.com Wed Nov 20 10:27:23 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7E1AE504 for ; Wed, 20 Nov 2013 10:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwaqjjl431PA for ; Wed, 20 Nov 2013 10:27:21 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0B1AE0A1 for ; Wed, 20 Nov 2013 10:27:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0F9FB1E4A89; Wed, 20 Nov 2013 10:27:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 40C4E1E48C7; Wed, 20 Nov 2013 10:27:12 -0800 (PST) Message-ID: <528CFEFD.2080103@joelhalpern.com> Date: Wed, 20 Nov 2013 13:27:09 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Dino Farinacci , Damien Saucez References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> <7246C17C-43FA-4F81-A0C7-11D4B5FE2637@gmail.com> In-Reply-To: <7246C17C-43FA-4F81-A0C7-11D4B5FE2637@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:27:23 -0000 Speaking personally, I find the notion of treating the ITR capability as a LCAF included in the request message to be very undesirable. It clearly can work. But it looks like a fairly bad misuse of the tools. One which will cause us trouble down the road. Yours, Joel On 11/20/13 1:17 PM, Dino Farinacci wrote: >> Dino, >> >> Sorry for the delay, I see this proposition just now. >> >> Do you propose this capability in the context of VPN and/or NSC? > > I didn't have anything specific in mind. I just wanted an ITR/ETR pair to know if they could do a feature and what to do if one supported the feature and the other one did not. > >> I would have a question, if there is capability, it means that there >> is a possibility to meet no capability so in this case what is >> replied? An record with 0 locators? no answer? a special answer > > Always reply, but state what you support so the capabilities bits can be compared at the ITR to see what is in common. > >> saying "bad luck no match for the capability"? If 0 locators then it > > There is always a baseline for what you support. That is what is in RFC 6830. So if an ITR wanted Geo-Coordinates returned in a RLOC-record, and the ETR did not support that, it would return an RLOC-record with a single-tuple (with just an AFI-encoded RLOC address) versus the two-tuple (with the AFI-encoded RLOC address and the LCAF-encoded Geo-Coordinates). And then the ITR would just encapsulate to the RLOC as it does today. > >> is a negative reply but conceptually this is not a negative reply. If >> no answer, then the requester will keep continuing sending requests. >> If a new message, what kind of message? > > There is no need for a new message. That would complicate matters and create more combinations to deal with when receiving responses. > > Dino > >> >> Thanks, >> >> Damien Saucez >> >> On 12 Sep 2013, at 20:29, Dino Farinacci wrote: >> >>> So wouldn't be useful if an ITR which sends a Map-Request to the mapping system, could say "I know Mr. ETR that you have registered a bunch of stuff to the mapping system, but can you return just the stuff I care about and more importantly the stuff I support in my implementation?". >>> >>> So I was thinking (and talking to several others about this), if we could have a Capabilities Type LCAF that is encoded in an address field of the Map-Request. I would like to propose that it get encoded in the ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs list could tell a Map-Replier what they support. >>> >>> I would propose that the Capabilities Type LCAF be encoded as a bit-string. Where each bit position indicates the LCAF Type value. We would have 2 fields, an EID field and a RLOC field so it can be conveyed which Types are supported for EID encoded fields or RLOC encoded fields in any LISP control message. >>> >>> It would be required of every implementation to support the Capabilities Type LCAF if nothing else would be supported. That would get the implementations to do the general parsing work so they could skip over LCAFs they don't understand and get to the ones they do understand while conveying what they support. >>> >>> Also I find that this may be useful for this world of multiple encapsulations. Rather than register UDP port numbers, a decapsulator could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). >>> >>> The Capabilities Type LCAF could also be used by the mapping system. So when an ETR sends an Info-Request, an Info-Reply from the map-server could tell the registering system what LCAFs it supported. Ditto, for asking map-resolvers what types of EID encodings they could support (maybe the mapping system can support more LCAF encodings then the map-resolvers, so you can choose a different map-resolver if you wanted more). >>> >>> And arguably, the Capabilities Type LCAF could be put in RLOC-probes. It could go anywhere with the address you wanted to encode as a 2-tuple. >>> >>> Comments? >>> >>> If people are interested I can draft up the details for the -03 version. Or if you think we should post the -03 version just with the current changes, I can do that. And also comment if you think we should go with the JSON Data Model Type for -03 or put it into -04 with perhaps this Capabilities LCAF. >>> >>> Thanks, >>> Dino >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From farinacci@gmail.com Wed Nov 20 10:55:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60B61AE05C for ; Wed, 20 Nov 2013 10:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teXsJk0QuNzZ for ; Wed, 20 Nov 2013 10:55:01 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A89DF1AE04D for ; Wed, 20 Nov 2013 10:55:01 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fa1so1490716pad.10 for ; Wed, 20 Nov 2013 10:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4QsvObZ8aMe/WlAesDlk6S9q+XD2hcNorzTk+j5JzRI=; b=xml4xkQwBQ4VKi6MLZptlhSl2OgZvf2UCYZQzh8PtJRbkel6PHG3TyAYU8mmYx7ivy s7ElGeMtnFkJRXhp77/5JX4qMT8RpGAl1P+Y4+7dUkzoVn1dzZ2G7g1K0ciDY3p6h5Yf rmJznSUsE0w71vS25eYc+xwXAprzjO7+H6cO9WbNQGRhHbOSvGckNYWWz6jrVMSBfWDk qLxHuMLTQ+jBi71RBYbd8cnnUo+yaHuHEfuEqQGIIezp36U4DQYA9ze2ztGoyt2JO95b FcxaYxOEpVw7/5u7irF0xJmJm0oj+epEplR4p2Fbs+AH2KOcQCn34+c4pVKfOT1UORGq g8rg== X-Received: by 10.68.139.233 with SMTP id rb9mr2198815pbb.29.1384973695398; Wed, 20 Nov 2013 10:54:55 -0800 (PST) Received: from [192.168.1.5] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id g6sm36608100pat.2.2013.11.20.10.54.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 10:54:54 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <528CFEFD.2080103@joelhalpern.com> Date: Wed, 20 Nov 2013 10:54:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FB6E5C2-AF6A-415A-8DE4-5958961A6661@gmail.com> <7246C17C-43FA-4F81-A0C7-11D4B5FE2637@gmail.com> <528CFEFD.2080103@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:55:03 -0000 > Speaking personally, I find the notion of treating the ITR capability = as a LCAF included in the request message to be very undesirable. It = clearly can work. But it looks like a fairly bad misuse of the tools. = One which will cause us trouble down the road. Perhaps you are right. That and the previous lack of interest, is why I = let the effort go and didn't persue it further. Dino >=20 > Yours, > Joel >=20 > On 11/20/13 1:17 PM, Dino Farinacci wrote: >>> Dino, >>>=20 >>> Sorry for the delay, I see this proposition just now. >>>=20 >>> Do you propose this capability in the context of VPN and/or NSC? >>=20 >> I didn't have anything specific in mind. I just wanted an ITR/ETR = pair to know if they could do a feature and what to do if one supported = the feature and the other one did not. >>=20 >>> I would have a question, if there is capability, it means that there >>> is a possibility to meet no capability so in this case what is >>> replied? An record with 0 locators? no answer? a special answer >>=20 >> Always reply, but state what you support so the capabilities bits can = be compared at the ITR to see what is in common. >>=20 >>> saying "bad luck no match for the capability"? If 0 locators then = it >>=20 >> There is always a baseline for what you support. That is what is in = RFC 6830. So if an ITR wanted Geo-Coordinates returned in a RLOC-record, = and the ETR did not support that, it would return an RLOC-record with a = single-tuple (with just an AFI-encoded RLOC address) versus the = two-tuple (with the AFI-encoded RLOC address and the LCAF-encoded = Geo-Coordinates). And then the ITR would just encapsulate to the RLOC as = it does today. >>=20 >>> is a negative reply but conceptually this is not a negative reply. = If >>> no answer, then the requester will keep continuing sending requests. >>> If a new message, what kind of message? >>=20 >> There is no need for a new message. That would complicate matters and = create more combinations to deal with when receiving responses. >>=20 >> Dino >>=20 >>>=20 >>> Thanks, >>>=20 >>> Damien Saucez >>>=20 >>> On 12 Sep 2013, at 20:29, Dino Farinacci = wrote: >>>=20 >>>> So wouldn't be useful if an ITR which sends a Map-Request to the = mapping system, could say "I know Mr. ETR that you have registered a = bunch of stuff to the mapping system, but can you return just the stuff = I care about and more importantly the stuff I support in my = implementation?". >>>>=20 >>>> So I was thinking (and talking to several others about this), if we = could have a Capabilities Type LCAF that is encoded in an address field = of the Map-Request. I would like to propose that it get encoded in the = ITR-RLOCs field of a Map-Request. This way, each ITR in the ITR-RLOCs = list could tell a Map-Replier what they support. >>>>=20 >>>> I would propose that the Capabilities Type LCAF be encoded as a = bit-string. Where each bit position indicates the LCAF Type value. We = would have 2 fields, an EID field and a RLOC field so it can be conveyed = which Types are supported for EID encoded fields or RLOC encoded fields = in any LISP control message. >>>>=20 >>>> It would be required of every implementation to support the = Capabilities Type LCAF if nothing else would be supported. That would = get the implementations to do the general parsing work so they could = skip over LCAFs they don't understand and get to the ones they do = understand while conveying what they support. >>>>=20 >>>> Also I find that this may be useful for this world of multiple = encapsulations. Rather than register UDP port numbers, a decapsulator = could convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, = VXLAN, NVGRE, IPsec, GRE, whatever-new-thing-nv03-comes-up-with). >>>>=20 >>>> The Capabilities Type LCAF could also be used by the mapping = system. So when an ETR sends an Info-Request, an Info-Reply from the = map-server could tell the registering system what LCAFs it supported. = Ditto, for asking map-resolvers what types of EID encodings they could = support (maybe the mapping system can support more LCAF encodings then = the map-resolvers, so you can choose a different map-resolver if you = wanted more). >>>>=20 >>>> And arguably, the Capabilities Type LCAF could be put in = RLOC-probes. It could go anywhere with the address you wanted to encode = as a 2-tuple. >>>>=20 >>>> Comments? >>>>=20 >>>> If people are interested I can draft up the details for the -03 = version. Or if you think we should post the -03 version just with the = current changes, I can do that. And also comment if you think we should = go with the JSON Data Model Type for -03 or put it into -04 with perhaps = this Capabilities LCAF. >>>>=20 >>>> Thanks, >>>> Dino >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From rogerj@gmail.com Wed Nov 20 11:00:17 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702021AE0A1 for ; Wed, 20 Nov 2013 11:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz56zlQwWnmQ for ; Wed, 20 Nov 2013 11:00:15 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F39EE1AE014 for ; Wed, 20 Nov 2013 11:00:14 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so2729848wib.8 for ; Wed, 20 Nov 2013 11:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dNxFK7YZfNoTOYYoqmb2IPcYPqJsyuKILbVxeD/WPLg=; b=Z9WZ10Sz3r8MqyQPeKdSiQpR8XY9X5T7cN2nxmCeMERN59mMvoI5jRldhLHJHMkUWF LFBvZVp8PuHaX6AnnXtKbS1YdMPBt4tagNvIpo4IwKTRw3cmncJqBKQdfCeY0x7Fb1oT LaxH2KUGTmG5Gdoe1G5B+/tco72Ln9P1IrD7/OEEDdgQZzTDAULv04XL0xLFno5fXlN1 mK6MBLq0jrY75CKY6hHpUN+G6vkkCd2nDFlMx8VNTI2zgE59rLeENqmiauzNzisHyVtM DYJzhm5EPQIedUEQVE72q0749e6Plk+/BUFFhfZwUMpOjkB49IPhIp2FncIOzIsgcSYI +lRg== MIME-Version: 1.0 X-Received: by 10.180.185.130 with SMTP id fc2mr26532846wic.43.1384974008149; Wed, 20 Nov 2013 11:00:08 -0800 (PST) Received: by 10.217.89.4 with HTTP; Wed, 20 Nov 2013 11:00:08 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 20:00:08 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Cc: "lisp@ietf.org" Subject: Re: [lisp] draft-iannone-eid-block-mgmnt-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:00:17 -0000 On Wed, Nov 20, 2013 at 12:25 AM, Terry Manderson wrote: > In Vancouver the chairs received a request for the following document to be > adopted as a WG item. > > http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 4th December, 2013. > > Please email the WG list stating that you either accept, or not accept, the > item. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. Maybe needless to say, accept it as wg item :-) Roger - co-author -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From jnc@mercury.lcs.mit.edu Wed Nov 20 11:12:02 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2203F1AE512 for ; Wed, 20 Nov 2013 11:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkYdT21y8vD for ; Wed, 20 Nov 2013 11:12:01 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 04A9B1AE50F for ; Wed, 20 Nov 2013 11:12:00 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7C19918C0E7; Wed, 20 Nov 2013 13:42:33 -0500 (EST) To: lisp@ietf.org Message-Id: <20131120184233.7C19918C0E7@mercury.lcs.mit.edu> Date: Wed, 20 Nov 2013 13:42:33 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:12:02 -0000 > From: Dino Farinacci > There is no need for a new message. That would complicate matters and > create more combinations to deal with when receiving responses. Huh? Less complication than a(nother) wart on Map-Request/Map-Replies? I fail to see why a new (clean) packet-type would be any extra complexity. (My take is that it's only illusory that re-using Map-Request/Map-Replies would be less complexity.) Sure, if the was the _only_ thing we were going to add, maybe we could tack it onto the side of Map-Request/Map-Replies - but when you take into account that we have a bunch of other things we'd like to do... Noel From farinacci@gmail.com Wed Nov 20 11:16:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5133D1AE110 for ; Wed, 20 Nov 2013 11:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xvnJGIfO1lJ for ; Wed, 20 Nov 2013 11:16:57 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFC1AE109 for ; Wed, 20 Nov 2013 11:16:57 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so3950941pbb.37 for ; Wed, 20 Nov 2013 11:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f3ZGjyuabeXXgk4PVJggZ80g8HHLfXYm7tkWhT2vS9E=; b=X+XSi2ctehqpe3Ie6j/a18hJJgQllk/K5yGZwFcC3WOE/E6xevTlYIyxttx3loNjI/ xc055RkrLQBIj/l8ZzIr8V1PHLYSj6F7LxMj89dpa80MVUPlfbrENPiZ9pp4IJn8rFKc AzMjLOBpYc1ksJDodl987X4q9dKLTWjuZBI1tJTmHUO6l8lD7tVf7Xbx68x7e5zvcZJv 7jfeHJulhE8Pzyd4HOhYIrJYBqgFLK8bTyU2AXd1Z+bn4IjmPDbTAKqkclQBWVnxUTfT hVRW7+Zk1LAQSdsOMjLz4n7R50Tn7mwYz0qcTu0F9SUbCpkvmatQD1i0rhqDh22LdWsH EIzg== X-Received: by 10.66.102.66 with SMTP id fm2mr2339422pab.94.1384975011086; Wed, 20 Nov 2013 11:16:51 -0800 (PST) Received: from [192.168.1.5] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id fk4sm44988655pab.23.2013.11.20.11.16.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 11:16:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Dino Farinacci In-Reply-To: <20131120184233.7C19918C0E7@mercury.lcs.mit.edu> Date: Wed, 20 Nov 2013 11:16:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3D78C8F1-2A2A-4574-B8B2-0EEF3E4DF6F7@gmail.com> References: <20131120184233.7C19918C0E7@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:16:59 -0000 >> From: Dino Farinacci >=20 >> There is no need for a new message. That would complicate matters and >> create more combinations to deal with when receiving responses. >=20 > Huh? Less complication than a(nother) wart on Map-Request/Map-Replies? = I fail There is no wart because consensus appears that we should not do = Capability negotiation. > to see why a new (clean) packet-type would be any extra complexity. = (My take > is that it's only illusory that re-using Map-Request/Map-Replies would = be > less complexity.) >=20 > Sure, if the was the _only_ thing we were going to add, maybe we could = tack > it onto the side of Map-Request/Map-Replies - but when you take into = account > that we have a bunch of other things we'd like to do... That is entirely different. So what are you thinking we need to add that = requires another message type? Dino >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rogerj@gmail.com Wed Nov 20 11:20:03 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D901AE0A1 for ; Wed, 20 Nov 2013 11:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5md2AFQizR1z for ; Wed, 20 Nov 2013 11:20:02 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1F76A1ADF8E for ; Wed, 20 Nov 2013 11:20:01 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id n12so9618853wgh.10 for ; Wed, 20 Nov 2013 11:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y67B6JH5TJHv5Y+deHJVUrOd56rev18hpFvfF0tu0sM=; b=WOSXJh/UFM5HJQLqHlrbTjkmSOLmA21oEbI8mRKK/+6XJyLjY86Hx56Fj4OZ/klDtI 3zPX1SRefZNV20j+wjKUrbwan05sFxhaWzF4gdvRa6LpkRyPEAQ2hkCOCGrqNqGselk8 X5PT8s17xZq56oKWxa4K1Df5EpYYyQ7yLDOKOwzTwMxyGf6QkYELubeh1P3gno4Fnv4O /utvLt6uajCT/Fc9TZcdiu3SyQ5LE/PcGWJPtS+6l+aV+W8VepIV59/5Wr2xJ+0ITFnG TEkFh2lFGGMl3byecEUDsohBhIw8QMqiyzqI1pb+fA8Bs+djfjb2J9e0NubVgpzb2RGN bALA== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mr2182056wjs.34.1384975195145; Wed, 20 Nov 2013 11:19:55 -0800 (PST) Received: by 10.217.89.4 with HTTP; Wed, 20 Nov 2013 11:19:55 -0800 (PST) In-Reply-To: <20131120124143.CD2B618C147@mercury.lcs.mit.edu> References: <20131120124143.CD2B618C147@mercury.lcs.mit.edu> Date: Wed, 20 Nov 2013 20:19:55 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Noel Chiappa , Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: "lisp@ietf.org" Subject: Re: [lisp] Capabilities Type LCAF - a proposal X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:20:03 -0000 On Wed, Nov 20, 2013 at 1:41 PM, Noel Chiappa wrote: > > From: Damien Saucez > > > I would have a question, if there is capability, it means that there is > > a possibility to meet no capability so in this case what is replied? > > ... > > If 0 locators then it is a negative reply but conceptually this is not > > a negative reply. If no answer, then the requester will keep continuing > > sending requests. > > Good points. > > In general, I don't think we should keep tweaking Map-Request and Map-Reply > messages 'because they are there'. If we need to extend semantics, let's do > it right. Keep tweaking existing things to support all sort of new idea only lead to complexity, and more problem somewhere down the road. But I do see the need for that Dino describe. > > If a new message, what kind of message? > > The has been some discussion about adding a new message-type to fill a > variety of roles which involve transferring information around (e.g. > dynamically loading configuration information such as default PxTRs into > small xTRs, a la DHCP, instead of having to manuall configure them). > > This would seem to naturally fall into that general classification? I would support doing this as a new message in the form of a framework to support existing idea, new idea and future needs. Sort of a version 2 extension. You don't need it, but if you support it an use it you get access to a whole range of cool and fancy extension of LISP :-) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From ggx@gigix.net Tue Nov 26 02:14:40 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D563A1ADF0F for ; Tue, 26 Nov 2013 02:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjNmrJymm068 for ; Tue, 26 Nov 2013 02:14:39 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id 435C41AD698 for ; Tue, 26 Nov 2013 02:14:39 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so2410961bkh.23 for ; Tue, 26 Nov 2013 02:14:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=imVlM8nbNn1F3CUbMOZZKs6kN06+41CB1jJ8XZ/dwpc=; b=Yh/Psg8dOr1HxSPUO9HOkItaD3gRn4MwyDmzZzfN6zpY1Ql9TR24Rwa4s8tDkImLEj d79X4/EBZSQG0mKM6+fVLCyCbVvCXtlHA/FggQQBC/EJk7AidduLC5DuYzJPWv9J/lOT r1PiGalacQze9S7rvr4WhDMlY5gdRDH66K6hL65cBga5gFM3XRuDQQd7qmY/dCtWwKAA M46khCHxE7z383Se1Bw7vQP1Yg0ayCPATTD0a7Fc9chroEuFU5tZiVKrbN8SZfPIFasX w9rTvwsTrp17yN03gHgaLddmnlK0jks5r6mb/HK5h1uGJziqutin73NUieVD2dyVmsFd 7mSA== X-Gm-Message-State: ALoCoQlpebHjh5qbBzjUvQr+0/JslI1NNp+Pnl5SDZSY+ksSWlhg7WCO6HsF+TnfY4dZDlJNw09f X-Received: by 10.204.123.3 with SMTP id n3mr729426bkr.73.1385460878268; Tue, 26 Nov 2013 02:14:38 -0800 (PST) Received: from [192.168.0.43] (bny92-2-81-56-19-67.fbx.proxad.net. [81.56.19.67]) by mx.google.com with ESMTPSA id a4sm50429155bko.11.2013.11.26.02.14.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 02:14:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Luigi Iannone In-Reply-To: Date: Tue, 26 Nov 2013 11:14:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2800ABF2-B079-4A91-BD11-AF137A321291@gigix.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1822) Cc: LISP mailing list list Subject: Re: [lisp] Confirming consensus on draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:14:41 -0000 Hi, actually the 26th is a tuesday.. so may be I am still on time. I vote to NOT split the document, keep it as it is. Luigi On 20 Nov. 2013, at 00:25 , Terry Manderson = wrote: > All, >=20 > During the meeting in Vancouver the in-room consensus was to NOT split = the > document into two. >=20 > This email is to confirm same on the WG mailing list. >=20 > If you do not agree with the consensus from the IETF88 LISP WG meeting = AND > have a substantive argument as to why - please speak up. >=20 > You have until midnight Monday 26th November (UTC), after that I = intend to > issue a last call as per WG in-room discussion. >=20 > Cheers > Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Tue Nov 26 18:42:47 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C091AE0BE for ; Tue, 26 Nov 2013 18:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfbEphUGPBg1 for ; Tue, 26 Nov 2013 18:42:46 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 334841AE0A0 for ; Tue, 26 Nov 2013 18:42:46 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 26 Nov 2013 18:42:45 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 26 Nov 2013 18:42:44 -0800 Thread-Topic: WGLC for draft-ietf-lisp-introduction Thread-Index: Ac7rGlpMxBf+A9kwRiKgo7XZJnxTQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3468400965_36870392" MIME-Version: 1.0 Subject: [lisp] WGLC for draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 02:42:47 -0000 --B_3468400965_36870392 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, Following my question regarding the state of draft-ietf-lisp-introduction, and as requested in Vancouver, the authors of draft-ietf-lisp-introduction have requested a work group last call. Here starts a 14 day last call for this document, the last call will end on Wednesday 11th December 2013. You will find its text here: http://tools.ietf.org/html/draft-ietf-lisp-introduction Please review this WG item and provide any last comments. Cheers Terry --B_3468400965_36870392 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFPOXQ74aQmzgkqRXNlDbMZFF2Rs3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTEyNzAyNDI0NVowDQYJKoZIhvcNAQEBBQAEggEAH1XDDcoX lhphRNIzRV2qY9J4v2p52/Xa8RrQbbtSIwSw5q3uBfJV2ZVJtBgBXmsDTVa3+ccu/g4IRBv6 XbQwPUkJD6TvSQ/NaEyykBpkH5DWJnSWsOww9oSmxjn1ramxddn8IXwQWtwAUSiMsrBR96cZ Wc/BUckQAuQtz3QAtTMrhT62RzXyL891KkmHK+ZAwwSN84UvLuzNh51GTClZcRqS9eqaBu0P APdc4AF9zNn7+YSG8KJcgeCYWed0SleLgdZv1zyTm6zGguYxRv/clWTuyjXkOgU2F4cGaqPr pDQsHUC5NilGLxuQagvUxrh4HAOWqbR/UTyiU6BfCE+Ohg== --B_3468400965_36870392-- From internet-drafts@ietf.org Wed Nov 27 05:21:16 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A7A1ACCD9; Wed, 27 Nov 2013 05:21:16 -0800 (PST) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm5ObgXMbvi6; Wed, 27 Nov 2013 05:21:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E71591A1F54; Wed, 27 Nov 2013 05:21:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131127132114.17385.48301.idtracker@ietfa.amsl.com> Date: Wed, 27 Nov 2013 05:21:14 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:21:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP EID Block Author(s) : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-07.txt Pages : 15 Date : 2013-11-27 Abstract: This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rcallon@juniper.net Wed Nov 27 08:55:36 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D911AD945 for ; Wed, 27 Nov 2013 08:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofsHT0KOb4GJ for ; Wed, 27 Nov 2013 08:55:34 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1321AD8F1 for ; Wed, 27 Nov 2013 08:55:33 -0800 (PST) Received: from mail48-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 16:55:32 +0000 Received: from mail48-va3 (localhost [127.0.0.1]) by mail48-va3-R.bigfish.com (Postfix) with ESMTP id 8EC8B2A013C; Wed, 27 Nov 2013 16:54:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h9a9j1155h) Received-SPF: pass (mail48-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(164054003)(199002)(13464003)(46102001)(31966008)(76482001)(15202345003)(76786001)(74366001)(74316001)(74876001)(74706001)(76796001)(51856001)(33646001)(56816003)(76576001)(85306002)(59766001)(54316002)(50986001)(56776001)(81342001)(66066001)(87266001)(47446002)(47976001)(2656002)(80022001)(15975445006)(65816001)(19580395003)(69226001)(81816001)(63696002)(87936001)(54356001)(77982001)(49866001)(74502001)(47736001)(4396001)(79102001)(53806001)(83072001)(19580405001)(81686001)(80976001)(83322001)(81542001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail48-va3 (localhost.localdomain [127.0.0.1]) by mail48-va3 (MessageSwitch) id 1385571286766172_7449; Wed, 27 Nov 2013 16:54:46 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.254]) by mail48-va3.bigfish.com (Postfix) with ESMTP id 96AC68011D; Wed, 27 Nov 2013 16:54:46 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 16:54:45 +0000 Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 27 Nov 2013 16:54:43 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 16:54:41 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 16:54:41 +0000 From: Ross Callon To: Terry Manderson , "lisp@ietf.org" Thread-Topic: WGLC for draft-ietf-lisp-introduction Thread-Index: Ac7rGlpMxBf+A9kwRiKgo7XZJnxTQAAdtrAg Date: Wed, 27 Nov 2013 16:54:41 +0000 Message-ID: <38f67ed06a844e4783f5404a1e9fee3e@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 004395A01C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [lisp] WGLC for draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 16:55:36 -0000 Just to be clear, this is on the -03 version, dated October 21, 2013. Corre= ct?=20 Thanks, Ross -----Original Message----- From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Terry Manderson Sent: Tuesday, November 26, 2013 9:43 PM To: lisp@ietf.org Subject: [lisp] WGLC for draft-ietf-lisp-introduction All, Following my question regarding the state of draft-ietf-lisp-introduction, and as requested in Vancouver, the authors of draft-ietf-lisp-introduction have requested a work group last call. Here starts a 14 day last call for this document, the last call will end on Wednesday 11th December 2013. You will find its text here: http://tools.ietf.org/html/draft-ietf-lisp-introduction Please review this WG item and provide any last comments. Cheers Terry From terry.manderson@icann.org Wed Nov 27 19:45:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5901AE0DA for ; Wed, 27 Nov 2013 19:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHOS1_9S5j7J for ; Wed, 27 Nov 2013 19:45:53 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED71AE1AC for ; Wed, 27 Nov 2013 19:45:53 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 27 Nov 2013 19:45:52 -0800 From: Terry Manderson To: Ross Callon , "lisp@ietf.org" Date: Wed, 27 Nov 2013 19:45:47 -0800 Thread-Topic: WGLC for draft-ietf-lisp-introduction Thread-Index: Ac7r7FXNGfYXBE0tSGiwv8XdP7rf5Q== Message-ID: References: <38f67ed06a844e4783f5404a1e9fee3e@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <38f67ed06a844e4783f5404a1e9fee3e@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3468491147_37590318" MIME-Version: 1.0 Subject: Re: [lisp] WGLC for draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 03:45:55 -0000 --B_3468491147_37590318 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Ross, Correct. T. On 28/11/13 2:54 AM, "Ross Callon" wrote: >Just to be clear, this is on the -03 version, dated October 21, 2013. >Correct? > >Thanks, Ross > >-----Original Message----- >From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Terry Manderson >Sent: Tuesday, November 26, 2013 9:43 PM >To: lisp@ietf.org >Subject: [lisp] WGLC for draft-ietf-lisp-introduction > >All, > >Following my question regarding the state of draft-ietf-lisp-introduction, >and as requested in Vancouver, the authors of draft-ietf-lisp-introduction >have requested a work group last call. > >Here starts a 14 day last call for this document, the last call will end >on >Wednesday 11th December 2013. > >You will find its text here: >http://tools.ietf.org/html/draft-ietf-lisp-introduction > >Please review this WG item and provide any last comments. > >Cheers >Terry > --B_3468491147_37590318 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFBfi7adAn2khQY1gx3OGK5NDxfL2MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTEyODAzNDU0N1owDQYJKoZIhvcNAQEBBQAEggEAIMvR/GkB h/AUrj74/ZS3wqCFg0Ww9I5G6QWSDZqU3TdzfZI3xIgTFkzxcPc7i+GrHIRv6YsiI47eLabT xGBkBzM599J8RqOFrkLFX+7jDNa9jTp6mMxsqDh+EZ27UZVo5m8s/QxCSWv7dsHXmjH2KXp2 c77B2Yw0KIdJJrmg0690jxIqcDCFq55ZK9TZhycztXHAkiIay+P2+KruiWdYKKBscx1JM8KP AJS9znD00z8XMmZYS9JWj8ZorEjkIQmvE425wnvjziUa29y2z3ZMFqtsX7TF1NxL5Txk3T0e RprXLjYHaVUGKgYg9BQ3Y6qoKeByOFxnyZy6IYzM1Wi+Qg== --B_3468491147_37590318-- From terry.manderson@icann.org Thu Nov 28 17:29:48 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440E41AE069 for ; Thu, 28 Nov 2013 17:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvNi9oM0FAHx for ; Thu, 28 Nov 2013 17:29:46 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id D226C1AE05C for ; Thu, 28 Nov 2013 17:29:46 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 28 Nov 2013 17:29:45 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 28 Nov 2013 17:29:42 -0800 Thread-Topic: [lisp] WGLC for draft-ietf-lisp-introduction Thread-Index: Ac7sonxhhHK4ZjiwR7C96lu2A5jNNA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3468569382_38910458" MIME-Version: 1.0 Subject: Re: [lisp] WGLC for draft-ietf-lisp-introduction X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 01:29:48 -0000 --B_3468569382_38910458 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, My apologies. I pulled the trigger on the WGLC one revision early, and was duly scolded by co-chairs and authors alike. ;) A -04 is needed to be uploaded. This will happen soon. As soon as I see that rev, I will restart the WGLC on this document. Cheers Terry On 27/11/13 12:42 PM, "Terry Manderson" wrote: >All, > >Following my question regarding the state of draft-ietf-lisp-introduction, >and as requested in Vancouver, the authors of draft-ietf-lisp-introduction >have requested a work group last call. > >Here starts a 14 day last call for this document, the last call will end >on >Wednesday 11th December 2013. > >You will find its text here: >http://tools.ietf.org/html/draft-ietf-lisp-introduction > >Please review this WG item and provide any last comments. > >Cheers >Terry --B_3468569382_38910458 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFOhJgnsqaKR52XWBQmschW/qT1EbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTEyOTAxMjk0MlowDQYJKoZIhvcNAQEBBQAEggEAWz5CONrT gptSpkJ48MjtDbisTxvqzIkL8hsVz0cp21MCSh3mIf/75FhAc8mWPrNmwRMse2+XYGdFwzgz pP1RPx3GJzEtgGyKMXf54aXbczuVJMuudIB87kJvbPIV7qrQWRoZ5Bei4QoKJV/3um8g5lI5 GFc8su2E+x3igtBEwkS91Qb9B+XHoA5XIbWH8R7Ht62OUfMZXEonqV1MWsgndZc8rVYF+bsC ucNAJdI5kdRu9T20b7viFHOR/4VP7KqKytBVi1/x6P8S9SkrFOlJXGWuJ2LgvRDk1ji13nTU JQWChxAqM3FYDljrDC7cOkZCJqK4NCN2yshFHwlFEQ+c2A== --B_3468569382_38910458-- From terry.manderson@icann.org Thu Nov 28 17:39:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCBD1AE265 for ; Thu, 28 Nov 2013 17:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST1TM-bbI3l6 for ; Thu, 28 Nov 2013 17:39:40 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 729111AE075 for ; Thu, 28 Nov 2013 17:39:40 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 28 Nov 2013 17:39:39 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 28 Nov 2013 17:39:32 -0800 Thread-Topic: WGLC draft-ietf-lisp-eid-block-07 Thread-Index: Ac7so934+2/7Y06YRiCmrwUo7elVeg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3468569972_38930162" MIME-Version: 1.0 Subject: [lisp] WGLC draft-ietf-lisp-eid-block-07 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 01:39:41 -0000 --B_3468569972_38930162 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, As requested in Vancouver, and after the authors updated the draft (to -07) based on the Vancouver in-room discussion. This starts a 14 day last call for this document, the last call will end on Friday the 13th December 2013. You will find its text here: http://www.ietf.org/id/draft-ietf-lisp-eid-block-07.txt Please review this WG item and provide any last comments. Cheers Terry --B_3468569972_38930162 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFKUWN/tWpBz5PLMHeDa14JXOU/3fMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMTEyOTAxMzkzMlowDQYJKoZIhvcNAQEBBQAEggEAjL8pZWcN 6PBOAUd/9NZM6RH45BbhScN1twDMb5NxgChXcstCnFDrhIedjAeqV4J9CU0sZ1TyM4dy+/aV S+0WuFaQeHK4oAF4FIYzeuSA1KWiHPnn7P7f00kjo3iuxmqlW1YHMLwTunqWh/T1syGhEfip vRU4WNHziw9/YDFLEqORUDJ/ywbxBXtFOmf0T1pA8P2KmeOwHcFyY6mXYPjQPUz6FL6N52Bv tGE9VtT+nh0saGdfjjqMnojJgUtVAm++9mSpgZSggxbN0IkH8W7p5xYPQZhuJ6/hhieK6jJL etrOpo/fMPJqUdvYjl7ZJvEzbc43WDAd7u2jv05EGkIZ5A== --B_3468569972_38930162-- From ietf@bartschnet.de Sat Nov 30 03:10:13 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C551ADF30 for ; Sat, 30 Nov 2013 03:10:13 -0800 (PST) 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=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EixZD2C0X9dR for ; Sat, 30 Nov 2013 03:10:12 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id DAB881AD9AB for ; Sat, 30 Nov 2013 03:10:11 -0800 (PST) Received: from [80.67.16.121] (helo=www.premium-webmail.de) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VmiR6-00059M-SF for lisp@ietf.org; Sat, 30 Nov 2013 12:10:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 30 Nov 2013 12:10:08 +0100 From: Rene Bartsch To: lisp@ietf.org Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl Subject: [lisp] AVM Fritz!Box 7390 works with LISP Beta-Network X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 11:10:13 -0000 Hi, the Fritz!Box 7390 works with the LISP Beta-Network! :-) LISP support requires Fritz!OS 6 on the box (german version). Unfortunately Fritz!OS cannot route IPv4 networks via LISP, so only the box itself gets an IPv4 EID and uses masquerading for hosts in the LAN. I've already proposed IPv4 routing support to AVM. Have Phun with LISP, Renne -- Best regards, Rene Bartsch, B. Sc. Informatics Current Bitcoin Exchange Rate: https://www.bitcoin.de/de/r/mwfngu