From jesper@cisco.com Mon Jan 3 07:27:47 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADBE3A6986 for ; Mon, 3 Jan 2011 07:27:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCfNWWVKmKkQ for ; Mon, 3 Jan 2011 07:27:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 14D6B3A6A03 for ; Mon, 3 Jan 2011 07:27:46 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI56IU1AZnwN/2dsb2JhbACkNHOiZZhbhUoEiwSDHYgV X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="198973396" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2011 15:29:53 +0000 Received: from [127.0.0.1] (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p03FTpd8009669; Mon, 3 Jan 2011 15:29:52 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jesper Skriver In-Reply-To: <20101230171008.F063B6BE5B6@mercury.lcs.mit.edu> Date: Mon, 3 Jan 2011 17:29:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17AAA160-5D0B-45CF-BEE1-81719A8547E1@cisco.com> References: <20101230171008.F063B6BE5B6@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1082) Cc: lisp@ietf.org Subject: Re: [lisp] ETR selection? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 15:27:47 -0000 On 30 Dec 2010, at 19:10, Noel Chiappa wrote: >=20 >> From: "Flinck, Hannu (NSN - FI/Espoo)" >=20 >> In section 4.3 Map-Server Processing it is mentioned that "...the >> Map-Server verifies that the destination EID matches an EID-prefix >> for which it has one or more registered ETRs, then re-encapsulates >> and forwards the now-Encapsulated Map-Request to a matching ETR." >=20 >> So, there is a set of ETR matching the EID-prefix out of which a one >> ETR is chosen. What would be the basis for selecting the target ETR >> out of the set of matching ETRs? >=20 > Off the top of my head, and as a personal opinion, I would assume it = would > be a random selection (although it need not be); remember, the only > packets that should be going through the path you are asking about are > Map-Requests, and all ETRs for a given EID block should return the = same > data in the Map-Reply, so it should not matter which ETR the = Map-Request > is sent to. >=20 > The only reason I can think of to prefer the algorithm of 'pick one at > pseudo-random' is that if an ETR fails, it may take a minute or two = for > the MS to notice that the ETR is down, and drop it; during that time > period, if the Map-Request is retransmitted, if it's sent to the same > (down) ETR that's not much good. A circulating sweep through all the = ETRs > for a given EID block would be just as good (and cheaper to = implement), so > maybe that's the way to go, actually. >=20 > I may have missed something, though - anyone else have a different = view? The LISP implementation in IOS round robin through the list of = registered RLOCs, ensuring that we do not forward to an RLOC of an = address family not included in the set of ITR-RLOCs in the map-request. = For example if the ITR only put IPv4 addresses(es) in the Map-Request, = the IOS Map-Server will not forward the Map-Request to an IPv6 RLOC of = the ETR(s), as if that ETR is IPv6 only, it has no way of replying back = to the ITR. Similarly we do not forward to RLOCs which have priority 255 or are = reported down. /Jesper >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp /Jesper From menth@informatik.uni-tuebingen.de Mon Jan 3 08:00:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCF73A6A33 for ; Mon, 3 Jan 2011 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ+17GonJyre for ; Mon, 3 Jan 2011 08:00:06 -0800 (PST) Received: from mx5.informatik.uni-tuebingen.de (mx5.informatik.uni-tuebingen.de [134.2.12.32]) by core3.amsl.com (Postfix) with SMTP id C8D063A6A25 for ; Mon, 3 Jan 2011 08:00:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9C5545299; Mon, 3 Jan 2011 17:02:08 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLSwPuMEDvk8; Mon, 3 Jan 2011 17:02:03 +0100 (MET) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6DEC4528C; Mon, 3 Jan 2011 17:02:03 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2E20DFDBD19; Mon, 3 Jan 2011 17:02:03 +0100 (CET) Message-ID: <4D21F2FE.5060106@informatik.uni-tuebingen.de> Date: Mon, 03 Jan 2011 17:02:06 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: lisp@ietf.org, jesper@cisco.com References: <20101230171008.F063B6BE5B6@mercury.lcs.mit.edu> <17AAA160-5D0B-45CF-BEE1-81719A8547E1@cisco.com> In-Reply-To: <17AAA160-5D0B-45CF-BEE1-81719A8547E1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] ETR selection? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 16:00:09 -0000 Hi Jesper, Am 03.01.2011 16:29, schrieb Jesper Skriver: > On 30 Dec 2010, at 19:10, Noel Chiappa wrote: > >>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>> In section 4.3 Map-Server Processing it is mentioned that "...the >>> Map-Server verifies that the destination EID matches an EID-prefix >>> for which it has one or more registered ETRs, then re-encapsulates >>> and forwards the now-Encapsulated Map-Request to a matching ETR." >>> So, there is a set of ETR matching the EID-prefix out of which a one >>> ETR is chosen. What would be the basis for selecting the target ETR >>> out of the set of matching ETRs? >> Off the top of my head, and as a personal opinion, I would assume it would >> be a random selection (although it need not be); remember, the only >> packets that should be going through the path you are asking about are >> Map-Requests, and all ETRs for a given EID block should return the same >> data in the Map-Reply, so it should not matter which ETR the Map-Request >> is sent to. >> >> The only reason I can think of to prefer the algorithm of 'pick one at >> pseudo-random' is that if an ETR fails, it may take a minute or two for >> the MS to notice that the ETR is down, and drop it; during that time >> period, if the Map-Request is retransmitted, if it's sent to the same >> (down) ETR that's not much good. A circulating sweep through all the ETRs >> for a given EID block would be just as good (and cheaper to implement), so >> maybe that's the way to go, actually. >> >> I may have missed something, though - anyone else have a different view? > The LISP implementation in IOS round robin through the list of registered RLOCs, Does the ITR choose ETRs in a round-robin fashion on a per-packet or on a per-flow basis? If packets of the same flow are tunneled towards different ETRs, reordering is possible. Can that happen or what's done to prevent that? Regards, Michael > ensuring that we do not forward to an RLOC of an address family not included in the set of ITR-RLOCs in the map-request. For example if the ITR only put IPv4 addresses(es) in the Map-Request, the IOS Map-Server will not forward the Map-Request to an IPv6 RLOC of the ETR(s), as if that ETR is IPv6 only, it has no way of replying back to the ITR. > > Similarly we do not forward to RLOCs which have priority 255 or are reported down. > > /Jesper > >> Noel >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > /Jesper > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Prof. Dr. habil. Michael Menth University of Tuebingen Wilhelm-Schickard-Institute Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de, http://www.net2.uni-tuebingen.de From jesper@cisco.com Mon Jan 3 08:12:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163D23A6A07 for ; Mon, 3 Jan 2011 08:12:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aLrke3Jctkz for ; Mon, 3 Jan 2011 08:12:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 98E103A6A16 for ; Mon, 3 Jan 2011 08:12:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB6EIU1AZnwN/2dsb2JhbACkNHOiY5hdAoVIBIsEgx0 X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="199230658" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2011 16:14:32 +0000 Received: from [127.0.0.1] (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p03GEVRl001686; Mon, 3 Jan 2011 16:14:31 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jesper Skriver In-Reply-To: <4D21F2FE.5060106@informatik.uni-tuebingen.de> Date: Mon, 3 Jan 2011 18:14:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101230171008.F063B6BE5B6@mercury.lcs.mit.edu> <17AAA160-5D0B-45CF-BEE1-81719A8547E1@cisco.com> <4D21F2FE.5060106@informatik.uni-tuebingen.de> To: Michael Menth X-Mailer: Apple Mail (2.1082) Cc: lisp@ietf.org Subject: Re: [lisp] ETR selection? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 16:12:32 -0000 Hi Michael, On 3 Jan 2011, at 18:02, Michael Menth wrote: > Hi Jesper, >=20 > Am 03.01.2011 16:29, schrieb Jesper Skriver: >> On 30 Dec 2010, at 19:10, Noel Chiappa wrote: >>=20 >>>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>>> In section 4.3 Map-Server Processing it is mentioned that "...the >>>> Map-Server verifies that the destination EID matches an EID-prefix >>>> for which it has one or more registered ETRs, then re-encapsulates >>>> and forwards the now-Encapsulated Map-Request to a matching ETR." >>>> So, there is a set of ETR matching the EID-prefix out of which a = one >>>> ETR is chosen. What would be the basis for selecting the target ETR >>>> out of the set of matching ETRs? >>> Off the top of my head, and as a personal opinion, I would assume it = would >>> be a random selection (although it need not be); remember, the only >>> packets that should be going through the path you are asking about = are >>> Map-Requests, and all ETRs for a given EID block should return the = same >>> data in the Map-Reply, so it should not matter which ETR the = Map-Request >>> is sent to. >>>=20 >>> The only reason I can think of to prefer the algorithm of 'pick one = at >>> pseudo-random' is that if an ETR fails, it may take a minute or two = for >>> the MS to notice that the ETR is down, and drop it; during that time >>> period, if the Map-Request is retransmitted, if it's sent to the = same >>> (down) ETR that's not much good. A circulating sweep through all the = ETRs >>> for a given EID block would be just as good (and cheaper to = implement), so >>> maybe that's the way to go, actually. >>>=20 >>> I may have missed something, though - anyone else have a different = view? >> The LISP implementation in IOS round robin through the list of = registered RLOCs, > Does the ITR choose ETRs in a round-robin fashion on a per-packet or = on a per-flow basis? If packets of the same flow are tunneled towards = different ETRs, reordering is possible. Can that happen or what's done = to prevent that? My reply was about how the Map-Server choose which ETR-RLOC to forward a = Map-Request to. An ITR will do load balancing for Map-Cache entries which has multiple = ETR-RLOCs of the best priority, this load balancing is by default = per-flow as otherwise you will likely see packet reordering, the user = can override this to be round robin if they choose, but its not = recommended. /Jesper >=20 > Regards, >=20 > Michael >=20 >=20 >> ensuring that we do not forward to an RLOC of an address family not = included in the set of ITR-RLOCs in the map-request. For example if the = ITR only put IPv4 addresses(es) in the Map-Request, the IOS Map-Server = will not forward the Map-Request to an IPv6 RLOC of the ETR(s), as if = that ETR is IPv6 only, it has no way of replying back to the ITR. >>=20 >> Similarly we do not forward to RLOCs which have priority 255 or are = reported down. >>=20 >> /Jesper >>=20 >>> Noel >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> /Jesper >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > --=20 > Prof. Dr. habil. Michael Menth > University of Tuebingen > Wilhelm-Schickard-Institute > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de, http://www.net2.uni-tuebingen.de /Jesper From menth@informatik.uni-tuebingen.de Mon Jan 3 08:15:31 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090B23A6A1C for ; Mon, 3 Jan 2011 08:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVYQ+3tPV4Ax for ; Mon, 3 Jan 2011 08:15:30 -0800 (PST) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by core3.amsl.com (Postfix) with SMTP id 9EFA63A6A09 for ; Mon, 3 Jan 2011 08:15:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 87DFA52D9; Mon, 3 Jan 2011 17:17:35 +0100 (MET) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlJRDeXYPb9M; Mon, 3 Jan 2011 17:17:33 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5299552D3; Mon, 3 Jan 2011 17:17:33 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-095-208-114-108.hsi5.kabel-badenwuerttemberg.de [95.208.114.108]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id C9AB1CB094C; Mon, 3 Jan 2011 17:17:32 +0100 (CET) Message-ID: <4D21F6A1.6000407@informatik.uni-tuebingen.de> Date: Mon, 03 Jan 2011 17:17:37 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jesper Skriver References: <20101230171008.F063B6BE5B6@mercury.lcs.mit.edu> <17AAA160-5D0B-45CF-BEE1-81719A8547E1@cisco.com> <4D21F2FE.5060106@informatik.uni-tuebingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] ETR selection? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 16:15:31 -0000 Hi Jesper, Am 03.01.2011 17:14, schrieb Jesper Skriver: > Hi Michael, > > On 3 Jan 2011, at 18:02, Michael Menth wrote: > >> Hi Jesper, >> >> Am 03.01.2011 16:29, schrieb Jesper Skriver: >>> On 30 Dec 2010, at 19:10, Noel Chiappa wrote: >>> >>>>> From: "Flinck, Hannu (NSN - FI/Espoo)" >>>>> In section 4.3 Map-Server Processing it is mentioned that "...the >>>>> Map-Server verifies that the destination EID matches an EID-prefix >>>>> for which it has one or more registered ETRs, then re-encapsulates >>>>> and forwards the now-Encapsulated Map-Request to a matching ETR." >>>>> So, there is a set of ETR matching the EID-prefix out of which a one >>>>> ETR is chosen. What would be the basis for selecting the target ETR >>>>> out of the set of matching ETRs? >>>> Off the top of my head, and as a personal opinion, I would assume it would >>>> be a random selection (although it need not be); remember, the only >>>> packets that should be going through the path you are asking about are >>>> Map-Requests, and all ETRs for a given EID block should return the same >>>> data in the Map-Reply, so it should not matter which ETR the Map-Request >>>> is sent to. >>>> >>>> The only reason I can think of to prefer the algorithm of 'pick one at >>>> pseudo-random' is that if an ETR fails, it may take a minute or two for >>>> the MS to notice that the ETR is down, and drop it; during that time >>>> period, if the Map-Request is retransmitted, if it's sent to the same >>>> (down) ETR that's not much good. A circulating sweep through all the ETRs >>>> for a given EID block would be just as good (and cheaper to implement), so >>>> maybe that's the way to go, actually. >>>> >>>> I may have missed something, though - anyone else have a different view? >>> The LISP implementation in IOS round robin through the list of registered RLOCs, >> Does the ITR choose ETRs in a round-robin fashion on a per-packet or on a per-flow basis? If packets of the same flow are tunneled towards different ETRs, reordering is possible. Can that happen or what's done to prevent that? > My reply was about how the Map-Server choose which ETR-RLOC to forward a Map-Request to. > > An ITR will do load balancing for Map-Cache entries which has multiple ETR-RLOCs of the best priority, this load balancing is by default per-flow as otherwise you will likely see packet reordering, the user can override this to be round robin if they choose, but its not recommended. Ok, that makes sense. Thanks for the fast reply. Michael > /Jesper > >> Regards, >> >> Michael >> >> >>> ensuring that we do not forward to an RLOC of an address family not included in the set of ITR-RLOCs in the map-request. For example if the ITR only put IPv4 addresses(es) in the Map-Request, the IOS Map-Server will not forward the Map-Request to an IPv6 RLOC of the ETR(s), as if that ETR is IPv6 only, it has no way of replying back to the ITR. >>> >>> Similarly we do not forward to RLOCs which have priority 255 or are reported down. >>> >>> /Jesper >>> >>>> Noel >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> /Jesper >>> >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> -- >> Prof. Dr. habil. Michael Menth >> University of Tuebingen >> Wilhelm-Schickard-Institute >> Chair of Communication Networks >> Sand 13, 72076 Tuebingen, Germany >> phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de, http://www.net2.uni-tuebingen.de > /Jesper > > > > -- Prof. Dr. habil. Michael Menth University of Tuebingen Wilhelm-Schickard-Institute Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de, http://www.net2.uni-tuebingen.de From sam@spacething.org Mon Jan 3 16:05:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A463A6E14 for ; Mon, 3 Jan 2011 16:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYK4HIaydgGg for ; Mon, 3 Jan 2011 16:05:20 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8FD9D3A6E0F for ; Mon, 3 Jan 2011 16:05:19 -0800 (PST) Received: by ewy8 with SMTP id 8so6326359ewy.31 for ; Mon, 03 Jan 2011 16:07:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.31.131 with SMTP id y3mr7125158ebc.54.1294099646658; Mon, 03 Jan 2011 16:07:26 -0800 (PST) Sender: sam@spacething.org Received: by 10.213.13.11 with HTTP; Mon, 3 Jan 2011 16:07:26 -0800 (PST) X-Originating-IP: [90.219.6.87] Date: Tue, 4 Jan 2011 00:07:26 +0000 X-Google-Sender-Auth: NkxJ5zX3dsxjBWbe9UNJmbJbc44 Message-ID: From: Sam Stickland To: lisp@ietf.org Content-Type: multipart/alternative; boundary=0015174c12c8be370b0498fa0dc7 Subject: [lisp] Setting up a LISP IPv4 environment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 00:05:21 -0000 --0015174c12c8be370b0498fa0dc7 Content-Type: text/plain; charset=ISO-8859-1 All, I'm interested in getting some practical experience with LISP, first in a lab then, but then in the real world. Is this possible yet? Are there public mapping servers and resolvers available? And how would I announce IPv4 EIDs? I could use an existing /24 as the EIDs, but I'm guessing there aren't any publically available PITRs, so I'd need to run one myself? (or just continue to announce the prefix into the BGP table in the existing manner?). Regards, Sam --0015174c12c8be370b0498fa0dc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
=A0
I'm interested in getting some practical experience with LISP, fir= st in a lab then, but then in the real world. Is this possible yet? Are the= re public mapping servers and resolvers available? And how would I=A0announ= ce IPv4 EIDs? I could use an existing /24 as the EIDs, but I'm guessing= there aren't any publically available PITRs, so I'd need to run on= e myself? (or just continue to announce the prefix into the BGP table in th= e existing manner?).
=A0
Regards,
=A0
Sam
--0015174c12c8be370b0498fa0dc7-- From sam@spacething.org Mon Jan 3 16:07:19 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE7A3A6E1C for ; Mon, 3 Jan 2011 16:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbTXFr+csWP7 for ; Mon, 3 Jan 2011 16:07:19 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id DF9F83A6E17 for ; Mon, 3 Jan 2011 16:07:18 -0800 (PST) Received: by eyd10 with SMTP id 10so5919818eyd.31 for ; Mon, 03 Jan 2011 16:09:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.19.84 with SMTP id z20mr17354491eba.80.1294099765311; Mon, 03 Jan 2011 16:09:25 -0800 (PST) Received: by 10.213.13.11 with HTTP; Mon, 3 Jan 2011 16:09:25 -0800 (PST) X-Originating-IP: [90.219.6.87] In-Reply-To: References: Date: Tue, 4 Jan 2011 00:09:25 +0000 Message-ID: From: Sam Stickland To: lisp@ietf.org Content-Type: multipart/alternative; boundary=0015174be150d0b9b30498fa14ac Subject: [lisp] Setting up a LISP IPv4 environment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 00:07:20 -0000 --0015174be150d0b9b30498fa14ac Content-Type: text/plain; charset=ISO-8859-1 All, I'm interested in getting some practical experience with LISP, first in a lab then, but then in the real world. Is this possible yet? Are there public mapping servers and resolvers available? And how would I announce IPv4 EIDs? I could use an existing /24 as the EIDs, but I'm guessing there aren't any publically available PITRs, so I'd need to run one myself? (or just continue to announce the prefix into the BGP table in the existing manner?). Regards, Sam --0015174be150d0b9b30498fa14ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,
=A0
I'm interested in getting some practical experience with LISP, fir= st in a lab then, but then in the real world. Is this possible yet? Are the= re public mapping servers and resolvers available? And how would I=A0announ= ce IPv4 EIDs? I could use an existing /24 as the EIDs, but I'm guessing= there aren't any publically available PITRs, so I'd need to run on= e myself? (or just continue to announce the prefix into the BGP table in th= e existing manner?).
=A0
Regards,
=A0
Sam
--0015174be150d0b9b30498fa14ac-- From jnc@mercury.lcs.mit.edu Mon Jan 3 16:29:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABD83A6E83 for ; Mon, 3 Jan 2011 16:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGrVySN0f5lK for ; Mon, 3 Jan 2011 16:29:56 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 10CB63A6E82 for ; Mon, 3 Jan 2011 16:29:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C2CF76BE570; Mon, 3 Jan 2011 19:32:01 -0500 (EST) To: lisp@ietf.org Message-Id: <20110104003201.C2CF76BE570@mercury.lcs.mit.edu> Date: Mon, 3 Jan 2011 19:32:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Setting up a LISP IPv4 environment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 00:29:57 -0000 > From: Sam Stickland > I'm interested in getting some practical experience with LISP, first in > a lab then, but then in the real world. Is this possible yet? You could start with: http://www.lisp4.net/ which has a fair amount of information about what's currently running. Noel From Internet-Drafts@ietf.org Wed Jan 5 12:45:02 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D927F3A6CF0; Wed, 5 Jan 2011 12:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reeVK6Sor7Kh; Wed, 5 Jan 2011 12:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58E23A6D01; Wed, 5 Jan 2011 12:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110105204501.21116.89379.idtracker@localhost> Date: Wed, 05 Jan 2011 12:45:01 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-mib-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 20:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP MIB Author(s) : G. Schudel, et al. Filename : draft-ietf-lisp-mib-00.txt Pages : 40 Date : 2011-01-05 This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05123333.I-D@ietf.org> --NextPart-- From gschudel@cisco.com Wed Jan 5 13:11:11 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B423A6D19 for ; Wed, 5 Jan 2011 13:11:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtv2fHuHfTOZ for ; Wed, 5 Jan 2011 13:11:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7534A3A6D0D for ; Wed, 5 Jan 2011 13:11:06 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Attached Message Part : 124 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgGAOdtJE2rR7Hu/2dsb2JhbACWB4k3hF1zpwCYK4VMBIRohiI X-IronPort-AV: E=Sophos;i="4.60,279,1291593600"; d="txt'208?scan'208,208";a="241020700" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2011 21:13:13 +0000 Received: from gschudel-mac-2.local ([64.101.107.48]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p05LDCWq000849 for ; Wed, 5 Jan 2011 21:13:12 GMT Message-ID: <4D24DF33.6040608@cisco.com> Date: Wed, 05 Jan 2011 13:14:27 -0800 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: lisp@ietf.org Content-Type: multipart/mixed; boundary="------------010500050900090304030108" Subject: [lisp] Fwd: I-D Action:draft-ietf-lisp-mib-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Jan 2011 21:11:11 -0000 This is a multi-part message in MIME format. --------------010500050900090304030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all Per the LISP working group co-chairs, draft-ietf-lisp-mib has been submitted as a working group document. cheers gregg -------- Original Message -------- Subject: [lisp] I-D Action:draft-ietf-lisp-mib-00.txt Date: Wed, 05 Jan 2011 12:45:01 -0800 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP MIB Author(s) : G. Schudel, et al. Filename : draft-ietf-lisp-mib-00.txt Pages : 40 Date : 2011-01-05 This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------010500050900090304030108 Content-Type: Message/External-body; name="draft-ietf-lisp-mib-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-mib-00.txt" Content-Type: text/plain Content-ID: <2011-01-05123333.I-D@ietf.org> --------------010500050900090304030108 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --------------010500050900090304030108--