From damian.lezama@hotmail.com Thu Apr 2 20:58:05 2009 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 0EC5D3A685E for ; Thu, 2 Apr 2009 20:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSLPWMBDb9gI for ; Thu, 2 Apr 2009 20:58:04 -0700 (PDT) Received: from col0-omc4-s4.col0.hotmail.com (col0-omc4-s4.col0.hotmail.com [65.55.34.206]) by core3.amsl.com (Postfix) with ESMTP id 66D2A3A69F1 for ; Thu, 2 Apr 2009 20:57:48 -0700 (PDT) Received: from COL110-DS14 ([65.55.34.199]) by col0-omc4-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 20:58:50 -0700 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: Date: Thu, 2 Apr 2009 20:58:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C9B3D5.BAA17840" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm0EGW1s84eaf+eTXS5xAsZoldudA== Content-Language: en-us X-OriginalArrivalTime: 03 Apr 2009 03:58:50.0756 (UTC) FILETIME=[7F741440:01C9B410] Subject: [lisp] Encapsulated map requests to the Map Resolver 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: Fri, 03 Apr 2009 03:58:05 -0000 ------=_NextPart_000_0015_01C9B3D5.BAA17840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I=92m trying to understand why the map requests sent to a Map Resolver = have to be encapsulated. The ITR has to know in advance the Map Resolver RLOC, that=92s for sure, is it really necessary for the ITR to encapsulate = this message? What will it put in the inner header, an also known Map = Resolver EID? =20 Thanks, Dami=E1n =20 ------=_NextPart_000_0015_01C9B3D5.BAA17840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m trying to understand why the map requests = sent to a Map Resolver have to be encapsulated. The ITR has to know in advance = the Map Resolver RLOC, that’s for sure, is it really necessary for the ITR = to encapsulate this message? What will it put in the inner header, an also = known Map Resolver EID?

 

Thanks,

Damián

 

------=_NextPart_000_0015_01C9B3D5.BAA17840-- From dino@cisco.com Thu Apr 2 22:00:27 2009 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 ED2313A6B67 for ; Thu, 2 Apr 2009 22:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 9ilRbXG6XIuS for ; Thu, 2 Apr 2009 22:00:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D83FE3A6B01 for ; Thu, 2 Apr 2009 22:00:26 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2009 05:01:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3351Two017257; Thu, 2 Apr 2009 22:01:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3351TV9000936; Fri, 3 Apr 2009 05:01:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 22:01:29 -0700 Received: from [192.168.1.3] ([10.21.124.32]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 22:01:28 -0700 Message-Id: <1E7874C1-A00B-438A-B9E3-367CB6ED77A2@cisco.com> From: Dino Farinacci To: "Damian Lezama" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 2 Apr 2009 22:01:28 -0700 References: X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 03 Apr 2009 05:01:28.0846 (UTC) FILETIME=[3F731AE0:01C9B419] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1491; t=1238734889; x=1239598889; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Encapsulated=20map=20requests= 20to=20the=20Map=20Resolver |Sender:=20; bh=FASMMVKFvcttG90YopKuQIS1WRM+2eJhbSpqo2hcPJ4=; b=eFuWQzFocIL4WvXTENPsVCjkAiLVKOKRd735eopgXHTacp2gGzwHAHg3P2 7Y0R3rGAvC7kgbU/fyCVJyNOS2STDNbQYu61VlJ1fnvNDVXPHkz4TU8y3Rdp IWrhXuSrFn; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Encapsulated map requests to the Map Resolver 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: Fri, 03 Apr 2009 05:00:28 -0000 > I=92m trying to understand why the map requests sent to a Map Resolver = =20 > have to be encapsulated. The ITR has to know in advance the Map =20 > Resolver RLOC, that=92s for sure, is it really necessary for the ITR =20= > to encapsulate this message? What will it put in the inner header, =20 > an also known Map Resolver EID? It's because a Map-Request is spec'ed out to have a destination =20 address set to the EID being sought. To get the Map-Request from the =20 ITR to the map-resolver, you need RLOCs in the source and destination =20= addresses. Therefore, we encapsulate so the outer header can have RLOCs. Another reason is to get IPv6 to work over an IPv4 infrastructure. =20 That is, if an IPv6 Map-Request is sent for an IPv6 EID and the path =20 to the map-resolver does not support IPv6 forwarding, we need to =20 encapsulate in a IPv4 header to get the Map-Request to the map-resolver. In the prototype implementation we have a command like this in the ITR: ipv6 lisp itr map-resolver Where IPv6 Map-Requests are sent to the IPv4 address in . There is another case why we want to encapsulate Map-Requests. When =20 the map-resolver gets the encapsulated Map-Request, we want it to =20 strip the outer header and forward what's inside. We want the inner =20 packet to not be touched by the map-resolver so we can debug on the =20 ALT the source of the Map-Request (which is the ITR). Dino From damian.lezama@hotmail.com Fri Apr 3 10:18:59 2009 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 252463A6A06 for ; Fri, 3 Apr 2009 10:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnjHgfwhZ7Ls for ; Fri, 3 Apr 2009 10:18:58 -0700 (PDT) Received: from col0-omc2-s16.col0.hotmail.com (col0-omc2-s16.col0.hotmail.com [65.55.34.90]) by core3.amsl.com (Postfix) with ESMTP id 4887B3A6954 for ; Fri, 3 Apr 2009 10:18:58 -0700 (PDT) Received: from COL110-DS14 ([65.55.34.72]) by col0-omc2-s16.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 10:20:01 -0700 X-Originating-IP: [131.107.0.101] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: "'Dino Farinacci'" References: <1E7874C1-A00B-438A-B9E3-367CB6ED77A2@cisco.com> In-Reply-To: <1E7874C1-A00B-438A-B9E3-367CB6ED77A2@cisco.com> Date: Fri, 3 Apr 2009 10:20:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm0GT+KwLbVp4NHQpea7CLsxu75CQAZcEWw Content-Language: en-us X-OriginalArrivalTime: 03 Apr 2009 17:20:01.0205 (UTC) FILETIME=[6BAC7E50:01C9B480] Cc: lisp@ietf.org Subject: Re: [lisp] Encapsulated map requests to the Map Resolver 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: Fri, 03 Apr 2009 17:18:59 -0000 Hi, Great, clear enough, thanks. Another issue that I have some doubts about is the role of the ETRs = sending map replies when they do not take part in the ALT topology (they just = send map registers to a Map Server that takes care). The one in the ALT that knows how to reach the ETR (and therefore can forward the Map Request to it) already has the mapping, so it can reply instead of forwarding it to the ETR (in your schema I think this Map = Server has to be also a Map Resolver in order to do that). Can you provide some practical scenarios where these "no ALT ETRs" replying to the Map = Requests is a requirement? Thanks. Regards, Dami=E1n > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Thursday, April 02, 2009 10:01 PM > To: Damian Lezama > Cc: lisp@ietf.org > Subject: Re: [lisp] Encapsulated map requests to the Map Resolver >=20 > > I=92m trying to understand why the map requests sent to a Map = Resolver > > have to be encapsulated. The ITR has to know in advance the Map > > Resolver RLOC, that=92s for sure, is it really necessary for the ITR > > to encapsulate this message? What will it put in the inner header, > > an also known Map Resolver EID? >=20 > It's because a Map-Request is spec'ed out to have a destination > address set to the EID being sought. To get the Map-Request from the > ITR to the map-resolver, you need RLOCs in the source and destination > addresses. Therefore, we encapsulate so the outer header can have > RLOCs. >=20 > Another reason is to get IPv6 to work over an IPv4 infrastructure. > That is, if an IPv6 Map-Request is sent for an IPv6 EID and the path > to the map-resolver does not support IPv6 forwarding, we need to > encapsulate in a IPv4 header to get the Map-Request to the map- > resolver. >=20 > In the prototype implementation we have a command like this in the = ITR: >=20 > ipv6 lisp itr map-resolver >=20 > Where IPv6 Map-Requests are sent to the IPv4 address in address>. >=20 > There is another case why we want to encapsulate Map-Requests. When > the map-resolver gets the encapsulated Map-Request, we want it to > strip the outer header and forward what's inside. We want the inner > packet to not be touched by the map-resolver so we can debug on the > ALT the source of the Map-Request (which is the ITR). >=20 > Dino From dino@cisco.com Fri Apr 3 18:42:02 2009 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 B995A3A69A3 for ; Fri, 3 Apr 2009 18:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 MNyA0oXCfwm2 for ; Fri, 3 Apr 2009 18:42:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9E84D3A68AB for ; Fri, 3 Apr 2009 18:42:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,322,1235952000"; d="scan'208";a="166581503" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2009 01:43:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n341h4WJ027075; Fri, 3 Apr 2009 18:43:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n341h4P9024224; Sat, 4 Apr 2009 01:43:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 18:43:04 -0700 Received: from [192.168.1.3] ([10.21.124.32]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 18:43:04 -0700 Message-Id: <384B1080-0DF9-4585-BB92-71F7A92C3E4B@cisco.com> From: Dino Farinacci To: Damian Lezama In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.4) Date: Fri, 3 Apr 2009 18:43:04 -0700 References: <1E7874C1-A00B-438A-B9E3-367CB6ED77A2@cisco.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 04 Apr 2009 01:43:04.0478 (UTC) FILETIME=[B24E73E0:01C9B4C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3145; t=1238809385; x=1239673385; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Encapsulated=20map=20requests= 20to=20the=20Map=20Resolver |Sender:=20; bh=n3DCIwH1js/3QyGjRQ9fz+I/Cpg+jxpvJPrnqjYJoHg=; b=eLHa6AbAIg31yz19bVsjnVFh8aGgg7cGYacmjmgO6HCixRhV142qksMG3r 0yHgCwcD/ijAIA6FH3aUVNv924D9vfFjK8eu94w1ebxwCZnD8LuPFR9fM6OB 5HGaB63Q2l; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Encapsulated map requests to the Map Resolver 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: Sat, 04 Apr 2009 01:42:02 -0000 > Great, clear enough, thanks. > > Another issue that I have some doubts about is the role of the ETRs =20= > sending > map replies when they do not take part in the ALT topology (they =20 > just send > map registers to a Map Server that takes care). But it is a authenticated leaf which tells the map-server that it =20 should forward Map-Requests to it. > The one in the ALT that knows how to reach the ETR (and therefore can > forward the Map Request to it) already has the mapping, so it can =20 > reply The packet format of a Map-Register encodes something that looks like =20= a map-cache entry but we do not, at this time, want the map-server to =20= proxy reply for the ETRs. The ETRs are the authoritative source of the =20= site's mapping and it wants to reply with up to date R-bits so the =20 requester knows the current up/down status of each RLOC. Plus the site =20= may want to modify the priority and weight per RLOC for policy =20 reasons. That all needs to be controlled at and by the site. Dino > instead of forwarding it to the ETR (in your schema I think this Map =20= > Server > has to be also a Map Resolver in order to do that). Can you provide =20= > some > practical scenarios where these "no ALT ETRs" replying to the Map =20 > Requests > is a requirement? Thanks. > > Regards, > Dami=E1n > >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Thursday, April 02, 2009 10:01 PM >> To: Damian Lezama >> Cc: lisp@ietf.org >> Subject: Re: [lisp] Encapsulated map requests to the Map Resolver >> >>> I=92m trying to understand why the map requests sent to a Map = Resolver >>> have to be encapsulated. The ITR has to know in advance the Map >>> Resolver RLOC, that=92s for sure, is it really necessary for the ITR >>> to encapsulate this message? What will it put in the inner header, >>> an also known Map Resolver EID? >> >> It's because a Map-Request is spec'ed out to have a destination >> address set to the EID being sought. To get the Map-Request from the >> ITR to the map-resolver, you need RLOCs in the source and destination >> addresses. Therefore, we encapsulate so the outer header can have >> RLOCs. >> >> Another reason is to get IPv6 to work over an IPv4 infrastructure. >> That is, if an IPv6 Map-Request is sent for an IPv6 EID and the path >> to the map-resolver does not support IPv6 forwarding, we need to >> encapsulate in a IPv4 header to get the Map-Request to the map- >> resolver. >> >> In the prototype implementation we have a command like this in the =20= >> ITR: >> >> ipv6 lisp itr map-resolver >> >> Where IPv6 Map-Requests are sent to the IPv4 address in > address>. >> >> There is another case why we want to encapsulate Map-Requests. When >> the map-resolver gets the encapsulated Map-Request, we want it to >> strip the outer header and forward what's inside. We want the inner >> packet to not be touched by the map-resolver so we can debug on the >> ALT the source of the Map-Request (which is the ITR). >> >> Dino > > From darlewis@cisco.com Mon Apr 6 09:44:42 2009 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 227F03A6CEE for ; Mon, 6 Apr 2009 09:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, FRT_BELOW2=2.154, J_CHICKENPOX_43=0.6, 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 UNvHUmn35DcW for ; Mon, 6 Apr 2009 09:44:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CF77E3A6CEC for ; Mon, 6 Apr 2009 09:44:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,331,1235952000"; d="scan'208";a="281185114" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Apr 2009 16:45:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n36GjkgH022849 for ; Mon, 6 Apr 2009 09:45:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n36Gjk49003735 for ; Mon, 6 Apr 2009 16:45:46 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 09:45:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Apr 2009 09:45:45 -0700 Message-ID: <60C4A248E730F249990993E3B9BD44D807969E95@xmb-sjc-218.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP IETF-74 Meeting Minutes Thread-Index: Acm21yHJlCBEZdz2TPu8i4pod1y1Vg== From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 06 Apr 2009 16:45:46.0470 (UTC) FILETIME=[22321060:01C9B6D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9962; t=1239036346; x=1239900346; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20LISP=20IETF-74=20Meeting=20Minutes |Sender:=20; bh=qn1GZCKto90Exwl59qANMVa8jvx1Bpend9dAtnyMx9c=; b=OS4dqB3VBEzyOXRT99CQHHB2NLJ0liSZWiKlTLa8Iv+A0Iz2tuMkwYpEBB HppbfD2D7OnFtY1c4mC4p8oMo3gAcIS5MPL74SkNp9fL5uMvNsD2XiJrgVjA EmJDSHx7wa; Authentication-Results: sj-dkim-3; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [lisp] LISP IETF-74 Meeting Minutes 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, 06 Apr 2009 16:44:42 -0000 Hello, Bellow are the meeting minutes for the San Francisco IETF. The deadline for comments is 4/20/2009. -Darrel ----------------- -- LISP BoF - IETF-74 - Chairs Darrel Lewis/Sam Hartman jabber: lisp@jabber.ietf.org 1) Agenda Bashing - Darrel Lewis no additional agenda info Introduction by Jari about status of WG, while it isn't officially formed, his view is the time is better spent as a WG than a BoF. Wasn't time to complete WG formation process prior to the meeting in SF,=20 the final decision of WG status by the IESG is pending. 2) Charter Discussion - Sam Hartman Sam Hartman - Accurately describe what LISP separates EID/LOC split discussion Changes - End Site Identifier vs End System Identifier Discuss end host changes are out of scope Focus on incremental deployability Concerns - endsite-identifier problematic idenitify vs identifier (multiple interfaces no a single system) (skipping ahead by co-chair) Charter(3) question from the floor - 'Global portion and local portion' is confusing Perhaps re-word this away from 'global'... Discussion of Noel's email about the charter Comments on whether the listeners think this should be chartered as a WG ietf-list Quesiton from the floor - HIP interrelationship/interworking with this WG Answer - HIP is focused on the end-station, forcing host-based changes at the expense of router changes (not changing routers/routing) Comment from the floor - Identify in HIP vs Identifier in LISP, can we use different terms for this? There is term collision, which is confusing. Chair - Focus please on how the charter is unclear, not how wording isn't clear. Comment - HIP/LISP id/loc split is nicely sited in the Charter's link to the IAB document about id/loc split Chair - Perhaps HIP =3D=3D host-based loc/id split LISP =3D=3D network-based loc/split Comment - Please accurately describe 'what we are doing', attempt to reach consensus on terminology and charter. 3) LISP Draft review - Dino Farinacci current draft discussions - draft-farinacci-lisp-00.txt - 01/2007 - fallout from the 2006 IAB Workshop draft-farinacci-lisp-01.txt - draft-farinacci-lisp-02.txt - editorial changes 03.txt - clarified for both AFI's 04.txt - mobility considerations 05.txt - added control/data ports + ALT discussion 06.txt - defined data-probes + MTU + referenced external docs (see slides) 07.txt - More clarification of EID, added multicast support 08.txt - 04/2008 - more discussion on EID 09.txt - 10/2008 - clarification on EID-prefix 10.txt - 11/2008 - added traceroute bits, indicated where LISP could run 11.txt - 12/2008 - added stateful + stateless MTU considerations (Question on MTU pushed to end) clarified where this should be used, small multi-homed sites 12.txt - 03/2009 - talk about map server cache state issues Doc Status - Fairly Stable, implemented 1.5-2 full systems, packet format is stable Possibly adding network management fields, as-name/as-number Open policy - LISP is open, no IPR claims, all volunteer effort from vendors/ops/researchers/inventors Peer review from many external folks (Noel/Vint/DaveClark/PaulMockapetris/LenBosack) MTU Issues/Questions - Stateless case - DF=3D0 means we can't drop the packet, must handle Frag packet, pass along to the end for reassembly In the end, the MTU discussion needs more work, please move to list. HIP vs LISP discussion, how does HIP deal with ipv4 - HIP Proxy being pushed to move along away from HIP discussion(s) Chair - Looking for reviews from: Transport, HIP, Security ... at least 4) What is LISP+ALT - Vince Fuller Split of what namespaces are used where: EID - local site RLOC - Internet-at-large Mappings of EID -> RLOC happen at the ETR (Egress Tunnel Router) Discussion of the LISP+ALT workings (see animated slides) Document History - 11/2007 -> current Spec stable since 10/2008 Working code today on NXos systems with 6+months of testing/experimentation on live network. Need more implementations, more testing, more experimentation Need to discuss at least: cache in ITR, negative cache replies What further review do we need/want here: Focus on completion of this WG/BoF focus on LISP+ALT only Security focus on LISP, ALT and the entire LISP+ALT system map-replies/map-requests have alternate security implications 5) LISP Map Server Draft discussion - Vince Fuller draft-fuller-lisp--ms-00.txt Eliminate ALT complexities in xTR's Map-Servers are co-located in the LISP-ALT routers, not required though. Map-Server/Map-Resolver - Resolver accepts Request from ITR to make the EID-to-RLOC mapping Server accepts request from the ALT, forwarding that to the ETR. ETR's are still authoritative for EID-RLOC mappings Map-Server is now a cache-layer See slides for illustration(s) For Future work - Negative caching (cache-management in general) caching in map-resolvers Questions about pushing this into a WG draft vs more individual works For ALT + MapServer: Some consensus to move this to a WG Draft Questions about 'is this a BoF or a WG?' More discussions about 'experiment before direction/decision' vs 'direction decision before experimentation' Incremental changes to current techniques, focus on less complexity Evaluation of complexity is possible says Dave Oran, forthcoming message to the list about measuring this. Jarri clarifies - BoF slot, the slot being run as a WG. 6) Interworking Mechanisms - darrel lewis draft-lewis-lisp-internetworking-02.txt Proxy Tunnel Routers (PTR) Originates few EID prefixes traffic is assymetrical ingress only allows lisp sites to see benefits of ingress TE immediately Placement as close to the traffic-source =3D=3D less stretch LISP-NAT - this is still NAT, that's good and bad, possibly useful for broadband interworking deployments Status/further-work PTRs and uRPF considerations Should work come for Broadband interworking? LISP-NAT for IPv6 as well? PTR behaviours and scaling - anycast? implementations in hardware? cache-management concerns and testing External Reviews - general security reviews? review by 6to4 implementors as well Call to bring this into a WG document. 7) LISP Multicast - dino draft-farinacci-lisp-multicast-00.txt - 04/2008 Result is a simple procedural change to PIM (S-EID,G) in reciever domains (S-RLOC,G) in core -01 posted 11/2008 No current implementations Need expert mcast implementor review Presented in PIM + MBoned WGs. Call for picking this up as a WG doc - Chair Sucker Search - Sam Securing the Mapping System - draft necessary 2 callers interested Security Analysis of LISP/ALT Network Management 8) LISP Mapping Versioning - Luigi Iannone Requirement for versioning of the Mapping database see slides for animation(s) Use this as a method to find unauthorized path generation in the mapping database (drop on version larger than currently known version) Use this as a method to update the end site mapping databases (notify on version lower than currently known version) Accept benign version equality Today we have SMR + Reachability bits already in LISP Reachability Bits - hints, when these change, require map-request to be sent SMR -=20 With versioning though - in the data-plane we can know directly when a map request is required, less control-plane complexity, push this complexity to the data-plane processing Data driven updates to the mapping database, no monitoring required at all=20 xTR devices. (more illustrations/animations - see slides) Alternate LISP Header changes potentially to enable the version marking Comments - =20 Dino - what about alt-4 - nonce overload DaveOran - linkstate mapping overloaded onto the LISP Mapping keep in mind what has come before - isis linkstate issues Dino - clarifications on terminology Call to WG adopt this? More discussion on-list required at this time. 9) Next Steps / Open Discussion Discussions on applicability, deployability, status of the=20 WG/BoF/whatever-this-is-today Management vs MIB work, where can you see all the parts that are important. Possibility add instead of 'Network Management' - Operations + Management Impact on upper layers=20 Dave Harrington - OpsAWG WG Doc to think about management of the protocol Discussion of rate + state based on huston-graphs/data This looks to address 'state' but not 'rate' dino - 'rate' addressed at the first ISP & aggregation of RLOC space 10) End Early From luigi@net.t-labs.tu-berlin.de Tue Apr 7 07:56:50 2009 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 4B55728C1C3 for ; Tue, 7 Apr 2009 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dRsW1ABtPlN for ; Tue, 7 Apr 2009 07:56:49 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id C9B9128C208 for ; Tue, 7 Apr 2009 07:56:27 -0700 (PDT) Received: from dyn109.net.t-labs.tu-berlin.de (dyn109.net.t-labs.tu-berlin.de [130.149.220.109]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 91CAD700D480; Tue, 7 Apr 2009 16:57:33 +0200 (CEST) Message-Id: <60BBA0A1-4E08-4FEC-9240-F3494257EB3A@net.t-labs.tu-berlin.de> From: Luigi Iannone To: Darrel Lewis (darlewis) In-Reply-To: <60C4A248E730F249990993E3B9BD44D807969E95@xmb-sjc-218.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 16:57:32 +0200 References: <60C4A248E730F249990993E3B9BD44D807969E95@xmb-sjc-218.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: lisp@ietf.org Subject: Re: [lisp] LISP IETF-74 Meeting Minutes 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, 07 Apr 2009 14:56:50 -0000 Hi, just one comment inline. On Apr 6, 2009, at 18:45 , Darrel Lewis (darlewis) wrote: [snip] > > 8) LISP Mapping Versioning - Luigi Iannone > > Requirement for versioning of the Mapping database > see slides for animation(s) > Use this as a method to find unauthorized path generation in the > mapping > database (drop on version larger than currently known version) > Use this as a method to update the end site mapping databases > (notify on version lower than currently known version) > Accept benign version equality > Today we have SMR + Reachability bits already in LISP > Reachability Bits - hints, when these change, require map-request > to > be sent > SMR - > With versioning though - in the data-plane we can know directly > when a > map > request is required, less control-plane complexity, I said that. > push this > complexity > to the data-plane processing I did not said this. The complexity on the data-plane is the same like SMR+ReachBits. But thanks, this is another point to clarify in the next version of the draft, to be discussed on the list. Cheers Luigi > > Data driven updates to the mapping database, no monitoring required > at > all > xTR devices. > (more illustrations/animations - see slides) > Alternate LISP Header changes potentially to enable the version > marking > Comments - > Dino - what about alt-4 - nonce overload > DaveOran - linkstate mapping overloaded onto the LISP Mapping > keep in mind what has come before - isis linkstate > issues > Dino - clarifications on terminology > Call to WG adopt this? > More discussion on-list required at this time. [snip] From hartmans@mit.edu Mon Apr 13 05:41:41 2009 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 B23043A6AF7 for ; Mon, 13 Apr 2009 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlChuVHEV9xN for ; Mon, 13 Apr 2009 05:41:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 09FEF3A68D9 for ; Mon, 13 Apr 2009 05:41:40 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B59A8414C; Mon, 13 Apr 2009 08:42:37 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 13 Apr 2009 08:42:37 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] chartering update 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, 13 Apr 2009 12:41:41 -0000 The LISP working group was on last Thursday's IESG agenda. Jari reports that there were no objections but that the IESG wanted to see the final charter text. I provided a clean copy to Jari and he's circulating within the IESG. From aihua9@gmail.com Thu Apr 23 00:38:15 2009 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 C369A28C685 for ; Thu, 23 Apr 2009 00:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3kmNVW58CRx for ; Thu, 23 Apr 2009 00:38:15 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 37DBF28C66C for ; Thu, 23 Apr 2009 00:38:13 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so175648waf.5 for ; Thu, 23 Apr 2009 00:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=d/WIhu8XOtHmtfo9PpBCgBPTwQoLE/V8UIV3lVo15NM=; b=wBqQbLic7BKWrXo+sGZJOOJI3iqrZ8efHYOUx4kNpxFC/itzxRs5wbVX9oqa3d/KZL zjgYUBQ5YZivbn6DzDk82fe+jXt+ihBpALqvT7H6Tid3RGrWGhrb5jc0VErr+4ozRfpT jC8fbJnXKaTLvpdD6gCs3FlL0CbrJQxKYyXac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PF/XDm65lhD25003vmx7EQMuIGQ4fJ4F1TAqcGTLY0yBpuQ0c/Uz3W5M9pp7eEkOkG FEQmrdsrw3U3wKEZel6TrGfVyf/c+sGSnxAsgxv+Jrq5puNc+3ip0RmPxpIjXaZTaKew JLas46HWzpGL0msYpniV2ibmFoMxPYLMCeyxc= MIME-Version: 1.0 Received: by 10.114.111.1 with SMTP id j1mr343503wac.79.1240472370892; Thu, 23 Apr 2009 00:39:30 -0700 (PDT) Date: Thu, 23 Apr 2009 15:39:30 +0800 Message-ID: From: aihua zhang To: lisp@ietf.org Content-Type: multipart/alternative; boundary=00163641790105612e046833fb6a Subject: [lisp] Lisp question 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: Thu, 23 Apr 2009 08:43:16 -0000 --00163641790105612e046833fb6a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Mr./Ms. I'm a student of BeiJing University of Posts and Telecommunications.currently, I read the lisp active draft. from the reading, I've a question about the mapping database services:the CONS and NERD draft have expired,but in the LISP=A3=A8draft-farinacci-lisp-12=A3=A9i= t also mentions these method. I don't know whether the lisp will consider CONS and NERD as the mapping service.please contact me,thanks. --=20 Best regards! Sincerely, aiHua Zhang State Key Lab. of Networking Technology Research Institute, BeiJing University of Posts and Telecommunications, 100876, P.R.China Email =A3=BA aihua9@gmail.com aihua9@bupt.edu.cn --00163641790105612e046833fb6a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Dear Mr./Ms.
 
   I'm a student of BeiJing University of Posts and Tele= communications.currently, I read the lisp active draft. from the = reading, I've a question about the mapping database services:the CONS a= nd NERD draft have expired,but in the LISP=A3=A8draft-farinacci-lisp-12=A3= =A9it also mentions these method. I don't know whether t= he lisp will consider CONS and NERD as the mapping service.please contact m= e,thanks.
--
Best regards!

Sincerely,
aiHua Zhang

State Key Lab.= of Networking Technology Research Institute, BeiJing University of Posts a= nd Telecommunications, 100876, P.R.China
Email =A3=BA
--00163641790105612e046833fb6a-- From rw@firstpr.com.au Thu Apr 23 02:02:52 2009 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 A31D73A6F01 for ; Thu, 23 Apr 2009 02:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV3rQenNjOY4 for ; Thu, 23 Apr 2009 02:02:52 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id BADB13A687A for ; Thu, 23 Apr 2009 02:02:51 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id AB2AE175723; Thu, 23 Apr 2009 19:04:08 +1000 (EST) Message-ID: <49F02E91.8050209@firstpr.com.au> Date: Thu, 23 Apr 2009 19:02:09 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 09:02:52 -0000 On the RRG list: http://www.ietf.org/mail-archive/web/rrg/current/msg04907.html As part of an RRG discussion with Bill Herrin, I created the idea of a "Distance Server" by which an ITR could choose (or have already chosen by something else) the closest (in BGP terms) ETR of multiple ETRs in the mapping. Bill suggested that an ITR can already do this, but it can't. LISP or Bill's TRRP could have this as a separate server, but it could also be integrated into LISP-ALT's Map Resolver. For Ivip, I would integrate it into the full database Query Server QSD. For APT, the logical thing is to integrate it into the Default Mapper. The same thing could be used for a core-edge elimination scheme, but I think core-edge separation schemes are the best approach. Without a "Distance Server" or similar, neither a core-edge separation scheme nor a core-edge elimination scheme can perform the equivalent of the existing, conventional BGP-based "anycast" in a way which scales better than the existing BGP approach. This BGP approach scales very poorly because it relies on a separate BGP prefix for every such set of "anycast" servers. See: http://www.ietf.org/mail-archive/web/rrg/current/msg04897.html http://www.ietf.org/mail-archive/web/rrg/current/msg04904.html With a "Distance Server", I think LISP, APT, Ivip and TRRP etc. could do this work very nicely, in a highly scalable fashion. This goes beyond conventional anycast and into high reliability and "disaster recovery" systems, which Bill gave an example of and which I quote in my RRG message. - Robin From olivier.bonaventure@uclouvain.be Thu Apr 23 02:47:04 2009 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 BB2753A7211 for ; Thu, 23 Apr 2009 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 VVewAPx1R5OY for ; Thu, 23 Apr 2009 02:47:03 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 761483A71FB for ; Thu, 23 Apr 2009 02:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=Kd5/MDmKdqo4fi7htI77wG2hnj0=; b=RNv72jPx52 5InScO0XHFaM3UirsSB6UV6b9Zp1/9HBgA3VMlDaKm+9RI+5opiKM2e8g/2eVFeo gLDT2xBVWwm/pwWDkemN0MKyKhfywMsbq7VEVMIiUVR0oCibS5xB5dp6efN3Qff2 bJ38C9vqq17F/VKwPSboEMQCfqKYHCYFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=kPC8d xKJEYyYUJst0C5OCwcdjp4RIKvHQYMId3FUubL5fgU80mAAki7SjHopbfY3If10a BhzChJ31TL9KIfSDGVg/HSNacTCe+1riF9zmUjfXBDc7kG/duA/B3rk/teHASRsU ZoYTEZrfO/gWl/iBBK67XF7PzhZLbJO+dgqY+U= Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 23 Apr 2009 11:48:07 +0200 (CEST) Message-ID: <49F03956.6010406@uclouvain.be> Date: Thu, 23 Apr 2009 11:48:06 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robin Whittle References: <49F02E91.8050209@firstpr.com.au> In-Reply-To: <49F02E91.8050209@firstpr.com.au> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6CA931C9270.4A0C3 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 23 Apr 2009 09:47:05 -0000 Robin, > On the RRG list: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04907.html > > As part of an RRG discussion with Bill Herrin, I created the idea of > a "Distance Server" by which an ITR could choose (or have already > chosen by something else) the closest (in BGP terms) ETR of multiple > ETRs in the mapping. This kind of idea is similar to what ALTO is supposed to develop. See http://www.ietf.org/html.charters/alto-charter.html Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Thu Apr 23 06:02:40 2009 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 E49483A67CC for ; Thu, 23 Apr 2009 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Y5S4ked8GI+g for ; Thu, 23 Apr 2009 06:02:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id B42D13A6E07 for ; Thu, 23 Apr 2009 06:01:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A251E6BE56E; Thu, 23 Apr 2009 09:02:43 -0400 (EDT) To: aihua9@gmail.com Message-Id: <20090423130243.A251E6BE56E@mercury.lcs.mit.edu> Date: Thu, 23 Apr 2009 09:02:43 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu, lisp@ietf.org Subject: Re: [lisp] Lisp question 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: Thu, 23 Apr 2009 13:02:41 -0000 > From: aihua zhang > I've a question about the mapping database services: the CONS and NERD > draft have expired ... I don't know whether the lisp will consider CONS > and NERD as the mapping service. The current plan is for LISP to use ALT as the mapping service initially, because it's a lot less work to get it running. However, ALT is seen as a short- or medium-term solution (in part because it is re-using other things, as opposed to being designed specifically for the purpose). In the long term, if LISP is successful, it will probably be necessary to deploy something else, and something like CONS could well be it. However, it will all depend on experience. Noel From dino@cisco.com Thu Apr 23 10:47:23 2009 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 68E343A6B0B for ; Thu, 23 Apr 2009 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 T35-C+NjHT0f for ; Thu, 23 Apr 2009 10:47:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3B5383A6C31 for ; Thu, 23 Apr 2009 10:45:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="158240822" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2009 17:47:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3NHl3Rd019186; Thu, 23 Apr 2009 10:47:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3NHl3Vs004529; Thu, 23 Apr 2009 17:47:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 10:46:57 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 10:46:57 -0700 Message-Id: <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49F02E91.8050209@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 10:46:56 -0700 References: <49F02E91.8050209@firstpr.com.au> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 17:46:57.0590 (UTC) FILETIME=[7F604560:01C9C43B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2073; t=1240508823; x=1241372823; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=20to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=dY5Av1limCQEipMu4Rx3/VkTTAtgi4fB/F5OhHr+4CE=; b=pOHvSOSvLrBvtP1IvBX7/6mcoOMYgH1NaPxxppWc34OgkJdvrPwo+seN8D uui2cDUCX5BF3Nt0U553pE2h+2BqIKj57X/9pcohfU8/5+2UptoyiDpdbf8A tS7SOT8bz5; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 17:47:23 -0000 Why not just pick an ETR, watch for return traffic and try to monitor RTTs between the sites for the data flow. Topological distance isn't as important as packet latency. Dino On Apr 23, 2009, at 2:02 AM, Robin Whittle wrote: > On the RRG list: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04907.html > > As part of an RRG discussion with Bill Herrin, I created the idea of > a "Distance Server" by which an ITR could choose (or have already > chosen by something else) the closest (in BGP terms) ETR of multiple > ETRs in the mapping. > > Bill suggested that an ITR can already do this, but it can't. > > LISP or Bill's TRRP could have this as a separate server, but it > could also be integrated into LISP-ALT's Map Resolver. > > For Ivip, I would integrate it into the full database Query Server > QSD. For APT, the logical thing is to integrate it into the Default > Mapper. The same thing could be used for a core-edge elimination > scheme, but I think core-edge separation schemes are the best > approach. > > Without a "Distance Server" or similar, neither a core-edge > separation scheme nor a core-edge elimination scheme can perform the > equivalent of the existing, conventional BGP-based "anycast" in a way > which scales better than the existing BGP approach. This BGP > approach scales very poorly because it relies on a separate BGP > prefix for every such set of "anycast" servers. See: > > http://www.ietf.org/mail-archive/web/rrg/current/msg04897.html > http://www.ietf.org/mail-archive/web/rrg/current/msg04904.html > > > With a "Distance Server", I think LISP, APT, Ivip and TRRP etc. could > do this work very nicely, in a highly scalable fashion. > > This goes beyond conventional anycast and into high reliability and > "disaster recovery" systems, which Bill gave an example of and which > I quote in my RRG message. > > > - Robin > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Thu Apr 23 11:38:18 2009 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 444C228C16D for ; Thu, 23 Apr 2009 11:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piyZ6QmnbWce for ; Thu, 23 Apr 2009 11:38:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 872BE28C166 for ; Thu, 23 Apr 2009 11:38:17 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1C0A415C; Thu, 23 Apr 2009 14:39:33 -0400 (EDT) To: Dino Farinacci References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> From: Sam Hartman Date: Thu, 23 Apr 2009 14:39:33 -0400 In-Reply-To: <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> (Dino Farinacci's message of "Thu\, 23 Apr 2009 10\:46\:56 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 18:38:18 -0000 >>>>> "Dino" == Dino Farinacci writes: Dino> Why not just pick an ETR, watch for return traffic and try Dino> to monitor RTTs between the sites for the data Dino> flow. When would you transition to another etr? So, its sounds like we're discussing anycast here. In that space, the following concerns seem to be worth thinking about: * Some anycast protocols only have one round trip ** balancing across all the possible destinatinos is important ** To the extent that closeness for some closeness metric matters, you need to get there on the first packet * Some anycast protocols care a lot about stability: once you start with one destination you have to keep that destination * TCP anycast is one limit of caring about stability From hartmans@mit.edu Thu Apr 23 11:41:37 2009 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 BFB3528C2CC for ; Thu, 23 Apr 2009 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPU7cs+hqPJw for ; Thu, 23 Apr 2009 11:41:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id A7C9828C220 for ; Thu, 23 Apr 2009 11:41:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A7878415C; Thu, 23 Apr 2009 14:42:51 -0400 (EDT) To: Robin Whittle References: <49F02E91.8050209@firstpr.com.au> From: Sam Hartman Date: Thu, 23 Apr 2009 14:42:51 -0400 In-Reply-To: <49F02E91.8050209@firstpr.com.au> (Robin Whittle's message of "Thu\, 23 Apr 2009 19\:02\:09 +1000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 18:41:37 -0000 Without speaking to whethre having some way to choose a best ETR for the first packet is good or not, putting it in the map resolver seems like the wrong place. At least as I understand things it is a goal that the map resolver be an optimization for people not connected to the alternate topology and thus it should not have capabilities that someone directly connected to the alternate topology. So, it seems like you should either be saying: there is some capability in the alternate topology I'd like to expose through the map resolver. or: There is some capability I'd like to add to the alternate topology and then expose through the resolver. From jmh@joelhalpern.com Thu Apr 23 11:59:17 2009 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 800573A6FDC for ; Thu, 23 Apr 2009 11:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8adh0fi5g1V for ; Thu, 23 Apr 2009 11:59:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A62353A6B4C for ; Thu, 23 Apr 2009 11:59:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 139A0430363 for ; Thu, 23 Apr 2009 12:00:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5976943034A for ; Thu, 23 Apr 2009 12:00:34 -0700 (PDT) Message-ID: <49F0BAC4.8080907@joelhalpern.com> Date: Thu, 23 Apr 2009 15:00:20 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 18:59:17 -0000 There is quite a bit of information available, or ways to gather information, for ETR selection. It is unlikely that a distance server (or an ALTO oracle) is either necessary or particularly useful. If we are going to support anycast, doing so in the "id" space (the domain side of the mapping, instead of the range side of the mapping) does make sense to me. However, I have a concern, related to the comments below about trnasaction. The assumption up till now has been that the device picking the ETR can use any ETR it wants. (Whether the chooser is the ITR or host software or whatever.) And that it can even change that choice during the lifetime of a communication, with no impact on that communication. (That's one of the benefits from the end users perspective.) Anycast mapping entries (IDs, or whatever you want to call them) do not have that mutability property. If you are talking to an entity using one entry mapped from an anycast, you can not expect to be able to continue the conversation with a different mapped entry. It seems to me that having a conceptual entity in the architecture (whether it appears in the protocol(s) on the wire(s) or not is a different question) that represents the thing that you are talking to, with a way to relate that thing to the set of locators you can use interchangably to talk with that, seems a very useful construct. If we want to handle anycast in the mapping, I would like to handle it in such a way (additional indirection?) that it does not obfuscate the notion of which locators for an interchangeable set for a communication session. Yours, Joel M. Halpern Sam Hartman wrote: >>>>>> "Dino" == Dino Farinacci writes: > > Dino> Why not just pick an ETR, watch for return traffic and try > Dino> to monitor RTTs between the sites for the data > Dino> flow. > When would you transition to another etr? > > So, its sounds like we're discussing anycast here. In that space, the following concerns seem to be worth thinking about: > > * Some anycast protocols only have one round trip > ** balancing across all the possible destinatinos is important > ** To the extent that closeness for some closeness metric matters, you need to get there on the first packet > * Some anycast protocols care a lot about stability: once you start with one destination you have to keep that destination > * TCP anycast is one limit of caring about stability > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From swb@employees.org Thu Apr 23 12:27:17 2009 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 33AD63A69E4 for ; Thu, 23 Apr 2009 12:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 Dy0NbFQsLNap for ; Thu, 23 Apr 2009 12:27:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AC8F328C6E9 for ; Thu, 23 Apr 2009 12:26:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="42581271" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2009 19:28:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJS78s028370 for ; Thu, 23 Apr 2009 15:28:07 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJS6P7024508 for ; Thu, 23 Apr 2009 19:28:06 GMT Date: Thu, 23 Apr 2009 15:28:06 -0400 From: Scott Brim To: lisp@ietf.org Message-ID: <20090423192806.GH70118@cisco.com> Mail-Followup-To: Scott Brim , lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:27:17 -0000 Excerpts from Sam Hartman on Thu, Apr 23, 2009 02:39:33PM -0400: > >>>>> "Dino" == Dino Farinacci writes: > > Dino> Why not just pick an ETR, watch for return traffic and try > Dino> to monitor RTTs between the sites for the data > Dino> flow. > When would you transition to another etr? What would the issue be? Packets might get out of sequence but that happens with every routing change and somehow applications do okay. > So, its sounds like we're discussing anycast here. In that space, > the following concerns seem to be worth thinking about: I don't think this has anything to do with anycast. Anycast is about a single address being used by multiple endpoints. This is about a single end prefix reachable via two different intermediate points. It has to do with choosing between alternative routes. If a different ETR is used, that will not change the endpoints that are being communicated with. From dino@cisco.com Thu Apr 23 12:39:44 2009 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 581A328C214 for ; Thu, 23 Apr 2009 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 gT9lDBad9UrM for ; Thu, 23 Apr 2009 12:39:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 414C328C2A2 for ; Thu, 23 Apr 2009 12:39:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="291765353" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Apr 2009 19:41:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJf1Nt031486; Thu, 23 Apr 2009 12:41:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJf1PS025674; Thu, 23 Apr 2009 19:41:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:41:01 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:41:00 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 12:41:00 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 19:41:00.0961 (UTC) FILETIME=[6E57D110:01C9C44B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2922; t=1240515661; x=1241379661; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=20=20to=20support=20scal able=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=1Fw8wxFdPaBwmGU9114YsAR7lIWIefyKKMnoPRajE/8=; b=OjJJjNc69Y69jTNGjsFXibfhRud7LGBVF3PDYmEBWp2vWeRT3u0BlrTAWO dIfXZd9od5TYsIBbi5Fe8Dv679Dk4zrQw5LN1uhy1S6XjuES7hhWpfaWvSWX Gxa4uR0p7kS1qtzL6YDmfDL6hf+4f+jUH2/n0iAvrR1VQx+02nwu8=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:39:44 -0000 >>>>>> "Dino" == Dino Farinacci writes: > > Dino> Why not just pick an ETR, watch for return traffic and try > Dino> to monitor RTTs between the sites for the data > Dino> flow. > When would you transition to another etr? I don't know. It would have to be local policy. But we have had to make these decision in fast-reroute algorithms as well. That is, if it's working and it's not broke, don't touch it. I think you'll find from sites and ISPs alike that what they want with traffic engineering is a smooth usage of all their links. Rather than have hot spots on some links when other links are idle. I really believe we don't have to be perfect and get this right. Best effort is really good enough. > So, its sounds like we're discussing anycast here. In that space, > the following concerns seem to be worth thinking about: Well, anycast RLOCs are interesting because it's like p2p protocols. That is, you just use an address and someone has to be up. So you just use it. Of course, your quality may vary. With LISP, anycast RLOCs can be used by you have to not use the loc- reach-bits. Because once someone says the RLOC is down, you obviously stop using any ETR that is assigned the anycast address. But you do want to switch from an anycast RLOC to another *when the last anycast RLOC goes down*. And sine the anycast ETRs really may not talk to each other (they can in LISP when the ETRs are deployed at the site), this might be more trouble then it is worth. > * Some anycast protocols only have one round trip > ** balancing across all the possible destinatinos is important Yes, and with the increase in the number of flows at a site, that will happen naturally. > ** To the extent that closeness for some closeness metric matters, > you need to get there on the first packet If a destination site has RLOCs in the US and Europe and a LISP source site in Europe sends a map-request to the destination site, the destination site can return a map-reply with the Euro RLOCs with better priority then the US ones. So the Euro LISP site uses only the Euro RLOCs until they go down, in which case, the Euro site switches to the US RLOCs. This is explained in draft-fuller-lisp-alt. > * Some anycast protocols care a lot about stability: once you start > with one destination you have to keep that destination I worked on AMT where anycast is used for discovery, but once you discover the server you latch on to a non-anycast address that you continue to use. This works as well when you use a transport protocol. Because the discovery with anycast addressing is done via packets and then when you get the latched real address (that doesn't move), you open the connection to the latched address. Dino > * TCP anycast is one limit of caring about stability From olivier.bonaventure@uclouvain.be Thu Apr 23 12:40:36 2009 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 3E77A28C6EF for ; Thu, 23 Apr 2009 12:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20D6mPSM2YkJ for ; Thu, 23 Apr 2009 12:40:35 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 844C128C69B for ; Thu, 23 Apr 2009 12:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=42hBzYj5oKL/XbpiY/IsFg2T0p4=; b=e4aHvYtSOF 2z9FRKpfY2phIVXSXFU9ZoQWpr7ZlzJQaXPzG3qLFPJwKtbb745CH73bnFbjc2CC JrNwU5cspZUC+I78WSz6j/8ZHMwRPlNuOiqM9aQ4f/kPxT9pvp+OqtMsbkGd1amq K5tnqXOA0oRlPDYxISWAw4ul7sm66+Ph0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=LvMTs T6Kl05N9woKEnrdaikVmWCOfjp+32cP8cHwg+WC6BkWRbSIJTWHEOL7EEYe9+Mby xW+FhJtRFdInUgOmpTPkP7LeO+2hF3MKK+82QkFTAdDCgLWmFuwsV+4Ose4NYUGi G/6Nv4uFJX9CUR1NrMViFiLczPPQp+960i49jY= Received: from mbpobo.local (ip-83-134-210-112.dsl.scarlet.be [83.134.210.112]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 23 Apr 2009 21:41:49 +0200 (CEST) Message-ID: <49F0C478.4080005@uclouvain.be> Date: Thu, 23 Apr 2009 21:41:44 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dino Farinacci References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> In-Reply-To: <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D5D5AEBFBB.60A4D X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 23 Apr 2009 19:40:36 -0000 Dino, > Why not just pick an ETR, watch for return traffic and try to monitor > RTTs between the sites for the data flow. This is one possibility. Damien and Luigi demonstrated a technique to pick ETRs based on additional information in http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineering-locatoridentifier-separation-context Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From dino@cisco.com Thu Apr 23 12:43:55 2009 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 0139028C723 for ; Thu, 23 Apr 2009 12:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 etCtSbvmlX8I for ; Thu, 23 Apr 2009 12:43:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 67B7228C748 for ; Thu, 23 Apr 2009 12:43:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="291768038" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Apr 2009 19:44:54 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJisVl001289; Thu, 23 Apr 2009 12:44:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJisvr026564; Thu, 23 Apr 2009 19:44:54 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:44:54 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:44:53 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 12:44:52 -0700 References: <49F02E91.8050209@firstpr.com.au> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 19:44:53.0201 (UTC) FILETIME=[F8C4D410:01C9C44B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1464; t=1240515894; x=1241379894; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=20to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=Yp6vC71GPWFSjxh2eHyG43zqKjxqv7lPRYJvsoyY3Rk=; b=fmG6p8hi/WtYXh6iQXHSv3HtgWxNqBk49Zz38c3Or9+qlrPKsaMdouC9BM aYY28HQUY7+VJWWNmq4hEaZkMHKHPWmEi5zcK0L05VQ4IRS7t6CQWlzXDyrH 5cTwrXSCQW; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:43:55 -0000 > Without speaking to whethre having some way to choose a best ETR for > the first packet is good or not, putting it in the map resolver seems From a LISP perspective, the best ETR is determined by the site and not by the cacher who sends packet to the site. And like I said in the previous email, the ETRs at the site can decide how to map-reply. Remember, it's the site that pays for it's links. It should be the final decision maker on how packets arrive on those links. > like the wrong place. At least as I understand things it is a goal > that the map resolver be an optimization for people not connected to > the alternate topology and thus it should not have capabilities that > someone directly connected to the alternate topology. It is more than an optimization, it will be the rule so we can deliver the ultimate in low opex multi-homing to stub sites. > So, it seems like you should either be saying: there is some > capability in the alternate topology I'd like to expose through the > map resolver. The ALT just moves bits. And those bits are Map-Requests which are addressed to EIDs. That is the service it provides. And since it uses BGP, you can use all your BGP policy and security tools being developed for the underlying BGP infrastructure. > or: There is some capability I'd like to add to the alternate topology > and then expose through the resolver. I would say probably not. Dino From olivier.bonaventure@uclouvain.be Thu Apr 23 12:44:03 2009 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 150DD28C70B for ; Thu, 23 Apr 2009 12:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 U1cVF0H45N9s for ; Thu, 23 Apr 2009 12:44:01 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 937A328C72E for ; Thu, 23 Apr 2009 12:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=2CMVoSYh4oMSDlHcPiWBNl6MJXg=; b=mayCNyZsnF dHasmURGaFArGQpbUDx9ph1z/5dgMy573fsauGUiU/rXLYCbhY0z5BgvjE5uTxaF MMYBr62LvXIiixSnIey34avGAXcocLumAGRggX6EacwVczfJ1SdFEWxEPddfm6Vw 2DzAqk379qWJU+iD0SaTaGU1cRcCX+Om8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=S/Htb qLPTh7aMKOkBpXzoAgBYWQlMZy1DM91JKRlDxRLo5WfCfK8hOC4MmDrTikdK8JoS RV19Q/Lk79nX1T1VfcawOamcqcws2MvUN5dwSKH46lwud3YLTdY1cmsghDUKPPYx YTKib7JSvqWd4Z/x1HMGhtF6pf8BRo3T4jelrI= Received: from mbpobo.local (ip-83-134-210-112.dsl.scarlet.be [83.134.210.112]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 23 Apr 2009 21:45:06 +0200 (CEST) Message-ID: <49F0C540.5060003@uclouvain.be> Date: Thu, 23 Apr 2009 21:45:04 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Hartman References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 00BF51C9198.84F25 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 23 Apr 2009 19:44:03 -0000 Sam, >>>>>> "Dino" == Dino Farinacci writes: > > Dino> Why not just pick an ETR, watch for return traffic and try > Dino> to monitor RTTs between the sites for the data > Dino> flow. > When would you transition to another etr? > > So, its sounds like we're discussing anycast here. I don't think so. With LISP, one EID can be reached via several ETRs and thus via different paths, but they all end at the same host for a given EID. >In that space, the following concerns seem to be worth thinking about: > > * Some anycast protocols only have one round trip > ** balancing across all the possible destinatinos is important > ** To the extent that closeness for some closeness metric matters, you need to get there on the first packet > * Some anycast protocols care a lot about stability: once you start with one destination you have to keep that destination > * TCP anycast is one limit of caring about stability Stability issues are likely to apply to LISP as well. Once an ITR has started to use a given ETR to forward flows towards a given EID, it should continue using this ETR for some time and not switch frequently from one ETR to another for a given (Src EID - DST EID - port) flow. It may of course load balance flows towards different ETRs. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From dino@cisco.com Thu Apr 23 12:45:28 2009 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 9A4513A6E41 for ; Thu, 23 Apr 2009 12:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Ke00wiJikfZl for ; Thu, 23 Apr 2009 12:45:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E17AD3A68F6 for ; Thu, 23 Apr 2009 12:45:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="176001564" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2009 19:46:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJkkAI022086; Thu, 23 Apr 2009 12:46:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJkkv3028906; Thu, 23 Apr 2009 19:46:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:46:45 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:46:45 -0700 Message-Id: <772C7253-A6DD-4DD9-A747-27B3703BDD49@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <49F0BAC4.8080907@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 12:46:45 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 19:46:45.0419 (UTC) FILETIME=[3BA7EFB0:01C9C44C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=276; t=1240516006; x=1241380006; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=20to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=e8y7XYdb4LGoSIis1J/eYaJ68bJNjM9S0ZujBnggAkM=; b=r4ZLel6AwycXrHZhrLlQ9yS45YclriL6CL3szCjKP8/2Zxw9SHY9HhBfiI D/OupRS1Fcphc3zjGWuIlc7h8DT4ZYGzNouVxj/sfZFoXZ3ytW/Bqr1/usqE JN6vFzSHCp; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:45:28 -0000 > If we want to handle anycast in the mapping, I would like to handle > it in such a way (additional indirection?) that it does not > obfuscate the notion of which locators for an interchangeable set > for a communication session. Really good point Joel. Dino From dino@cisco.com Thu Apr 23 12:47:01 2009 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 EB5733A6FEE for ; Thu, 23 Apr 2009 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 E56YA1MFtWw5 for ; Thu, 23 Apr 2009 12:47:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 08F9E3A6FD4 for ; Thu, 23 Apr 2009 12:47:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="158301039" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Apr 2009 19:48:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJmJDM013409; Thu, 23 Apr 2009 12:48:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJmJpb000645; Thu, 23 Apr 2009 19:48:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:48:19 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:48:18 -0700 Message-Id: <7E1F5069-6A50-44C2-9575-05F8578F759F@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49F0C540.5060003@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 12:48:18 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0C540.5060003@uclouvain.be> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 19:48:18.0757 (UTC) FILETIME=[734A2F50:01C9C44C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=376; t=1240516099; x=1241380099; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=09to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=4WcOZ7LagJF5tNKIEdBru2BKvbMLGlQNxruh7AlS8Co=; b=Eld+M3JJfLEuvi3SvUgGh9cODBrSq7U3hg9wVv5vQCR4KHQNWmG7WRLY20 8VCajB6lhRJvyGuZ5Vev7Sc+SFtufK2jQtSDDOG3EjczhineXDawCz0KD4jW DHdG7QjvHb; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:47:02 -0000 > Stability issues are likely to apply to LISP as well. Once an ITR has > started to use a given ETR to forward flows towards a given EID, it > should continue using this ETR for some time and not switch frequently > from one ETR to another for a given (Src EID - DST EID - port) flow. > It may of course load balance flows towards different ETRs. 100% agree. Dino From dino@cisco.com Thu Apr 23 12:50:54 2009 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 7377F3A6BA5 for ; Thu, 23 Apr 2009 12:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 SLGWr+aaRFiY for ; Thu, 23 Apr 2009 12:50:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 42F183A68F6 for ; Thu, 23 Apr 2009 12:50:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="176004947" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2009 19:52:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3NJq78X017734; Thu, 23 Apr 2009 12:52:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3NJq76m023015; Thu, 23 Apr 2009 19:52:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:52:07 -0700 Received: from [192.168.1.2] ([10.21.68.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:52:06 -0700 Message-Id: <782B6E51-F985-4D40-8934-D53D4C03D600@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <49F0C478.4080005@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 12:52:06 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0C478.4080005@uclouvain.be> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 19:52:06.0823 (UTC) FILETIME=[FB3A4B70:01C9C44C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1065; t=1240516327; x=1241380327; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=09to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=3WMpLw2pHxJEk86l7dM2JrL3IkTaAItCxt2TpNU0agg=; b=ZJDZxTBIGFJjo5m6/SeejHrzrEWotnlCZ8IOeCi6it0HH8ngrLVeKYM3iZ BqwkThByO9zEKQXDbY4/VkwbBP1WpGqWvwTlJ98G800+u9jQNWj6oliYJ5qd 1Y/jOJNwoK; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 19:50:54 -0000 Yes, I have read it. A find paper. I think there is potential for it but the Path Selection Mechanism needs to reside at the site. No one will allow a third party to decide how it's links should be used. But if there is a box, which can be co-located with the xTRs that want to change the ranking, they could either start advertising them in Map- Replies or advertise those rankings to the map-server via Map-Register messages. But at this point, we are not committing to having the map-server be a *proxy* map-replier for the site. Dino On Apr 23, 2009, at 12:41 PM, Olivier Bonaventure wrote: > Dino, > >> Why not just pick an ETR, watch for return traffic and try to monitor >> RTTs between the sites for the data flow. > > This is one possibility. Damien and Luigi demonstrated a technique to > pick ETRs based on additional information in > http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineering-locatoridentifier-separation-context > > Olivier > -- > http://inl.info.ucl.ac.be , UCLouvain, Belgium From jari.arkko@piuha.net Thu Apr 23 13:12:42 2009 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 F2E023A6E3F for ; Thu, 23 Apr 2009 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Ms5rcsnipy for ; Thu, 23 Apr 2009 13:12:41 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7ECBF28C2FC for ; Thu, 23 Apr 2009 13:11:47 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1F14B198718 for ; Thu, 23 Apr 2009 23:13:05 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B29EC198665 for ; Thu, 23 Apr 2009 23:13:04 +0300 (EEST) Message-ID: <49F0CBBC.1020807@piuha.net> Date: Thu, 23 Apr 2009 23:12:44 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [lisp] WG status 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: Thu, 23 Apr 2009 20:12:42 -0000 The IESG had a call today and approved the charter as it is below. The official announcement comes out early next week. I realize that there were a few people who were unhappy with the charter but I think in the end we have rough consensus to move forward. I looked at the discussion, we got a few alternative proposals but after some thinking I did not see a reason to deviate from the charter that the chairs had came up with. There were small editorial changes to the charter: garbled text about the IAB workshop, removing the dangling reference the RLOC term later in the text, deletion of the word "other" from the sentence that describes parallel work in the IRTF and IETF [I didn't want to create an impression that only the other approaches are at an early stage], and changed IPV4 to IPv4 [same for IPv6]. So its time to get to the technical work, full steam ahead! Please remember that the success of this WG depends primarily on what you learn from discussions between different people in the group and from testing Lisp, not so much on pushing out RFCs at the earliest possible date. Take time to go through everything so that we actually understand the technology and its implications. Jari Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-04-23 Current status: Working Group Chair(s): Sam Hartman Darrel Lewis Internet Area Director(s): Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. From swb@employees.org Thu Apr 23 13:22:50 2009 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 5DECD3A72E2 for ; Thu, 23 Apr 2009 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1XLkjfwRVj3 for ; Thu, 23 Apr 2009 13:22:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7B9673A72E0 for ; Thu, 23 Apr 2009 13:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,236,1238976000"; d="scan'208";a="42513337" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2009 20:24:07 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NKO74h020864 for ; Thu, 23 Apr 2009 16:24:07 -0400 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NKO9Ig012139 for ; Thu, 23 Apr 2009 20:24:10 GMT Date: Thu, 23 Apr 2009 16:24:01 -0400 From: Scott Brim To: lisp@ietf.org Message-ID: <20090423202401.GK70118@cisco.com> Mail-Followup-To: Scott Brim , lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F0BAC4.8080907@joelhalpern.com> User-Agent: Mutt/1.5.19 (2009-01-05) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 20:22:50 -0000 Excerpts from Joel M. Halpern on Thu, Apr 23, 2009 03:00:20PM -0400: > Anycast mapping entries (IDs, or whatever you want to call them) do > not have that mutability property. If you are talking to an entity > using one entry mapped from an anycast, you can not expect to be > able to continue the conversation with a different mapped entry. LISP is encapsulation not tunnels. If RLOCs are anycast addresses, then once a packet leaves an ITR, the packet is forwarded based on how intermediate routers reach that anycast address. The ITR doesn't control switching between ETRs if it's given an anycast RLOC to send to. From hartmans@mit.edu Thu Apr 23 13:38:46 2009 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 3BA1D3A69E4 for ; Thu, 23 Apr 2009 13:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-bg77YqNZZH for ; Thu, 23 Apr 2009 13:38:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 7BAD73A69D3 for ; Thu, 23 Apr 2009 13:38:45 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B6644415B; Thu, 23 Apr 2009 16:27:40 -0400 (EDT) To: Olivier.Bonaventure@uclouvain.be References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0C540.5060003@uclouvain.be> From: Sam Hartman Date: Thu, 23 Apr 2009 16:27:40 -0400 In-Reply-To: <49F0C540.5060003@uclouvain.be> (Olivier Bonaventure's message of "Thu\, 23 Apr 2009 21\:45\:04 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 20:38:46 -0000 >>>>> "Olivier" == Olivier Bonaventure writes: >> So, its sounds like we're discussing anycast here. Olivier> I don't think so. With LISP, one EID can be reached via Olivier> several ETRs and thus via different paths, but they all Olivier> end at the same host for a given EID. While that's all true, I thought I read in Robin's original message that he was talking about scalable anycast over lisp. I do agree that stability applies to situations outside of anycast. I think it is more critical in some anycast situations than in non-anycast, but obviously there are reasons to. From hartmans@mit.edu Thu Apr 23 13:43:44 2009 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 952AA3A6B2D for ; Thu, 23 Apr 2009 13:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z-tTta+neU5 for ; Thu, 23 Apr 2009 13:43:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id E38493A6A25 for ; Thu, 23 Apr 2009 13:43:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 23B42415F; Thu, 23 Apr 2009 16:39:36 -0400 (EDT) To: Jari Arkko References: <49F0CBBC.1020807@piuha.net> From: Sam Hartman Date: Thu, 23 Apr 2009 16:39:36 -0400 In-Reply-To: <49F0CBBC.1020807@piuha.net> (Jari Arkko's message of "Thu\, 23 Apr 2009 23\:12\:44 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] WG status 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: Thu, 23 Apr 2009 20:43:44 -0000 Thanks Jari for all your work on this! I'm looking forward to our progress as an official activity of the IETF! From hartmans@mit.edu Thu Apr 23 13:48:44 2009 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 65F073A684B for ; Thu, 23 Apr 2009 13:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+osWBCYMOHy for ; Thu, 23 Apr 2009 13:48:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id A3CD03A6833 for ; Thu, 23 Apr 2009 13:48:43 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A1B26415D; Thu, 23 Apr 2009 16:34:54 -0400 (EDT) To: Dino Farinacci References: <49F02E91.8050209@firstpr.com.au> From: Sam Hartman Date: Thu, 23 Apr 2009 16:34:54 -0400 In-Reply-To: (Dino Farinacci's message of "Thu\, 23 Apr 2009 12\:44\:52 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 20:48:44 -0000 >>>>> "Dino" == Dino Farinacci writes: >> Without speaking to whethre having some way to choose a best >> ETR for the first packet is good or not, putting it in the map >> resolver seems Dino> From a LISP perspective, the best ETR is determined by the Dino> site and not by the cacher who sends packet to the site. And Dino> like I said in the previous email, the ETRs at the site can Dino> decide how to map-reply. Do you agree that Robin was proposing changing this in the case of map resolvers? If not, do you understand what he was proposing? >> like the wrong place. At least as I understand things it is a >> goal that the map resolver be an optimization for people not >> connected to the alternate topology and thus it should not have >> capabilities that someone directly connected to the alternate >> topology. Dino> It is more than an optimization, it will be the rule so we Dino> can deliver the ultimate in low opex multi-homing to stub Dino> sites. That sounds like an optimization to me. A critical optimization, used by most sites, but do you agree with my point that we don't expect additional capibilities to be present in the mapping resolver not present in the alternate mapping system. >> So, it seems like you should either be saying: there is some >> capability in the alternate topology I'd like to expose through >> the map resolver. Dino> The ALT just moves bits. And those bits are Map-Requests Dino> which are addressed to EIDs. That is the service it Dino> provides. And since it uses BGP, you can use all your BGP Dino> policy and security tools being developed for the underlying Dino> BGP infrastructure. I agree with your statement, but do not understand how it is responsive to mine. From dino@cisco.com Thu Apr 23 15:34:39 2009 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 BFA5B28C306 for ; Thu, 23 Apr 2009 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 anuuRPHaQbFZ for ; Thu, 23 Apr 2009 15:34:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 023BF28C703 for ; Thu, 23 Apr 2009 15:33:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,237,1238976000"; d="scan'208";a="176091635" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2009 22:34:26 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3NMYQT4010558; Thu, 23 Apr 2009 15:34:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3NMYQim004068; Thu, 23 Apr 2009 22:34:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 15:34:26 -0700 Received: from dhcp-171-71-55-200.cisco.com ([171.71.55.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 15:34:25 -0700 Message-Id: From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Thu, 23 Apr 2009 15:34:24 -0700 References: <49F02E91.8050209@firstpr.com.au> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 23 Apr 2009 22:34:25.0964 (UTC) FILETIME=[A83546C0:01C9C463] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2372; t=1240526066; x=1241390066; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Adding=20a=20=22Distance=20Ser ver=22=20to=20the=20Map=20Resolver,=20to=20support=20scalabl e=20=22anycast=22=20and=20=22disaster=20recovery=22 |Sender:=20; bh=HOlau0GqdJq5A+nGx1hM12cAFcKUbr68ZcpUh8Dk2Ic=; b=JNkihaNzZVlAWTAMP2q3zoj6IhlWhv7AlqMOAJwPLTphQXEEQpoRtOZiV4 I6nJeILUi7ZFj8J6ghecK2rf1+rVq6nymE1dLAqhCp/nJqNs4sSVIUxyA28s nt3FKm1jws; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Robin Whittle , lisp@ietf.org Subject: Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery" 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: Thu, 23 Apr 2009 22:34:39 -0000 >>>> >>>> "Dino" == Dino Farinacci writes: > >>> Without speaking to whethre having some way to choose a best >>> ETR for the first packet is good or not, putting it in the map >>> resolver seems > > Dino> From a LISP perspective, the best ETR is determined by the > Dino> site and not by the cacher who sends packet to the site. And > Dino> like I said in the previous email, the ETRs at the site can > Dino> decide how to map-reply. > > Do you agree that Robin was proposing changing this in the case of map > resolvers? If not, do you understand what he was proposing? I do not understand what he is proposing. >>> like the wrong place. At least as I understand things it is a >>> goal that the map resolver be an optimization for people not >>> connected to the alternate topology and thus it should not have >>> capabilities that someone directly connected to the alternate >>> topology. > > Dino> It is more than an optimization, it will be the rule so we > Dino> can deliver the ultimate in low opex multi-homing to stub > Dino> sites. > > That sounds like an optimization to me. A critical optimization, used > by most sites, but do you agree with my point that we don't expect > additional capibilities to be present in the mapping resolver not > present in the alternate mapping system. Is using /etc/hosts the DNS and using name-resolvers and name-servers an optimization? I think this is the analogue. >>> So, it seems like you should either be saying: there is some >>> capability in the alternate topology I'd like to expose through >>> the map resolver. > > Dino> The ALT just moves bits. And those bits are Map-Requests > Dino> which are addressed to EIDs. That is the service it > Dino> provides. And since it uses BGP, you can use all your BGP > Dino> policy and security tools being developed for the underlying > Dino> BGP infrastructure. > > I agree with your statement, but do not understand how it is > responsive to mine. I'm saying you don't want to add more capability to the ALT. Because it has this benefit of being generic enough to use existing equipment from any host or router vendor. If you had say, ".. there is some capability of the mapping system I'd like to expose ..." then I wouldn't have responded. Dino From dmm@1-4-5.net Thu Apr 23 17:23:11 2009 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 6C87C3A63EC for ; Thu, 23 Apr 2009 17:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLLX5rdGV2dj for ; Thu, 23 Apr 2009 17:23:10 -0700 (PDT) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B627E3A6860 for ; Thu, 23 Apr 2009 17:22:09 -0700 (PDT) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n3O0NMsp008907; Thu, 23 Apr 2009 17:23:22 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n3O0NLGx008906; Thu, 23 Apr 2009 17:23:21 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 23 Apr 2009 17:23:21 -0700 From: David Meyer To: Jari Arkko Message-ID: <20090424002321.GA8883@1-4-5.net> References: <49F0CBBC.1020807@piuha.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <49F0CBBC.1020807@piuha.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] WG status 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: Fri, 24 Apr 2009 00:23:11 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 23, 2009 at 11:12:44PM +0300, Jari Arkko wrote: > The IESG had a call today and approved the charter as it is below. The = =20 > official announcement comes out early next week. Thanks for all your hard work on this Jari. Its much appreciated. Dave --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknxBnkACgkQORgD1qCZ2KeakACcC9PnfbFvE5qz6667q7liBOsq GOcAn0P1W5BE++sNXMGJOXyfDU2ORDjN =BZE5 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From hartmans@mit.edu Fri Apr 24 08:04:42 2009 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 88EB73A6931 for ; Fri, 24 Apr 2009 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RFJ8YITwdSl for ; Fri, 24 Apr 2009 08:04:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C38293A680C for ; Fri, 24 Apr 2009 08:04:41 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E476415C; Fri, 24 Apr 2009 11:05:58 -0400 (EDT) To: Scott Brim References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> From: Sam Hartman Date: Fri, 24 Apr 2009 11:05:58 -0400 In-Reply-To: <20090423202401.GK70118@cisco.com> (Scott Brim's message of "Thu\, 23 Apr 2009 16\:24\:01 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: [lisp] Anycast 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: Fri, 24 Apr 2009 15:04:42 -0000 >>>>> "Scott" == Scott Brim writes: Scott> Excerpts from Joel M. Halpern on Thu, Apr 23, 2009 Scott> 03:00:20PM -0400: >> Anycast mapping entries (IDs, or whatever you want to call >> them) do not have that mutability property. If you are talking >> to an entity using one entry mapped from an anycast, you can >> not expect to be able to continue the conversation with a >> different mapped entry. Scott> LISP is encapsulation not tunnels. If RLOCs are anycast Scott> addresses, then once a packet leaves an ITR, the packet is Scott> forwarded based on how intermediate routers reach that Scott> anycast address. The ITR doesn't control switching between Scott> ETRs if it's given an anycast RLOC to send to. Joel, and I think Robin were talking about EID anycast, not RLOC anycast. I'll admit that I'm not really seeing the point in the result of the mapping being an anycast address, although I agree that if that happens, it should behave as you describe. However I'm fairly sure that Joel made it clear he was talking about providing anycast service using LISP. In that case, the EID would be an anycast address, and the RLOC would reach one instance of that service. Currently, I think the only person who may be proposing working on this is Robin; and I may be misreading even his message. From jmh@joelhalpern.com Fri Apr 24 08:38:21 2009 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 63D303A6B0A for ; Fri, 24 Apr 2009 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F94GlpxNXgNm for ; Fri, 24 Apr 2009 08:38:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9307B3A6AFE for ; Fri, 24 Apr 2009 08:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 83D424304C5 for ; Fri, 24 Apr 2009 08:39:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id D8D1D4304A8 for ; Fri, 24 Apr 2009 08:39:38 -0700 (PDT) Message-ID: <49F1DD38.4050801@joelhalpern.com> Date: Fri, 24 Apr 2009 11:39:36 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Anycast 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: Fri, 24 Apr 2009 15:38:21 -0000 Just to confirm, I do not think this is a topic that the LISP WG needs to spend any energy on. Joel Sam Hartman wrote: >>>>>> "Scott" == Scott Brim writes: > > Scott> Excerpts from Joel M. Halpern on Thu, Apr 23, 2009 > Scott> 03:00:20PM -0400: > >> Anycast mapping entries (IDs, or whatever you want to call > >> them) do not have that mutability property. If you are talking > >> to an entity using one entry mapped from an anycast, you can > >> not expect to be able to continue the conversation with a > >> different mapped entry. > > Scott> LISP is encapsulation not tunnels. If RLOCs are anycast > Scott> addresses, then once a packet leaves an ITR, the packet is > Scott> forwarded based on how intermediate routers reach that > Scott> anycast address. The ITR doesn't control switching between > Scott> ETRs if it's given an anycast RLOC to send to. > > Joel, and I think Robin were talking about EID anycast, not RLOC > anycast. I'll admit that I'm not really seeing the point in the > result of the mapping being an anycast address, although I agree that > if that happens, it should behave as you describe. However I'm fairly > sure that Joel made it clear he was talking about providing anycast > service using LISP. In that case, the EID would be an anycast > address, and the RLOC would reach one instance of that service. > > Currently, I think the only person who may be proposing working on > this is Robin; and I may be misreading even his message. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Fri Apr 24 10:07:17 2009 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 E82003A6B8F for ; Fri, 24 Apr 2009 10:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 3m3DG19QZTsi for ; Fri, 24 Apr 2009 10:07:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 16BA928C1B7 for ; Fri, 24 Apr 2009 10:06:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="292381435" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2009 17:07:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3OH7Jft001507; Fri, 24 Apr 2009 10:07:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OH7I2K022490; Fri, 24 Apr 2009 17:07:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:07:18 -0700 Received: from [192.168.1.2] ([10.21.69.37]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:07:18 -0700 Message-Id: <1A330739-5F0E-4EBB-A68E-0B3AEA6E6B8A@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Fri, 24 Apr 2009 10:07:17 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 24 Apr 2009 17:07:18.0291 (UTC) FILETIME=[1F9DCE30:01C9C4FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1953; t=1240592839; x=1241456839; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Anycast |Sender:=20; bh=0u5CH97YnYrDMLlVLRGKj8mBkICW5BMQ/Suw5SkMGKs=; b=FQNh7Dz+8/JhJcwljrO1hGzd9/AR0o6Ac3+yB3DvQvKybMaFquvrnNzQJQ 9sq9ajtS6UL8Or6r3fd9O6bWVOSq1ajNnhqRsUnegcCvo7Jc5tUT0lbGXWA9 yNFJEZNSSo; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Anycast 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: Fri, 24 Apr 2009 17:07:18 -0000 > Scott> LISP is encapsulation not tunnels. If RLOCs are anycast > Scott> addresses, then once a packet leaves an ITR, the packet is > Scott> forwarded based on how intermediate routers reach that > Scott> anycast address. The ITR doesn't control switching between > Scott> ETRs if it's given an anycast RLOC to send to. > > Joel, and I think Robin were talking about EID anycast, not RLOC Right, well my opinion about an EID being used as an anycast address basically has the same usage it does today. But with LISP the scope is within a site that assigns EIDs out of the EID-prefix it owns. > anycast. I'll admit that I'm not really seeing the point in the > result of the mapping being an anycast address, although I agree that Well, there is an important point. You don't have to worry about RLOC liveness when you have anycast. You just pray and send packets and they will get to the destination site through one of the anycast ETRs. And if any of them go down or become unreachable, the core will reroute without any involvement from the ITRs. > if that happens, it should behave as you describe. However I'm fairly > sure that Joel made it clear he was talking about providing anycast > service using LISP. In that case, the EID would be an anycast > address, and the RLOC would reach one instance of that service. There actually should be one more level of indirection. The EID indeed describes a service, but the EID comes out of an EID-prefix, and the RLOCs are associated with the EID-prefix. Having said that, the EID-prefix could be a /32 or /128, but need to be extremely careful here that the mapping database doesn't become flat with host based entries. > Currently, I think the only person who may be proposing working on > this is Robin; and I may be misreading even his message. Understand. We will wait for a Robin reply for clarification. Dino From dino@cisco.com Fri Apr 24 10:07:18 2009 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 025F93A6BFE for ; Fri, 24 Apr 2009 10:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 wpyv5aVQ3yFR for ; Fri, 24 Apr 2009 10:07:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A85FE3A6FF3 for ; Fri, 24 Apr 2009 10:06:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="73212705" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2009 17:07:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OH7WDw032153; Fri, 24 Apr 2009 10:07:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3OH7WtZ022728; Fri, 24 Apr 2009 17:07:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:07:32 -0700 Received: from [192.168.1.2] ([10.21.69.37]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:07:32 -0700 Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <49F1DD38.4050801@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Fri, 24 Apr 2009 10:07:31 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 24 Apr 2009 17:07:32.0291 (UTC) FILETIME=[27F60930:01C9C4FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1946; t=1240592852; x=1241456852; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Anycast |Sender:=20; bh=WAryzvVmOIsCPnWGnvuctgPtYdFWAB2icLadGJ0yk/c=; b=P1/1UkwBKZXlqMVDuKEn8zmBMVZGUZPkkdrhKbuWDCOU/WaDWU+8Ci/o7U UktE7oytf4Ud5JqeLbmenr4+VvgEQzDlaYAOLyKtVkzo819n16WGs/+cr5tE LOh8wC5L/Z; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Anycast 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: Fri, 24 Apr 2009 17:07:18 -0000 I'll second that. Dino On Apr 24, 2009, at 8:39 AM, Joel M. Halpern wrote: > Just to confirm, I do not think this is a topic that the LISP WG > needs to spend any energy on. > Joel > > Sam Hartman wrote: >>>>>>> "Scott" == Scott Brim writes: >> Scott> Excerpts from Joel M. Halpern on Thu, Apr 23, 2009 >> Scott> 03:00:20PM -0400: >> >> Anycast mapping entries (IDs, or whatever you want to call >> >> them) do not have that mutability property. If you are talking >> >> to an entity using one entry mapped from an anycast, you can >> >> not expect to be able to continue the conversation with a >> >> different mapped entry. >> Scott> LISP is encapsulation not tunnels. If RLOCs are anycast >> Scott> addresses, then once a packet leaves an ITR, the packet is >> Scott> forwarded based on how intermediate routers reach that >> Scott> anycast address. The ITR doesn't control switching between >> Scott> ETRs if it's given an anycast RLOC to send to. >> Joel, and I think Robin were talking about EID anycast, not RLOC >> anycast. I'll admit that I'm not really seeing the point in the >> result of the mapping being an anycast address, although I agree that >> if that happens, it should behave as you describe. However I'm >> fairly >> sure that Joel made it clear he was talking about providing anycast >> service using LISP. In that case, the EID would be an anycast >> address, and the RLOC would reach one instance of that service. >> Currently, I think the only person who may be proposing working on >> this is Robin; and I may be misreading even his message. >> _______________________________________________ >> 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 Fred.L.Templin@boeing.com Fri Apr 24 15:18:17 2009 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 05A1D3A69E2 for ; Fri, 24 Apr 2009 15:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 VwA7Q-cpUwJb for ; Fri, 24 Apr 2009 15:18:16 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 3A8F63A68DE for ; Fri, 24 Apr 2009 15:18:16 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3OMJQ4k026811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Apr 2009 15:19:27 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3OMJQAj017701 for ; Fri, 24 Apr 2009 15:19:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3OMJQgC017698 for ; Fri, 24 Apr 2009 15:19:26 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 15:19:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 15:19:17 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP errors Thread-Index: AcnFCpDazbIvK8enRJWbeuJFqm/t3QAGDV9A References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 24 Apr 2009 22:19:16.0901 (UTC) FILETIME=[B4C70550:01C9C52A] Subject: [lisp] LISP errors 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: Fri, 24 Apr 2009 22:18:17 -0000 In addition to errors that may occur along the path from the ITE to the ETE *before* decapsulation and errors that may occur along the path from the ETE to the final destination *after* decapsulation, errors may also occur *during* decapsulation. An example is what if the ETR decapsulates the outer IP header, but the inner IP stack is not configured? (Answer is that the ITR should receive an error by which it can ascertain that this ETR is having trouble, and should start using a different ETR instead.) This gives rise to a type of error message that is neither fish nor fowl, i.e., it is neither an RLOC-based nor an EID-based ICMP error - it is a *LISP* error instead. One approach is to have the ETR send such a LISP error back to the ITR with enough identifying credentials such that the ITR can be reasonably sure the message is authentic. The message should further not be dropped by packet filters on the path from the ETR to the ITR that filter "naked" ICMP messages. Such LISP errors would need to be identified by a bit in the LISP header (call it the 'E' bit) preferably adjacent to the existing 'S' bit. The ETR sets the 'E' bit to tell the ITR that this LISP packet contains an error, and not an IPv4 nor IPv6 packet. The error could be formatted as per an ICMPv4 or ICMPv6 error, but it need not be so. For example, the packet could be constructed as: +-----------------+ | Outer IP header | +-----------------+ | UDP header | +-----------------+ | LISP hdr (E=3D1) | +-----------------+ | ICMP header (?) | +-----------------+ | | ~ Packet-in-error ~ ~(up to 512 bytes)~ | | +-----------------+ Again, this would be the ETR's way of telling the ITR that it is having trouble and perhaps a different ETR should be chosen. An exception would be a "packet too big" error, in which the ITR would simply adjust its packet sizes as long as the MTU reported by the ETR is of a reasonable size. As with any network-based error message feedback, this is susceptible to on-path attacks. It is resilient against off-path attacks, however. Comments? Fred fred.l.templin@boeing.com From rw@firstpr.com.au Sat Apr 25 05:07:26 2009 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 E26D33A6A33 for ; Sat, 25 Apr 2009 05:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhbbQQwwancQ for ; Sat, 25 Apr 2009 05:07:25 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 165673A6A19 for ; Sat, 25 Apr 2009 05:07:23 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 2D67B175A64; Sat, 25 Apr 2009 22:08:42 +1000 (EST) Message-ID: <49F2FCD5.1040301@firstpr.com.au> Date: Sat, 25 Apr 2009 22:06:45 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <1A330739-5F0E-4EBB-A68E-0B3AEA6E6B8A@cisco.com> In-Reply-To: <1A330739-5F0E-4EBB-A68E-0B3AEA6E6B8A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Anycast - not really, standby for more on "nearcast" 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: Sat, 25 Apr 2009 12:07:27 -0000 Short version: I am working on a better description of the uses of the "distance server" idea I proposes. I will call this system "nearcast". In the future I will write this up on the Ivip site. For now, I am writing about it to the LISP and RRG lists, because it seems to be novel and useful - and because I think it can be applied just as well to LISP, APT and TRRP as to Ivip. (Actually, I have to change Ivip significantly to do it - the changes to LISP etc. would be less.) I think this "nearcast" approach has many of the benefits of conventional BGP-based anycast, but it will be entirely scalable as part of LISP etc. Conventional BGP-anycast is highly unscalable: one DFZ prefix must be devoted to each set of anycast servers. LISP, APT, Ivip etc, could be made to do much the same job as conventional BGP-based anycast, by anycasting the ETRs. However this cannot be done in a scalable fashion. It would be just as unscalable as conventional BGP-based anycast, and be more complex - with no obvious benefits. Each set of anycast servers would still need a route in the DFZ. The "nearcast" system I am working on would have significant advantages, in addition to being scalable, compared to conventional BGP-based anycast. I think the most important novel function would be, its much greater suitability for session-based protocols. Hi Sam and Dino, This "nearcast" "Distance Server" system addition to LISP or other core-edge separation schemes should function as a scalable replacement for conventional BGP-based anycast. However, it would not have precisely the same functionality. In many scenarios its functionality would probably be just as good as conventional BGP-based anycast. However, I think it would be also much more suitable for the session-based protocols which are generally not used for conventional BGP-based anycast. I will write more about this in a forthcoming message on the RRG list. I am going to use the term "nearcast" for this system, since it looks useful and since it is different from anycast and unicast. >> Currently, I think the only person who may be proposing working on >> this is Robin; and I may be misreading even his message. > > Understand. We will wait for a Robin reply for clarification. I wouldn't "propose" the LISP team embark on any work or addition to LISP, since I am not part of the team. I try to contribute to the development of LISP project by way of constructive critiques and by suggesting new ideas which I think would improve LISP. I just thought of this a day ago and as far as I know it is novel and would be useful in some important and unique ways. Amongst other things, it would be a way that with a single EID address, an end-user network could field multiple servers around the world - with full support for routing scalability. Neither the current BGP-based anycast technique, or its functional equivalent in LISP etc.(anycast ETRs) is scalable. Both are *less* scalable than ordinary PI prefixes for end-user networks since in both cases, a complete DFZ prefix needs to be dedicated to each set of anycast servers. There are many potential purposes for the "nearcasting" system I am working on. One of these is providing different DNS responses to requesters from topologically separate parts of the Net. I understand this is currently done via a different technique, loosely called "geo-DNS": matching the requesting IP address against some kind of database to determine the country of origin. I think there are paid-for services for such maps, but a free one is http://countries.nerd.dk/more.html . This is a tricky business, to say the least - because it requires a constantly updated database as the usage of 0.25M DFZ prefixes change. Another approach is pgeodns, a perl script which is used by ntp.org at least to enable a DNS server to respond according to the approximate "location" (topological? geographical?) of the requester. Both these and I guess any other approaches to geo-DNS are going to work less and less once a core-edge separation scheme is operational, assuming more and more requesters to the geo-DNS equipped server come from EID addresses. There will be little or no direct relationship between an EID address and geographical or topological location, since one of the purposes of a scalable routing solution is to enable these EID addresses to be portable and used with any ISP, irrespective of location. So it seems that LISP or any other core-edge separation scheme is incompatible with geo-DNS. Unless we provide an alternative, this would be a reason for people to argue against the adoption of LISP etc. If we can provide a better alternative, to geo-DNS and to conventional BGP-based anycast, or for other uses of "anycast"-like techniques, then this would be a reason people would want to adopt LISP or whatever. I think the "distance server" "nearcasting" system I am working on would be useful for many things, including placing multiple nameservers in different topological locations, all on the same IP address - and then letting each one of those nameservers return different IP addresses to their requesters. No IP-to-location database or any fancy computer programming is needed for this approach. So it doesn't work exactly on countries, but it would automatically provide each separate DNS with a catchment area of requesters according to how the BGP routers consider each "nearcast" DNS server is "nearest" to the requester. This will work fine with requesters which are on EID addresses, as well as requesters on conventional RLOC addresses. A geo-DNS will not work as well, or in principle, at all, with EID addresses. >> Joel, and I think Robin were talking about EID anycast, not RLOC >> anycast. I am using a new term now: "nearcast", because what I am suggesting is not precisely "EID anycast" or anything else. I haven't found a good use for "RLOC anycast" == "anycast ETRs": putting two or more ETRs on the same global unicast RLOC address, but each with a separate border router in topologically separate parts of the Net. > Right, well my opinion about an EID being used as an anycast address > basically has the same usage it does today. But with LISP the scope is > within a site that assigns EIDs out of the EID-prefix it owns. I understand this as there there being one or more ETRs at a site (as usual, with each one having its own RLOC address) and within the site's internal routing system there being multiple hosts anycast with the same IP address. So the area (scope) in which the anycast system operates (the distinctive "closest alive destination" way of choosing where to send packets) is entirely within the one "site" - however defined. Therefore, assuming the ITR's choice of ETR has nothing to do with how close the ETR is to the ITR (how could the ITR known this, without something like a "distance server"), then this "anycast EID within a site" has no influence on the path taken by packets in the DFZ. Therefore, the scope of the anycast arrangement is within the end-user network, not in the DFZ. This would be scalable and may have its uses. The only one I can think of is load-sharing and/or redundancy with multiple locally anycast hosts handling packets sent to them from one or more ETRs. However, this "anycast within the end-user network" does not does not at all achieve the benefits of conventional BGP-based anycast in the DFZ. The benefits of what I call "conventional BGP-based anycast" - as used for some root nameservers - rely on the way packets take the "shortest" path within the DFZ to the nearest operational "anycast host". "Shortest" is in terms of each BGP router's choice of shortest path - based on the number of ASNs in the path offered by its neighbours. The BGP system naturally transports the packet to the the nearest of typically multiple border routers advertising the same prefix. In the case of a single conventional ISP or end-user network advertising the same prefix from multiple border routers, there is only one destination host for each IP address (unless there is local anycast within that network, which is not at all conventional). What makes two or more border routers advertising the same prefix a true "anycast" arrangement is that each border router sends the packet to its own host. Typically, the border routers are widely geographically and topologically separated. It is impossible to discern from the flow of packets in the DFZ whether this arrangement of two or more border routers advertising the same prefix is anycast or not. The "anycast" nature of it depends on each router sending packets to its own host, not all such routers sending packets to the one host. With conventional BGP-based anycast, the scope of the anycast system is the entire Internet, including the DFZ. >> I'll admit that I'm not really seeing the point in the >> result of the mapping being an anycast address, although I agree that >> if that happens, it should behave as you describe. What Dino refers to below is something different: "RLOC anycast" AKA "anycast ETRs": multiple ETRs having the same, globally (with BGP), anycast address - and each ETR having a separate border router, if the ETR itself is not a border router. This is simply a case of using otherwise conventional BGP-based anycast for ETRs. So these multiple border routers (one for each ETR) advertise the same prefix, or at least prefixes which all encompass the one anycast address used by the multiple ETRs. These ETRs are physically separate and located in different parts of the world. This could work, but I didn't find any good use for it. Below, I explain why anycast ETRs is at odds with LISP's (or APT's, or Ivip's etc.) intention to help with the routing scaling problem While I didn't find any use for it, I didn't consider this: > Well, there is an important point. You don't have to worry about > RLOC liveness when you have anycast. You just pray and send > packets and they will get to the destination site through one of > the anycast ETRs. And if any of them go down or become > unreachable, the core will reroute without any involvement from > the ITRs. This is not an issue in Ivip. (Not counting how I intend to alter Ivip with this "distance server", "nearcast" stuff) Ivip ITRs do not make decisions about which ETR to use. The mapping for each micronet (EID prefix) has a single ETR address - since with real-time (a few seconds) mapping distribution to all the ITRs which need it, the single ETR address which each micronet is mapped to can be assumed to be alive. With LISP, APT and TRRP, you don't have real-time mapping so you need the mapping to include multiple possible ETR addresses - and let the ITRs (or for APT, the Default Mappers) decide which ETR address to used, based on tests or assumptions about which ETRs are currently reachable. In this context, anycast ETRs ("RLOC anycast") looks like it has an an advantage for LISP, because as you wrote, it solves a problem of ITRs needing to decide whether one ETR or another is reachable. Instead, you can assume that at at least one ETR is alive and allow the BGP system to take care of sending the tunneled packet to the nearest ETR which is alive. However . . . there is a serious gotcha with this "anycast ETR" use of LISP (or any other core-edge separation scheme): it is of no use to scalable routing. Let's say you have an ETR in LA and another in NY, both on the same address 44.55.66.77. Each one decapsulates packets and sends them to its own server, both of which are on the same EID address, for example 7.6.5.4. In this example, we use the BGP system's natural behavior to direct tunneled packets to the nearest ETR which is alive. This depends entirely on the router at each site (which may be the ETR, or may be some other router which the ETR is using to connect to the DFZ) withdrawing the route which encompasses the ETR's address the moment that ETR dies, or becomes unreachable - or the moment the server behind the ETR (on 7.6.5.4) dies or becomes unreachable. So for instance, both routers RLA and RNY would advertise 44.55.66.0/24 - which encompasses the address of the two ETRs. The mapping for the EID prefix encompassing 7.6.5.4 has a single ETR address: 44.55.66.77. Because each router RLA or RNY must withdraw the route when its ETR dies, or when the server behind the ETR dies, you can't use this 44.55.66.0/24 prefix for any other purpose. The scalable benefits of core-edge separation schemes such as LISP, APT, Ivip and TRRP depend entirely on an ISP being able to have the ETRs used by many end-user networks - thousands or hundreds of thousands or whatever - all covered by a single BGP-advertised prefix of an ISP. Anycast ETRs violate this principle completely. I haven't yet found a practical use for them. >> However I'm fairly >> sure that Joel made it clear he was talking about providing anycast >> service using LISP. In that case, the EID would be an anycast >> address, and the RLOC would reach one instance of that service. > > There actually should be one more level of indirection. The EID indeed > describes a service, but the EID comes out of an EID-prefix, and the > RLOCs are associated with the EID-prefix. You can do local EID anycast as I initially described, where the anycast scope is entirely within a single end-user network. That does not have the benefits of conventional, global scope, BGP-based anycast: within the DFZ the packets automatically being forwarded to the border router of the nearest alive host. The closest way you can achieve the same benefit with LISP etc. is to anycast the ETRs instead as I just described. That has similar benefits to conventional BGP-based anycast, and it uses EID space for the destination host, as with all LISP etc. systems. While it neatly solves the problem of LISP ITRs having to figure out which of multiple ETR addresses to use, the system does not seem to be useful because: 1 - It is no more scalable than conventional BGP-anycast: a single DFZ prefix is required for every set of hosts. (This is worse scalability than conventional PI prefixes for end-user networks which are typically used to support large numbers of hosts.) 2 - It is more complex than conventional BGP-anycast. > Having said that, the EID-prefix could be a /32 or /128, but need to be > extremely careful here that the mapping database doesn't become flat > with host based entries. This is a question which I think is unrelated to anycast. I will take it up in a separate thread. - Robin From dino@cisco.com Sat Apr 25 16:56:38 2009 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 966053A6DC1 for ; Sat, 25 Apr 2009 16:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 WHN7nRuCCuax for ; Sat, 25 Apr 2009 16:56:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B06763A6C77 for ; Sat, 25 Apr 2009 16:56:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="292970235" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Apr 2009 23:57:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3PNvUSr003629; Sat, 25 Apr 2009 16:57:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3PNvUmW009717; Sat, 25 Apr 2009 23:57:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 16:57:30 -0700 Received: from [192.168.1.2] ([10.21.77.184]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 16:57:29 -0700 Message-Id: <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Sat, 25 Apr 2009 16:57:29 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 25 Apr 2009 23:57:29.0802 (UTC) FILETIME=[97A21AA0:01C9C601] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4014; t=1240703850; x=1241567850; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20errors |Sender:=20; bh=xvheImnrkpjJwequu530oq+Jh3qwTlv6Zw1GhoyZEIY=; b=dMLVYwZqedScD8RiSghPGtsZbRqbcxHQDHMlgbSAC/Alln6S62VOjdvsUO SXjznrx5QZbXKXxpxAVErhFzwG+0jbtIN/38V3xRpxsMcYEkrqcdZz+y2nMY xAsD8OVbw5; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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: Sat, 25 Apr 2009 23:56:38 -0000 > In addition to errors that may occur along the path from > the ITE to the ETE *before* decapsulation and errors that You mean from ITR to ETR (since this is a LISP mailing list post). > may occur along the path from the ETE to the final > destination *after* decapsulation, errors may also occur > *during* decapsulation. An example is what if the ETR > decapsulates the outer IP header, but the inner IP stack > is not configured? (Answer is that the ITR should receive > an error by which it can ascertain that this ETR is having > trouble, and should start using a different ETR instead.) This is unlikely in most implementations. If the IP stack is not configured the decapsulation wouldn't have happened. And that's because the IP packet would arrive on an interface and IP wouldn't process it. So Fred, you really don't want to send per-packet errors. You don't want to send errors at all actually. What if a regular IP packet had a source address of say 127.0.0.1, 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? First, you don't want hardware forwarding engines to test for all these invalid addresses, and second, you don't want the control-plane to have to deal with per packet errors. IP is best-effort and drops packets, that's one of the best features the Internet architecture has. > This gives rise to a type of error message that is neither > fish nor fowl, i.e., it is neither an RLOC-based nor an > EID-based ICMP error - it is a *LISP* error instead. One Not true. What if a NAT in the middle swapped a source address from a good address to 224.1.1.1? Putting the blame to which protocol component is in error and trying to take action is not fruitful at all. In fact, it is rather damaging. > approach is to have the ETR send such a LISP error back > to the ITR with enough identifying credentials such that > the ITR can be reasonably sure the message is authentic. Ah man, you are making the solution even harder. So you want pair-wise Security Associations among all ITR->ETR conversations? > The message should further not be dropped by packet > filters on the path from the ETR to the ITR that filter > "naked" ICMP messages. > > Such LISP errors would need to be identified by a bit in > the LISP header (call it the 'E' bit) preferably adjacent > to the existing 'S' bit. The ETR sets the 'E' bit to tell > the ITR that this LISP packet contains an error, and not > an IPv4 nor IPv6 packet. The error could be formatted as > per an ICMPv4 or ICMPv6 error, but it need not be so. > For example, the packet could be constructed as: > > +-----------------+ > | Outer IP header | > +-----------------+ > | UDP header | > +-----------------+ > | LISP hdr (E=1) | > +-----------------+ > | ICMP header (?) | > +-----------------+ > | | > ~ Packet-in-error ~ > ~(up to 512 bytes)~ > | | > +-----------------+ > > Again, this would be the ETR's way of telling the ITR > that it is having trouble and perhaps a different ETR And since the ITR is so buggy, what makes you think it will listen to what the ETR has to say? What happens if the ITR is malicious? > should be chosen. An exception would be a "packet too > big" error, in which the ITR would simply adjust its > packet sizes as long as the MTU reported by the ETR > is of a reasonable size. > > As with any network-based error message feedback, this > is susceptible to on-path attacks. It is resilient > against off-path attacks, however. > > Comments? With all due respect Fred, when I first read this, I checked the date on my calendar to make sure it wasn't April 1st. The only reason I make this statement above is because you asked for comments. Dino > > > Fred > fred.l.templin@boeing.com > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sat Apr 25 16:59:25 2009 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 EF7363A6DF9 for ; Sat, 25 Apr 2009 16:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Vc-l73PTGIa8 for ; Sat, 25 Apr 2009 16:59:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 946273A6DCA for ; Sat, 25 Apr 2009 16:59:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,247,1238976000"; d="scan'208";a="158958216" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2009 00:00:43 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3Q00hrA016370; Sat, 25 Apr 2009 17:00:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3Q00h4l003454; Sun, 26 Apr 2009 00:00:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 17:00:43 -0700 Received: from [192.168.1.2] ([10.21.77.184]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Apr 2009 17:00:42 -0700 Message-Id: <8F9DE3F2-F405-4450-A807-69489F49E2BC@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <49F2FCD5.1040301@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Sat, 25 Apr 2009 17:00:42 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <1A330739-5F0E-4EBB-A68E-0B3AEA6E6B8A@cisco.com> <49F2FCD5.1040301@firstpr.com.au> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 26 Apr 2009 00:00:42.0799 (UTC) FILETIME=[0AAB1BF0:01C9C602] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16432; t=1240704043; x=1241568043; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Anycast=20-=20not=20really,=20 standby=20for=20more=20on=20=22nearcast=22 |Sender:=20; bh=JMbzh8UFBcHCqTq6qndeS3Io2IbycX9tpZoWDpjMC9Y=; b=fSoGZwzcxhrxNrI4j3n3XBDGK44A5wKWeQa9EIxBbyA5WcQR9rV6/9Z/Ta yfH7RNxS2CLfFGjVfNdsX4qnV0wo/7ob0azGKNJrJ0CZeOMfIPOkh4RYRdc2 kOVqPaMbWV; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Anycast - not really, standby for more on "nearcast" 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: Sat, 25 Apr 2009 23:59:26 -0000 Okay Robin, if you want us to take you seriously, and I really want to, can you please stop saying what the idea is 1) named, 2) who is going to work on it, 3) what it's benefits are, and 4) what protoocols can use it? Rather, tell us what the idea is before you marketed it to death? Give us the idea in a short description and the smart people on this list can conclude what the benefits and costs are. Thanks in advance, Dino On Apr 25, 2009, at 5:06 AM, Robin Whittle wrote: > Short version: I am working on a better description of the uses of > the "distance server" idea I proposes. I will call > this system "nearcast". In the future I will write > this up on the Ivip site. For now, I am writing > about it to the LISP and RRG lists, because it seems > to be novel and useful - and because I think it can > be applied just as well to LISP, APT and TRRP as to > Ivip. (Actually, I have to change Ivip significantly > to do it - the changes to LISP etc. would be less.) > > I think this "nearcast" approach has many of the > benefits of conventional BGP-based anycast, but it > will be entirely scalable as part of LISP etc. > > Conventional BGP-anycast is highly unscalable: one > DFZ prefix must be devoted to each set of anycast > servers. > > LISP, APT, Ivip etc, could be made to do much the > same job as conventional BGP-based anycast, by > anycasting the ETRs. However this cannot be done > in a scalable fashion. It would be just as > unscalable as conventional BGP-based anycast, and > be more complex - with no obvious benefits. Each > set of anycast servers would still need a route > in the DFZ. > > The "nearcast" system I am working on would have > significant advantages, in addition to being > scalable, compared to conventional BGP-based > anycast. I think the most important novel function > would be, its much greater suitability for > session-based protocols. > > > Hi Sam and Dino, > > This "nearcast" "Distance Server" system addition to LISP or other > core-edge separation schemes should function as a scalable > replacement for conventional BGP-based anycast. However, it would > not have precisely the same functionality. In many scenarios its > functionality would probably be just as good as conventional > BGP-based anycast. However, I think it would be also much more > suitable for the session-based protocols which are generally not used > for conventional BGP-based anycast. > > I will write more about this in a forthcoming message on the RRG > list. I am going to use the term "nearcast" for this system, since > it looks useful and since it is different from anycast and unicast. > > >>> Currently, I think the only person who may be proposing working on >>> this is Robin; and I may be misreading even his message. >> >> Understand. We will wait for a Robin reply for clarification. > > I wouldn't "propose" the LISP team embark on any work or addition to > LISP, since I am not part of the team. I try to contribute to the > development of LISP project by way of constructive critiques and by > suggesting new ideas which I think would improve LISP. > > I just thought of this a day ago and as far as I know it is novel and > would be useful in some important and unique ways. > > Amongst other things, it would be a way that with a single EID > address, an end-user network could field multiple servers around the > world - with full support for routing scalability. Neither the > current BGP-based anycast technique, or its functional equivalent in > LISP etc.(anycast ETRs) is scalable. Both are *less* scalable than > ordinary PI prefixes for end-user networks since in both cases, a > complete DFZ prefix needs to be dedicated to each set of anycast > servers. > > There are many potential purposes for the "nearcasting" system I am > working on. One of these is providing different DNS responses to > requesters from topologically separate parts of the Net. I > understand this is currently done via a different technique, loosely > called "geo-DNS": matching the requesting IP address against some > kind of database to determine the country of origin. I think there > are paid-for services for such maps, but a free one is > http://countries.nerd.dk/more.html . This is a tricky business, to > say the least - because it requires a constantly updated database as > the usage of 0.25M DFZ prefixes change. Another approach is > pgeodns, a perl script which is used by ntp.org at least to enable a > DNS server to respond according to the approximate "location" > (topological? geographical?) of the requester. > > Both these and I guess any other approaches to geo-DNS are going to > work less and less once a core-edge separation scheme is operational, > assuming more and more requesters to the geo-DNS equipped server come > from EID addresses. There will be little or no direct relationship > between an EID address and geographical or topological location, > since one of the purposes of a scalable routing solution is to enable > these EID addresses to be portable and used with any ISP, > irrespective of location. > > So it seems that LISP or any other core-edge separation scheme is > incompatible with geo-DNS. Unless we provide an alternative, this > would be a reason for people to argue against the adoption of LISP > etc. If we can provide a better alternative, to geo-DNS and to > conventional BGP-based anycast, or for other uses of "anycast"-like > techniques, then this would be a reason people would want to adopt > LISP or whatever. > > > I think the "distance server" "nearcasting" system I am working on > would be useful for many things, including placing multiple > nameservers in different topological locations, all on the same IP > address - and then letting each one of those nameservers return > different IP addresses to their requesters. No IP-to-location > database or any fancy computer programming is needed for this > approach. So it doesn't work exactly on countries, but it would > automatically provide each separate DNS with a catchment area of > requesters according to how the BGP routers consider each "nearcast" > DNS server is "nearest" to the requester. This will work fine with > requesters which are on EID addresses, as well as requesters on > conventional RLOC addresses. A geo-DNS will not work as well, or in > principle, at all, with EID addresses. > > >>> Joel, and I think Robin were talking about EID anycast, not RLOC >>> anycast. > > I am using a new term now: "nearcast", because what I am suggesting > is not precisely "EID anycast" or anything else. > > I haven't found a good use for "RLOC anycast" == "anycast ETRs": > putting two or more ETRs on the same global unicast RLOC address, but > each with a separate border router in topologically separate parts of > the Net. > > >> Right, well my opinion about an EID being used as an anycast address >> basically has the same usage it does today. But with LISP the scope >> is >> within a site that assigns EIDs out of the EID-prefix it owns. > > I understand this as there there being one or more ETRs at a site (as > usual, with each one having its own RLOC address) and within the > site's internal routing system there being multiple hosts anycast > with the same IP address. So the area (scope) in which the anycast > system operates (the distinctive "closest alive destination" way of > choosing where to send packets) is entirely within the one "site" - > however defined. Therefore, assuming the ITR's choice of ETR has > nothing to do with how close the ETR is to the ITR (how could the ITR > known this, without something like a "distance server"), then this > "anycast EID within a site" has no influence on the path taken by > packets in the DFZ. Therefore, the scope of the anycast arrangement > is within the end-user network, not in the DFZ. > > This would be scalable and may have its uses. The only one I can > think of is load-sharing and/or redundancy with multiple locally > anycast hosts handling packets sent to them from one or more ETRs. > However, this "anycast within the end-user network" does not does not > at all achieve the benefits of conventional BGP-based anycast in the > DFZ. > > The benefits of what I call "conventional BGP-based anycast" - as > used for some root nameservers - rely on the way packets take the > "shortest" path within the DFZ to the nearest operational "anycast > host". "Shortest" is in terms of each BGP router's choice of > shortest path - based on the number of ASNs in the path offered by > its neighbours. > > The BGP system naturally transports the packet to the the nearest of > typically multiple border routers advertising the same prefix. In > the case of a single conventional ISP or end-user network advertising > the same prefix from multiple border routers, there is only one > destination host for each IP address (unless there is local anycast > within that network, which is not at all conventional). > > What makes two or more border routers advertising the same prefix a > true "anycast" arrangement is that each border router sends the > packet to its own host. Typically, the border routers are widely > geographically and topologically separated. > > It is impossible to discern from the flow of packets in the DFZ > whether this arrangement of two or more border routers advertising > the same prefix is anycast or not. The "anycast" nature of it > depends on each router sending packets to its own host, not all such > routers sending packets to the one host. With conventional > BGP-based anycast, the scope of the anycast system is the entire > Internet, including the DFZ. > > >>> I'll admit that I'm not really seeing the point in the >>> result of the mapping being an anycast address, although I agree >>> that >>> if that happens, it should behave as you describe. > > What Dino refers to below is something different: "RLOC anycast" AKA > "anycast ETRs": multiple ETRs having the same, globally (with BGP), > anycast address - and each ETR having a separate border router, if > the ETR itself is not a border router. This is simply a case of > using otherwise conventional BGP-based anycast for ETRs. > > So these multiple border routers (one for each ETR) advertise the > same prefix, or at least prefixes which all encompass the one anycast > address used by the multiple ETRs. These ETRs are physically > separate and located in different parts of the world. This could > work, but I didn't find any good use for it. Below, I explain why > anycast ETRs is at odds with LISP's (or APT's, or Ivip's etc.) > intention to help with the routing scaling problem > > While I didn't find any use for it, I didn't consider this: > >> Well, there is an important point. You don't have to worry about >> RLOC liveness when you have anycast. You just pray and send >> packets and they will get to the destination site through one of >> the anycast ETRs. And if any of them go down or become >> unreachable, the core will reroute without any involvement from >> the ITRs. > > This is not an issue in Ivip. (Not counting how I intend to alter > Ivip with this "distance server", "nearcast" stuff) Ivip ITRs do not > make decisions about which ETR to use. The mapping for each micronet > (EID prefix) has a single ETR address - since with real-time (a few > seconds) mapping distribution to all the ITRs which need it, the > single ETR address which each micronet is mapped to can be assumed to > be alive. > > With LISP, APT and TRRP, you don't have real-time mapping so you need > the mapping to include multiple possible ETR addresses - and let the > ITRs (or for APT, the Default Mappers) decide which ETR address to > used, based on tests or assumptions about which ETRs are currently > reachable. > > In this context, anycast ETRs ("RLOC anycast") looks like it has an > an advantage for LISP, because as you wrote, it solves a problem of > ITRs needing to decide whether one ETR or another is reachable. > Instead, you can assume that at at least one ETR is alive and allow > the BGP system to take care of sending the tunneled packet to the > nearest ETR which is alive. > > However . . . there is a serious gotcha with this "anycast ETR" use > of LISP (or any other core-edge separation scheme): it is of no use > to scalable routing. > > Let's say you have an ETR in LA and another in NY, both on the same > address 44.55.66.77. Each one decapsulates packets and sends them to > its own server, both of which are on the same EID address, for > example 7.6.5.4. > > In this example, we use the BGP system's natural behavior to direct > tunneled packets to the nearest ETR which is alive. This depends > entirely on the router at each site (which may be the ETR, or may be > some other router which the ETR is using to connect to the DFZ) > withdrawing the route which encompasses the ETR's address the moment > that ETR dies, or becomes unreachable - or the moment the server > behind the ETR (on 7.6.5.4) dies or becomes unreachable. > > So for instance, both routers RLA and RNY would advertise > 44.55.66.0/24 - which encompasses the address of the two ETRs. The > mapping for the EID prefix encompassing 7.6.5.4 has a single ETR > address: 44.55.66.77. > > Because each router RLA or RNY must withdraw the route when its ETR > dies, or when the server behind the ETR dies, you can't use this > 44.55.66.0/24 prefix for any other purpose. > > The scalable benefits of core-edge separation schemes such as LISP, > APT, Ivip and TRRP depend entirely on an ISP being able to have the > ETRs used by many end-user networks - thousands or hundreds of > thousands or whatever - all covered by a single BGP-advertised prefix > of an ISP. Anycast ETRs violate this principle completely. I > haven't yet found a practical use for them. > > >>> However I'm fairly >>> sure that Joel made it clear he was talking about providing anycast >>> service using LISP. In that case, the EID would be an anycast >>> address, and the RLOC would reach one instance of that service. >> >> There actually should be one more level of indirection. The EID >> indeed >> describes a service, but the EID comes out of an EID-prefix, and the >> RLOCs are associated with the EID-prefix. > > You can do local EID anycast as I initially described, where the > anycast scope is entirely within a single end-user network. That > does not have the benefits of conventional, global scope, BGP-based > anycast: within the DFZ the packets automatically being forwarded to > the border router of the nearest alive host. > > The closest way you can achieve the same benefit with LISP etc. is to > anycast the ETRs instead as I just described. That has similar > benefits to conventional BGP-based anycast, and it uses EID space for > the destination host, as with all LISP etc. systems. While it neatly > solves the problem of LISP ITRs having to figure out which of > multiple ETR addresses to use, the system does not seem to be useful > because: > > 1 - It is no more scalable than conventional BGP-anycast: a single > DFZ prefix is required for every set of hosts. (This is worse > scalability than conventional PI prefixes for end-user networks > which are typically used to support large numbers of hosts.) > > 2 - It is more complex than conventional BGP-anycast. > > >> Having said that, the EID-prefix could be a /32 or /128, but need >> to be >> extremely careful here that the mapping database doesn't become flat >> with host based entries. > > This is a question which I think is unrelated to anycast. I will > take it up in a separate thread. > > - Robin > > From Fred.L.Templin@boeing.com Mon Apr 27 07:00:18 2009 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 D699228C150 for ; Mon, 27 Apr 2009 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 k49CCrDSgMat for ; Mon, 27 Apr 2009 07:00:17 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 199163A68AF for ; Mon, 27 Apr 2009 07:00:14 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3RE1VaK027931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 07:01:32 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3RE1VKk020325; Mon, 27 Apr 2009 07:01:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3RE1U7Z020300; Mon, 27 Apr 2009 07:01:31 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 07:01:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 07:01:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnGAZnWGiJeRzzOR+WyTTTtD4/pMABPvTaQ References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 27 Apr 2009 14:01:29.0030 (UTC) FILETIME=[A960D660:01C9C740] Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 14:00:18 -0000 Dino, You can belittle all you want; just remember that you heard it here first. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Saturday, April 25, 2009 4:57 PM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP errors >=20 > > In addition to errors that may occur along the path from > > the ITE to the ETE *before* decapsulation and errors that >=20 > You mean from ITR to ETR (since this is a LISP mailing list post). >=20 > > may occur along the path from the ETE to the final > > destination *after* decapsulation, errors may also occur > > *during* decapsulation. An example is what if the ETR > > decapsulates the outer IP header, but the inner IP stack > > is not configured? (Answer is that the ITR should receive > > an error by which it can ascertain that this ETR is having > > trouble, and should start using a different ETR instead.) >=20 > This is unlikely in most implementations. If the IP stack is not > configured the decapsulation wouldn't have happened. And that's > because the IP packet would arrive on an interface and IP wouldn't > process it. >=20 > So Fred, you really don't want to send per-packet errors. You don't > want to send errors at all actually. >=20 > What if a regular IP packet had a source address of say 127.0.0.1, > 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? First, > you don't want hardware forwarding engines to test for all these > invalid addresses, and second, you don't want the control-plane to > have to deal with per packet errors. >=20 > IP is best-effort and drops packets, that's one of the best features > the Internet architecture has. >=20 > > This gives rise to a type of error message that is neither > > fish nor fowl, i.e., it is neither an RLOC-based nor an > > EID-based ICMP error - it is a *LISP* error instead. One >=20 > Not true. What if a NAT in the middle swapped a source address from a > good address to 224.1.1.1? >=20 > Putting the blame to which protocol component is in error and trying > to take action is not fruitful at all. In fact, it is rather damaging. >=20 > > approach is to have the ETR send such a LISP error back > > to the ITR with enough identifying credentials such that > > the ITR can be reasonably sure the message is authentic. >=20 > Ah man, you are making the solution even harder. So you want pair-wise > Security Associations among all ITR->ETR conversations? >=20 > > The message should further not be dropped by packet > > filters on the path from the ETR to the ITR that filter > > "naked" ICMP messages. > > > > Such LISP errors would need to be identified by a bit in > > the LISP header (call it the 'E' bit) preferably adjacent > > to the existing 'S' bit. The ETR sets the 'E' bit to tell > > the ITR that this LISP packet contains an error, and not > > an IPv4 nor IPv6 packet. The error could be formatted as > > per an ICMPv4 or ICMPv6 error, but it need not be so. > > For example, the packet could be constructed as: > > > > +-----------------+ > > | Outer IP header | > > +-----------------+ > > | UDP header | > > +-----------------+ > > | LISP hdr (E=3D1) | > > +-----------------+ > > | ICMP header (?) | > > +-----------------+ > > | | > > ~ Packet-in-error ~ > > ~(up to 512 bytes)~ > > | | > > +-----------------+ > > > > Again, this would be the ETR's way of telling the ITR > > that it is having trouble and perhaps a different ETR >=20 > And since the ITR is so buggy, what makes you think it will listen to > what the ETR has to say? What happens if the ITR is malicious? >=20 > > should be chosen. An exception would be a "packet too > > big" error, in which the ITR would simply adjust its > > packet sizes as long as the MTU reported by the ETR > > is of a reasonable size. > > > > As with any network-based error message feedback, this > > is susceptible to on-path attacks. It is resilient > > against off-path attacks, however. > > > > Comments? >=20 > With all due respect Fred, when I first read this, I checked the date > on my calendar to make sure it wasn't April 1st. >=20 > The only reason I make this statement above is because you asked for > comments. >=20 > Dino >=20 > > > > > > Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Apr 27 09:24:03 2009 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 120543A6955 for ; Mon, 27 Apr 2009 09:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 cUeCPUGqmvrI for ; Mon, 27 Apr 2009 09:24:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4A40A3A67FA for ; Mon, 27 Apr 2009 09:24:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1238976000"; d="scan'208";a="177419842" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2009 16:25:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3RGPMV3018644; Mon, 27 Apr 2009 09:25:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3RGPM5h012405; Mon, 27 Apr 2009 16:25:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:25:22 -0700 Received: from [192.168.1.2] ([10.21.80.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:25:21 -0700 Message-Id: <75D6916F-D729-405E-AF90-795B31211183@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Mon, 27 Apr 2009 09:25:21 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 27 Apr 2009 16:25:21.0820 (UTC) FILETIME=[C2EC0DC0:01C9C754] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4788; t=1240849522; x=1241713522; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20errors |Sender:=20; bh=gQDYc6VkAjA0KKdnaans39ETpi1mjDZ96QAZiz/6H9I=; b=oXoJrPBALDUJMJhpa9L5UAXrYdnWzsrcYYDHd+3YX7YQ5X/EakWJfW/9cJ 3QE2P4tH4/p31SdxxXkprP7IYztoy2cDj4VkTbhyFO+a+Tn0zPapwv7YA5+m a6THEyq05/WKO1RZzV7p8ZL1LpsGIKpznz4WV1/fKADuCHKIBo8Zk=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 16:24:03 -0000 I'm not belittling you Fred. I did say "with all due respect" and I wasn't being sarcastic. I just can't see how this idea can scale. Dino On Apr 27, 2009, at 7:01 AM, Templin, Fred L wrote: > Dino, > > You can belittle all you want; just remember that you > heard it here first. > > Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Saturday, April 25, 2009 4:57 PM >> To: Templin, Fred L >> Cc: lisp@ietf.org >> Subject: Re: [lisp] LISP errors >> >>> In addition to errors that may occur along the path from >>> the ITE to the ETE *before* decapsulation and errors that >> >> You mean from ITR to ETR (since this is a LISP mailing list post). >> >>> may occur along the path from the ETE to the final >>> destination *after* decapsulation, errors may also occur >>> *during* decapsulation. An example is what if the ETR >>> decapsulates the outer IP header, but the inner IP stack >>> is not configured? (Answer is that the ITR should receive >>> an error by which it can ascertain that this ETR is having >>> trouble, and should start using a different ETR instead.) >> >> This is unlikely in most implementations. If the IP stack is not >> configured the decapsulation wouldn't have happened. And that's >> because the IP packet would arrive on an interface and IP wouldn't >> process it. >> >> So Fred, you really don't want to send per-packet errors. You don't >> want to send errors at all actually. >> >> What if a regular IP packet had a source address of say 127.0.0.1, >> 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? First, >> you don't want hardware forwarding engines to test for all these >> invalid addresses, and second, you don't want the control-plane to >> have to deal with per packet errors. >> >> IP is best-effort and drops packets, that's one of the best features >> the Internet architecture has. >> >>> This gives rise to a type of error message that is neither >>> fish nor fowl, i.e., it is neither an RLOC-based nor an >>> EID-based ICMP error - it is a *LISP* error instead. One >> >> Not true. What if a NAT in the middle swapped a source address from a >> good address to 224.1.1.1? >> >> Putting the blame to which protocol component is in error and trying >> to take action is not fruitful at all. In fact, it is rather >> damaging. >> >>> approach is to have the ETR send such a LISP error back >>> to the ITR with enough identifying credentials such that >>> the ITR can be reasonably sure the message is authentic. >> >> Ah man, you are making the solution even harder. So you want pair- >> wise >> Security Associations among all ITR->ETR conversations? >> >>> The message should further not be dropped by packet >>> filters on the path from the ETR to the ITR that filter >>> "naked" ICMP messages. >>> >>> Such LISP errors would need to be identified by a bit in >>> the LISP header (call it the 'E' bit) preferably adjacent >>> to the existing 'S' bit. The ETR sets the 'E' bit to tell >>> the ITR that this LISP packet contains an error, and not >>> an IPv4 nor IPv6 packet. The error could be formatted as >>> per an ICMPv4 or ICMPv6 error, but it need not be so. >>> For example, the packet could be constructed as: >>> >>> +-----------------+ >>> | Outer IP header | >>> +-----------------+ >>> | UDP header | >>> +-----------------+ >>> | LISP hdr (E=1) | >>> +-----------------+ >>> | ICMP header (?) | >>> +-----------------+ >>> | | >>> ~ Packet-in-error ~ >>> ~(up to 512 bytes)~ >>> | | >>> +-----------------+ >>> >>> Again, this would be the ETR's way of telling the ITR >>> that it is having trouble and perhaps a different ETR >> >> And since the ITR is so buggy, what makes you think it will listen to >> what the ETR has to say? What happens if the ITR is malicious? >> >>> should be chosen. An exception would be a "packet too >>> big" error, in which the ITR would simply adjust its >>> packet sizes as long as the MTU reported by the ETR >>> is of a reasonable size. >>> >>> As with any network-based error message feedback, this >>> is susceptible to on-path attacks. It is resilient >>> against off-path attacks, however. >>> >>> Comments? >> >> With all due respect Fred, when I first read this, I checked the date >> on my calendar to make sure it wasn't April 1st. >> >> The only reason I make this statement above is because you asked for >> comments. >> >> Dino >> >>> >>> >>> Fred >>> fred.l.templin@boeing.com >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp > From Fred.L.Templin@boeing.com Mon Apr 27 09:37:42 2009 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 E04EE3A6B5D for ; Mon, 27 Apr 2009 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 TeEph4Se9TsP for ; Mon, 27 Apr 2009 09:37:42 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E2FD33A6A8B for ; Mon, 27 Apr 2009 09:37:41 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3RGcoV2011014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2009 09:38:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3RGcnbN012697; Mon, 27 Apr 2009 11:38:50 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3RGcfUS012394; Mon, 27 Apr 2009 11:38:49 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 09:38:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 09:38:47 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <75D6916F-D729-405E-AF90-795B31211183@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnHVMbGNzCQ59vsR2yBD5UfqtYwogAAau8A References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com><49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com><6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 27 Apr 2009 16:38:49.0305 (UTC) FILETIME=[A4387C90:01C9C756] Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 16:37:43 -0000 Dino, > I just can't see how this idea can scale. Then, I will give you just one more thought for now: *rate limit*! Fred fred.l.templin@boeing.com > Dino >=20 > On Apr 27, 2009, at 7:01 AM, Templin, Fred L wrote: >=20 > > Dino, > > > > You can belittle all you want; just remember that you > > heard it here first. > > > > Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:dino@cisco.com] > >> Sent: Saturday, April 25, 2009 4:57 PM > >> To: Templin, Fred L > >> Cc: lisp@ietf.org > >> Subject: Re: [lisp] LISP errors > >> > >>> In addition to errors that may occur along the path from > >>> the ITE to the ETE *before* decapsulation and errors that > >> > >> You mean from ITR to ETR (since this is a LISP mailing list post). > >> > >>> may occur along the path from the ETE to the final > >>> destination *after* decapsulation, errors may also occur > >>> *during* decapsulation. An example is what if the ETR > >>> decapsulates the outer IP header, but the inner IP stack > >>> is not configured? (Answer is that the ITR should receive > >>> an error by which it can ascertain that this ETR is having > >>> trouble, and should start using a different ETR instead.) > >> > >> This is unlikely in most implementations. If the IP stack is not > >> configured the decapsulation wouldn't have happened. And that's > >> because the IP packet would arrive on an interface and IP wouldn't > >> process it. > >> > >> So Fred, you really don't want to send per-packet errors. You don't > >> want to send errors at all actually. > >> > >> What if a regular IP packet had a source address of say 127.0.0.1, > >> 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? First, > >> you don't want hardware forwarding engines to test for all these > >> invalid addresses, and second, you don't want the control-plane to > >> have to deal with per packet errors. > >> > >> IP is best-effort and drops packets, that's one of the best features > >> the Internet architecture has. > >> > >>> This gives rise to a type of error message that is neither > >>> fish nor fowl, i.e., it is neither an RLOC-based nor an > >>> EID-based ICMP error - it is a *LISP* error instead. One > >> > >> Not true. What if a NAT in the middle swapped a source address from a > >> good address to 224.1.1.1? > >> > >> Putting the blame to which protocol component is in error and trying > >> to take action is not fruitful at all. In fact, it is rather > >> damaging. > >> > >>> approach is to have the ETR send such a LISP error back > >>> to the ITR with enough identifying credentials such that > >>> the ITR can be reasonably sure the message is authentic. > >> > >> Ah man, you are making the solution even harder. So you want pair- > >> wise > >> Security Associations among all ITR->ETR conversations? > >> > >>> The message should further not be dropped by packet > >>> filters on the path from the ETR to the ITR that filter > >>> "naked" ICMP messages. > >>> > >>> Such LISP errors would need to be identified by a bit in > >>> the LISP header (call it the 'E' bit) preferably adjacent > >>> to the existing 'S' bit. The ETR sets the 'E' bit to tell > >>> the ITR that this LISP packet contains an error, and not > >>> an IPv4 nor IPv6 packet. The error could be formatted as > >>> per an ICMPv4 or ICMPv6 error, but it need not be so. > >>> For example, the packet could be constructed as: > >>> > >>> +-----------------+ > >>> | Outer IP header | > >>> +-----------------+ > >>> | UDP header | > >>> +-----------------+ > >>> | LISP hdr (E=3D1) | > >>> +-----------------+ > >>> | ICMP header (?) | > >>> +-----------------+ > >>> | | > >>> ~ Packet-in-error ~ > >>> ~(up to 512 bytes)~ > >>> | | > >>> +-----------------+ > >>> > >>> Again, this would be the ETR's way of telling the ITR > >>> that it is having trouble and perhaps a different ETR > >> > >> And since the ITR is so buggy, what makes you think it will listen to > >> what the ETR has to say? What happens if the ITR is malicious? > >> > >>> should be chosen. An exception would be a "packet too > >>> big" error, in which the ITR would simply adjust its > >>> packet sizes as long as the MTU reported by the ETR > >>> is of a reasonable size. > >>> > >>> As with any network-based error message feedback, this > >>> is susceptible to on-path attacks. It is resilient > >>> against off-path attacks, however. > >>> > >>> Comments? > >> > >> With all due respect Fred, when I first read this, I checked the date > >> on my calendar to make sure it wasn't April 1st. > >> > >> The only reason I make this statement above is because you asked for > >> comments. > >> > >> Dino > >> > >>> > >>> > >>> Fred > >>> fred.l.templin@boeing.com > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > > >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Apr 27 09:43:11 2009 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 CF3DD3A69DD for ; Mon, 27 Apr 2009 09:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 gGuTN6lK5vAi for ; Mon, 27 Apr 2009 09:43:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 416A23A6A43 for ; Mon, 27 Apr 2009 09:43:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1238976000"; d="scan'208";a="177429310" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2009 16:44:31 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3RGiVGe032475; Mon, 27 Apr 2009 09:44:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3RGiVmD006696; Mon, 27 Apr 2009 16:44:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:44:31 -0700 Received: from [192.168.1.2] ([10.21.80.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:44:30 -0700 Message-Id: From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Mon, 27 Apr 2009 09:44:30 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com><49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com><6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 27 Apr 2009 16:44:30.0695 (UTC) FILETIME=[6FB47770:01C9C757] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5420; t=1240850671; x=1241714671; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20errors |Sender:=20; bh=5QGYzaV//nL2Sj5kjdTjw7KlM11MeI8/fXR/fmef/mo=; b=rukXzwJ3QZrzYEkKCqkg9SxOyo1TkQaddnz8uQmejR262gM7aOfCxDHFTk 5Xh9D+iq7CA5kzzU1hWwxpddA8Cuj/lM08lpTVMAVdonJduQqAJDYUTqlrGu wI9AQnwLW6WJu9oxPLj7g8JTZX3HJvC+T1N0VE30jJl6F25V3HYA8=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 16:43:11 -0000 But the point is, what would the ITR do with such error information if it could be scalably transmitted. Dino On Apr 27, 2009, at 9:38 AM, Templin, Fred L wrote: > Dino, > >> I just can't see how this idea can scale. > > Then, I will give you just one more thought for now: > *rate limit*! > > Fred > fred.l.templin@boeing.com > >> Dino >> >> On Apr 27, 2009, at 7:01 AM, Templin, Fred L wrote: >> >>> Dino, >>> >>> You can belittle all you want; just remember that you >>> heard it here first. >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:dino@cisco.com] >>>> Sent: Saturday, April 25, 2009 4:57 PM >>>> To: Templin, Fred L >>>> Cc: lisp@ietf.org >>>> Subject: Re: [lisp] LISP errors >>>> >>>>> In addition to errors that may occur along the path from >>>>> the ITE to the ETE *before* decapsulation and errors that >>>> >>>> You mean from ITR to ETR (since this is a LISP mailing list post). >>>> >>>>> may occur along the path from the ETE to the final >>>>> destination *after* decapsulation, errors may also occur >>>>> *during* decapsulation. An example is what if the ETR >>>>> decapsulates the outer IP header, but the inner IP stack >>>>> is not configured? (Answer is that the ITR should receive >>>>> an error by which it can ascertain that this ETR is having >>>>> trouble, and should start using a different ETR instead.) >>>> >>>> This is unlikely in most implementations. If the IP stack is not >>>> configured the decapsulation wouldn't have happened. And that's >>>> because the IP packet would arrive on an interface and IP wouldn't >>>> process it. >>>> >>>> So Fred, you really don't want to send per-packet errors. You don't >>>> want to send errors at all actually. >>>> >>>> What if a regular IP packet had a source address of say 127.0.0.1, >>>> 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? > First, >>>> you don't want hardware forwarding engines to test for all these >>>> invalid addresses, and second, you don't want the control-plane to >>>> have to deal with per packet errors. >>>> >>>> IP is best-effort and drops packets, that's one of the best > features >>>> the Internet architecture has. >>>> >>>>> This gives rise to a type of error message that is neither >>>>> fish nor fowl, i.e., it is neither an RLOC-based nor an >>>>> EID-based ICMP error - it is a *LISP* error instead. One >>>> >>>> Not true. What if a NAT in the middle swapped a source address from > a >>>> good address to 224.1.1.1? >>>> >>>> Putting the blame to which protocol component is in error and > trying >>>> to take action is not fruitful at all. In fact, it is rather >>>> damaging. >>>> >>>>> approach is to have the ETR send such a LISP error back >>>>> to the ITR with enough identifying credentials such that >>>>> the ITR can be reasonably sure the message is authentic. >>>> >>>> Ah man, you are making the solution even harder. So you want pair- >>>> wise >>>> Security Associations among all ITR->ETR conversations? >>>> >>>>> The message should further not be dropped by packet >>>>> filters on the path from the ETR to the ITR that filter >>>>> "naked" ICMP messages. >>>>> >>>>> Such LISP errors would need to be identified by a bit in >>>>> the LISP header (call it the 'E' bit) preferably adjacent >>>>> to the existing 'S' bit. The ETR sets the 'E' bit to tell >>>>> the ITR that this LISP packet contains an error, and not >>>>> an IPv4 nor IPv6 packet. The error could be formatted as >>>>> per an ICMPv4 or ICMPv6 error, but it need not be so. >>>>> For example, the packet could be constructed as: >>>>> >>>>> +-----------------+ >>>>> | Outer IP header | >>>>> +-----------------+ >>>>> | UDP header | >>>>> +-----------------+ >>>>> | LISP hdr (E=1) | >>>>> +-----------------+ >>>>> | ICMP header (?) | >>>>> +-----------------+ >>>>> | | >>>>> ~ Packet-in-error ~ >>>>> ~(up to 512 bytes)~ >>>>> | | >>>>> +-----------------+ >>>>> >>>>> Again, this would be the ETR's way of telling the ITR >>>>> that it is having trouble and perhaps a different ETR >>>> >>>> And since the ITR is so buggy, what makes you think it will listen > to >>>> what the ETR has to say? What happens if the ITR is malicious? >>>> >>>>> should be chosen. An exception would be a "packet too >>>>> big" error, in which the ITR would simply adjust its >>>>> packet sizes as long as the MTU reported by the ETR >>>>> is of a reasonable size. >>>>> >>>>> As with any network-based error message feedback, this >>>>> is susceptible to on-path attacks. It is resilient >>>>> against off-path attacks, however. >>>>> >>>>> Comments? >>>> >>>> With all due respect Fred, when I first read this, I checked the > date >>>> on my calendar to make sure it wasn't April 1st. >>>> >>>> The only reason I make this statement above is because you asked > for >>>> comments. >>>> >>>> Dino >>>> >>>>> >>>>> >>>>> Fred >>>>> fred.l.templin@boeing.com >>>>> _______________________________________________ >>>>> 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 Fred.L.Templin@boeing.com Mon Apr 27 09:58:24 2009 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 E8C1B3A6A7A for ; Mon, 27 Apr 2009 09:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 JgQ26KXpYiiY for ; Mon, 27 Apr 2009 09:58:23 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A7A503A6863 for ; Mon, 27 Apr 2009 09:58:23 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3RGxceB013639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2009 11:59:39 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3RGxcWp025164; Mon, 27 Apr 2009 09:59:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3RGxcSf025153; Mon, 27 Apr 2009 09:59:38 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 09:59:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 09:59:29 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnHV3OQWKlB56qiSdGnPBja64+iOAAABegQ References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com><49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com><6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com><75D6916F-D729-405E-AF90-795B31211183@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 27 Apr 2009 16:59:32.0907 (UTC) FILETIME=[897717B0:01C9C759] Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 16:58:25 -0000 Dino, > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, April 27, 2009 9:45 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP errors >=20 > But the point is, what would the ITR do with such error information if > it could be scalably transmitted. In order to answer this, we would have to begin by enumerating the sorts of errors that could happen at the LISP level. Examples: - Parameter Problem (e.g., the version field following the LISP header contains an unknown value). Do not discount the importance of this one in particular, since it can be used by the ITR to determine whether or not this ETR implements a new function. - Packet Too Big - packets sent by the ITR are being fragmented by the network. The ITR should begin limiting the size of the packets it sends. - Destination Unreachable - no route. The FIB in the ETR is inconsistent with what appears in the mapping tables. The ITR should really try a different ETR. - Destination Unreachable - protocol unreachable. The ETR somehow is in a funky state in which it can receive encapsulated packets and decapsulate them, but it can't forward them further, e.g. because the inner IP stack is down. - Destination Unreachable - administratively prohibited. This is a case study unto itself - Destination Unreachable - failed ingress/egress filtering. Ditto. - others? Fred fred.l.templin@boeing.com >=20 > Dino >=20 > On Apr 27, 2009, at 9:38 AM, Templin, Fred L wrote: >=20 > > Dino, > > > >> I just can't see how this idea can scale. > > > > Then, I will give you just one more thought for now: > > *rate limit*! > > > > Fred > > fred.l.templin@boeing.com > > > >> Dino > >> > >> On Apr 27, 2009, at 7:01 AM, Templin, Fred L wrote: > >> > >>> Dino, > >>> > >>> You can belittle all you want; just remember that you > >>> heard it here first. > >>> > >>> Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: Dino Farinacci [mailto:dino@cisco.com] > >>>> Sent: Saturday, April 25, 2009 4:57 PM > >>>> To: Templin, Fred L > >>>> Cc: lisp@ietf.org > >>>> Subject: Re: [lisp] LISP errors > >>>> > >>>>> In addition to errors that may occur along the path from > >>>>> the ITE to the ETE *before* decapsulation and errors that > >>>> > >>>> You mean from ITR to ETR (since this is a LISP mailing list post). > >>>> > >>>>> may occur along the path from the ETE to the final > >>>>> destination *after* decapsulation, errors may also occur > >>>>> *during* decapsulation. An example is what if the ETR > >>>>> decapsulates the outer IP header, but the inner IP stack > >>>>> is not configured? (Answer is that the ITR should receive > >>>>> an error by which it can ascertain that this ETR is having > >>>>> trouble, and should start using a different ETR instead.) > >>>> > >>>> This is unlikely in most implementations. If the IP stack is not > >>>> configured the decapsulation wouldn't have happened. And that's > >>>> because the IP packet would arrive on an interface and IP wouldn't > >>>> process it. > >>>> > >>>> So Fred, you really don't want to send per-packet errors. You don't > >>>> want to send errors at all actually. > >>>> > >>>> What if a regular IP packet had a source address of say 127.0.0.1, > >>>> 224.1.1.1, or 0.0.0.0? Do we send errors for these situations? > > First, > >>>> you don't want hardware forwarding engines to test for all these > >>>> invalid addresses, and second, you don't want the control-plane to > >>>> have to deal with per packet errors. > >>>> > >>>> IP is best-effort and drops packets, that's one of the best > > features > >>>> the Internet architecture has. > >>>> > >>>>> This gives rise to a type of error message that is neither > >>>>> fish nor fowl, i.e., it is neither an RLOC-based nor an > >>>>> EID-based ICMP error - it is a *LISP* error instead. One > >>>> > >>>> Not true. What if a NAT in the middle swapped a source address from > > a > >>>> good address to 224.1.1.1? > >>>> > >>>> Putting the blame to which protocol component is in error and > > trying > >>>> to take action is not fruitful at all. In fact, it is rather > >>>> damaging. > >>>> > >>>>> approach is to have the ETR send such a LISP error back > >>>>> to the ITR with enough identifying credentials such that > >>>>> the ITR can be reasonably sure the message is authentic. > >>>> > >>>> Ah man, you are making the solution even harder. So you want pair- > >>>> wise > >>>> Security Associations among all ITR->ETR conversations? > >>>> > >>>>> The message should further not be dropped by packet > >>>>> filters on the path from the ETR to the ITR that filter > >>>>> "naked" ICMP messages. > >>>>> > >>>>> Such LISP errors would need to be identified by a bit in > >>>>> the LISP header (call it the 'E' bit) preferably adjacent > >>>>> to the existing 'S' bit. The ETR sets the 'E' bit to tell > >>>>> the ITR that this LISP packet contains an error, and not > >>>>> an IPv4 nor IPv6 packet. The error could be formatted as > >>>>> per an ICMPv4 or ICMPv6 error, but it need not be so. > >>>>> For example, the packet could be constructed as: > >>>>> > >>>>> +-----------------+ > >>>>> | Outer IP header | > >>>>> +-----------------+ > >>>>> | UDP header | > >>>>> +-----------------+ > >>>>> | LISP hdr (E=3D1) | > >>>>> +-----------------+ > >>>>> | ICMP header (?) | > >>>>> +-----------------+ > >>>>> | | > >>>>> ~ Packet-in-error ~ > >>>>> ~(up to 512 bytes)~ > >>>>> | | > >>>>> +-----------------+ > >>>>> > >>>>> Again, this would be the ETR's way of telling the ITR > >>>>> that it is having trouble and perhaps a different ETR > >>>> > >>>> And since the ITR is so buggy, what makes you think it will listen > > to > >>>> what the ETR has to say? What happens if the ITR is malicious? > >>>> > >>>>> should be chosen. An exception would be a "packet too > >>>>> big" error, in which the ITR would simply adjust its > >>>>> packet sizes as long as the MTU reported by the ETR > >>>>> is of a reasonable size. > >>>>> > >>>>> As with any network-based error message feedback, this > >>>>> is susceptible to on-path attacks. It is resilient > >>>>> against off-path attacks, however. > >>>>> > >>>>> Comments? > >>>> > >>>> With all due respect Fred, when I first read this, I checked the > > date > >>>> on my calendar to make sure it wasn't April 1st. > >>>> > >>>> The only reason I make this statement above is because you asked > > for > >>>> comments. > >>>> > >>>> Dino > >>>> > >>>>> > >>>>> > >>>>> Fred > >>>>> fred.l.templin@boeing.com > >>>>> _______________________________________________ > >>>>> 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 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Apr 27 10:08:30 2009 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 1D78D3A68B9 for ; Mon, 27 Apr 2009 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 hTCx5hEBChPk for ; Mon, 27 Apr 2009 10:08:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 37D243A698F for ; Mon, 27 Apr 2009 10:08:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1238976000"; d="scan'208";a="73474225" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Apr 2009 17:09:50 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3RH9o2F005434; Mon, 27 Apr 2009 10:09:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RH9oM7007922; Mon, 27 Apr 2009 17:09:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 10:09:50 -0700 Received: from [192.168.1.2] ([10.21.80.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 10:09:49 -0700 Message-Id: <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Mon, 27 Apr 2009 10:09:49 -0700 References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com><49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com><6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com><75D6916F-D729-405E-AF90-795B31211183@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.4) X-OriginalArrivalTime: 27 Apr 2009 17:09:49.0586 (UTC) FILETIME=[F908D720:01C9C75A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=45; t=1240852190; x=1241716190; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20LISP=20errors |Sender:=20; bh=dDcM3I9SpW/hcncQGBcLWi0LtpYgb+OqQ/0CZ+Yoi0Y=; b=lUsJtZ2t8F+DOiX7uej14Pcw+M05cdVsdATWliTGiQCq4s151BOoh9F4no ha5fUdUrGyhK6prcG+GfuWcb6tUOU99SkheK9zQWYBUBvrpwNuwcGM7YtsVj U+MOhnQQbL; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 17:08:30 -0000 > - others? There are 100s more. Dino From Fred.L.Templin@boeing.com Mon Apr 27 10:17:29 2009 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 13DD63A6FB7 for ; Mon, 27 Apr 2009 10:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 cZHEU9fvArPg for ; Mon, 27 Apr 2009 10:17:28 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id C5E5A3A6FC5 for ; Mon, 27 Apr 2009 10:15:51 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3RHHBnG025324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 12:17:11 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3RHHAH0017904; Mon, 27 Apr 2009 10:17:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3RHH4go017702; Mon, 27 Apr 2009 10:17:10 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:17:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 10:17:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnHWv+k6vV1jl38RLSEEZSsdhDAuAAANJbA References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com><49F1DD38.4050801@joelhalpern.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com><6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com><75D6916F-D729-405E-AF90-795B31211183@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 27 Apr 2009 17:17:05.0989 (UTC) FILETIME=[FD26A750:01C9C75B] Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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, 27 Apr 2009 17:17:29 -0000 > There are 100s more. Then, let's just focus on the few that *really* matter; ICMPv4 and ICMPv6 were able to keep the lists bounded. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, April 27, 2009 10:10 AM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] LISP errors >=20 > > - others? >=20 > There are 100s more. >=20 > Dino >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From wwwrun@core3.amsl.com Tue Apr 28 13:28:10 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A27033A707F; Tue, 28 Apr 2009 13:28:10 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090428202810.A27033A707F@core3.amsl.com> Date: Tue, 28 Apr 2009 13:28:10 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] WG Action: Locator/ID Separation Protocol (lisp) 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, 28 Apr 2009 20:28:10 -0000 A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-04-23 Current status: Working Group Chair(s): Sam Hartman Darrel Lewis Internet Area Director(s): Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Technical Advisor(s): Joel Halpern Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. From hartmans@mit.edu Thu Apr 30 09:13:31 2009 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 1046F3A68E4 for ; Thu, 30 Apr 2009 09:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVXztg7RWB64 for ; Thu, 30 Apr 2009 09:13:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4E5843A67F7 for ; Thu, 30 Apr 2009 09:13:29 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E40F2415B; Thu, 30 Apr 2009 12:14:49 -0400 (EDT) To: lisp@ietf.org References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> From: Sam Hartman Date: Thu, 30 Apr 2009 12:14:49 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> (Fred L. Templin's message of "Mon\, 27 Apr 2009 10\:17\:04 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 16:13:31 -0000 >>>>> "Templin," == Templin, Fred L writes: >> There are 100s more. Templin,> Then, let's just focus on the few that *really* matter; Templin,> ICMPv4 and ICMPv6 were able to keep the lists bounded. Templin,> Fred fred.l.templin@boeing.com Fred has made a proposal that LISP needs a mechanism to indicate errors. Dino has raised scalability objections as well as an objection that the ITR would not be able to do anything useful with the information. I'd appreciate comments from others. I'd appreciate comments from Fred and Dino on how the motivations behind this mechanism differ from ICMP. My default presumption is that Dino's concerns apply to ICMP, but so does the value proposition--so that it would be valuable in many of the same ways that ICMP is valuable but that many of the same constraints to make sure it does not become unworkable would apply. In particular, I believe we've already had to deal with Dino's concern about sending to multicast, local or other sources for both ICMPv4 and ICMPv6. From olivier.bonaventure@uclouvain.be Thu Apr 30 09:27:49 2009 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 3F56C3A677D for ; Thu, 30 Apr 2009 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNLA8HS6E70k for ; Thu, 30 Apr 2009 09:27:48 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id E85873A67F7 for ; Thu, 30 Apr 2009 09:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=3W8fqxbErT0EXqptlUi3dhFnKdI=; b=tibwgs9WVW C7N5ZN/AhTKofja4OrSPtgivO7ZiDl3ZWxmZePu9iTwuNvjSSFjcY3A7PA3uTBbg xajhnDNlhVdeMeX2rxqtLKEkDhNYraGLoXcSxD8IWN709mEw0Q9k0VHw3YZw1C/E J7ZLKJKnt6fv8zeDDCJC9kw5i4DdFFfiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=SFrMt k6JI2Ly4AzugWTuFjk823atuONxI65QiZA71RAfv9QsYdecS0R+EJJzfu51JC8EC MJEKCzRiwvEGF0KsazBLSKn47zUvOJ99eG/iGLYFXzCLjj1DMy+BOuU4X+bf2Hmv ykncqM1FZByQQBkLwCzsuM3qGGdKQ/Pq1aeuk0= Received: from mbpobo.local (ip-83-134-219-4.dsl.scarlet.be [83.134.219.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 30 Apr 2009 18:29:05 +0200 (CEST) Message-ID: <49F9D1CF.3030800@uclouvain.be> Date: Thu, 30 Apr 2009 18:29:03 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Sam Hartman References: <49F02E91.8050209@firstpr.com.au> <2A46347B-8C47-4DA1-86E3-28D02EE52EE2@cisco.com> <49F0BAC4.8080907@joelhalpern.com> <20090423202401.GK70118@cisco.com> <49F1DD38.4050801@joelhalpern.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 62B83CF308.1F1D1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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, 30 Apr 2009 16:27:49 -0000 Sam, > > >> There are 100s more. > Templin,> Then, let's just focus on the few that *really* matter; > Templin,> ICMPv4 and ICMPv6 were able to keep the lists bounded. > > Templin,> Fred fred.l.templin@boeing.com > > Fred has made a proposal that LISP needs a mechanism to indicate > errors. Dino has raised scalability objections as well as an > objection that the ITR would not be able to do anything useful with > the information. > > I'd appreciate comments from others. I think that once we'll have a stable definition of the lisp protocol, we'll need to define the error cases that will trigger the transmission of an ICMP message. Although ICMP has clear drawbacks, I'm not convinced that we can simply discard all packets in error. There are some errors that may lead to the generation of an ICMP message. The protocol spec will also need to discuss how an xTR will behave upon reception of an ICMP message. Olivier > I'd appreciate comments from Fred and Dino on how the motivations > behind this mechanism differ from ICMP. My default presumption is > that Dino's concerns apply to ICMP, but so does the value > proposition--so that it would be valuable in many of the same ways > that ICMP is valuable but that many of the same constraints to make > sure it does not become unworkable would apply. > In particular, I believe we've already had to deal with Dino's concern about sending to multicast, local or other sources for both ICMPv4 and ICMPv6. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From swb@employees.org Thu Apr 30 09:29:07 2009 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 841FD3A6E4E for ; Thu, 30 Apr 2009 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+ZBg-YB8+cT for ; Thu, 30 Apr 2009 09:29:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8B4453A67F7 for ; Thu, 30 Apr 2009 09:29:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238976000"; d="scan'208";a="43107693" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Apr 2009 16:30:28 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UGUSfZ005686 for ; Thu, 30 Apr 2009 12:30:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UGUSN9016921 for ; Thu, 30 Apr 2009 16:30:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 12:30:28 -0400 Received: from cisco.com ([10.86.250.41]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 12:30:27 -0400 Date: Thu, 30 Apr 2009 12:30:21 -0400 From: Scott Brim To: lisp@ietf.org Message-ID: <20090430163021.GH338@cisco.com> Mail-Followup-To: Scott Brim , lisp@ietf.org References: <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 30 Apr 2009 16:30:27.0530 (UTC) FILETIME=[F860F2A0:01C9C9B0] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 16:29:07 -0000 Excerpts from Sam Hartman on Thu, Apr 30, 2009 12:14:49PM -0400: > >>>>> "Templin," == Templin, Fred L writes: > > >> There are 100s more. > Templin,> Then, let's just focus on the few that *really* matter; > Templin,> ICMPv4 and ICMPv6 were able to keep the lists bounded. > > Templin,> Fred fred.l.templin@boeing.com > > Fred has made a proposal that LISP needs a mechanism to indicate > errors. Dino has raised scalability objections as well as an > objection that the ITR would not be able to do anything useful with > the information. > > I'd appreciate comments from others. If I understand Fred's scenario correctly, I would not put the error handling in LISP. If I'm correct: Site A encapsulates a packet and sends it to Site B. The packet is correctly delivered to Site B's ETR. The ETR correctly decapsulates it. AFTER THAT, a forwarding function looks at the unencapsulated packet and discovers it doesn't understand the packet (wrong protocol version?), or there is something else wrong with it. This is not a LISP error -- LISP did its job correctly. It is either a configuration error or a forwarding error and it should be handled as such errors are handled today, outside the scope of LISP. If an ordinary router, today, sees an IP packet with a bad version number, what does it do? What do the endpoints do in response? Etc. Scott From robert@raszuk.net Thu Apr 30 09:59:39 2009 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 267B23A6F59 for ; Thu, 30 Apr 2009 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3ql+QUln-rX for ; Thu, 30 Apr 2009 09:59:38 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 2A49B3A6E95 for ; Thu, 30 Apr 2009 09:59:38 -0700 (PDT) Received: (qmail 6260 invoked by uid 399); 30 Apr 2009 17:01:00 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.24.19.185) by mail37.opentransfer.com with SMTP; 30 Apr 2009 17:01:00 -0000 Message-ID: <49F9D949.6050008@raszuk.net> Date: Thu, 30 Apr 2009 10:00:57 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Scott Brim , lisp@ietf.org References: <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> <20090430163021.GH338@cisco.com> In-Reply-To: <20090430163021.GH338@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net 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, 30 Apr 2009 16:59:39 -0000 Hi Scott, I think if I read Fred's proposal correctly he is talking about the errors at the ETR. ETR will most likely be a router so we can not say that once the packet is decapsulated it is no longer, a LISP business. LISP is part of end to end architecture and will be in this experiment used as a transport. Even if we say this is not part of LISP ... it is clearly in the ITRs interest to know as much as possible about health of ETRs he is sending data to and to gather as much as possible hints on what good or bad is happening with those packets. Remember it is almost given that ITRs & ETRs will be sitting in different administrative domains. I am in favour of defining finite set of error messages even if those happen after decapsulation and triggering ICMP to ITR to take some action on it. At min it could be just a syslog action, for more intelligent ITRs that could be skipping given ETR from the dst points :). Otherwise how would you propose to detect malfunctioning ETR if ITR uses N of them simultaneously ? You ping all they all respond it is just that one has a crashed RIB/FIB. Cheers, R. > Excerpts from Sam Hartman on Thu, Apr 30, 2009 12:14:49PM -0400: >>>>>>> "Templin," == Templin, Fred L writes: >> >> There are 100s more. >> Templin,> Then, let's just focus on the few that *really* matter; >> Templin,> ICMPv4 and ICMPv6 were able to keep the lists bounded. >> >> Templin,> Fred fred.l.templin@boeing.com >> >> Fred has made a proposal that LISP needs a mechanism to indicate >> errors. Dino has raised scalability objections as well as an >> objection that the ITR would not be able to do anything useful with >> the information. >> >> I'd appreciate comments from others. > > If I understand Fred's scenario correctly, I would not put the error > handling in LISP. If I'm correct: Site A encapsulates a packet and > sends it to Site B. The packet is correctly delivered to Site B's > ETR. The ETR correctly decapsulates it. AFTER THAT, a forwarding > function looks at the unencapsulated packet and discovers it doesn't > understand the packet (wrong protocol version?), or there is something > else wrong with it. This is not a LISP error -- LISP did its job > correctly. It is either a configuration error or a forwarding error > and it should be handled as such errors are handled today, outside the > scope of LISP. If an ordinary router, today, sees an IP packet with a > bad version number, what does it do? What do the endpoints do in > response? Etc. > > Scott > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > From jnc@mercury.lcs.mit.edu Thu Apr 30 10:23:49 2009 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 0DBA43A6900 for ; Thu, 30 Apr 2009 10:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 ovTp8tcFDwH8 for ; Thu, 30 Apr 2009 10:23:48 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 616F23A6767 for ; Thu, 30 Apr 2009 10:23:48 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 624746BE589; Thu, 30 Apr 2009 13:25:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090430172510.624746BE589@mercury.lcs.mit.edu> Date: Thu, 30 Apr 2009 13:25:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 17:23:49 -0000 > From: Olivier Bonaventure > The protocol spec will also need to discuss how an xTR will behave upon > reception of an ICMP message. And also how the xTR can make sure the ICMP message is not spurious, and intended to perform a DoS attack. Etc, etc. My instinct would be to leave dealing with a lot of this until we have some more operation experience to make sure the whole direction is worthwhile - i.e. that lookup delays are tolerable, mapping caching behaviour plausible, etc, etc. Sure, if we run into _operational_ issues with our field trial that require them, then by all means we should go ahead and spec the ones we need for that right away. Otherwise, they can probably wait for a bit... Noel From Fred.L.Templin@boeing.com Thu Apr 30 10:49:47 2009 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 C68933A6D8E for ; Thu, 30 Apr 2009 10:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 5Tuaq0t4r22r for ; Thu, 30 Apr 2009 10:49:47 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id CACBC3A6A22 for ; Thu, 30 Apr 2009 10:49:46 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UHp0Qs015810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 12:51:02 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UHoxib010923; Thu, 30 Apr 2009 12:50:59 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UHosX1010716; Thu, 30 Apr 2009 12:50:59 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 10:50:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 10:50:52 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105E1EAC9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090430172510.624746BE589@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnJuKDhXr+MoCjiT625T2ZJXY5bpwAAhQzw References: <20090430172510.624746BE589@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 30 Apr 2009 17:50:54.0018 (UTC) FILETIME=[35309220:01C9C9BC] Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 17:49:47 -0000 There seems to be points for discussion on both sides of the coin regarding whether/not LISP errors are needed, and I think I agree with what I hear others saying which is that we don't have to solve it all right now. I don't have time right now to work up an exhaustive list of LISP errors (but see the short list in my previous message), but I'd like to add one thought for now to see if it sheds more light on the considerations. Consider the ITR and ETR as being the left and right halves of a unified router that are simply split apart with an Internet stuck in between them. We can therefore abstract away the Internet (along with all of its ICMP "noise"), and consider LISP errors simply as a way for the right half of the unified router to tell left half what is going on. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Thursday, April 30, 2009 10:25 AM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] LISP errors >=20 >=20 > > From: Olivier Bonaventure >=20 > > The protocol spec will also need to discuss how an xTR will behave upon > > reception of an ICMP message. >=20 > And also how the xTR can make sure the ICMP message is not spurious, and > intended to perform a DoS attack. >=20 > Etc, etc. >=20 >=20 > My instinct would be to leave dealing with a lot of this until we have some > more operation experience to make sure the whole direction is worthwhile - > i.e. that lookup delays are tolerable, mapping caching behaviour plausible, > etc, etc. >=20 > Sure, if we run into _operational_ issues with our field trial that require > them, then by all means we should go ahead and spec the ones we need for that > right away. Otherwise, they can probably wait for a bit... >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Thu Apr 30 12:03:56 2009 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 CDC3928C176 for ; Thu, 30 Apr 2009 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7V9pbcFISSH for ; Thu, 30 Apr 2009 12:03:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 4141D28C349 for ; Thu, 30 Apr 2009 12:01:31 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 483EA415B; Thu, 30 Apr 2009 15:02:50 -0400 (EDT) To: Scott Brim References: <39C363776A4E8C4A94691D2BD9D1C9A105DAE13E@XCH-NW-7V2.nw.nos.boeing.com> <6F26E415-45C6-4530-A002-AE6DC2DEF92F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE346@XCH-NW-7V2.nw.nos.boeing.com> <75D6916F-D729-405E-AF90-795B31211183@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE4D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE511@XCH-NW-7V2.nw.nos.boeing.com> <1D456EB0-46E2-4492-A180-89789C7CA874@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A105DAE553@XCH-NW-7V2.nw.nos.boeing.com> <20090430163021.GH338@cisco.com> From: Sam Hartman Date: Thu, 30 Apr 2009 15:02:50 -0400 In-Reply-To: <20090430163021.GH338@cisco.com> (Scott Brim's message of "Thu\, 30 Apr 2009 12\:30\:21 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 19:03:56 -0000 >>>>> "Scott" == Scott Brim writes: Scott> Excerpts from Sam Hartman on Thu, Apr 30, 2009 12:14:49PM Scott> -0400: >> >>>>> "Templin," == Templin, Fred L >> writes: >> >> >> There are 100s more. Templin,> Then, let's just focus on >> the few that *really* matter; Templin,> ICMPv4 and ICMPv6 were >> able to keep the lists bounded. >> >> Templin,> Fred fred.l.templin@boeing.com >> >> Fred has made a proposal that LISP needs a mechanism to >> indicate errors. Dino has raised scalability objections as >> well as an objection that the ITR would not be able to do >> anything useful with the information. >> >> I'd appreciate comments from others. Scott> If I understand Fred's scenario correctly, I would not put Scott> the error handling in LISP. If I'm correct: Site A Scott> encapsulates a packet and sends it to Site B. The packet Scott> is correctly delivered to Site B's ETR. The ETR correctly Scott> decapsulates it. Scott, I believe as others have said that we're talking about problems decapsulating the packet. However I suspect you're quite familiar with a similar situation from MPLS. If I get an MPLS error trying to pop a label--for example I didn't distribute that label over the incoming interface, what do I do? What about TTL handling in the MPLS network? When I generate errors do I send them towards the original source of the packet or do I send them to the entity who sent an MPLS packet to me? Is this different with TE tunnels? From jnc@mercury.lcs.mit.edu Thu Apr 30 13:01:49 2009 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 0FD3B3A6FE4 for ; Thu, 30 Apr 2009 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 JAWq3Sogd30Z for ; Thu, 30 Apr 2009 13:01:48 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3C4EF3A6D84 for ; Thu, 30 Apr 2009 13:01:47 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 748D56BE589; Thu, 30 Apr 2009 16:03:10 -0400 (EDT) To: lisp@ietf.org Message-Id: <20090430200310.748D56BE589@mercury.lcs.mit.edu> Date: Thu, 30 Apr 2009 16:03:10 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 20:01:49 -0000 > From Fred.L.Templin@boeing.com Thu Apr 30 13:51:11 2009 > Consider the ITR and ETR as being the left and right halves of a > unified router that are simply split apart with an Internet stuck in > between them. Oh, wow, half-gateways - for the elderly among us, those words bring back memories! (See, e.g., RFC-1009!) :-) But to be serious, I have previously discussed (on the RRG list, back in December) my notion that in some sense what we're building is _another_ packet switching layer, one which uses the legacy Internet as a giant NBMA 'local' network underneath it. (An ITR has to run 'routing' to figure out what the 'next-hop' ETR is, make sure it's not down, etc, etc...) (When discussing this concept with some other LISP people, I got the sense that they didn't buy it.... but I still think there's enough truth to it for it to be a useful mental model! :-) I'l have to think whether this new model you mention (the half-router one) is one that brings any useful improvement; right off the top of my head I don't see any, but my brain is kind of frazzled today. Can you show me any ways in which the 'half-router' model helps conceptually, in a way the 'new packet switching layer' one does not? Noel From Fred.L.Templin@boeing.com Thu Apr 30 13:19:13 2009 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 2E2EF3A6DFC for ; Thu, 30 Apr 2009 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 VVBEOHymWgcL for ; Thu, 30 Apr 2009 13:19:12 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 471663A6D6F for ; Thu, 30 Apr 2009 13:19:12 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UKKYro002718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Apr 2009 13:20:34 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UKKXEI003890; Thu, 30 Apr 2009 15:20:33 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UKKRsV003495; Thu, 30 Apr 2009 15:20:33 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 13:20:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 13:20:30 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105E1EC10@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090430200310.748D56BE589@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnJzrKc7VkULwANSRmK/gJFp9DASAAADR6g References: <20090430200310.748D56BE589@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 30 Apr 2009 20:20:31.0173 (UTC) FILETIME=[1BFDB750:01C9C9D1] Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 20:19:13 -0000 Noel, Trying to clarify a bit, I'm thinking of the ITR as a "left-half-router" that can in some sense be thought of as being paired with an ETR as the "right-half-router" when the ETR receives a tunneled packet. So, the ITR will pair with many ETRs (not just one), but the pairing is temporal and lasts only for the duration of the delivery of the packet to the ETR's LISP process. At that precise moment in time, it is as if the ITR and ETR LISP processes were co-resident within the same physical box and passing a message via IPC, and the Internet is abstracted away. So, any errors that need to be conveyed would be specific to the IPC protocol (in this case, LISP) and not to the (abstracted away) network layer.=20 I'm not trying to claim any originality here; just trying a conceptual model on for size. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Thursday, April 30, 2009 1:03 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [lisp] LISP errors >=20 >=20 > > From Fred.L.Templin@boeing.com Thu Apr 30 13:51:11 2009 >=20 > > Consider the ITR and ETR as being the left and right halves of a > > unified router that are simply split apart with an Internet stuck in > > between them. >=20 > Oh, wow, half-gateways - for the elderly among us, those words bring back > memories! (See, e.g., RFC-1009!) :-) >=20 > But to be serious, I have previously discussed (on the RRG list, back in > December) my notion that in some sense what we're building is _another_ > packet switching layer, one which uses the legacy Internet as a giant NBMA > 'local' network underneath it. (An ITR has to run 'routing' to figure out > what the 'next-hop' ETR is, make sure it's not down, etc, etc...) >=20 > (When discussing this concept with some other LISP people, I got the sense > that they didn't buy it.... but I still think there's enough truth to it for > it to be a useful mental model! :-) >=20 > I'l have to think whether this new model you mention (the half-router one) is > one that brings any useful improvement; right off the top of my head I don't > see any, but my brain is kind of frazzled today. Can you show me any ways in > which the 'half-router' model helps conceptually, in a way the 'new packet > switching layer' one does not? >=20 > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Fred.L.Templin@boeing.com Thu Apr 30 15:47:42 2009 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 9D46C3A688F for ; Thu, 30 Apr 2009 15:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 x1GweReGcrIZ for ; Thu, 30 Apr 2009 15:47:42 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0B9BA28C19D for ; Thu, 30 Apr 2009 15:46:11 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n3UMlPFx015771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 15:47:25 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n3UMlOx5005991; Thu, 30 Apr 2009 15:47:24 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n3UMlOOY005984; Thu, 30 Apr 2009 15:47:24 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 15:47:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:47:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105E1ED83@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090430200310.748D56BE589@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] LISP errors Thread-Index: AcnJzrKc7VkULwANSRmK/gJFp9DASAAFnUHQ References: <20090430200310.748D56BE589@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 30 Apr 2009 22:47:24.0722 (UTC) FILETIME=[A1469120:01C9C9E5] Subject: Re: [lisp] LISP errors 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: Thu, 30 Apr 2009 22:47:42 -0000 Noel, Another brief follow-up: =20 > But to be serious, I have previously discussed (on the RRG list, back in > December) my notion that in some sense what we're building is _another_ > packet switching layer, one which uses the legacy Internet as a giant NBMA > 'local' network underneath it. (An ITR has to run 'routing' to figure out > what the 'next-hop' ETR is, make sure it's not down, etc, etc...) Regarding NBMA, we have been closely tracking that model in RANGER/VET/SEAL/ISATAP for about 10 years now. Still, not meaning to claim originality or the like. Thanks - Fred fred.l.templin@boeing.com