From trac+lisp@trac.tools.ietf.org Fri Apr 1 01:40:12 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B283A6784 for ; Fri, 1 Apr 2011 01:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZy4HpVeaSnS for ; Fri, 1 Apr 2011 01:40:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 741C33A6783 for ; Fri, 1 Apr 2011 01:40:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5ZvQ-0002U9-GU; Fri, 01 Apr 2011 01:41:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 01 Apr 2011 08:41:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/74#comment:1 Message-ID: <077.9a27a208d959f51427357a1f4cb28bba@trac.tools.ietf.org> References: <068.db5abe2159ac4ec249bc5681aa7f49ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <068.db5abe2159ac4ec249bc5681aa7f49ef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #74: Deployment Scenarios (from R. Bonica review for the RTG directorate) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:40:12 -0000 #74: Deployment Scenarios (from R. Bonica review for the RTG directorate) Changes (by terry.manderson@…): * type: technical => editorial -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 1 01:49:57 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9393A63D3 for ; Fri, 1 Apr 2011 01:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4bgzNVbdqgu for ; Fri, 1 Apr 2011 01:49:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7319F3A63CB for ; Fri, 1 Apr 2011 01:49:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5a4u-0007Qj-Vq; Fri, 01 Apr 2011 01:51:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 01 Apr 2011 08:51:36 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/95#comment:1 Message-ID: <066.215b04c2fa9937d0f225db17ad8a2d78@trac.tools.ietf.org> References: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:49:57 -0000 #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) Changes (by terry.manderson@…): * priority: major => minor * type: technical => editorial -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 1 02:31:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908413A67A6 for ; Fri, 1 Apr 2011 02:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njX3iUp18DrD for ; Fri, 1 Apr 2011 02:31:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9D66A3A67A4 for ; Fri, 1 Apr 2011 02:31:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5ajF-0007oU-LW; Fri, 01 Apr 2011 02:33:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 01 Apr 2011 09:33:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/5#comment:3 Message-ID: <069.7b92de4d05e2f7f9c97989a7c71c9f63@trac.tools.ietf.org> References: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #5: protocol version in lisp header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:31:41 -0000 #5: protocol version in lisp header Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: As this issue evolved into map versioning it has been subsumed by the document lisp-map-versioning. Closing this issue here. Further concerns should be raised against lisp-map-versioning. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 1 02:50:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4ED53A6783 for ; Fri, 1 Apr 2011 02:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcLYJ6ueLd4I for ; Fri, 1 Apr 2011 02:50:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F21D83A6774 for ; Fri, 1 Apr 2011 02:49:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5b10-0003zo-Ic; Fri, 01 Apr 2011 02:51:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 01 Apr 2011 09:51:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/5#comment:4 Message-ID: <069.55f1967a2d5889d3d69f49e22fc191e8@trac.tools.ietf.org> References: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <060.0b90a9804fbd4caaeedd9cdd9ca4d9f2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #5: protocol version in lisp header X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:50:00 -0000 #5: protocol version in lisp header Changes (by terry.manderson@…): * status: resolved => closed -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 1 02:52:55 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1417F3A67B0 for ; Fri, 1 Apr 2011 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIOHYFTw8i4G for ; Fri, 1 Apr 2011 02:52:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4EA243A67AE for ; Fri, 1 Apr 2011 02:52:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5b3n-000425-7M; Fri, 01 Apr 2011 02:54:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 01 Apr 2011 09:54:31 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/64#comment:2 Message-ID: <077.ddc04298d44b76702998fbb751a15589@trac.tools.ietf.org> References: <068.200921803b020f7b2e6fe117ab763621@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <068.200921803b020f7b2e6fe117ab763621@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #64: Host based LISP implementations (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:52:55 -0000 #64: Host based LISP implementations (from Y. Rekhter's review) Changes (by terry.manderson@…): * type: technical => editorial -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From yakov@juniper.net Mon Apr 4 07:31:02 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7FEC28C118 for ; Mon, 4 Apr 2011 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.406 X-Spam-Level: X-Spam-Status: No, score=-106.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgLGKOEIkRI1 for ; Mon, 4 Apr 2011 07:31:00 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 3289F28C108 for ; Mon, 4 Apr 2011 07:30:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTZnWhPppQObPpniXN4ATdLHODI8J/J8e@postini.com; Mon, 04 Apr 2011 07:32:43 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 07:29:16 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p34EUtv69134; Mon, 4 Apr 2011 07:30:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104041430.p34EUtv69134@magenta.juniper.net> To: Eliot Lear In-Reply-To: <4D93541E.7020404@cisco.com> References: <057.078f7daa8dd3209507b0e7d5bc7da39a@trac.tools.ietf.org> <066.78965594e2a0942ac8660a75b80688ef@trac.tools.ietf.org> <201103291714.p2THEIv41513@magenta.juniper.net> <4D92464E.1060101@cisco.com> <201103301451.p2UEpMv24056@magenta.juniper.net> <4D93541E.7020404@cisco.com> X-MH-In-Reply-To: Eliot Lear message dated "Wed, 30 Mar 2011 18:02:38 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47186.1301927454.1@juniper.net> Date: Mon, 4 Apr 2011 07:30:55 -0700 From: Yakov Rekhter Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) 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, 04 Apr 2011 14:31:02 -0000 Eliot, > >> Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > >> and that undersized caches could cause excessive control traffic, > >> implementations MUST have some form of cache management in place. > >> The specific management mechanisms are beyond the scope of this > >> specification. > > The text you proposed above is insufficient as (a) it failed to > > mention that undersized caches could lead to cache thrashing, > > Rather than use the term "cache thrashing", I chose instead to describe > the effects of undersized caches, which is another way of saying... > cache thrashing. And it's a bit more descriptive. I would also argue > that it is important to be concise. Ok, let's go with describing the effects of undersized caches. > > (b) cache thrashing, in addition to excessive control traffic, > > could also result in dropping data (thus negatively affecting > > connectivity), > > I think the above text captures this as well. Perhaps you can point me to the specific part of the above text that "captures this as well", and specifically describes how undersized cache could result in dropping data. > > and (c) the detrimental effects of excessive > > control traffic due to thrashing could spread beyond the ITR/PTR > > that experiences thrashing. > > Control traffic has to go somewhere, right? "go somewhere" does not capture the fact that that the detrimental effect is spread beyong the ITR/PTR that experiences thrashing. > > Moreover, saying that an implementation must has "some form > > of cache management in place" is insufficinet, as what is needed > > is not just "some form" of cache management, but a mechanism > > that would allow to suppress thrashing. > > Fair enough. > > How about the following then: > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > and that undersized caches could cause excessive control traffic, > implementations MUST have some form of cache management in place > that prevents excessive network control traffic. The specific > management mechanisms are beyond the scope of this specification. > > This also keeps things concise. That still does not capture the fact that undersized caches could also result in dropping data (thus negatively affecting connectivity), and that the excessive control traffic could have detrimental effect beyond the ITR/PTR with the undersized cache. To address this how about the following: Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, undersized caches could result in dropping data (thus negatively affecting connectivity), and could cause excessive control traffic that could spread the detrimental effect of undersized caches beyond the ITR/PTR with the undersized cache. Therefore, implementations MUST have some form of cache management in place that prevents excessive network control traffic due to undersized caches. The specific management mechanisms are beyond the scope of this specification. > I also understand that others may be > uncomfortable about a normative MUST. I understand those concerns and > have thrashed (cough) both ways about that myself. Yakov. From yakov@juniper.net Mon Apr 4 07:36:39 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BE828C128 for ; Mon, 4 Apr 2011 07:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3KIAgC9xZcj for ; Mon, 4 Apr 2011 07:36:33 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 4AB8A28C108 for ; Mon, 4 Apr 2011 07:36:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTZnX0Xm8iJEgywAR1khms4cIQqHjEK+q@postini.com; Mon, 04 Apr 2011 07:38:15 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 07:34:57 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p34Eaav71142; Mon, 4 Apr 2011 07:36:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104041436.p34Eaav71142@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Thu, 31 Mar 2011 08:24:19 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <47389.1301927796.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 07:36:36 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 04 Apr 2011 14:36:39 -0000 Dino, > > Dino, > > > >> We did in -11. Here is the text at the end of section 12. > >> > >> There is a potential security risk implicit in the fact that ETRs > >> generate the EID prefix to which they are responding. In = > >> theory, an > >> ETR can claim a shorter prefix than it is actually responsible = > >> for. > >> Various mechanisms to ameliorate or resolve this issue will be > >> examined in the future, [LISP-SEC]. > > > > The text should elaborate a bit on what is exactly the "potential > > security risk", and specifically what are some of the implications > > of that risk. > = > "ETR can claim a shorter prefix than it is actually responsible for". That still does not describe the implications of that risk. > > Also, replace "In theory" with "Thus" (as the ETR can do this not just > > "in theory", but in practice as well). > = > In practice the implementation test mask-lengths and don't install = > coarse routes. Please point me to the text in the draft that specifies how an implementation can determine whether a route is "coarse". Yakov. > >> > >> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: > >> > >>> #27: ETR may claim a larger prefix than is delegated to it > >>> > >>> > >>> Comment(by yakov@=85): > >>> > >>> If the base LISP spec is not going to have additional mechanisms to > >>> address over-claiming, then I would suggest to add to the base LISP > >>> spec > >>> some text that would just describe the issue of over-claiming, and > >>> state > >>> that handling this issue is outside the scope of the document. > >>> > >>> -- = > >>> ---------------------------------- > >>> +----------------------------------------- > >>> Reporter: hartmans-ietf@=85 | Owner: > >>> Type: technical | Status: resolved > >>> Priority: major | Component: draft-ietf-lisp > >>> Severity: - | Resolution: fixed > >>> Keywords: | > >>> ---------------------------------- > >>> +----------------------------------------- > >>> > >>> Ticket URL: >>> :5 > >>>> > >>> lisp > >>> LISP WG document issues > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >> > >> > = > = From jnc@mercury.lcs.mit.edu Mon Apr 4 07:59:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A8628C108 for ; Mon, 4 Apr 2011 07:59:27 -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 82JQHC0dgk83 for ; Mon, 4 Apr 2011 07:59:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id EA8FF28C104 for ; Mon, 4 Apr 2011 07:59:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EA44A18C0E2; Mon, 4 Apr 2011 11:01:08 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110404150108.EA44A18C0E2@mercury.lcs.mit.edu> Date: Mon, 4 Apr 2011 11:01:08 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) 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, 04 Apr 2011 14:59:27 -0000 > From: Yakov Rekhter > how about the following: > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > undersized caches could result in dropping data (thus negatively > affecting connectivity), and could cause excessive control traffic > that could spread the detrimental effect of undersized caches > beyond the ITR/PTR with the undersized cache. Therefore, > implementations MUST have some form of cache management in place > that prevents excessive network control traffic due to undersized > caches. The specific management mechanisms are beyond the scope > of this specification. This mostly all looks fine, but I still don't get the wishy-washy "specific management mechanisms are beyond the scope of this specification". Despite my repeatedly asking on the list, nobody has mentioned any solution to this (very real) potential problem other than the time-honoured 'have a large enough cache'. Sure, we don't have to mandate that as _the_ solution (so if someone has some brilliant 'better mousetrap', they should feel free to go for it), but if it's the only one a group of very knowledgeable engineers/designers knows of, it's professional malfeasance (IMO) not to explicitly refer to that solution. Noel From yakov@juniper.net Mon Apr 4 08:22:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B2A28C114 for ; Mon, 4 Apr 2011 08:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.408 X-Spam-Level: X-Spam-Status: No, score=-106.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvjBAngAKLVv for ; Mon, 4 Apr 2011 08:22:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 70B4828C12B for ; Mon, 4 Apr 2011 08:22:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZnijhGuBXxt4C+I8+a1L3iMRXd4Y+rE@postini.com; Mon, 04 Apr 2011 08:24:00 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 08:19:47 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p34FLQv89317; Mon, 4 Apr 2011 08:21:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104041521.p34FLQv89317@magenta.juniper.net> To: Noel Chiappa In-Reply-To: <20110404150108.EA44A18C0E2@mercury.lcs.mit.edu> References: <20110404150108.EA44A18C0E2@mercury.lcs.mit.edu> X-MH-In-Reply-To: jnc@mercury.lcs.mit.edu (Noel Chiappa) message dated "Mon, 04 Apr 2011 11:01:08 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48462.1301930486.1@juniper.net> Date: Mon, 4 Apr 2011 08:21:26 -0700 From: Yakov Rekhter Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) 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, 04 Apr 2011 15:22:18 -0000 Noel, > > From: Yakov Rekhter > > > how about the following: > > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > > undersized caches could result in dropping data (thus negatively > > affecting connectivity), and could cause excessive control traffic > > that could spread the detrimental effect of undersized caches > > beyond the ITR/PTR with the undersized cache. Therefore, > > implementations MUST have some form of cache management in place > > that prevents excessive network control traffic due to undersized > > caches. The specific management mechanisms are beyond the scope > > of this specification. > > This mostly all looks fine, but I still don't get the wishy-washy > "specific management mechanisms are beyond the scope of this > specification". Despite my repeatedly asking on the list, nobody has > mentioned any solution to this (very real) potential problem other than > the time-honoured 'have a large enough cache'. > > Sure, we don't have to mandate that as _the_ solution (so if someone has some > brilliant 'better mousetrap', they should feel free to go for it), but if > it's the only one a group of very knowledgeable engineers/designers knows > of, it's professional malfeasance (IMO) not to explicitly refer to that > solution. How about the following modification of the text I proposed in my previous e-mail (the change is in the last sentence): Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, undersized caches could result in dropping data (thus negatively affecting connectivity), and could cause excessive control traffic that could spread the detrimental effect of undersized caches beyond the ITR/PTR with the undersized cache. Therefore, implementations MUST have some form of cache management in place that prevents excessive network control traffic due to undersized caches. While the specific management mechanisms are beyond the scope of this specification, we would like to note that one such possible mechanism would be to increase the cache size. Yakov. From dino@cisco.com Mon Apr 4 11:15:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90323A635F for ; Mon, 4 Apr 2011 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrLuEaOMT0+k for ; Mon, 4 Apr 2011 11:15:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8039E3A6359 for ; Mon, 4 Apr 2011 11:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2616; q=dns/txt; s=iport; t=1301941042; x=1303150642; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=gaJW3yOfqGdRT97MAQXdlpJ1e7kmbIJpXUuk8BLp+bs=; b=PIIT3AAbEOT1bGCd2pWp2JRfJTOZzV1jqhVwc8xuX6cTSfQ687YgSy6g lUj24u3XF3xoNzTFpr89r98EcFab3jHh+pLJBHj3IsvQTMkRtg3dqrr7z CebkOZbjPyezEsXWYiQCQ+Rj0q7cKSMofYyij/hEb26iiZYMEILrp28TJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIUKmk2rRDoH/2dsb2JhbAClYXeIeZtmnAOFawSFR4dcg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="289030024" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2011 18:17:21 +0000 Received: from [172.20.10.2] ([10.21.74.200]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p34IHIe2012627; Mon, 4 Apr 2011 18:17:20 GMT Message-Id: <82195F87-1B28-4E1B-92BD-41741362C4F8@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <201104041436.p34Eaav71142@magenta.juniper.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 4 Apr 2011 11:10:07 -0700 References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> <201104041436.p34Eaav71142@magenta.juniper.net> X-Mailer: Apple Mail (2.936) Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 04 Apr 2011 18:15:40 -0000 > Dino, > >>> Dino, >>> >>>> We did in -11. Here is the text at the end of section 12. >>>> >>>> There is a potential security risk implicit in the fact that ETRs >>>> generate the EID prefix to which they are responding. In >>>> theory, an >>>> ETR can claim a shorter prefix than it is actually responsible >>>> for. >>>> Various mechanisms to ameliorate or resolve this issue will be >>>> examined in the future, [LISP-SEC]. >>> >>> The text should elaborate a bit on what is exactly the "potential >>> security risk", and specifically what are some of the implications >>> of that risk. >> >> "ETR can claim a shorter prefix than it is actually responsible for". > > That still does not describe the implications of that risk. The security section talks about this risk. >>> Also, replace "In theory" with "Thus" (as the ETR can do this not =20= >>> just >>> "in theory", but in practice as well). >> >> In practice the implementation test mask-lengths and don't install >> coarse routes. > > Please point me to the text in the draft that specifies how an > implementation can determine whether a route is "coarse". See the security section. Dino > > Yakov. > >>>> >>>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >>>> >>>>> #27: ETR may claim a larger prefix than is delegated to it >>>>> >>>>> >>>>> Comment(by yakov@=85): >>>>> >>>>> If the base LISP spec is not going to have additional mechanisms =20= >>>>> to >>>>> address over-claiming, then I would suggest to add to the base =20 >>>>> LISP >>>>> spec >>>>> some text that would just describe the issue of over-claiming, and >>>>> state >>>>> that handling this issue is outside the scope of the document. >>>>> >>>>> --=20 >>>>> ---------------------------------- >>>>> +----------------------------------------- >>>>> Reporter: hartmans-ietf@=85 | Owner: >>>>> Type: technical | Status: resolved >>>>> Priority: major | Component: draft-ietf-lisp >>>>> Severity: - | Resolution: fixed >>>>> Keywords: | >>>>> ---------------------------------- >>>>> +----------------------------------------- >>>>> >>>>> Ticket URL: = >>>> :5 >>>>>> >>>>> lisp >>>>> LISP WG document issues >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>>> >> >> From yakov@juniper.net Mon Apr 4 11:36:48 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18293A6407 for ; Mon, 4 Apr 2011 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.114 X-Spam-Level: X-Spam-Status: No, score=-106.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoekfAB3AG3b for ; Mon, 4 Apr 2011 11:36:47 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 542D53A63D2 for ; Mon, 4 Apr 2011 11:36:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZoQBljqylAGtuhZO2Pi6X8RqerD+BrH@postini.com; Mon, 04 Apr 2011 11:38:30 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 11:33:34 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p34IZDv76021; Mon, 4 Apr 2011 11:35:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201104041835.p34IZDv76021@magenta.juniper.net> To: Dino Farinacci In-Reply-To: <82195F87-1B28-4E1B-92BD-41741362C4F8@cisco.com> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> <201104041436.p34Eaav71142@magenta.juniper.net> <82195F87-1B28-4E1B-92BD-41741362C4F8@cisco.com> X-MH-In-Reply-To: Dino Farinacci message dated "Mon, 04 Apr 2011 11:10:07 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <57316.1301942113.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 11:35:13 -0700 From: Yakov Rekhter Cc: lisp@ietf.org, lisp issue tracker Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it 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, 04 Apr 2011 18:36:48 -0000 Dino, > >>>> We did in -11. Here is the text at the end of section 12. > >>>> > >>>> There is a potential security risk implicit in the fact that ETRs > >>>> generate the EID prefix to which they are responding. In theory,= an > >>>> ETR can claim a shorter prefix than it is actually responsible fo= r. > >>>> Various mechanisms to ameliorate or resolve this issue will be > >>>> examined in the future, [LISP-SEC]. > >>> > >>> The text should elaborate a bit on what is exactly the "potential > >>> security risk", and specifically what are some of the implications > >>> of that risk. > >> > >> "ETR can claim a shorter prefix than it is actually responsible for". > > > > That still does not describe the implications of that risk. > = > The security section talks about this risk. > = > >>> Also, replace "In theory" with "Thus" (as the ETR can do this not = > >>> just > >>> "in theory", but in practice as well). > >> > >> In practice the implementation test mask-lengths and don't install > >> coarse routes. > > > > Please point me to the text in the draft that specifies how an > > implementation can determine whether a route is "coarse". > = > See the security section. Here is from the Security Considerations section of -11: There is a potential security risk implicit in the fact that ETRs generate the EID prefix to which they are responding. In theory, an ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future, [LISP-SEC]. The above text said *nothing* about the implications of the risk. The above text said *nothing* about how an implementation can determine whether a route is "coarse". Yakov. > >>>> > >>>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: > >>>> > >>>>> #27: ETR may claim a larger prefix than is delegated to it > >>>>> > >>>>> > >>>>> Comment(by yakov@=85): > >>>>> > >>>>> If the base LISP spec is not going to have additional mechanisms = > >>>>> to > >>>>> address over-claiming, then I would suggest to add to the base = > >>>>> LISP > >>>>> spec > >>>>> some text that would just describe the issue of over-claiming, and > >>>>> state > >>>>> that handling this issue is outside the scope of the document. > >>>>> > >>>>> -- = > >>>>> ---------------------------------- > >>>>> +----------------------------------------- > >>>>> Reporter: hartmans-ietf@=85 | Owner: > >>>>> Type: technical | Status: resolved > >>>>> Priority: major | Component: draft-ietf-lisp > >>>>> Severity: - | Resolution: fixed > >>>>> Keywords: | > >>>>> ---------------------------------- > >>>>> +----------------------------------------- > >>>>> > >>>>> Ticket URL: >>>>> :5 > >>>>>> > >>>>> lisp > >>>>> LISP WG document issues > >>>>> _______________________________________________ > >>>>> lisp mailing list > >>>>> lisp@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>>> > >> > >> > = > = From srinsubr@cisco.com Mon Apr 4 13:02:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FAA3A67B7 for ; Mon, 4 Apr 2011 13:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11g1tsuKsiYx for ; Mon, 4 Apr 2011 13:02:08 -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 A37E43A63D3 for ; Mon, 4 Apr 2011 13:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=srinsubr@cisco.com; l=2849; q=dns/txt; s=iport; t=1301947431; x=1303157031; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Yd5vQwLRnscxj/q29i0pS+pa7ts1IUGc1FVqrXK4IGY=; b=iGY6IO/4VyiJ5lnispSMzKqZdV4IffPw+74XbxltdljCnJX68K7n2iCh 9+++o8Kp7PaofpSJSGHTuxu6pvhJIqKo/LODeTISuIWwihg6+XsRDQoO/ RgaHkJKZTGuxe3a5+Cu1DJfSedagqDF8uVb5L0TpnHuGS4I9J3kxlwaa3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAM4jmk2rRDoI/2dsb2JhbAClYgJ3iHmdJpwShWsEhUeHXINhhVaDMg X-IronPort-AV: E=Sophos;i="4.63,299,1299456000"; d="scan'208";a="330460251" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2011 20:03:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34K3pEs032525; Mon, 4 Apr 2011 20:03:51 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 13:03:51 -0700 Received: from 128.107.112.119 ([128.107.112.119]) by xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Apr 2011 20:03:50 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 04 Apr 2011 13:04:05 -0700 From: Srinivas Subramanian To: Yakov Rekhter , Noel Chiappa Message-ID: Thread-Topic: [lisp] #46: Cache Thrashing (review by Y. Rekhter) Thread-Index: AcvzA3L/TLDsN9PNzUm+UgVP5/UlWw== In-Reply-To: <201104041521.p34FLQv89317@magenta.juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2011 20:03:51.0174 (UTC) FILETIME=[6AC1FA60:01CBF303] Cc: lisp@ietf.org Subject: Re: [lisp] #46: Cache Thrashing (review by Y. Rekhter) 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, 04 Apr 2011 20:02:10 -0000 >> >>> how about the following: >> >>> Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, >>> undersized caches could result in dropping data (thus negatively >>> affecting connectivity), and could cause excessive control traffic >>> that could spread the detrimental effect of undersized caches >>> beyond the ITR/PTR with the undersized cache. Therefore, >>> implementations MUST have some form of cache management in place >>> that prevents excessive network control traffic due to undersized >>> caches. The specific management mechanisms are beyond the scope >>> of this specification. >> >> This mostly all looks fine, but I still don't get the wishy-washy >> "specific management mechanisms are beyond the scope of this >> specification". Despite my repeatedly asking on the list, nobody has >> mentioned any solution to this (very real) potential problem other than >> the time-honoured 'have a large enough cache'. >> >> Sure, we don't have to mandate that as _the_ solution (so if someone has some >> brilliant 'better mousetrap', they should feel free to go for it), but if >> it's the only one a group of very knowledgeable engineers/designers knows >> of, it's professional malfeasance (IMO) not to explicitly refer to that >> solution. > > How about the following modification of the text I proposed in my previous > e-mail (the change is in the last sentence): > > Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, > undersized caches could result in dropping data (thus negatively > affecting connectivity), and could cause excessive control traffic > that could spread the detrimental effect of undersized caches > beyond the ITR/PTR with the undersized cache. Therefore, > implementations MUST have some form of cache management in place > that prevents excessive network control traffic due to undersized > caches. While the specific management mechanisms are beyond > the scope of this specification, we would like to note that one > such possible mechanism would be to increase the cache size. Another possible mechanism for undersized caches on ITRs - when an ITR detects that its cache has hit a high water mark, then it could install a coarse (catch all) entry and encapsulate data to a PETR. The PETR would decapsulate the traffic from the ITR and if it is also a PITR, it could re-encapsulate the traffic to the remote ETR using the EID-to-RLOC mappings in its cache. This might increase the stretch for data but would decrease the excessive control traffic and avoid the data traffic drops on the ITR caused by the excessive cache churn. -Srin > > Yakov. > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Internet-Drafts@ietf.org Tue Apr 5 08:00:10 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201C83A6949; Tue, 5 Apr 2011 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3L150+O+lwJ; Tue, 5 Apr 2011 08:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20E83A6947; Tue, 5 Apr 2011 08:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405150001.27481.31368.idtracker@localhost> Date: Tue, 05 Apr 2011 08:00:01 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-multicast-05.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:00:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP for Multicast Environments Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-multicast-05.txt Pages : 37 Date : 2011-04-05 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-multicast-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05074520.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Apr 5 08:00:11 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B923A6947; Tue, 5 Apr 2011 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3f31H1ptRW2; Tue, 5 Apr 2011 08:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F109D3A694C; Tue, 5 Apr 2011 08:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405150001.27481.5305.idtracker@localhost> Date: Tue, 05 Apr 2011 08:00:01 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-lig-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:00:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Internet Groper (LIG) Author(s) : D. Farinacci, D. Meyer Filename : draft-ietf-lisp-lig-02.txt Pages : 18 Date : 2011-04-05 A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-lig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05074612.I-D@ietf.org> --NextPart-- From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:35:41 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170FC3A6A58 for ; Fri, 8 Apr 2011 02:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8ZveA+sAWxk for ; Fri, 8 Apr 2011 02:35:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 47DA83A69B8 for ; Fri, 8 Apr 2011 02:35:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q8882-000060-94; Fri, 08 Apr 2011 02:37:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:37:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/4#comment:2 Message-ID: <093.20217a01952e3bfd464c4c724d23428a@trac.tools.ietf.org> References: <084.db5eb501d0b28549ddf3634d2b9c21ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <084.db5eb501d0b28549ddf3634d2b9c21ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #4: LISP errors X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:35:41 -0000 #4: LISP errors Changes (by luigi@…): * status: resolved => closed -- ----------------------------------------------------------+----------------- Reporter: "Templin, Fred L" | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: invalid Keywords: | ----------------------------------------------------------+----------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:36:50 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EBF28C0E2 for ; Fri, 8 Apr 2011 02:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtVEhVAcmNqT for ; Fri, 8 Apr 2011 02:36:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C186728C0DE for ; Fri, 8 Apr 2011 02:36:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q889A-0003QM-LB; Fri, 08 Apr 2011 02:38:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartmans-ietf@mit.edu, jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:38:32 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/13#comment:4 Message-ID: <066.791711f5f31f0ff1ecf62cfd56d1d4c7@trac.tools.ietf.org> References: <057.75f89d1aeb61c057c11462433095816f@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <057.75f89d1aeb61c057c11462433095816f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:36:50 -0000 #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: mrw@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: UDP checksums | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:40:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF76A3A69EE for ; Fri, 8 Apr 2011 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU8uyfTMzlRh for ; Fri, 8 Apr 2011 02:40:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 311883A6971 for ; Fri, 8 Apr 2011 02:40:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Cz-0000cN-R9; Fri, 08 Apr 2011 02:42:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:42:29 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/45#comment:6 Message-ID: <066.f8bd2005d43a044e38f823e3a3890f8e@trac.tools.ietf.org> References: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <057.5601b1e7a42fa9a9fa57276a7b7ac0eb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #45: LISP vs. Existing (from Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:40:49 -0000 #45: LISP vs. Existing (from Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:46:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C4C3A69EE for ; Fri, 8 Apr 2011 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mURmnKsi3SXy for ; Fri, 8 Apr 2011 02:45:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B911A3A6971 for ; Fri, 8 Apr 2011 02:45:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88I3-0008Eq-Ra; Fri, 08 Apr 2011 02:47:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:47:43 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/49#comment:5 Message-ID: <066.6dcd3a5f59275eac45df5491cfa8e5e7@trac.tools.ietf.org> References: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.53ee0fe910e8e7ef6a9927b83fe4cb81@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:46:00 -0000 #49: "MAP-Replies" content that is allowed to change (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:46:44 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F093A6971 for ; Fri, 8 Apr 2011 02:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I91tg4-XfOra for ; Fri, 8 Apr 2011 02:46:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E83943A67F3 for ; Fri, 8 Apr 2011 02:46:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Im-000167-04; Fri, 08 Apr 2011 02:48:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:48:27 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/50#comment:5 Message-ID: <066.71a8146ef7041df9bae74f7c491687fd@trac.tools.ietf.org> References: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <057.6fdc264209fe6bed0510ab4c5ab17307@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:46:44 -0000 #50: MAP-Replies content that MUST be invariant (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:47:27 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7633A6A4D for ; Fri, 8 Apr 2011 02:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2QMFHswQ7aq for ; Fri, 8 Apr 2011 02:47:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 864613A67F3 for ; Fri, 8 Apr 2011 02:47:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88JT-0002dp-QS; Fri, 08 Apr 2011 02:49:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:49:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/51#comment:2 Message-ID: <066.1031b2ec3d4e098b73fc511ee1d7b1cf@trac.tools.ietf.org> References: <057.afb9a72f6ee9de02e699ffa4cc31fd68@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <057.afb9a72f6ee9de02e699ffa4cc31fd68@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #51: Returning same locator-set for a given EID (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:47:27 -0000 #51: Returning same locator-set for a given EID (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:49:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF233A6A61 for ; Fri, 8 Apr 2011 02:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBt7lOkR1nNC for ; Fri, 8 Apr 2011 02:49:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 799CE3A69FF for ; Fri, 8 Apr 2011 02:49:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88LT-00048Z-FM; Fri, 08 Apr 2011 02:51:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:51:15 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/57#comment:7 Message-ID: <077.2cfd048b2f42d93b55eabbab55ecf718@trac.tools.ietf.org> References: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <068.ce085df57fc97c68212636551555c56c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:49:32 -0000 #57: How to determine EIDs not forwardable on the routable topology (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:50:32 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF3B3A6A5E for ; Fri, 8 Apr 2011 02:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4gfjRixTPDT for ; Fri, 8 Apr 2011 02:50:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2263E3A6A49 for ; Fri, 8 Apr 2011 02:50:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88MQ-00049H-CP; Fri, 08 Apr 2011 02:52:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:52:14 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/68#comment:6 Message-ID: <077.d06fa63c4dc85b35cec361144a71377c@trac.tools.ietf.org> References: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <068.f483118418ff0a04689ef79494e01869@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:50:33 -0000 #68: What is the source address for a negative reply, which has a zero length locator -set ? (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:51:21 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4326E3A6A49 for ; Fri, 8 Apr 2011 02:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSS7971UGj9g for ; Fri, 8 Apr 2011 02:51:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4A4553A69FF for ; Fri, 8 Apr 2011 02:51:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88NF-0004AU-GA; Fri, 08 Apr 2011 02:53:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:53:05 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/69#comment:4 Message-ID: <077.e1d5b3b321475ff3f37fb57d4509e615@trac.tools.ietf.org> References: <068.062591f9c2a73c88a94091fd86bb2c73@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <068.062591f9c2a73c88a94091fd86bb2c73@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:51:21 -0000 #69: Inadequate solution for ETR overclaims (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:52:08 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D6C3A6A61 for ; Fri, 8 Apr 2011 02:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5Geat2H341c for ; Fri, 8 Apr 2011 02:52:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C84E83A69FF for ; Fri, 8 Apr 2011 02:52:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88O0-0004B6-Vz; Fri, 08 Apr 2011 02:53:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:53:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/80#comment:2 Message-ID: <077.28a2ea398958b1d40740a918923e8777@trac.tools.ietf.org> References: <068.16cc2f76eb8757537cf620ea51234a22@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <068.16cc2f76eb8757537cf620ea51234a22@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #80: Router Performances X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:52:08 -0000 #80: Router Performances Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:53:09 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B453A69FF for ; Fri, 8 Apr 2011 02:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPMCucO9Zx1A for ; Fri, 8 Apr 2011 02:53:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 38FB63A69EE for ; Fri, 8 Apr 2011 02:53:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Oy-0004CZ-Le; Fri, 08 Apr 2011 02:54:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:54:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/84#comment:6 Message-ID: <066.1f64e76565102368296ef8b9ce5dfc21@trac.tools.ietf.org> References: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <057.c1bdfa25dec19e9e9f05544b409f4401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, wmhaddad@gmail.com, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:53:10 -0000 #84: Renumbering burden when clients change providers (comment 9 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:54:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DFE3A6A59 for ; Fri, 8 Apr 2011 02:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVNKyClJ2TYA for ; Fri, 8 Apr 2011 02:54:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D6B1D3A69E7 for ; Fri, 8 Apr 2011 02:54:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Q5-0004Lc-Rn; Fri, 08 Apr 2011 02:56:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:56:01 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/86#comment:2 Message-ID: <066.bf190e67866322ee422781e89b153546@trac.tools.ietf.org> References: <057.1f293e91cef920f8eee0de47c3c10e1d@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <057.1f293e91cef920f8eee0de47c3c10e1d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #86: On the design goals and requirements (comment 10 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:54:18 -0000 #86: On the design goals and requirements (comment 10 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:55:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E183A69EE for ; Fri, 8 Apr 2011 02:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxtFxxcIOHHz for ; Fri, 8 Apr 2011 02:55:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 192553A69E7 for ; Fri, 8 Apr 2011 02:55:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Qo-0004Na-9X; Fri, 08 Apr 2011 02:56:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:56:46 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/89#comment:5 Message-ID: <066.f1038016fd8fb59e97e2622ccdbfff01@trac.tools.ietf.org> References: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <057.915c3b2990c494d4d75d76e0f1fee088@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:55:04 -0000 #89: On redefining the name of the encapsulated packet header (comment 12 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:55:54 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AED3A6A59 for ; Fri, 8 Apr 2011 02:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLXP1lvIilKI for ; Fri, 8 Apr 2011 02:55:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DD38B3A69E7 for ; Fri, 8 Apr 2011 02:55:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Re-0004RC-3z; Fri, 08 Apr 2011 02:57:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:57:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/94#comment:5 Message-ID: <066.ef8df2ec5601d3e8edbdd53aa116d656@trac.tools.ietf.org> References: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <057.c2b1b0517ccbbb9b4e1f3be9554f775b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:55:54 -0000 #94: Implications on using Control plane for data forwarding (comment 15 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:56:40 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055933A69E7 for ; Fri, 8 Apr 2011 02:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQYFceB5G5dS for ; Fri, 8 Apr 2011 02:56:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 482723A69FF for ; Fri, 8 Apr 2011 02:56:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88SN-0004S0-Ix; Fri, 08 Apr 2011 02:58:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:58:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/96#comment:2 Message-ID: <066.a2d1e57c65f7bfdc891cc46440cb80a9@trac.tools.ietf.org> References: <057.6ff6aad30217bed0a620c320885db98b@trac.tools.ietf.org> X-Trac-Ticket-ID: 96 In-Reply-To: <057.6ff6aad30217bed0a620c320885db98b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #96: Confidence in informal Survey (comment 16 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:56:40 -0000 #96: Confidence in informal Survey (comment 16 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:57:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D6F3A6A59 for ; Fri, 8 Apr 2011 02:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j-ngk9g9Upm for ; Fri, 8 Apr 2011 02:57:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D1383A69E7 for ; Fri, 8 Apr 2011 02:57:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88TB-0004TB-GL; Fri, 08 Apr 2011 02:59:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 09:59:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/97#comment:2 Message-ID: <066.6eca6446ce6a4ef2412560db77c64477@trac.tools.ietf.org> References: <057.8ea20e7a00dec499bcff4e4fa48eacda@trac.tools.ietf.org> X-Trac-Ticket-ID: 97 In-Reply-To: <057.8ea20e7a00dec499bcff4e4fa48eacda@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #97: MTU concerns (comment 16 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:57:30 -0000 #97: MTU concerns (comment 16 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:58:18 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37C13A69FF for ; Fri, 8 Apr 2011 02:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCfCzSmfEpLs for ; Fri, 8 Apr 2011 02:58:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EF6C33A69EE for ; Fri, 8 Apr 2011 02:58:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Tw-0004UD-UF; Fri, 08 Apr 2011 03:00:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:00:00 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/98#comment:5 Message-ID: <066.7009e228366786e5473ded7bcb076324@trac.tools.ietf.org> References: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <057.4c9852b0a65d29853b641f556c39a295@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #98: LISP nonce (comment 17 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:58:18 -0000 #98: LISP nonce (comment 17 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:59:00 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03C83A69BC for ; Fri, 8 Apr 2011 02:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySi0je79vsq9 for ; Fri, 8 Apr 2011 02:59:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 003B23A69B8 for ; Fri, 8 Apr 2011 02:58:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Ue-0004AI-AJ; Fri, 08 Apr 2011 03:00:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:00:44 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/99#comment:2 Message-ID: <066.dd2e1f4289f2b78bd4f69b53765a4099@trac.tools.ietf.org> References: <057.412ba34f2babe03fe10d1234f260eba3@trac.tools.ietf.org> X-Trac-Ticket-ID: 99 In-Reply-To: <057.412ba34f2babe03fe10d1234f260eba3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #99: Confusion in Section 5.4.1 (comment 18 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:59:00 -0000 #99: Confusion in Section 5.4.1 (comment 18 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 02:59:49 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD0B3A69FF for ; Fri, 8 Apr 2011 02:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o58trA9B2qCC for ; Fri, 8 Apr 2011 02:59:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 932923A6A62 for ; Fri, 8 Apr 2011 02:59:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88VQ-0002yR-Fn; Fri, 08 Apr 2011 03:01:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:01:32 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/103#comment:2 Message-ID: <066.e58f6c4568730cb64a0f3db4a842fdfe@trac.tools.ietf.org> References: <057.d807df80a56b7add227b99565ce590d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <057.d807df80a56b7add227b99565ce590d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #103: Mapping Protocol Data (comment 20 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 09:59:49 -0000 #103: Mapping Protocol Data (comment 20 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 03:00:29 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE483A69FF for ; Fri, 8 Apr 2011 03:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLTgYBpKPgTG for ; Fri, 8 Apr 2011 03:00:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B22703A69B8 for ; Fri, 8 Apr 2011 03:00:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88W4-0002zR-I0; Fri, 08 Apr 2011 03:02:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:02:12 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/104#comment:2 Message-ID: <066.f1b2d9c6747002d8d6bbaad7aabcb701@trac.tools.ietf.org> References: <057.f694ed8ffc9311fa27f420bbc248f1c8@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <057.f694ed8ffc9311fa27f420bbc248f1c8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #104: Impact of slashdotting ETR (comment 21 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:00:29 -0000 #104: Impact of slashdotting ETR (comment 21 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 03:00:59 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0EB3A6A5E for ; Fri, 8 Apr 2011 03:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdpRAcd+hd-d for ; Fri, 8 Apr 2011 03:00:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EA423A69E7 for ; Fri, 8 Apr 2011 03:00:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88WY-00031f-OB; Fri, 08 Apr 2011 03:02:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:02:42 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/lisp/trac/ticket/106#comment:2 Message-ID: <066.8f38b99ff06372188c3bd0656afb9f82@trac.tools.ietf.org> References: <057.39e8e70821ba35f11c2eda95607db252@trac.tools.ietf.org> X-Trac-Ticket-ID: 106 In-Reply-To: <057.39e8e70821ba35f11c2eda95607db252@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:00:59 -0000 #106: Unassigned values in Map-Reply messages (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 03:01:29 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A639B3A69B8 for ; Fri, 8 Apr 2011 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urxxxdcB-1dV for ; Fri, 8 Apr 2011 03:01:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 119413A6A49 for ; Fri, 8 Apr 2011 03:01:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88X3-00035g-00; Fri, 08 Apr 2011 03:03:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:03:12 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/109#comment:2 Message-ID: <066.c248f47f537e90bad82acf634a69c3a8@trac.tools.ietf.org> References: <057.9c2e4d52ca3762d5ccd0de2094680378@trac.tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <057.9c2e4d52ca3762d5ccd0de2094680378@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #109: "Locator" in Map-reply message format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:01:29 -0000 #109: "Locator" in Map-reply message format (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 03:02:20 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5233928C0E2 for ; Fri, 8 Apr 2011 03:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4j3PuIqMLj9 for ; Fri, 8 Apr 2011 03:02:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 89FF13A69B8 for ; Fri, 8 Apr 2011 03:02:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q88Xr-0003Cv-QW; Fri, 08 Apr 2011 03:04:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 08 Apr 2011 10:04:03 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/71#comment:5 Message-ID: <077.c032af6b025886af299ffe5a8c274dda@trac.tools.ietf.org> References: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <068.671f82f82e7522e3783ce3ca2c9b02bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:02:20 -0000 #71: Missing description mechanism to make EID-to-RLOC (from D. Papadimitriou's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 8 06:17:30 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8614328C118 for ; Fri, 8 Apr 2011 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg8PP7iT0VHX for ; Fri, 8 Apr 2011 06:17:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DB08528C106 for ; Fri, 8 Apr 2011 06:17:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q8Bah-0007iC-BA; Fri, 08 Apr 2011 06:19:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 08 Apr 2011 13:19:11 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/25#comment:3 Message-ID: <069.7a774843346277e17abac00f665ba383@trac.tools.ietf.org> References: <060.d231c2fff311c375f62f929d7213d1c4@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <060.d231c2fff311c375f62f929d7213d1c4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jmh@joelhalpern.com, luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #25: Map Server to ETR security has no automated key management X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 13:17:30 -0000 #25: Map Server to ETR security has no automated key management Comment(by jmh@…): After discussion with the security folks, the current plan is to add material in the front (probably in the introduction) emphasizing the experimental nature of the work and noting that there are security issues which will need significant future attention in the event of a desire to take this to the standards track. That wording will need to be checked with the WG and the authors of course. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: technical | Status: new Priority: blocker | Component: ms Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From ljakab@ac.upc.edu Fri Apr 8 12:10:24 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC203A6A10 for ; Fri, 8 Apr 2011 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBMP8XNxaFh2 for ; Fri, 8 Apr 2011 12:10:23 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 9B6163A6975 for ; Fri, 8 Apr 2011 12:10:23 -0700 (PDT) Received: from [192.168.1.133] (171.46.21.95.dynamic.jazztel.es [95.21.46.171]) by gw.ac.upc.edu (Postfix) with ESMTP id A36FD6B01DA; Fri, 8 Apr 2011 21:12:06 +0200 (CEST) Message-ID: <4D9F5E06.8010206@ac.upc.edu> Date: Fri, 08 Apr 2011 21:12:06 +0200 From: =?UTF-8?B?TG9yw6FuZCBKYWthYg==?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: LISP WG OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: New Version Notification for draft-jakab-lisp-deployment-03 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, 08 Apr 2011 19:10:24 -0000 Folks, We just posted an updated -03 addressing Jari's comment from Prague and some other minor editorial changes. We would like to kindly ask the chairs to consider the adoption of the document as a working group item. Thank you, -Lorand Jakab -------- Original Message -------- Subject: New Version Notification for draft-jakab-lisp-deployment-03 Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) From: IETF I-D Submission Tool To: ljakab@ac.upc.edu CC: acabello@ac.upc.edu, fcoras@ac.upc.edu, jordi.domingo@ac.upc.edu, darlewis@cisco.com A new version of I-D, draft-jakab-lisp-deployment-03.txt has been successfully submitted by Lorand Jakab and posted to the IETF repository. Filename: draft-jakab-lisp-deployment Revision: 03 Title: LISP Network Element Deployment Considerations Creation_date: 2011-04-08 WG ID: Independent Submission Number_of_pages: 21 Abstract: This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). The IETF Secretariat. From jmh@joelhalpern.com Fri Apr 8 12:14:03 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266973A69CC for ; Fri, 8 Apr 2011 12:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwR8rpClUnFi for ; Fri, 8 Apr 2011 12:13:59 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 6649D3A6975 for ; Fri, 8 Apr 2011 12:13:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EF9E4300E4; Fri, 8 Apr 2011 12:15:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-71.clppva.btas.verizon.net [71.161.52.71]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7E2474300EF; Fri, 8 Apr 2011 12:15:44 -0700 (PDT) Message-ID: <4D9F5EDA.2080506@joelhalpern.com> Date: Fri, 08 Apr 2011 15:15:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= References: <4D9F5E06.8010206@ac.upc.edu> In-Reply-To: <4D9F5E06.8010206@ac.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: LISP WG Subject: Re: [lisp] Fwd: New Version Notification for draft-jakab-lisp-deployment-03 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, 08 Apr 2011 19:14:03 -0000 Thank you Loránd. This starts a two week call for working group adoption of this document. Please respond to the list indicating whether you would like the WG to use this document as the basis for its work on documenting deployment considerations, or whether you see a difficulty with such adoption. Thank you, Joel (and Terry) On 4/8/2011 3:12 PM, Loránd Jakab wrote: > Folks, > > We just posted an updated -03 addressing Jari's comment from Prague and > some other minor editorial changes. > > We would like to kindly ask the chairs to consider the adoption of the > document as a working group item. > > Thank you, > -Lorand Jakab > > -------- Original Message -------- > Subject: New Version Notification for draft-jakab-lisp-deployment-03 > Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) > From: IETF I-D Submission Tool > To: ljakab@ac.upc.edu > CC: acabello@ac.upc.edu, fcoras@ac.upc.edu, jordi.domingo@ac.upc.edu, > darlewis@cisco.com > > > > A new version of I-D, draft-jakab-lisp-deployment-03.txt has been successfully submitted by Lorand Jakab and posted to the IETF repository. > > Filename: draft-jakab-lisp-deployment > Revision: 03 > Title: LISP Network Element Deployment Considerations > Creation_date: 2011-04-08 > WG ID: Independent Submission > Number_of_pages: 21 > > Abstract: > This document discusses the different scenarios for the deployment of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > > The IETF Secretariat. > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From luigi@net.t-labs.tu-berlin.de Mon Apr 11 05:19:42 2011 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309AE28C0FE for ; Mon, 11 Apr 2011 05:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1AqjvON-OuT for ; Mon, 11 Apr 2011 05:19:41 -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 2517C28C0FC for ; Mon, 11 Apr 2011 05:19:40 -0700 (PDT) Received: from dyn103.net.t-labs.tu-berlin.de (dyn103.net.t-labs.tu-berlin.de [130.149.220.103]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 311A2700D28D for ; Mon, 11 Apr 2011 14:19:40 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Luigi Iannone In-Reply-To: <4D9F5EDA.2080506@joelhalpern.com> Date: Mon, 11 Apr 2011 14:19:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9F5E06.8010206@ac.upc.edu> <4D9F5EDA.2080506@joelhalpern.com> To: lisp@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [lisp] Fwd: New Version Notification for draft-jakab-lisp-deployment-03 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, 11 Apr 2011 12:19:42 -0000 In favor of adoption. I will read the last version and provide feedback. Luigi On 8, Apr, 2011, at 21:15 , Joel M. Halpern wrote: > Thank you Lor=E1nd. > This starts a two week call for working group adoption of this = document. Please respond to the list indicating whether you would like = the WG to use this document as the basis for its work on documenting = deployment considerations, or whether you see a difficulty with such = adoption. >=20 > Thank you, > Joel (and Terry) >=20 > On 4/8/2011 3:12 PM, Lor=E1nd Jakab wrote: >> Folks, >>=20 >> We just posted an updated -03 addressing Jari's comment from Prague = and >> some other minor editorial changes. >>=20 >> We would like to kindly ask the chairs to consider the adoption of = the >> document as a working group item. >>=20 >> Thank you, >> -Lorand Jakab >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for = draft-jakab-lisp-deployment-03 >> Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: ljakab@ac.upc.edu >> CC: acabello@ac.upc.edu, fcoras@ac.upc.edu, = jordi.domingo@ac.upc.edu, >> darlewis@cisco.com >>=20 >>=20 >>=20 >> A new version of I-D, draft-jakab-lisp-deployment-03.txt has been = successfully submitted by Lorand Jakab and posted to the IETF = repository. >>=20 >> Filename: draft-jakab-lisp-deployment >> Revision: 03 >> Title: LISP Network Element Deployment Considerations >> Creation_date: 2011-04-08 >> WG ID: Independent Submission >> Number_of_pages: 21 >>=20 >> Abstract: >> This document discusses the different scenarios for the deployment of >> the new network elements introduced by the Locator/Identifier >> Separation Protocol (LISP). >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 terry.manderson@icann.org Thu Apr 14 17:20:57 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 836DFE07BD for ; Thu, 14 Apr 2011 17:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRRCrAC8vgRn for ; Thu, 14 Apr 2011 17:20:56 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfc.amsl.com (Postfix) with ESMTP id B595DE075D for ; Thu, 14 Apr 2011 17:20:56 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 14 Apr 2011 17:20:55 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 14 Apr 2011 17:20:54 -0700 Thread-Topic: Adoption of draft-maino-lisp-sec as a WG item Thread-Index: Acv7Avub7NEzd1frt0mBmqBg6N1jeQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:20:57 -0000 Workgroup, The authors of draft-maino-lisp-sec have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-maino-lisp-sec Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) From terry.manderson@icann.org Thu Apr 14 17:21:11 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 41CF0E07DB for ; Thu, 14 Apr 2011 17:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q90HZAWb8IP for ; Thu, 14 Apr 2011 17:21:10 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfc.amsl.com (Postfix) with ESMTP id 72E28E07E1 for ; Thu, 14 Apr 2011 17:21:10 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 14 Apr 2011 17:21:09 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 14 Apr 2011 17:21:03 -0700 Thread-Topic: Adoption of draft-meyer-lisp-eid-block as a WG item Thread-Index: Acv7AwD5t4Onh/y9OEKyySHz3LV7Zw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:21:11 -0000 Workgroup, The authors of draft-meyer-lisp-eid-block have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-meyer-lisp-eid-block Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) From terry.manderson@icann.org Thu Apr 14 17:21:12 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85475E0803 for ; Thu, 14 Apr 2011 17:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK3iTnnPtOUa for ; Thu, 14 Apr 2011 17:21:11 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfc.amsl.com (Postfix) with ESMTP id BBFD2E07DB for ; Thu, 14 Apr 2011 17:21:11 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 14 Apr 2011 17:21:10 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 14 Apr 2011 17:21:07 -0700 Thread-Topic: Adoption of draft-saucez-lisp-security as a WG item Thread-Index: Acv7AwNbMCdcTZHBKUu++fYcXYbt4w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:21:12 -0000 Workgroup, The authors of draft-saucez-lisp-security have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-saucez-lisp-security Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) From dino@cisco.com Thu Apr 14 20:51:09 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D885BE07A9 for ; Thu, 14 Apr 2011 20:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFVTk3WbiXXL for ; Thu, 14 Apr 2011 20:51:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 3E842E0787 for ; Thu, 14 Apr 2011 20:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=963; q=dns/txt; s=iport; t=1302839468; x=1304049068; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=O15+NSkc0cBG4gAbm2gAeoo9QzwCbYGfkM7Gix4zKwE=; b=XF15XYx8XUaV1u83SrNVe0p5AzCozcPdbLKEGp7JxaMu9JmzDNoRrMaS CEhGpJ2VWtqOYFibo4xni3NYxkyamSiam8VBdarulzQPkWEyaOubclJu0 UPIBHaXufA+Qnx1fUNxqdRvUsWNie/sAe9/wBLLsguZ/uwcgpLVJbRdbW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFC/p02rRDoJ/2dsb2JhbACmAXeIb556nHyFbgSFWogVg3M X-IronPort-AV: E=Sophos;i="4.64,215,1301875200"; d="scan'208";a="681838303" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 03:51:07 +0000 Received: from [192.168.1.2] ([10.21.79.112]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3F3p7g9025609; Fri, 15 Apr 2011 03:51:07 GMT Message-Id: From: Dino Farinacci To: Terry Manderson 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 v936) Date: Thu, 14 Apr 2011 20:51:08 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 03:51:10 -0000 Support. Dino On Apr 14, 2011, at 5:20 PM, Terry Manderson wrote: > Workgroup, > > The authors of draft-maino-lisp-sec have requested for it to be > considered > as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this > document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not > accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG > item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Thu Apr 14 20:53:04 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EBA8AE0787 for ; Thu, 14 Apr 2011 20:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.3 X-Spam-Level: X-Spam-Status: No, score=-100.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUEGxtusdciv for ; Thu, 14 Apr 2011 20:53:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 0E943E0750 for ; Thu, 14 Apr 2011 20:53:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAa5Z-00039v-8z; Thu, 14 Apr 2011 20:52:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 15 Apr 2011 03:52:57 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/15#comment:4 Message-ID: <069.2dc2cad8f65ee40aafc1ca411c09edbe@trac.tools.ietf.org> References: <060.b4b15d03f6ba3bc357ace2e39ad3d053@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <060.b4b15d03f6ba3bc357ace2e39ad3d053@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #15: chairs to review normative and informative references X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 03:53:05 -0000 #15: chairs to review normative and informative references Changes (by terry.manderson@…): * priority: major => minor Comment: Secretaries reviewed the references, this is their report. 15.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. OK [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Not needed for implementation or understanding. Move it to Informative. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. IMHO this is not needed at all. The RFC just explains the process to assign number to protocols. Delete it or move it to the informative section. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. OK [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. OK [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. OK [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. This is not needed for implementation and is cited just when authors state that router supporting GRE may be already able to do header prepending. Move it to informative. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. This is not needed for implementation and is cited just when authors state that router supporting 6to4 may be already able to do header prepending. Move it to informative. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. OK [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Similar to the DNS RFC, is not needed for implementation or understanding. Move it to informative. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. OK [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. OK [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. OK [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. OK [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. Not needed for implementation or understanding. Move it to informative. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. OK [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. OK [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. OK [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets"", draft-eubanks-chimento-6man-00.txt (work in progress), February 2009. This is a tricky point. In principle we need what is proposed in the document, but this could block the publication as RFC. We should check what is the state of the draft and if it will go further. Must in any case be updated to -01 which expires 27th April. 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/.../address-family-numbers, Febuary 2007. This should be normative. it defines numbers and is needed for implementation. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in progress), March 2011. This should be normative since is needed to understand the architecture. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. OK [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. OK [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress), November 2007. OK [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. This should be normative since it is necessary to understand how the architecture works. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-04.txt (work in progress), October 2010. This is present in the IANA section, hence should be normative for the code introduced in it. But is not a WG doc so it should possibly go to Informative. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. OK [LISP-DEPLOY] Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", draft-jakab-lisp-deployment-02.txt (work in progress), February 2011. I would put this normative since has important information to understand the deployment and the architecture. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-01.txt (work in progress), October 2010. Normative since is part of the architecture. [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt (work in progress), March 2009. OK [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-01.txt (work in progress), March 2011. OK [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-04.txt (work in progress), October 2010. OK [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-07.txt (work in progress), March 2011. Normative, since is an important part of the architecture. [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-maino-lisp-sec-00.txt (work in progress), February 2011. OK [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress), Januaryr 2009. OK [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-04.txt (work in progress), October 2010. Normative since it is part of the architecture. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. OK [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress), July 2008. OK [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. OK [RFC3344bis] Perkins, C., "IP Mobility Support for IPv4, revised", draft-ietf-mip4-rfc3344bis-05 (work in progress), July 2007. OK [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. OK [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress), July 2007. OK [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-01.txt (work in progress), March 2011. Normative since it is part of the architecture. -- ----------------------------------+----------------------------------------- Reporter: hartmans-ietf@… | Owner: Type: editorial | Status: new Priority: minor | Component: draft-ietf-lisp Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: lisp LISP WG document issues From dino@cisco.com Thu Apr 14 21:05:58 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE669E074B for ; Thu, 14 Apr 2011 21:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JptpQVNXtK1 for ; Thu, 14 Apr 2011 21:05:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 115EBE06AE for ; Thu, 14 Apr 2011 21:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=970; q=dns/txt; s=iport; t=1302840352; x=1304049952; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=CgdstY8zhevhmCMI+VDZY2bXElEVAATL3pR5Ouwykco=; b=QSrTeM54QxIqpL+hthylr1wLdA+sUBhvdRKwcyRFQCWl5qc3OPXteAvw P81hVSi/ytM7SfAWrNWR+1Y3l3mfwbWI6S58Yegv7JacKO3zZPBC1tS0V Jl8V0Jr0kIkLSusNvdv3s+Z0LjXZYyxo7I6Z5rG6493RLM5aW0juHF7e/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMDDp02rRDoJ/2dsb2JhbACmAXeIb557nHyFbgSFWogVg3M X-IronPort-AV: E=Sophos;i="4.64,215,1301875200"; d="scan'208";a="337919554" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 04:05:51 +0000 Received: from [192.168.1.200] (sjc-vpn3-998.cisco.com [10.21.67.230]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3F450a4001216; Fri, 15 Apr 2011 04:05:51 GMT Message-Id: <7ECD2937-77EE-4ED0-A0FF-BBA911082A22@cisco.com> From: Dino Farinacci To: Terry Manderson 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 v936) Date: Thu, 14 Apr 2011 21:05:52 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 04:05:59 -0000 Support. Dino On Apr 14, 2011, at 5:21 PM, Terry Manderson wrote: > Workgroup, > > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this > document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not > accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG > item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Apr 14 21:05:59 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DF5FBE079F for ; Thu, 14 Apr 2011 21:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4gYtEkA2rla for ; Thu, 14 Apr 2011 21:05:59 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 0231FE071F for ; Thu, 14 Apr 2011 21:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=970; q=dns/txt; s=iport; t=1302840358; x=1304049958; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=i4I+62Wj5DmTHCIhOzj0ANtLLpwxF0bK1MZM347VNpI=; b=fwOE4lsoT/F0nCXiciiaro28clSmgX27/bUt4YrAxN1CLIQtfXdM8Bdd iAJLedLBdjrLeAC/gzfEpTa4xnsTlFMr1GFMiQzhGqC8hd9xbN5NHY9dG 37CpQztgTVDKyLMczLXJL7AAJFlNTtzub02IwcdxfzWYcvBQEieLNSDAr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN/Cp02rRDoJ/2dsb2JhbACmAXeIb58DnHyFbgSFWogVg3M X-IronPort-AV: E=Sophos;i="4.64,215,1301875200"; d="scan'208";a="430547883" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 04:05:57 +0000 Received: from [192.168.1.200] (sjc-vpn3-998.cisco.com [10.21.67.230]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3F450a5001216; Fri, 15 Apr 2011 04:05:57 GMT Message-Id: <3E48E40F-67AB-4E2D-9F87-9EDAB98934E1@cisco.com> From: Dino Farinacci To: Terry Manderson 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 v936) Date: Thu, 14 Apr 2011 21:05:58 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 04:06:00 -0000 Support. Dino On Apr 14, 2011, at 5:21 PM, Terry Manderson wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this > document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not > accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG > item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:18:30 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A75EE06A6 for ; Thu, 14 Apr 2011 21:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruefaqJaXVgb for ; Thu, 14 Apr 2011 21:18:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id B06FCE0677 for ; Thu, 14 Apr 2011 21:18:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAaUB-0001Hz-Ow; Thu, 14 Apr 2011 21:18:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:18:23 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63#comment:6 Message-ID: <077.83a3ef62c9cd7f09f09589487bd49f88@trac.tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:18:30 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: The current draft (-11) text is: Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast locators is the limited advertisement scope of /32 (or /128 for IPv6) routes. Adding in sections about constraining the use of anycasted RLOCs falls in an operations document. If such a document dealing with anycasted RLOC operation comes into existence as a BCP, then the recommendation can live there. The text above highlights the concern about ingress in anycast. I think that is sufficient in this case. I am resolving and closing this ticket. Terry (co-chair) -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:18:49 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C096E0720 for ; Thu, 14 Apr 2011 21:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCd9fLF9fn7X for ; Thu, 14 Apr 2011 21:18:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id F072AE071F for ; Thu, 14 Apr 2011 21:18:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAaUX-0001tr-4s; Thu, 14 Apr 2011 21:18:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:18:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/63#comment:7 Message-ID: <077.af73df6fb4b6194e8a669e9e429baf82@trac.tools.ietf.org> References: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <068.d92e7478bf86c421ac2f1228852f774a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:18:49 -0000 #63: On the use of anycast addresses for RLOCs (from Y. Rekhter's review) Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:34:30 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27FCCE06E0 for ; Thu, 14 Apr 2011 21:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgntjDgGFXcF for ; Thu, 14 Apr 2011 21:34:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 5FDBCE06AE for ; Thu, 14 Apr 2011 21:34:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAaje-0000ov-6j; Thu, 14 Apr 2011 21:34:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:34:21 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:5 Message-ID: <065.4b42e22ba56ca5ec078c97dfd7e45d2b@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #111: Semantics of LSB X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:34:30 -0000 #111: Semantics of LSB Changes (by terry.manderson@…): * status: reopened => resolved * resolution: => fixed Comment: The draft authors have agree to add the following to -12 " If the LSB for an anycast locator is set to 1, then there is at least one RLOC with that address that the ETR is considered 'up'." I have seen a copy of -12. It is there. I am resolving and closing this ticket Terry (co-chair) -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:34:43 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22988E0693 for ; Thu, 14 Apr 2011 21:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h24rmIJCfdrr for ; Thu, 14 Apr 2011 21:34:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 70BC8E0668 for ; Thu, 14 Apr 2011 21:34:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAaju-0001bn-Pc; Thu, 14 Apr 2011 21:34:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:34:38 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/111#comment:6 Message-ID: <065.04fe19a8e02db91276ffe93186beccdf@trac.tools.ietf.org> References: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 In-Reply-To: <056.ec8f02790caa5fcbbae985c1057f553c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #111: Semantics of LSB X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:34:43 -0000 #111: Semantics of LSB Changes (by terry.manderson@…): * status: resolved => closed -- ------------------------------+--------------------------------------------- Reporter: yakov@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:39:53 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7FC9E0693 for ; Thu, 14 Apr 2011 21:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBJfqCV0zNiq for ; Thu, 14 Apr 2011 21:39:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 462A8E0668 for ; Thu, 14 Apr 2011 21:39:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAaoy-0001O2-Qp; Thu, 14 Apr 2011 21:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:39:52 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/110#comment:1 Message-ID: <066.1e12f5f200f03eadc5abc848bfb7094a@trac.tools.ietf.org> References: <057.4533d3a2a5f3888dcb0b76e3c2e3f0ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 110 In-Reply-To: <057.4533d3a2a5f3888dcb0b76e3c2e3f0ae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:39:54 -0000 #110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: new => resolved * resolution: => fixed Comment: the text in the soon to published -12 says: Mapping Protocol Data: See [CONS] or [ALT] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. The Mapping Protocol Data is used when needed by the particular mapping system. This addresses the use of mapping data in the mapping system when needed. I am resolving this ticket Terry (co-chair) -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Thu Apr 14 21:40:07 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B894EE06FB for ; Thu, 14 Apr 2011 21:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2Pn46jOhpS0 for ; Thu, 14 Apr 2011 21:40:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 2434EE06EB for ; Thu, 14 Apr 2011 21:40:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAapC-0001rV-Lw; Thu, 14 Apr 2011 21:40:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 15 Apr 2011 04:40:06 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/110#comment:2 Message-ID: <066.4cc73a7d89c04d62af83fbdf38441958@trac.tools.ietf.org> References: <057.4533d3a2a5f3888dcb0b76e3c2e3f0ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 110 In-Reply-To: <057.4533d3a2a5f3888dcb0b76e3c2e3f0ae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 04:40:07 -0000 #110: "Mapping Protocol Data" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) Changes (by terry.manderson@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From vimoreno@cisco.com Thu Apr 14 22:20:15 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74642E06AE for ; Thu, 14 Apr 2011 22:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2efaEAKOxdFM for ; Thu, 14 Apr 2011 22:20:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 368C8E0668 for ; Thu, 14 Apr 2011 22:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vimoreno@cisco.com; l=1185; q=dns/txt; s=iport; t=1302844814; x=1304054414; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/ve0Yi5GaPUEtICTQSOx/G3jQdE3iBLrrj//zz06CPw=; b=CzXmcqkPNum2CNwrv9457CgFJAVOu8AupDOg8agb9svnGFnFqAzm6j79 N5Ynottz+gYJ2Y71Py7AtsdceRk+ps1tbCgT3VilNuqSn8RoFWzC5SkZa RnwbKUsKe1b6x2OaKIUHVD1mdxcor+XwgwKqRY4qoI48/djqYdq57iYBL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAFjVp02rRDoG/2dsb2JhbACYA41/d6gWnQSFbgSFYIwT X-IronPort-AV: E=Sophos;i="4.64,216,1301875200"; d="scan'208";a="337956110" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 05:20:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3F5KDvo031323; Fri, 15 Apr 2011 05:20:13 GMT Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 22:20:13 -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, 14 Apr 2011 22:20:11 -0700 Message-ID: <40966CDBEF22C64F84F20BD68D445B21227A63@xmb-sjc-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Adoption of draft-saucez-lisp-security as a WG item Thread-Index: Acv7AwNbMCdcTZHBKUu++fYcXYbt4wAKcUVg References: From: "Victor Moreno (vimoreno)" To: "Terry Manderson" , X-OriginalArrivalTime: 15 Apr 2011 05:20:13.0340 (UTC) FILETIME=[CC35C5C0:01CBFB2C] Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 05:20:15 -0000 support > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Terry Manderson > Sent: Thursday, April 14, 2011 5:21 PM > To: lisp@ietf.org > Subject: [lisp] Adoption of draft-saucez-lisp-security as a WG item >=20 > Workgroup, >=20 > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. >=20 > I am opening a 14 day call for comments on the adoption of this document as > a WG item. >=20 > You will find the ID at: >=20 > http://tools.ietf.org/id/draft-saucez-lisp-security >=20 > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately. >=20 > Cheers > Terry (& Joel) >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vimoreno@cisco.com Thu Apr 14 22:20:27 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4B47E073E for ; Thu, 14 Apr 2011 22:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFBJ0IiO9L5y for ; Thu, 14 Apr 2011 22:20:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9F977E06AE for ; Thu, 14 Apr 2011 22:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vimoreno@cisco.com; l=1185; q=dns/txt; s=iport; t=1302844826; x=1304054426; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Dl+GBE8RQbt06bLRoIUyN1Mhi8JBUKAjWrayZuwBzpM=; b=Rl281m7C+zpOmlt+00Kbhmg0jBqIT49M9MGDkPpG0Vg3/vtwGcsRsCdZ nrHiiyBPik2Qvj1mnNNGDngpcilGymo6SLZTHxBLs8kEqH4sSNtkWQJVe VFsXrHCQMevMjdOuVyqQZb8spn9X28Lnyclm+ra6Mg38aLNTjpfOSgXRa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAHfUp02rRDoI/2dsb2JhbACYA41/d6gRnQSFbgSFYIwT X-IronPort-AV: E=Sophos;i="4.64,216,1301875200"; d="scan'208";a="430581207" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 05:20:26 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F5KQbT001281; Fri, 15 Apr 2011 05:20:26 GMT Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 22:20:25 -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, 14 Apr 2011 22:20:24 -0700 Message-ID: <40966CDBEF22C64F84F20BD68D445B21227A64@xmb-sjc-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item Thread-Index: Acv7AwD5t4Onh/y9OEKyySHz3LV7ZwAKczqQ References: From: "Victor Moreno (vimoreno)" To: "Terry Manderson" , X-OriginalArrivalTime: 15 Apr 2011 05:20:25.0918 (UTC) FILETIME=[D3B505E0:01CBFB2C] Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 05:20:27 -0000 support > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Terry Manderson > Sent: Thursday, April 14, 2011 5:21 PM > To: lisp@ietf.org > Subject: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item >=20 > Workgroup, >=20 > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. >=20 > I am opening a 14 day call for comments on the adoption of this document as > a WG item. >=20 > You will find the ID at: >=20 > http://tools.ietf.org/id/draft-meyer-lisp-eid-block >=20 > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately. >=20 > Cheers > Terry (& Joel) >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From vimoreno@cisco.com Thu Apr 14 22:20:39 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4F60FE0781 for ; Thu, 14 Apr 2011 22:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYmU+BrAZZjk for ; Thu, 14 Apr 2011 22:20:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 3FB9CE077C for ; Thu, 14 Apr 2011 22:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vimoreno@cisco.com; l=1168; q=dns/txt; s=iport; t=1302844838; x=1304054438; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UqymFlL7qV3JLAn8qFubQMVxie2465QJIZx77H6vaEE=; b=coXwcsYLKLeTmEYLMU/vnQaMHTxHmChmu+79wB9KvNxnzPJA9YTFqjHH aflCA3KAJrVZY+gguKsrxTu/bJ2yR6pwj1wYGpxsvzUZlaoBdGDUS9g5v 1IFQ/a+akJ4gYIh2rdJzcoRWMyniEyvI8rv/nQBqYfJnH6T+peAFQd7iq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAHfUp02rRDoG/2dsb2JhbACYA41/d6gRnQSFbgSFYIwT X-IronPort-AV: E=Sophos;i="4.64,216,1301875200"; d="scan'208";a="681872449" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 05:20:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3F5Kbe1031668; Fri, 15 Apr 2011 05:20:37 GMT Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 22:20:37 -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, 14 Apr 2011 22:20:36 -0700 Message-ID: <40966CDBEF22C64F84F20BD68D445B21227A65@xmb-sjc-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Adoption of draft-maino-lisp-sec as a WG item Thread-Index: Acv7Avub7NEzd1frt0mBmqBg6N1jeQAKdvXA References: From: "Victor Moreno (vimoreno)" To: "Terry Manderson" , X-OriginalArrivalTime: 15 Apr 2011 05:20:37.0692 (UTC) FILETIME=[DAB997C0:01CBFB2C] Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 05:20:39 -0000 support > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Terry Manderson > Sent: Thursday, April 14, 2011 5:21 PM > To: lisp@ietf.org > Subject: [lisp] Adoption of draft-maino-lisp-sec as a WG item >=20 > Workgroup, >=20 > The authors of draft-maino-lisp-sec have requested for it to be considered > as a workgroup item. >=20 > I am opening a 14 day call for comments on the adoption of this document as > a WG item. >=20 > You will find the ID at: >=20 > http://tools.ietf.org/id/draft-maino-lisp-sec >=20 > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately. >=20 > Cheers > Terry (& Joel) >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From job@instituut.net Thu Apr 14 23:27:53 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 84B65E06FC for ; Thu, 14 Apr 2011 23:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfDddoMonFye for ; Thu, 14 Apr 2011 23:27:52 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id B4969E06F2 for ; Thu, 14 Apr 2011 23:27:52 -0700 (PDT) Received: by ewy19 with SMTP id 19so848491ewy.31 for ; Thu, 14 Apr 2011 23:27:52 -0700 (PDT) Received: by 10.14.53.134 with SMTP id g6mr178531eec.6.1302848869404; Thu, 14 Apr 2011 23:27:49 -0700 (PDT) Received: from [172.16.42.136] ([85.223.119.252]) by mx.google.com with ESMTPS id r48sm1699951eei.2.2011.04.14.23.27.47 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 23:27:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Job Snijders In-Reply-To: Date: Fri, 15 Apr 2011 08:27:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B9C227E-1158-40C9-909F-A1B2F89CFD64@instituut.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:27:53 -0000 Hi Terry, On 15 Apr 2011, at 02:21, Terry Manderson wrote: > http://tools.ietf.org/id/draft-saucez-lisp-security >=20 > Please email the WG list stating that you either accept, or not = accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. Support.=20 Kind regards, Job From job@instituut.net Thu Apr 14 23:28:33 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 64E3EE06F2 for ; Thu, 14 Apr 2011 23:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXlFRoEBsXDh for ; Thu, 14 Apr 2011 23:28:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfc.amsl.com (Postfix) with ESMTP id A7264E0693 for ; Thu, 14 Apr 2011 23:28:32 -0700 (PDT) Received: by eye13 with SMTP id 13so851596eye.31 for ; Thu, 14 Apr 2011 23:28:32 -0700 (PDT) Received: by 10.14.53.134 with SMTP id g6mr178721eec.6.1302848911948; Thu, 14 Apr 2011 23:28:31 -0700 (PDT) Received: from [172.16.42.136] ([85.223.119.252]) by mx.google.com with ESMTPS id r48sm1699951eei.2.2011.04.14.23.28.30 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 23:28:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Job Snijders In-Reply-To: Date: Fri, 15 Apr 2011 08:28:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58654698-E2E4-402C-B599-BEB2C4BD6F05@instituut.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:28:33 -0000 Hi Terry, On 15 Apr 2011, at 02:21, Terry Manderson wrote: > http://tools.ietf.org/id/draft-meyer-lisp-eid-block >=20 > Please email the WG list stating that you either accept, or not = accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. Support. Kind regards, Job Snijders= From job@instituut.net Thu Apr 14 23:29:09 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9963BE0693 for ; Thu, 14 Apr 2011 23:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 935Prr58FFaO for ; Thu, 14 Apr 2011 23:29:09 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id E2376E06FC for ; Thu, 14 Apr 2011 23:29:08 -0700 (PDT) Received: by ewy19 with SMTP id 19so848763ewy.31 for ; Thu, 14 Apr 2011 23:29:08 -0700 (PDT) Received: by 10.14.123.209 with SMTP id v57mr528532eeh.229.1302848948154; Thu, 14 Apr 2011 23:29:08 -0700 (PDT) Received: from [172.16.42.136] ([85.223.119.252]) by mx.google.com with ESMTPS id r48sm1699951eei.2.2011.04.14.23.29.06 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 23:29:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Job Snijders In-Reply-To: Date: Fri, 15 Apr 2011 08:29:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Terry Manderson X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:29:09 -0000 Hi Terry, On 15 Apr 2011, at 02:20, Terry Manderson wrote: > http://tools.ietf.org/id/draft-maino-lisp-sec >=20 > Please email the WG list stating that you either accept, or not = accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. Support.=20 Kind regards, Job Snijders= From ljakab@ac.upc.edu Thu Apr 14 23:51:28 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EAAE0E0686 for ; Thu, 14 Apr 2011 23:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEG1Af3pwSoU for ; Thu, 14 Apr 2011 23:51:28 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id F38D8E0695 for ; Thu, 14 Apr 2011 23:51:26 -0700 (PDT) Received: from [192.168.1.133] (171.46.21.95.dynamic.jazztel.es [95.21.46.171]) by gw.ac.upc.edu (Postfix) with ESMTP id B3E516B01DA; Fri, 15 Apr 2011 08:51:24 +0200 (CEST) Message-ID: <4DA7EAEC.4000404@ac.upc.edu> Date: Fri, 15 Apr 2011 08:51:24 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:51:29 -0000 Support. -Lori On 04/15/2011 02:20 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-maino-lisp-sec have requested for it to be considered > as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Thu Apr 14 23:51:47 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C8A5E0693 for ; Thu, 14 Apr 2011 23:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDahNUWXCAaq for ; Thu, 14 Apr 2011 23:51:47 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id EB324E0686 for ; Thu, 14 Apr 2011 23:51:46 -0700 (PDT) Received: from [192.168.1.133] (171.46.21.95.dynamic.jazztel.es [95.21.46.171]) by gw.ac.upc.edu (Postfix) with ESMTP id 4702D6B01DA; Fri, 15 Apr 2011 08:51:45 +0200 (CEST) Message-ID: <4DA7EB01.3030504@ac.upc.edu> Date: Fri, 15 Apr 2011 08:51:45 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:51:47 -0000 Support. -Lori On 04/15/2011 02:21 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Thu Apr 14 23:52:13 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4BA8AE0695 for ; Thu, 14 Apr 2011 23:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgZcQRVHDzV6 for ; Thu, 14 Apr 2011 23:52:12 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id B4EDEE0686 for ; Thu, 14 Apr 2011 23:52:12 -0700 (PDT) Received: from [192.168.1.133] (171.46.21.95.dynamic.jazztel.es [95.21.46.171]) by gw.ac.upc.edu (Postfix) with ESMTP id 3506E6B01DA; Fri, 15 Apr 2011 08:52:11 +0200 (CEST) Message-ID: <4DA7EB1B.6010906@ac.upc.edu> Date: Fri, 15 Apr 2011 08:52:11 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:52:13 -0000 Support. -Lori On 04/15/2011 02:21 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From fcoras@ac.upc.edu Fri Apr 15 00:03:32 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EC881E067D for ; Fri, 15 Apr 2011 00:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9kN+hNnDvLN for ; Fri, 15 Apr 2011 00:03:32 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id 5F6CBE0693 for ; Fri, 15 Apr 2011 00:03:32 -0700 (PDT) Received: from [192.168.1.12] (223.pool85-58-220.dynamic.orange.es [85.58.220.223]) by gw.ac.upc.edu (Postfix) with ESMTP id DC0CC6B01DA; Fri, 15 Apr 2011 09:03:30 +0200 (CEST) Message-ID: <4DA7EDBE.8040604@ac.upc.edu> Date: Fri, 15 Apr 2011 09:03:26 +0200 From: Florin Coras User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:03:33 -0000 > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > Support. Florin From fcoras@ac.upc.edu Fri Apr 15 00:04:52 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDCF0E0686 for ; Fri, 15 Apr 2011 00:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYJhQKT1NHPS for ; Fri, 15 Apr 2011 00:04:52 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id 2A716E067D for ; Fri, 15 Apr 2011 00:04:52 -0700 (PDT) Received: from [192.168.1.12] (223.pool85-58-220.dynamic.orange.es [85.58.220.223]) by gw.ac.upc.edu (Postfix) with ESMTP id A83CC6B01DA; Fri, 15 Apr 2011 09:04:50 +0200 (CEST) Message-ID: <4DA7EE13.6000503@ac.upc.edu> Date: Fri, 15 Apr 2011 09:04:51 +0200 From: Florin Coras User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:04:52 -0000 > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > Support. Florin From fcoras@ac.upc.edu Fri Apr 15 00:05:44 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08BEAE0686 for ; Fri, 15 Apr 2011 00:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLalIwqI3FUE for ; Fri, 15 Apr 2011 00:05:43 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id 6837DE067D for ; Fri, 15 Apr 2011 00:05:43 -0700 (PDT) Received: from [192.168.1.12] (223.pool85-58-220.dynamic.orange.es [85.58.220.223]) by gw.ac.upc.edu (Postfix) with ESMTP id E713A6B01DA; Fri, 15 Apr 2011 09:05:41 +0200 (CEST) Message-ID: <4DA7EE46.3010204@ac.upc.edu> Date: Fri, 15 Apr 2011 09:05:42 +0200 From: Florin Coras User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:05:44 -0000 > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Support. Florin From luigi@net.t-labs.tu-berlin.de Fri Apr 15 01:38:05 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CCC59E0693 for ; Fri, 15 Apr 2011 01:38:05 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtndFGLRlNCF for ; Fri, 15 Apr 2011 01:38:04 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfc.amsl.com (Postfix) with ESMTP id 65842E065A for ; Fri, 15 Apr 2011 01:37:54 -0700 (PDT) Received: from dyn103.net.t-labs.tu-berlin.de (dyn103.net.t-labs.tu-berlin.de [130.149.220.103]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 34A0170015A9 for ; Fri, 15 Apr 2011 10:37:53 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Luigi Iannone In-Reply-To: Date: Fri, 15 Apr 2011 10:37:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: lisp@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:38:05 -0000 I support the adoption. Luigi On Apr 15, 2011, at 2:20 AM, Terry Manderson wrote: > Workgroup, >=20 > The authors of draft-maino-lisp-sec have requested for it to be = considered > as a workgroup item. >=20 > I am opening a 14 day call for comments on the adoption of this = document as > a WG item. >=20 > You will find the ID at: >=20 > http://tools.ietf.org/id/draft-maino-lisp-sec >=20 > Please email the WG list stating that you either accept, or not = accept, the > item before Friday the 29th of April. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 > Cheers > Terry (& Joel) >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From trac+lisp@trac.tools.ietf.org Fri Apr 15 02:08:22 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19E68E07A4 for ; Fri, 15 Apr 2011 02:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95m0wPrkTavF for ; Fri, 15 Apr 2011 02:08:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 7206EE079F for ; Fri, 15 Apr 2011 02:08:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAf0m-00049o-0t; Fri, 15 Apr 2011 02:08:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 15 Apr 2011 09:08:20 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/56#comment:1 Message-ID: <066.b96b558654fc1d73bf0baaa3ce9101ba@trac.tools.ietf.org> References: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #56: ETR unreachability (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:08:22 -0000 #56: ETR unreachability (review by Y. Rekhter) Comment(by luigi@…): The first part of this issue is covered by section 6.6 of the current draft, while the second part is overlapping with issue #66. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: new Priority: major | Component: draft-ietf-lisp Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 15 02:09:23 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 538FAE07B0 for ; Fri, 15 Apr 2011 02:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXF4yv7zNlic for ; Fri, 15 Apr 2011 02:09:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id C1436E06D6 for ; Fri, 15 Apr 2011 02:09:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAf1j-0004BD-Ah; Fri, 15 Apr 2011 02:09:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 15 Apr 2011 09:09:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/56#comment:2 Message-ID: <066.3e24791aa137f379c518264d4de08850@trac.tools.ietf.org> References: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #56: ETR unreachability (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:09:23 -0000 #56: ETR unreachability (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => duplicate -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: duplicate Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 15 02:09:44 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13E62E07DB for ; Fri, 15 Apr 2011 02:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Mhm4l69b8ho for ; Fri, 15 Apr 2011 02:09:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 7447DE07D0 for ; Fri, 15 Apr 2011 02:09:43 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAf26-0004Ba-W9; Fri, 15 Apr 2011 02:09:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 15 Apr 2011 09:09:42 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/56#comment:3 Message-ID: <066.2e24c0ae505961a151413f94c49436b9@trac.tools.ietf.org> References: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <057.1115c19bef2f95ed5ab5761e0cecbaec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #56: ETR unreachability (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:09:44 -0000 #56: ETR unreachability (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: duplicate Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 15 02:10:51 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8D3A2E07B0 for ; Fri, 15 Apr 2011 02:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTaGHl17XRdz for ; Fri, 15 Apr 2011 02:10:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id F2D45E065A for ; Fri, 15 Apr 2011 02:10:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAf3A-0004MB-IT; Fri, 15 Apr 2011 02:10:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 09:10:48 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:7 Message-ID: <077.ea1d7a836a1a13d5adff14b4cbd70cf0@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:10:51 -0000 #66: Strict RLOC ordering causing problems on mapping changes Changes (by luigi@…): * status: reopened => resolved * resolution: => fixed Comment: The issue has been fixed with the text describing the case of new RLOC inserted in the middle of the RLOC set lexicographically ordered. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 15 02:11:25 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50FC2E0752 for ; Fri, 15 Apr 2011 02:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkMG+t8hvWw4 for ; Fri, 15 Apr 2011 02:11:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 1A99CE0693 for ; Fri, 15 Apr 2011 02:11:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QAf3i-0004Ng-C2; Fri, 15 Apr 2011 02:11:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 15 Apr 2011 09:11:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/66#comment:8 Message-ID: <077.8e6b42cff26827bf9e6de05e06351bc3@trac.tools.ietf.org> References: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <068.3a3b43d90cb0ced8925103b20f872430@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #66: Strict RLOC ordering causing problems on mapping changes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 09:11:25 -0000 #66: Strict RLOC ordering causing problems on mapping changes Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From gschudel@cisco.com Fri Apr 15 02:22:27 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8ADE06E9 for ; Fri, 15 Apr 2011 02:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh72P49vrdmQ for ; Fri, 15 Apr 2011 02:22:26 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 2B83EE0693 for ; Fri, 15 Apr 2011 02:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gschudel@cisco.com; l=1159; q=dns/txt; s=iport; t=1302859346; x=1304068946; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3yUPX1yjyvpD/Rtl8GDtbm1SK8LHpzyGlJ0sPrf0xYg=; b=IkfV0K6ckBEUhjTluwWN04E7UaoQgL7SuVfOJkV/RjOMNwX9zR2E6R3/ OJfHooG2keJKGSgMi0wWWa5Re3uH1LkjG28NQva9tK/9erC4WX6bbwBO+ IbNDRtEJWI9wIUlnPPzAZ+dxVmKFBC5AFMJepKTOcViJKP5i3clkvekgB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUHAK0NqE2rRDoI/2dsb2JhbACYQY0/d6ZmnHiDGIJWBI14 X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="338103850" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 09:22:25 +0000 Received: from gschudel-mac-2.local ([10.21.70.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F9MOVI011900; Fri, 15 Apr 2011 09:22:24 GMT Message-ID: <4DA80E4F.8020504@cisco.com> Date: Fri, 15 Apr 2011 11:22:23 +0200 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:22:27 -0000 Hi Terry "support" Cheers gregg On 4/15/11 2:20 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-maino-lisp-sec have requested for it to be considered > as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. -- -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical mrkting engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From gschudel@cisco.com Fri Apr 15 02:22:48 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A3C4AE07A4 for ; Fri, 15 Apr 2011 02:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb1NZHVB9CAk for ; Fri, 15 Apr 2011 02:22:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 9DDDEE07AA for ; Fri, 15 Apr 2011 02:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gschudel@cisco.com; l=1253; q=dns/txt; s=iport; t=1302859367; x=1304068967; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZCrj0jzBOacCJNtldb0rzbjlV/J2oe4jEKZs2YryPEY=; b=K92DEPEn9oSprwm2Vf02RI2BxyhbUmwabFFKU6ta8phpbUMvKdANDOaz X1p+qsnaOl8MHX1oVG0sWZikyVuXxMEuPV66eVxZ/vkPZKEYsFaePQJzm HmmJX6F8sHyFgne9nkA8tAPQYWpd/H2w/uW2RzxAOemBfqpEgQmlOAP2M A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUHAK0NqE2rRDoI/2dsb2JhbACYQY0/d6ZmnHiDGIJWBI14 X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="338104046" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 09:22:47 +0000 Received: from gschudel-mac-2.local ([10.21.70.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F9Mj4a012157; Fri, 15 Apr 2011 09:22:46 GMT Message-ID: <4DA80E65.9090103@cisco.com> Date: Fri, 15 Apr 2011 11:22:45 +0200 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:22:48 -0000 Hi Terry "support" Cheers gregg On 4/15/11 2:21 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. -- -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical mrkting engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From gschudel@cisco.com Fri Apr 15 02:23:06 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AD7BFE06E9 for ; Fri, 15 Apr 2011 02:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrWoJ-RqF475 for ; Fri, 15 Apr 2011 02:23:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id F41D8E0693 for ; Fri, 15 Apr 2011 02:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gschudel@cisco.com; l=1257; q=dns/txt; s=iport; t=1302859386; x=1304068986; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k/wzWYhTCKTYXaP9ez0r5fZbnw2IkGGbURtC32HKiFA=; b=CgNtpLw6pyUU2zZIZijNe17aYwcNTHQ8uA9taogTIu/yEqE1w9Hw5TRZ yBncm92U5iGVwO9fmPExe+2K5Vpijo0snAZFbCamClh5HCb5UGP0rLGIW ciQj1WAAlwlSHOWoItXpXsTpAeljAd4gXwfCAMSFvO9qqQUXKIU8MPwb0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUHAK0NqE2rRDoG/2dsb2JhbACYQY0/d6ZmnHiDGIJWBI14 X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="338104269" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 09:23:05 +0000 Received: from gschudel-mac-2.local ([10.21.70.221]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3F9N45s011996; Fri, 15 Apr 2011 09:23:04 GMT Message-ID: <4DA80E77.7010300@cisco.com> Date: Fri, 15 Apr 2011 11:23:03 +0200 From: Gregg Schudel Organization: cisco.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:23:06 -0000 Hi Terry "support" Cheers gregg On 4/15/11 2:21 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. -- -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical mrkting engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From damien.saucez@uclouvain.be Fri Apr 15 03:13:20 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 52E01E07DD for ; Fri, 15 Apr 2011 03:13:20 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDUQIb2nc0Gn for ; Fri, 15 Apr 2011 03:13:19 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfc.amsl.com (Postfix) with ESMTP id 1DF42E07CE for ; Fri, 15 Apr 2011 03:13:18 -0700 (PDT) Received: from [130.104.228.23] (unknown [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F063FCF308; Fri, 15 Apr 2011 12:12:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4DA80E65.9090103@cisco.com> Date: Fri, 15 Apr 2011 12:12:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DA80E65.9090103@cisco.com> To: Gregg Schudel X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-2.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.23; helo= Received-SPF: Pass (sender authenticated); receiver=; client-ip=130.104.228.23; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F063FCF308.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:13:20 -0000 support but still have to define if /16 is good or not Damien Saucez On 15 Apr 2011, at 11:22, Gregg Schudel wrote: > Hi Terry >=20 > "support" >=20 > Cheers > gregg >=20 > On 4/15/11 2:21 AM, Terry Manderson wrote: >> Workgroup, >>=20 >> The authors of draft-meyer-lisp-eid-block have requested for it to be >> considered as a workgroup item. >>=20 >> I am opening a 14 day call for comments on the adoption of this = document as >> a WG item. >>=20 >> You will find the ID at: >>=20 >> http://tools.ietf.org/id/draft-meyer-lisp-eid-block >>=20 >> Please email the WG list stating that you either accept, or not = accept, the >> item before Friday the 29th of April. >>=20 >> If you email to support the acceptance of this document as a WG item, = please >> also indicate if you are able and willing to either contribute to, or >> review, (or both) the draft. >>=20 >> Sitting in silence does not indicate support, please respond = appropriately. >=20 >=20 > --=20 > -------------------------------------------------------------------- > .:|:.:|:. | gregg schudel (ccie#9591) LISP technical mrkting engr > cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com > -------------------------------------------------------------------- > cisco corporate legal statement: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -------------------------------------------------------------------- > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From kouvelas@cisco.com Fri Apr 15 03:47:57 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C4C28E07DD for ; Fri, 15 Apr 2011 03:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RitXMypND6KH for ; Fri, 15 Apr 2011 03:47:56 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id A41FFE07B2 for ; Fri, 15 Apr 2011 03:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kouvelas@cisco.com; l=934; q=dns/txt; s=iport; t=1302864476; x=1304074076; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=I6sxFsNvpuPmyVTTS/Gkh3dq7BxhGpJDmdRhIvLq29A=; b=Fc4NjaFABwd+SslTZ+0iHelVkMV9nP4tagq/TK8eNK70lnH2R4+bNG6U yjBnRECuzRLgeVawoyg4PgnovLxTmm8B9mS50Nf611HeBSLSRlGFbDpqc COC0rjiGXA/51pmloErTpw2P9kzBaXUuQrNLgaWRu7kvwWZWBd9hbeFsP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkhqE2rRDoJ/2dsb2JhbACmAHenI5x5hW4EhVqIHg X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="682038750" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2011 10:47:56 +0000 Received: from sjc-kouvelas-87111.cisco.com (sjc-kouvelas-87111.cisco.com [10.19.208.108]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3FAlrlG008118; Fri, 15 Apr 2011 10:47:54 GMT Message-ID: <4DA82258.7020209@cisco.com> Date: Fri, 15 Apr 2011 13:47:52 +0300 From: Isidor Kouvelas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:47:57 -0000 support Isidor On 15/4/11 3:20 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-maino-lisp-sec have requested for it to be considered > as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From kouvelas@cisco.com Fri Apr 15 03:48:19 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EE9D0E07E7 for ; Fri, 15 Apr 2011 03:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCPYA2UVKxz6 for ; Fri, 15 Apr 2011 03:48:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id C2663E07DD for ; Fri, 15 Apr 2011 03:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kouvelas@cisco.com; l=946; q=dns/txt; s=iport; t=1302864498; x=1304074098; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0IsAaRu3fhCGPFxNmN1hRnQ3L9JQI0S24w1sYrPjB40=; b=Pm11yt9MKCNum9n3I5JuV4WMGMJ7M0woAc/3h8eIK+uNYAQCnqFUcLj0 9ZYHoViWRlU+xMejRwK396DJRqZHMJcWyShhCHTImyGZ4Vn49edlD/dzp CJOrtg6BK0vaqG+W/C+M9o44M7c5h+bMCI/lxc7Q/srLhdE1FNhr4IMx9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMkhqE2rRDoG/2dsb2JhbACmAHenI5x5hW4EhVqIHg X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="430765284" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 10:48:18 +0000 Received: from sjc-kouvelas-87111.cisco.com (sjc-kouvelas-87111.cisco.com [10.19.208.108]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3FAmGUD017698; Fri, 15 Apr 2011 10:48:17 GMT Message-ID: <4DA82270.3060908@cisco.com> Date: Fri, 15 Apr 2011 13:48:16 +0300 From: Isidor Kouvelas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:48:20 -0000 support Isidor On 15/4/11 3:21 AM, Terry Manderson wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From fmaino@cisco.com Fri Apr 15 09:29:29 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 632D9E0705 for ; Fri, 15 Apr 2011 09:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgJAqknwIdn7 for ; Fri, 15 Apr 2011 09:29:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 390C5E06D4 for ; Fri, 15 Apr 2011 09:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=4323; q=dns/txt; s=iport; t=1302884964; x=1304094564; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=kw29qXA5Pji5RtqJHZKUpErjgr4woSt5VMQz4z/EZFo=; b=EhI3R0wmvnfEmmlTNBIP9j5jXemHuT6kCdPVkC8PYiDxvjeBu3flLL1Y Zip5zPFMBFnVPyYiCT/e6S+vyNahucFyKMPvy0OLy2gXrI151F0GAej53 mWdrROAdTDgM+zoKQZknexeKHyvwfY2YB2HpD3Z5txUBZ7eqq862fIoqa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoIAC5xqE2rRDoJ/2dsb2JhbACYRI1Ad6d1nH+FbgSBfoNiiBg X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208,217";a="338465140" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 16:29:23 +0000 Received: from dhcp-128-107-166-192.cisco.com (dhcp-128-107-166-192.cisco.com [128.107.166.192]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGTNqw001208 for ; Fri, 15 Apr 2011 16:29:23 GMT Message-ID: <4DA87263.6010106@cisco.com> Date: Fri, 15 Apr 2011 09:29:23 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050804040801070609030501" Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:29:29 -0000 This is a multi-part message in MIME format. --------------050804040801070609030501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit support. I can help with review/contribute. Fabio On 4/14/11 5:21 PM, Terry Manderson wrote: > > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this > document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not > accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------050804040801070609030501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit support.

I can help with review/contribute.

Fabio

On 4/14/11 5:21 PM, Terry Manderson wrote:
[lisp] Adoption of draft-saucez-lisp-security as a WG item

Workgroup,

The authors of draft-saucez-lisp-security have requested for it to be
considered as a workgroup item.

I am opening a 14 day call for comments on the adoption of this document as
a WG item.

You will find the ID at:

    http://tools.ietf.org/id/draft-saucez-lisp-security

Please email the WG list stating that you either accept, or not accept, the
item before Friday the 29th of April.

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

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

Cheers
Terry (& Joel)

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



-- 
Fabio Maino
fmaino@cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------050804040801070609030501-- From fmaino@cisco.com Fri Apr 15 09:30:20 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D0F6AE06C6 for ; Fri, 15 Apr 2011 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7SbiGNCMqpJ for ; Fri, 15 Apr 2011 09:30:16 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 3CE04E06D7 for ; Fri, 15 Apr 2011 09:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=4230; q=dns/txt; s=iport; t=1302885016; x=1304094616; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=RwoyNHPFKRazcVLbM/DscvevdsB+4nOMmg8P9R3Svb8=; b=HLXud7ftZ8t2JrPxiti8mVv6wtIt4XOeY55DersA6Ys8AesD6JP807gz JjMefhTctr2vg4zWyE5DYpT/nJVBlsTECmTUinxrE2/CUfcFOnpvmcPMv vnRWBmnHQge/sbQyQU12AiUJZRQypMeDK2RRkXqClacnaO/uiog+5Fo8g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoIAF9yqE2rRDoJ/2dsb2JhbACYRI1Ad6d+nQKFbgSBfoNiiBg X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208,217";a="338465583" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 16:29:58 +0000 Received: from dhcp-128-107-166-192.cisco.com (dhcp-128-107-166-192.cisco.com [128.107.166.192]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGTwpu001641 for ; Fri, 15 Apr 2011 16:29:58 GMT Message-ID: <4DA87285.1010009@cisco.com> Date: Fri, 15 Apr 2011 09:29:57 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207030102030800040106" Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:30:21 -0000 This is a multi-part message in MIME format. --------------010207030102030800040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit support. Fabio On 4/14/11 5:21 PM, Terry Manderson wrote: > > Workgroup, > > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this > document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not > accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------010207030102030800040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit support.

Fabio

On 4/14/11 5:21 PM, Terry Manderson wrote:
[lisp] Adoption of draft-meyer-lisp-eid-block as a WG item

Workgroup,

The authors of draft-meyer-lisp-eid-block have requested for it to be
considered as a workgroup item.

I am opening a 14 day call for comments on the adoption of this document as
a WG item.

You will find the ID at:

    http://tools.ietf.org/id/draft-meyer-lisp-eid-block

Please email the WG list stating that you either accept, or not accept, the
item before Friday the 29th of April.

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

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

Cheers
Terry (& Joel)

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



-- 
Fabio Maino
fmaino@cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------010207030102030800040106-- From amijain@cisco.com Fri Apr 15 09:31:34 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9C71E06C6 for ; Fri, 15 Apr 2011 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09QzPyLFE1gi for ; Fri, 15 Apr 2011 09:31:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 84AB3E0681 for ; Fri, 15 Apr 2011 09:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=amijain@cisco.com; l=982; q=dns/txt; s=iport; t=1302885090; x=1304094690; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=l3MpebUosey4MWTdBqxpsDElTDD2SZBSa/oUixSukC0=; b=fccwqhApkVZyMENa+Dj8eRZWV5ww1LUaSjhE3lThqWoxP2/UBrkg1HCH MklzM+sRfzDqEWOq5wl9cOR9bE6VPMullo3LTRhypJEyq+zr8FLafwFE8 GthX0RovACnbkl4OWON/YLhMMTPXUJtFMXY0LTWRuzMBheaUXfzgQufwZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL1xqE2rRDoI/2dsb2JhbACmBHeIb58NnQKFbgSFYIgYg3s X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="431049077" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 16:31:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGVTGJ031219; Fri, 15 Apr 2011 16:31:29 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 09:31:29 -0700 Received: from 10.21.79.179 ([10.21.79.179]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Apr 2011 16:31:28 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 15 Apr 2011 09:32:52 -0700 From: Amit Jain To: Terry Manderson , "lisp@ietf.org" Message-ID: Thread-Topic: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item Thread-Index: Acv7AwD5t4Onh/y9OEKyySHz3LV7ZwAh8Lc3 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 16:31:29.0547 (UTC) FILETIME=[92B33DB0:01CBFB8A] Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:31:35 -0000 support Amit On 4/14/11 5:21 PM, "Terry Manderson" wrote: > Workgroup, > > The authors of draft-meyer-lisp-eid-block have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From amijain@cisco.com Fri Apr 15 09:31:41 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C4E18130018 for ; Fri, 15 Apr 2011 09:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpQSilEYzYge for ; Fri, 15 Apr 2011 09:31:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 6DF99130017 for ; Fri, 15 Apr 2011 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=amijain@cisco.com; l=982; q=dns/txt; s=iport; t=1302885097; x=1304094697; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=pyN7IxePMgxiyZ9aKoretr8OuYVfxW6C7wh96Gid8xQ=; b=RyMmmvCfNz/YK+K45uhJl3tObHTys6xviIh/BBmCtQ3kPYyRRg91S87+ ZRSwT1l+2z5wcVOskQVko61943zsjC42xucZ4EPiisFfyTiVSvlh1v2Zr IR3R9wD8NJMgOtNykPLx2OmFN4OYuxI+9PqMfNaEtTVFI4DS5Y9dnFlQW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF9yqE2rRDoI/2dsb2JhbACmBHeIb58PnQKFbgSFYIgYg3s X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="338466979" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 16:31:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGVahi031429; Fri, 15 Apr 2011 16:31:36 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 09:31:36 -0700 Received: from 10.21.79.179 ([10.21.79.179]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Apr 2011 16:31:36 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 15 Apr 2011 09:33:00 -0700 From: Amit Jain To: Terry Manderson , "lisp@ietf.org" Message-ID: Thread-Topic: [lisp] Adoption of draft-saucez-lisp-security as a WG item Thread-Index: Acv7AwNbMCdcTZHBKUu++fYcXYbt4wAh8VAz In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 16:31:36.0984 (UTC) FILETIME=[97220980:01CBFB8A] Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:31:41 -0000 support Amit On 4/14/11 5:21 PM, "Terry Manderson" wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From amijain@cisco.com Fri Apr 15 09:32:33 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBDEF13001F for ; Fri, 15 Apr 2011 09:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guBzA7NPfhrq for ; Fri, 15 Apr 2011 09:32:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 68A64130018 for ; Fri, 15 Apr 2011 09:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=amijain@cisco.com; l=1000; q=dns/txt; s=iport; t=1302885149; x=1304094749; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=5nZYFZLDXLI+d44QRZ8ZBaC+NywzMSMOR8te2xplYYs=; b=cuzIqW3nU/6Hb3j/Fld+WHLUYowmvC/BQR3S2vvM4rPAV40/y/LsfYeD EvvwkNYpYikd4j3/vLj88P0jmL99m4KpbdIa4choCSdN02DojZVYqUHqM rWD9rIHUdJdj3STggvwX8mcvrDDmbwW2NIJQ+sb863ohOUv0XlngEF3df I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZyqE2rRDoH/2dsb2JhbACmBHeIb58RnQKFbgSFYIgYg3s X-IronPort-AV: E=Sophos;i="4.64,220,1301875200"; d="scan'208";a="431050030" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 16:32:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FGWSdD026460; Fri, 15 Apr 2011 16:32:28 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 09:32:28 -0700 Received: from 10.21.79.179 ([10.21.79.179]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 15 Apr 2011 16:32:28 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 15 Apr 2011 09:33:54 -0700 From: Amit Jain To: Terry Manderson , "lisp@ietf.org" Message-ID: Thread-Topic: [lisp] Adoption of draft-maino-lisp-sec as a WG item Thread-Index: Acv7Avub7NEzd1frt0mBmqBg6N1jeQAh7/nuAAALU9w= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 16:32:28.0937 (UTC) FILETIME=[B6196F90:01CBFB8A] Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:32:33 -0000 support Amit > On 4/14/11 5:20 PM, "Terry Manderson" wrote: > >> Workgroup, >> >> The authors of draft-maino-lisp-sec have requested for it to be considered >> as a workgroup item. >> >> I am opening a 14 day call for comments on the adoption of this document as >> a WG item. >> >> You will find the ID at: >> >> http://tools.ietf.org/id/draft-maino-lisp-sec >> >> Please email the WG list stating that you either accept, or not accept, the >> item before Friday the 29th of April. >> >> If you email to support the acceptance of this document as a WG item, please >> also indicate if you are able and willing to either contribute to, or >> review, (or both) the draft. >> >> Sitting in silence does not indicate support, please respond appropriately. >> >> Cheers >> Terry (& Joel) >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nordmark@acm.org Fri Apr 15 09:41:22 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54991E06BA for ; Fri, 15 Apr 2011 09:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uKrgyOPD3B7 for ; Fri, 15 Apr 2011 09:41:16 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 66076E076C for ; Fri, 15 Apr 2011 09:41:16 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3FGeogV024468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 09:40:51 -0700 Message-ID: <4DA87530.7030509@acm.org> Date: Fri, 15 Apr 2011 09:41:20 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:41:22 -0000 I've read this draft and it makes sense as a WG document. Erik On 4/14/11 5:20 PM, Terry Manderson wrote: > Workgroup, > > The authors of draft-maino-lisp-sec have requested for it to be considered > as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-maino-lisp-sec > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nordmark@acm.org Fri Apr 15 09:43:03 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 621AD130022 for ; Fri, 15 Apr 2011 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7-L4P6KjkSs for ; Fri, 15 Apr 2011 09:43:01 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id A8C7C13002B for ; Fri, 15 Apr 2011 09:43:01 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3FGgZsK025312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 09:42:36 -0700 Message-ID: <4DA87599.2050900@acm.org> Date: Fri, 15 Apr 2011 09:43:05 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:43:03 -0000 I've read this draft and it makes sense as a WG document. Erik On 4/14/11 5:21 PM, Terry Manderson wrote: > Workgroup, > > The authors of draft-saucez-lisp-security have requested for it to be > considered as a workgroup item. > > I am opening a 14 day call for comments on the adoption of this document as > a WG item. > > You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > > Please email the WG list stating that you either accept, or not accept, the > item before Friday the 29th of April. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > Cheers > Terry (& Joel) > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jnc@mercury.lcs.mit.edu Fri Apr 15 11:52:13 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B2E3EE0749 for ; Fri, 15 Apr 2011 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rbfGigdxlXR for ; Fri, 15 Apr 2011 11:52:13 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfc.amsl.com (Postfix) with ESMTP id 37AE9E06B0 for ; Fri, 15 Apr 2011 11:52:13 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A2C9E18C199; Fri, 15 Apr 2011 14:52:12 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110415185212.A2C9E18C199@mercury.lcs.mit.edu> Date: Fri, 15 Apr 2011 14:52:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: New Version Notification for draft-jaka- draft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 18:52:13 -0000 > From: "Joel M. Halpern" > This starts a two week call for working group adoption of this document. > Please respond to the list indicating whether you would like the WG to > use this document as the basis for its work on documenting deployment > considerations, or whether you see a difficulty with such adoption. I've taken a quick look at draft-jakab-lisp-deployment-03.txt, and it seems to me a good start on a deployment document, so I support its adoption as a WG item. Noel From msiddiqui@whitestone.com.sa Sun Apr 17 12:08:19 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4634EE0730 for ; Sun, 17 Apr 2011 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qqIMAJCwzBJ for ; Sun, 17 Apr 2011 12:08:18 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.52.25]) by ietfc.amsl.com (Postfix) with SMTP id 7C24FE06A0 for ; Sun, 17 Apr 2011 12:08:17 -0700 (PDT) Received: (qmail 25128 invoked from network); 17 Apr 2011 19:06:30 -0000 Received: from gator110.hostgator.com (70.87.64.130) by gateway01.websitewelcome.com with SMTP; 17 Apr 2011 19:06:30 -0000 Received: from [86.60.13.31] (port=51442 helo=localhost) by gator110.hostgator.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1QBXKR-0007jS-Nc; Sun, 17 Apr 2011 14:08:16 -0500 Date: Sun, 17 Apr 2011 22:08:12 +0300 (AST) From: Maqsood Siddiqui To: Terry Manderson Message-ID: <5707400.0.1303067288343.JavaMail.msiddiqui@TEST123.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator110.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - whitestone.com.sa X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost) [86.60.13.31]:51442 Cc: lisp@ietf.org Subject: Re: [lisp] Adoption of draft-maino-lisp-sec as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:08:19 -0000 Support. Willing to contribute to/review draft.... Maqsood ----- Original Message ----- From: "Terry Manderson" To: lisp@ietf.org Sent: Friday, April 15, 2011 3:20:54 AM Subject: [lisp] Adoption of draft-maino-lisp-sec as a WG item Workgroup, The authors of draft-maino-lisp-sec have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-maino-lisp-sec Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, please also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From msiddiqui@whitestone.com.sa Sun Apr 17 12:42:07 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 66177E0731 for ; Sun, 17 Apr 2011 12:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+iPcb925A3n for ; Sun, 17 Apr 2011 12:42:06 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.170.18]) by ietfc.amsl.com (Postfix) with SMTP id BDCFAE072B for ; Sun, 17 Apr 2011 12:42:06 -0700 (PDT) Received: (qmail 32720 invoked from network); 17 Apr 2011 19:39:49 -0000 Received: from gator110.hostgator.com (70.87.64.130) by gateway07.websitewelcome.com with SMTP; 17 Apr 2011 19:39:49 -0000 Received: from [86.60.13.31] (port=51939 helo=localhost) by gator110.hostgator.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1QBXr9-0005ch-CB; Sun, 17 Apr 2011 14:42:04 -0500 Date: Sun, 17 Apr 2011 22:42:00 +0300 (AST) From: Maqsood Siddiqui To: Terry Manderson Message-ID: <5184218.4.1303069316285.JavaMail.msiddiqui@TEST123.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator110.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - whitestone.com.sa X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost) [86.60.13.31]:51939 Cc: lisp@ietf.org Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:42:07 -0000 Support. Willing to contribute to/review draft.... Maqsood ----- Original Message ----- From: "Terry Manderson" To: lisp@ietf.org Sent: Friday, April 15, 2011 3:21:03 AM Subject: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item Workgroup, The authors of draft-meyer-lisp-eid-block have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-meyer-lisp-eid-block Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, please also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From msiddiqui@whitestone.com.sa Sun Apr 17 12:42:23 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 822BDE071C for ; Sun, 17 Apr 2011 12:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8SIj2+uc7za for ; Sun, 17 Apr 2011 12:42:23 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.170.18]) by ietfc.amsl.com (Postfix) with SMTP id D6583E0681 for ; Sun, 17 Apr 2011 12:42:22 -0700 (PDT) Received: (qmail 1154 invoked from network); 17 Apr 2011 19:40:07 -0000 Received: from gator110.hostgator.com (70.87.64.130) by gateway07.websitewelcome.com with SMTP; 17 Apr 2011 19:40:07 -0000 Received: from [86.60.13.31] (port=51941 helo=localhost) by gator110.hostgator.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1QBXrR-0005lH-6P; Sun, 17 Apr 2011 14:42:21 -0500 Date: Sun, 17 Apr 2011 22:42:18 +0300 (AST) From: Maqsood Siddiqui To: Terry Manderson Message-ID: <337177.8.1303069338352.JavaMail.msiddiqui@TEST123.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator110.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - whitestone.com.sa X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (localhost) [86.60.13.31]:51941 Cc: lisp@ietf.org Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 19:42:23 -0000 Support. Willing to contribute to/review draft.... Maqsood ----- Original Message ----- From: "Terry Manderson" To: lisp@ietf.org Sent: Friday, April 15, 2011 3:21:07 AM Subject: [lisp] Adoption of draft-saucez-lisp-security as a WG item Workgroup, The authors of draft-saucez-lisp-security have requested for it to be considered as a workgroup item. I am opening a 14 day call for comments on the adoption of this document as a WG item. You will find the ID at: http://tools.ietf.org/id/draft-saucez-lisp-security Please email the WG list stating that you either accept, or not accept, the item before Friday the 29th of April. If you email to support the acceptance of this document as a WG item, please also indicate if you are able and willing to either contribute to, or review, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. Cheers Terry (& Joel) _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From vermagan@cisco.com Mon Apr 18 15:56:44 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 91B69E083C for ; Mon, 18 Apr 2011 15:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLxWvagkc2Ux for ; Mon, 18 Apr 2011 15:56:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 85E66E082A for ; Mon, 18 Apr 2011 15:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vermagan@cisco.com; l=1183; q=dns/txt; s=iport; t=1303167403; x=1304377003; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PuqzjLPh5yPSPgiH0gMp3rS2mPilYxAHGOxFLwRFM/A=; b=bhqjTVN2LW8VmcvoJaKi5S7UobBpjI2Y2u1ou2g1g4+xuAqov9RL6FXS DIvq/SyuSzGd4iFtp0U23iN3hAjVLoWYPcQHtpNYPrupoWKNuQyEZCHFY ggQ/K28fM6h3RzzoPGpPahQXq/OGrWAjnSq0lCp5ockauWenGHZsT2kHt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocBAJ/ArE2rRDoI/2dsb2JhbACXOj+NRneqB5xYhXEEhWKMGg X-IronPort-AV: E=Sophos;i="4.64,236,1301875200"; d="scan'208";a="683502575" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2011 22:56:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3IMugOw028854 for ; Mon, 18 Apr 2011 22:56:42 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 15:56:42 -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, 18 Apr 2011 15:56:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item Thread-Index: Acv7AwD5t4Onh/y9OEKyySHz3LV7ZwDGLkuQ References: From: "Vina Ermagan (vermagan)" To: X-OriginalArrivalTime: 18 Apr 2011 22:56:42.0040 (UTC) FILETIME=[E20F0B80:01CBFE1B] Subject: Re: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:56:44 -0000 =20 Support. Regards, Vina Ermagan >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of Terry Manderson >Sent: Thursday, April 14, 2011 5:21 PM >To: lisp@ietf.org >Subject: [lisp] Adoption of draft-meyer-lisp-eid-block as a WG item > >Workgroup, > >The authors of draft-meyer-lisp-eid-block have requested for=20 >it to be considered as a workgroup item. > >I am opening a 14 day call for comments on the adoption of=20 >this document as a WG item. > >You will find the ID at: > > http://tools.ietf.org/id/draft-meyer-lisp-eid-block > >Please email the WG list stating that you either accept, or=20 >not accept, the item before Friday the 29th of April. > >If you email to support the acceptance of this document as a=20 >WG item, please also indicate if you are able and willing to=20 >either contribute to, or review, (or both) the draft. > >Sitting in silence does not indicate support, please respond=20 >appropriately. > >Cheers >Terry (& Joel) > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp > From vermagan@cisco.com Mon Apr 18 15:59:21 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCFCCE082A for ; Mon, 18 Apr 2011 15:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEa53n9TfFzB for ; Mon, 18 Apr 2011 15:59:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 1B63FE088A for ; Mon, 18 Apr 2011 15:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vermagan@cisco.com; l=1242; q=dns/txt; s=iport; t=1303167561; x=1304377161; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=vMeZ0ndllnIJ/Ydaxf5mwUMVlMnNI6xNEIuVAubzlfw=; b=BDDSvzk3rY5lTn9EgurQO7c3JB3eZ1Y2TN8s4BgPvtpZD26TNs8NedOh c/2T3a7yNss0PEkWa7PIxuSz7CWlgQ3IXnKqvV6c9LUO9wGD7x+2zX3Jn ai0iTvuRRIbGkl3AXKSQ6JgZR/kyfShPSJ1diZcWczbJZ5hara9a6L8dY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocBABDCrE2rRDoJ/2dsb2JhbACXOj+NRneqGJxYhXEEhWKMGg X-IronPort-AV: E=Sophos;i="4.64,236,1301875200"; d="scan'208";a="297130709" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2011 22:59:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3IMx9rh024249 for ; Mon, 18 Apr 2011 22:59:09 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 15:59:09 -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, 18 Apr 2011 15:59:08 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Adoption of draft-saucez-lisp-security as a WG item Thread-Index: Acv7AwNbMCdcTZHBKUu++fYcXYbt4wDGOvxA References: From: "Vina Ermagan (vermagan)" To: X-OriginalArrivalTime: 18 Apr 2011 22:59:09.0658 (UTC) FILETIME=[3A0BC3A0:01CBFE1C] Subject: Re: [lisp] Adoption of draft-saucez-lisp-security as a WG item X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 22:59:22 -0000 Support acceptance. I can help with review/contribute for this draft. Regards, Vina Ermagan >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of Terry Manderson >Sent: Thursday, April 14, 2011 5:21 PM >To: lisp@ietf.org >Subject: [lisp] Adoption of draft-saucez-lisp-security as a WG item > >Workgroup, > >The authors of draft-saucez-lisp-security have requested for=20 >it to be considered as a workgroup item. > >I am opening a 14 day call for comments on the adoption of=20 >this document as a WG item. > >You will find the ID at: > > http://tools.ietf.org/id/draft-saucez-lisp-security > >Please email the WG list stating that you either accept, or=20 >not accept, the item before Friday the 29th of April. > >If you email to support the acceptance of this document as a=20 >WG item, please also indicate if you are able and willing to=20 >either contribute to, or review, (or both) the draft. > >Sitting in silence does not indicate support, please respond=20 >appropriately. > >Cheers >Terry (& Joel) > >_______________________________________________ >lisp mailing list >lisp@ietf.org >https://www.ietf.org/mailman/listinfo/lisp > From vaf@cisco.com Tue Apr 19 16:22:45 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ACD16E089E for ; Tue, 19 Apr 2011 16:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KUdLL9J0gbE for ; Tue, 19 Apr 2011 16:22:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 1BE4BE088D for ; Tue, 19 Apr 2011 16:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=291; q=dns/txt; s=iport; t=1303255364; x=1304464964; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xgdILMSxvZ2gJrzDzgcdYtQazZa+2mBqast9Y2j3wWo=; b=OMc6z+IIMmhplppzqbMGeu58dB3OQHm1HuaqrpoExJhBhnHWGn92TnDq BLm2hG+WgeMbruUVM3bi9oV2522intTHMr+zWb/uc9VCzg1p0coowcIhW qOBAa9P5V5CUr9B9HjOVQZShz+mXUsbRWaZPUwgpjpVzcUJ0uotieeV3C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHMYrk2rRDoH/2dsb2JhbAClOHeIb586nQ6FcQSFZ5Vr X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="340869737" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2011 23:22:43 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JNMhYW014715; Tue, 19 Apr 2011 23:22:43 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 7FB94FB6CFA; Tue, 19 Apr 2011 16:22:43 -0700 (PDT) Date: Tue, 19 Apr 2011 16:22:43 -0700 From: Vince Fuller To: Lor??nd Jakab Message-ID: <20110419232243.GE5241@vaf-mac1.cisco.com> References: <4D9F5E06.8010206@ac.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D9F5E06.8010206@ac.upc.edu> User-Agent: Mutt/1.4.2.3i Cc: LISP WG Subject: Re: [lisp] Fwd: New Version Notification for draft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:22:46 -0000 > We just posted an updated -03 addressing Jari's comment from Prague and > some other minor editorial changes. > > We would like to kindly ask the chairs to consider the adoption of the > document as a working group item. I support adoption of this document by the WG. --Vince From mperesse@corp.free.fr Wed Apr 20 03:01:41 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1BF52E0795 for ; Wed, 20 Apr 2011 03:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u29VJrzoGJAB for ; Wed, 20 Apr 2011 03:01:40 -0700 (PDT) Received: from zmc.proxad.net (zmc.proxad.net [212.27.53.206]) by ietfc.amsl.com (Postfix) with ESMTP id 8FD8AE0733 for ; Wed, 20 Apr 2011 03:01:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmc.proxad.net (Postfix) with ESMTP id 683BD251C96 for ; Wed, 20 Apr 2011 12:01:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at Received: from zmc.proxad.net ([127.0.0.1]) by localhost (zmc.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvXzUcjxub9n for ; Wed, 20 Apr 2011 12:01:39 +0200 (CEST) Received: from zmc.proxad.net (zmc.proxad.net [127.0.1.1]) by zmc.proxad.net (Postfix) with ESMTP id 43573250E46 for ; Wed, 20 Apr 2011 12:01:39 +0200 (CEST) Date: Wed, 20 Apr 2011 12:01:39 +0200 (CEST) From: Mathieu Peresse To: lisp Message-ID: <1466636435.182041303293699196.JavaMail.root@zimbra-corp-1-b8> In-Reply-To: <1982159752.181751303293519611.JavaMail.root@zimbra-corp-1-b8> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [213.228.1.121] X-Mailer: Zimbra 6.0.1_GA_1816.UBUNTU8_64 (ZimbraWebClient - SAF3 (Linux)/6.0.1_GA_1816.UBUNTU8_64) Subject: [lisp] Question on draft-ietf-lisp-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:01:41 -0000 Hi, section 6.1.5 (EID-to-RLOC UDP Map-Reply Message) states: When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. I don't understand how 10.1.5.5 longest matches 10.1.1.0/24 and 10.1.2.0/24 ? It would match with a /16 mask in the request but the requested mask is not mentionned so I assume it is a /32... am I missing something ? -- Mathieu From luigi@net.t-labs.tu-berlin.de Wed Apr 20 03:20:14 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F7C2E06B1 for ; Wed, 20 Apr 2011 03:20:14 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM+qXxJwfVpP for ; Wed, 20 Apr 2011 03:20:13 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfc.amsl.com (Postfix) with ESMTP id C8DB9E0682 for ; Wed, 20 Apr 2011 03:20:13 -0700 (PDT) Received: from dyn103.net.t-labs.tu-berlin.de (dyn103.net.t-labs.tu-berlin.de [130.149.220.103]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 076D770002FD; Wed, 20 Apr 2011 12:20:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <1466636435.182041303293699196.JavaMail.root@zimbra-corp-1-b8> Date: Wed, 20 Apr 2011 12:20:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56056AF6-1824-4CA3-83DF-FAB67D6B1762@net.t-labs.tu-berlin.de> References: <1466636435.182041303293699196.JavaMail.root@zimbra-corp-1-b8> To: Mathieu Peresse X-Mailer: Apple Mail (2.1084) Cc: lisp Subject: Re: [lisp] Question on draft-ietf-lisp-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:20:14 -0000 On Apr 20, 2011, at 12:01 PM, Mathieu Peresse wrote: > Hi, >=20 > section 6.1.5 (EID-to-RLOC UDP Map-Reply Message) states: >=20 > When an ETR is configured with overlapping EID-prefixes, a Map- > Request with an EID that longest matches any EID-prefix MUST be > returned in a single Map-Reply message. For instance, if an ETR had > database mapping entries for EID-prefixes: >=20 > 10.0.0.0/8 > 10.1.0.0/16 > 10.1.1.0/24 > 10.1.2.0/24 >=20 > A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record > count of 1 to be returned with a mapping record EID-prefix of > 10.1.1.0/24. >=20 > A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a = record > count of 3 to be returned with mapping records for EID-prefixes > 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. >=20 If you store only 10.1/16 what will happen if later on you have a packet = destined to 10.1.1.69? It will match 10.1/16 without generating any cache-miss, but this means = that the wrong mapping is used, since you should use 10.1.1.0/24. That's why you need the other two. Luigi >=20 > I don't understand how 10.1.5.5 longest matches 10.1.1.0/24 and = 10.1.2.0/24 ? > It would match with a /16 mask in the request but the requested mask = is not mentionned so > I assume it is a /32... >=20 > am I missing something ? >=20 > --=20 > Mathieu > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From mperesse@corp.free.fr Wed Apr 20 05:44:00 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E52C6E066F for ; Wed, 20 Apr 2011 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsiKfoypVzCS for ; Wed, 20 Apr 2011 05:44:00 -0700 (PDT) Received: from zmc.proxad.net (zmc.proxad.net [212.27.53.206]) by ietfc.amsl.com (Postfix) with ESMTP id 66ABCE0655 for ; Wed, 20 Apr 2011 05:44:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zmc.proxad.net (Postfix) with ESMTP id 8957F2525D1; Wed, 20 Apr 2011 14:43:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at Received: from zmc.proxad.net ([127.0.0.1]) by localhost (zmc.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDP54VESSJJ6; Wed, 20 Apr 2011 14:43:59 +0200 (CEST) Received: from zmc.proxad.net (zmc.proxad.net [127.0.1.1]) by zmc.proxad.net (Postfix) with ESMTP id 61E8D250842; Wed, 20 Apr 2011 14:43:59 +0200 (CEST) Date: Wed, 20 Apr 2011 14:43:59 +0200 (CEST) From: Mathieu Peresse To: Luigi Iannone Message-ID: <1947852048.194121303303439333.JavaMail.root@zimbra-corp-1-b8> In-Reply-To: <1620617202.193651303303221794.JavaMail.root@zimbra-corp-1-b8> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [213.228.1.121] X-Mailer: Zimbra 6.0.1_GA_1816.UBUNTU8_64 (ZimbraWebClient - SAF3 (Linux)/6.0.1_GA_1816.UBUNTU8_64) Cc: lisp Subject: Re: [lisp] Question on draft-ietf-lisp-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:44:01 -0000 Hi Luigi, ----- "Luigi Iannone" wrote: > If you store only 10.1/16 what will happen if later on you have a > packet destined to 10.1.1.69? > It will match 10.1/16 without generating any cache-miss, but this > means that the wrong mapping is used, since you should use > 10.1.1.0/24. > > That's why you need the other two. > OK thanks for the clarification. So, should be present in the reply: mapping records of the longest match prefix AND its more specific prefixes. -- Mathieu From akatlas@gmail.com Wed Apr 20 08:40:29 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E476EE06F1 for ; Wed, 20 Apr 2011 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZgVSswu6yPl for ; Wed, 20 Apr 2011 08:40:29 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id E4CAFE06C4 for ; Wed, 20 Apr 2011 08:40:28 -0700 (PDT) Received: by iye19 with SMTP id 19so909295iye.31 for ; Wed, 20 Apr 2011 08:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=f+o6noCOtXD+qyw5EwQ94vKb+qU8w3jk9eGgZOob5fA=; b=UG3eRWG5UsPerdJjICeAeOmvYNQ9zmBw/S/eVw+YxA1/ymAzLr1d495nm4FX+X0bXZ kTCN8htknoi1Kp4tmH0sDTOYfFTVk+k8Agt4fG2xp351EV3Zo0EMUBhYtNXTu7aMl+jq UYUttNlcCiH43BhjQ99jmlhnSp9KVKfUQXDQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ktbHrdJHaDJHJ8zB3HkgtE2G19OVGhNjPMOYwweDBJ7oqsMpjMI7xa34UnjjEgM1f/ H1DEXO9jVg5oz4VBhPXVk+onsG12xLG3KuxcFzZSTiOIWRfOHmSKaqxfdRcHILOYhpY8 5ALV1XvcYxSmmDTN+XFiS6aWxONTA+QsXU+4I= MIME-Version: 1.0 Received: by 10.42.132.65 with SMTP id c1mr9773495ict.513.1303314028521; Wed, 20 Apr 2011 08:40:28 -0700 (PDT) Received: by 10.42.3.67 with HTTP; Wed, 20 Apr 2011 08:40:28 -0700 (PDT) Date: Wed, 20 Apr 2011 11:40:28 -0400 Message-ID: From: Alia Atlas To: lisp@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [lisp] comments and questions on draft-ietf-lisp-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 15:40:30 -0000 1. For instance, a mapping service is required =96 but the role and assumptions for that mapping service are never described. The Packet Flow Sequence (4.1) was helpful, but doesn=92t contain enough details to be clear. Who are the LISP Map-Requests sent to? How is this known? 2. The idea of using LISP for traffic-engineering is scattered through the draft, but there is no clear example or description of how to do so. This also applies to the use of anycast. 3. On p. 9, it specifies for the EID-to-RLOC Database that =93the same database mapping entries MUST be configured on all ETRs for a given site.=94 Later in the draft, it is said that they can be transiently different =96 but what is the impact there? How is/should a misconfiguration be detected much less enforced? What are the consequences of a misconfiguration & how would an operator deal with it? 4. How is looping prevented when doing re-encapsulation of packets? What safety measures exist to prevent/minimize looping when there are transient EID-to-RLOC mappings? Obviously, TTL helps eventually to discard packets, but that isn=92t sufficient. 5. Why is there no definition for the RLOC to be IPv4 while the EID is IPv6 or vice versa?? In Section 9, traceroute talks about it =96 but it isn=92t defined. As I understand the potential uses of LISP, an idea is to v6 in v4 automatic tunneling & vice versa =96 so it=92s very strange to me that those packet formats aren=92t defined. 6. On p.23 in the 2nd to last paragraph, it seems that an ETR MUST do fragment reassembly (at line rate) just in case the ITR (or an attacker) chooses to set the DF bit to 0 and there is an MTU issue? That isn=92t explicitly specified as a MUST =96 but the rest of the language makes it pretty clear that=92s the case? I really don=92t understand the reasoning for this. Wouldn=92t it be much cleaner and easier for the ITR to fragment packets when it encapsulates them? Forcing reassembly at the ETR requires queuing of the packets and makes more attack vectors and complications=85 7. For the virtualization/segmentation, how is the Source-EID AFI & Source EID Address of use in the Mapping Request? If there can be multiple instances behind an RLOC, doesn=92t an instance ID need to be there also? This area seems slightly described in the draft for the traffic, but not for learning mappings. 8. Sec 6.1.3, =93For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter 2 cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry.=94 How is the receiver of the Map-Request supposed to know whether an EID or RLOC is being used?!? 9. On p.33, the Record TTL specifies how long the entry is stored??? How does that go with the cache being locally managed? Having it be the length of time that the mapping is good for makes some sense. 10. Related to the Record TTL & cache storage, the description of how to handle mappings and expirations needs much better description. A single case where a prefix has more specific prefixes that route differently is shown =96 but not the implications of handling that as more mappings are added and removed. I think this is largely a question of better language. However, it is also unclear how an ITR doing cache management knows which entries to remove and the connections between them. Related, would an ETR announce mappings for instance for 3 /24 instead of the /23 and one exception /24? What if the ETR doesn=92t own the exception /24? I think more policy and explanation is really needed here. 11. If the cache is =93locally managed=94, then a good description of the rules that the cache MUST follow should be in the draft. There clearly are some and the issues are scattered. 12. I suspect that I can get more context from other LISP drafts (and plan to do so), but I don=92t see how the mapping service isn=92t a normative reference? I feel like there should be a framework draft =96 perhaps the individual deployment draft is intended in its place?? Perhaps it is because this is intended to be experimental, but I find the draft, writing, and consistency to be significantly rough compared to what I=92d expect for a draft about to enter WG last call. From luigi@net.t-labs.tu-berlin.de Thu Apr 21 01:29:50 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06086E0696 for ; Thu, 21 Apr 2011 01:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86sUa3F2ev6P for ; Thu, 21 Apr 2011 01:29:48 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfc.amsl.com (Postfix) with ESMTP id D9B58E0698 for ; Thu, 21 Apr 2011 01:29:47 -0700 (PDT) Received: from dyn103.net.t-labs.tu-berlin.de (dyn103.net.t-labs.tu-berlin.de [130.149.220.103]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id A9D50700043D; Thu, 21 Apr 2011 10:29:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-797355355 From: Luigi Iannone In-Reply-To: Date: Thu, 21 Apr 2011 10:29:46 +0200 Message-Id: References: To: Alia Atlas X-Mailer: Apple Mail (2.1084) Cc: lisp Subject: Re: [lisp] comments and questions on draft-ietf-lisp-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 08:29:50 -0000 --Apple-Mail-7-797355355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alia, and a good day to you as well. I have a couple of answers/comments inline. ciao Luigi On Apr 20, 2011, at 5:40 PM, Alia Atlas wrote: > 1. For instance, a mapping service is required =96 but the role and > assumptions for that mapping service are never described. The Packet > Flow Sequence (4.1) was helpful, but doesn=92t contain enough details = to > be clear. Who are the LISP Map-Requests sent to? How is this known? In point 2 of the example it is clearly stated that the specific method = is not described in the example itself. For that example you can think to the mapping system as a black box that = you can query in order to retrieve the needed mappings. >=20 > 2. The idea of using LISP for traffic-engineering is scattered = through > the draft, but there is no clear example or description of how to do > so. This also applies to the use of anycast. >=20 The draft is about protocol specification not about the use/deployment = of LISP, hence IMHO there is no need to go deep in the TE topic. Even = the deployment draft cannot be IMO exhaustive on that topic. How to do = TE is up to the operators. > 3. On p. 9, it specifies for the EID-to-RLOC Database that =93the = same > database mapping entries MUST be configured on all ETRs for a given > site.=94 Later in the draft, it is said that they can be transiently > different =96 but what is the impact there? How is/should a > misconfiguration be detected much less enforced? What are the > consequences of a misconfiguration & how would an operator deal with > it? >=20 There is no use in document this. Is impossible to document all possible = misconfigurations, their consequences, and their fixes. This applies also to your next point. > 4. How is looping prevented when doing re-encapsulation of packets? > What safety measures exist to prevent/minimize looping when there are > transient EID-to-RLOC mappings? Obviously, TTL helps eventually to > discard packets, but that isn=92t sufficient. >=20 > 5. Why is there no definition for the RLOC to be IPv4 while the EID = is > IPv6 or vice versa?? In Section 9, traceroute talks about it =96 but = it > isn=92t defined. As I understand the potential uses of LISP, an idea = is > to v6 in v4 automatic tunneling & vice versa =96 so it=92s very = strange to > me that those packet formats aren=92t defined. >=20 Your EIDs and RLOCs can be anything. Why the specs should define EID in = IPv6 and RLOCs in IPv4? A very nice feature of LISP is that you can mix = protocol families, having v4 on v6 or viceversa, beside the v6 on v6 and = v4 on v4. Concerning the packet format, there is no use in adding all possible = cases in the specs. The text is sufficiently clear on how to build = packet in all cases. > 6. On p.23 in the 2nd to last paragraph, it seems that an ETR MUST = do > fragment reassembly (at line rate) Not true. It is clearly stated that ETR treats the packet independently = and does not perform reassembly. > just in case the ITR (or an > attacker) chooses to set the DF bit to 0 and there is an MTU issue? > That isn=92t explicitly specified as a MUST =96 but the rest of the > language makes it pretty clear that=92s the case? I really don=92t > understand the reasoning for this. Wouldn=92t it be much cleaner and > easier for the ITR to fragment packets when it encapsulates them? > Forcing reassembly at the ETR requires queuing of the packets and > makes more attack vectors and complications=85 >=20 > 7. For the virtualization/segmentation, how is the Source-EID AFI & > Source EID Address of use in the Mapping Request? If there can be > multiple instances behind an RLOC, doesn=92t an instance ID need to be > there also? This area seems slightly described in the draft for the > traffic, but not for learning mappings. >=20 > 8. Sec 6.1.3, =93For the initial case, the destination IP address = used > for the Map-Request is the destination-EID from the packet which had a > mapping cache lookup failure. For the latter 2 cases, the destination > IP address used for the Map-Request is one of the RLOC addresses from > the locator-set of the map cache entry.=94 How is the receiver of = the > Map-Request supposed to know whether an EID or RLOC is being used?!? >=20 > 9. On p.33, the Record TTL specifies how long the entry is = stored??? > How does that go with the cache being locally managed? Having it be > the length of time that the mapping is good for makes some sense. Which is what the specs actually say. You can store for TTL time the = mapping, then you have to refresh if you still want to use it. The cache = management is local. >=20 > 10. Related to the Record TTL & cache storage, the description of = how > to handle mappings and expirations needs much better description. A > single case where a prefix has more specific prefixes that route > differently is shown =96 but not the implications of handling that as > more mappings are added and removed. I think this is largely a > question of better language. > However, it is also unclear how an ITR > doing cache management knows which entries to remove and the > connections between them. =20 > Related, would an ETR announce mappings > for instance for 3 /24 instead of the /23 and one exception /24? > What if the ETR doesn=92t own the exception /24? I think more policy > and explanation is really needed here. >=20 How can you have the right to origin a mapping announce of a /23 when = you own only a part of it??=20 > 11. If the cache is =93locally managed=94, then a good description = of the > rules that the cache MUST follow should be in the draft. I totally disagree. This is an implementation issue. > There > clearly are some and the issues are scattered. >=20 > 12. I suspect that I can get more context from other LISP drafts = (and > plan to do so), but I don=92t see how the mapping service isn=92t a > normative reference? References will be re-organized before going for LC. Luigi > I feel like there should be a framework draft =96 > perhaps the individual deployment draft is intended in its place?? >=20 > Perhaps it is because this is intended to be experimental, but I find > the draft, writing, and consistency to be significantly rough compared > to what I=92d expect for a draft about to enter WG last call. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-7-797355355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Alia,

and a good day to you as = well.

I have a couple of answers/comments = inline.

ciao

Luigi
=


On Apr 20, 2011, at 5:40 PM, Alia = Atlas wrote:

1. For instance, a mapping service is required =96 = but the role and
assumptions for that mapping service are never = described.   The Packet
Flow Sequence (4.1) was helpful, = but doesn=92t contain enough details to
be clear.  Who are the = LISP Map-Requests sent to?  How is this = known?

In point 2 of the = example it is clearly stated that the specific method is not described = in the example itself.
For that example you can think to the = mapping system as a black box that you can query in order to retrieve = the needed mappings.



2. The idea of using LISP for = traffic-engineering is scattered through
the draft, but there is no = clear example or description of how to do
so.    This = also applies to the use of = anycast.


The draft is = about protocol specification not about the use/deployment of LISP, hence = IMHO there is no need to go deep in the TE topic. Even the deployment = draft cannot be IMO exhaustive on that topic. How to do TE is up to the = operators.

3. On p. 9, =  it specifies for the EID-to-RLOC Database that =93the = same
database mapping entries MUST be configured on all ETRs for a = given
site.=94   Later in the draft, it is said that they = can be transiently
different =96 but what is the impact there? =  How is/should a
misconfiguration be detected much less = enforced?  What are the
consequences of a misconfiguration & = how would an operator deal = with
it?


There is no = use in document this. Is impossible to document all possible = misconfigurations, their consequences,  and their = fixes.
This applies also to your next = point.

4. How is = looping prevented when doing re-encapsulation of packets?
What safety = measures exist to prevent/minimize looping when there are
transient = EID-to-RLOC mappings?  Obviously, TTL helps eventually = to
discard packets, but that isn=92t = sufficient.

5. Why is = there no definition for the RLOC to be IPv4 while the EID is
IPv6 or = vice versa??  In Section 9, traceroute talks about it =96 but = it
isn=92t defined.  As I understand the potential uses of LISP, = an idea is
to v6 in v4 automatic tunneling & vice versa =96 so = it=92s very strange to
me that those packet formats aren=92t = defined.


Your EIDs and = RLOCs can be anything. Why the specs should define EID in IPv6 and RLOCs = in IPv4? A very nice feature of LISP is that you can mix protocol = families, having v4 on v6 or viceversa, beside the v6 on v6 and v4 on = v4.

Concerning the packet format, there is no = use in adding all possible cases in the specs. The text is sufficiently = clear on how to build packet in all = cases.


6. On p.23 = in the 2nd to last paragraph, it seems that an ETR MUST do
fragment = reassembly (at line rate)

Not = true. It is clearly stated that ETR treats the packet independently and = does not perform reassembly.

= just in case the ITR (or an
attacker) chooses to set the DF bit to 0 = and there is an MTU issue?
That isn=92t explicitly specified as a = MUST =96 but the rest of the
language makes it pretty clear that=92s = the case?  I really don=92t
understand the reasoning for this. =  Wouldn=92t it be much cleaner and
easier for the ITR to = fragment packets when it encapsulates them?
Forcing reassembly at the = ETR requires queuing of the packets and
makes more attack vectors and = complications=85

7. For the = virtualization/segmentation, how is the Source-EID AFI &
Source = EID Address of use in the Mapping Request?  If there can = be
multiple instances behind an RLOC, doesn=92t an instance ID need = to be
there also?   This area seems slightly described in = the draft for the
traffic, but not for learning = mappings.

8. Sec 6.1.3, =93For the initial = case, the destination IP address used
for the Map-Request is the = destination-EID from the packet which had a
mapping cache lookup = failure.  For the latter 2 cases, the destination
IP address = used for the Map-Request is one of the RLOC addresses from
the = locator-set of the map cache entry.=94   How is the receiver = of the
Map-Request supposed to know whether an EID or RLOC is being = used?!?

9. On p.33, the Record TTL specifies = how long the entry is stored???
How does that go with the cache being = locally managed?   Having it be
the length of time that the = mapping is good for makes some = sense.

Which is what the specs = actually say. You can store for TTL time the mapping, then you have to = refresh if you still want to use it. The cache management is = local.



10. Related = to the Record TTL & cache storage, the description of how
to = handle mappings and expirations needs much better description. =  A
single case where a prefix has more specific prefixes that = route
differently is shown =96 but not the implications of handling = that as
more mappings are added and removed.  I think this is = largely a
question of better language.
 However, it is also unclear how an = ITR
doing cache management knows which entries to remove and = the
connections between them. =   
 Related, would an ETR announce mappings
for = instance for 3  /24 instead of the /23 and one exception = /24?
What if the ETR doesn=92t own the exception /24?  I think = more policy
and explanation is really needed = here.


How can you have the = right to origin a mapping announce of a /23 when you own only a part of = it?? 


11. If the = cache is =93locally managed=94, then a good description of the
rules = that the cache MUST follow should be in the draft. =

I totally disagree. This is an = implementation issue.

  There
clearly are some and the issues = are scattered.

12. I suspect that I can get more = context from other LISP drafts (and
plan to do so), but I don=92t see = how the mapping service isn=92t a
normative reference? =

References will be re-organized = before going for = LC.

Luigi


  I feel like there should be a framework = draft =96
perhaps the individual deployment draft is intended in its = place??

Perhaps it is because this is intended to be = experimental, but I find
the draft, writing, and consistency to be = significantly rough compared
to what I=92d expect for a draft about = to enter WG last = call.
_______________________________________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/lisp

= --Apple-Mail-7-797355355-- From vermagan@cisco.com Thu Apr 21 13:27:21 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 598B8E07E0 for ; Thu, 21 Apr 2011 13:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzEv2PAaZSWY for ; Thu, 21 Apr 2011 13:27:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id E9F16E06B9 for ; Thu, 21 Apr 2011 13:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vermagan@cisco.com; l=2351; q=dns/txt; s=iport; t=1303417639; x=1304627239; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YJwUCGp8VCdq2VWNUt+f5qhWU/ccbc3KgI76vy6FSOM=; b=QwMu5q7Cv9iYu9lJVbvJD/BWWZaUSC6XJk0bSYFKrjFcDPiZVgCfcPXu 7XgyJuTRi1eGD4EclTYtdb8VsMQFgFXH4a7UZ8pEW15s8U0TgFKHETSs7 1C0bEfL215b2/JFHLkLursVRKTl3KProh3O76gTQj96NgmlJ/1ooMzxYB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAEiSsE2rRDoI/2dsb2JhbACXTY4Jd6gdnFqFdgSFdIxD X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="299544442" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2011 20:27:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LKRBhT012161 for ; Thu, 21 Apr 2011 20:27:11 GMT Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 13:27:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 13:27:08 -0700 Message-ID: In-Reply-To: <4D9F5EDA.2080506@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Fwd: New Version Notificationfor draft-jakab-lisp-deployment-03 Thread-Index: Acv2IX1IcbH4JsqgR4ObcT/5hbUR7wKQMXqw References: <4D9F5E06.8010206@ac.upc.edu> <4D9F5EDA.2080506@joelhalpern.com> From: "Vina Ermagan (vermagan)" To: "LISP WG" X-OriginalArrivalTime: 21 Apr 2011 20:27:11.0565 (UTC) FILETIME=[7E7A6FD0:01CC0062] Subject: Re: [lisp] Fwd: New Version Notificationfor draft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:27:21 -0000 I support adoption of this document by the WG. Thanks, Vina Ermagan >-----Original Message----- >From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >Behalf Of Joel M. Halpern >Sent: Friday, April 08, 2011 12:16 PM >To: Lor=E1nd Jakab >Cc: LISP WG >Subject: Re: [lisp] Fwd: New Version Notificationfor=20 >draft-jakab-lisp-deployment-03 > >Thank you Lor=E1nd. >This starts a two week call for working group adoption of this=20 >document.=20 > Please respond to the list indicating whether you would like=20 >the WG to use this document as the basis for its work on=20 >documenting deployment considerations, or whether you see a=20 >difficulty with such adoption. > >Thank you, >Joel (and Terry) > >On 4/8/2011 3:12 PM, Lor=E1nd Jakab wrote: >> Folks, >> >> We just posted an updated -03 addressing Jari's comment from Prague=20 >> and some other minor editorial changes. >> >> We would like to kindly ask the chairs to consider the=20 >adoption of the=20 >> document as a working group item. >> >> Thank you, >> -Lorand Jakab >> >> -------- Original Message -------- >> Subject: New Version Notification for=20 >draft-jakab-lisp-deployment-03 >> Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: ljakab@ac.upc.edu >> CC: acabello@ac.upc.edu, fcoras@ac.upc.edu,=20 >jordi.domingo@ac.upc.edu, >> darlewis@cisco.com >> >> >> >> A new version of I-D, draft-jakab-lisp-deployment-03.txt has=20 >been successfully submitted by Lorand Jakab and posted to the=20 >IETF repository. >> >> Filename: draft-jakab-lisp-deployment >> Revision: 03 >> Title: LISP Network Element Deployment Considerations >> Creation_date: 2011-04-08 >> WG ID: Independent Submission >> Number_of_pages: 21 >> >> Abstract: >> This document discusses the different scenarios for the=20 >deployment of=20 >> the new network elements introduced by the Locator/Identifier=20 >> Separation Protocol (LISP). >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> 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 akatlas@gmail.com Thu Apr 21 14:31:32 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45AC3E0678 for ; Thu, 21 Apr 2011 14:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ltEmDXNrfbF for ; Thu, 21 Apr 2011 14:31:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id EB190E0704 for ; Thu, 21 Apr 2011 14:31:27 -0700 (PDT) Received: by iwn39 with SMTP id 39so124586iwn.31 for ; Thu, 21 Apr 2011 14:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2CyS6XHlQV6oIwGISIgBgAjtyU0oMJXaruD4mxj8hyE=; b=hmyf/fU07M/eLY5TDAPUbow690hsYIyZQ4MGNb8fvdFGF8nR+ciEq27cbrXTrNNAHu O3VJB9C2xYkKh90a1rAvvSl6ClkcBt6EcyZgd/ROW07aI02jRmsTQmSquQl0Km35E5Ws NAs65YdFyzNvd6DwVJDPhoY7YMDxIZOTtvXIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CabFSz1bMKa0NHDVSe2Gjx9PaG1jpn48SgIhYKbT/h84n0I9IogrV6txTtlqT6bNAx QOL1vyT8BSKioB6ni9bXJYYiT9yqwzD2ozKFrcoWVIQOMj+MyfODUMpxJeHM/MAXcyMJ KE8+q2xAkSOS4H1tnB63X+9/+J93g5OFnj4Bs= MIME-Version: 1.0 Received: by 10.42.132.65 with SMTP id c1mr496418ict.513.1303421486698; Thu, 21 Apr 2011 14:31:26 -0700 (PDT) Received: by 10.42.3.67 with HTTP; Thu, 21 Apr 2011 14:31:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Apr 2011 17:31:26 -0400 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: lisp Subject: Re: [lisp] comments and questions on draft-ietf-lisp-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 21:31:32 -0000 Hi Luigi, I appreciate your response, though I would have preferred more answers and fewer assertions. I fully intend to read the mapping service and deployment drafts - but they are not listed as normative references and I found this draft lacks adequate clarity to determine the completeness or accuracy of the protocol. My responses are, of course, in-line. Alia On Thu, Apr 21, 2011 at 4:29 AM, Luigi Iannone wrote: > Hi Alia, > and a good day to you as well. > I have a couple of answers/comments inline. > ciao > Luigi > > On Apr 20, 2011, at 5:40 PM, Alia Atlas wrote: > > 1. For instance, a mapping service is required =96 but the role and > assumptions for that mapping service are never described. =A0=A0The Packe= t > Flow Sequence (4.1) was helpful, but doesn=92t contain enough details to > be clear. =A0Who are the LISP Map-Requests sent to? =A0How is this known? > > In point 2 of the example it is clearly stated that the specific method i= s > not described in the example itself. > For that example you can think to the mapping system as a black box that = you > can query in order to retrieve the needed mappings. [Alia] I do not need the Mapping Service to be defined here. I am looking for a brief description of what a mapping service is. I'm looking for the black-box architectural definition of a Mapping Service - not the white-box or internal detailed description. Without such a definition, I can only see the Mapping Service as an Oracle - and the interactions between the ITR and ETR are not clear. > 2. The idea of using LISP for traffic-engineering is scattered through > the draft, but there is no clear example or description of how to do > so. =A0=A0=A0This also applies to the use of anycast. > > > The draft is about protocol specification not about the use/deployment of > LISP, hence IMHO there is no need to go deep in the TE topic. Even the > deployment draft cannot be IMO exhaustive on that topic. How to do TE is = up > to the operators. [Alia] I am more familiar with OSPF/ISIS/MPLS specifications and their completeness. Just because this is experimental doesn't mean that it shouldn't be clearly enough defined to be comprehensible and understood. I am looking for something that pulls out and describes briefly what TE is meant or intended. I understand, of course, that by providing different RLOCs for various EIDs one can direct traffic in different directions. A few examples would aid comprehension substantially. > 3. On p. 9, =A0it specifies for the EID-to-RLOC Database that =93the same > database mapping entries MUST be configured on all ETRs for a given > site.=94 =A0=A0Later in the draft, it is said that they can be transientl= y > different =96 but what is the impact there? =A0How is/should a > misconfiguration be detected much less enforced? =A0What are the > consequences of a misconfiguration & how would an operator deal with > it? > > > There is no use in document this. Is impossible to document all possible > misconfigurations, their consequences, =A0and their fixes. > This applies also to your next point. [Alia] A protocol exists in a network with operators. From reading this draft, it is NOT clear what the consequences of misconfiguration are nor how they would be detected. Is it simply that traffic may be routed differently depending upon which ETR a Map-Reply is heard from? Is it that traffic will oscillate between the different answers provided by the ETRs? > 4. How is looping prevented when doing re-encapsulation of packets? > What safety measures exist to prevent/minimize looping when there are > transient EID-to-RLOC mappings? =A0Obviously, TTL helps eventually to > discard packets, but that isn=92t sufficient. [Alia] Where and how is consistency guaranteed by LISP? This is not a misconfiguration question! Looping is traditionally avoided in overlay networks by staying in the overlay network. With MPLS-TE, LSPs can be advertised into the IGP as adjacencies that are then considered by the IGP's SPF computation. >From this draft, I cannot clearly tell either when re-encapsulation of packets is required nor how and when looping is prevented. In OSPF/ISIS, the opportunity for loops are well understood and occur only during convergence times. LISP doesn't explicitly have convergence... > 5. Why is there no definition for the RLOC to be IPv4 while the EID is > IPv6 or vice versa?? =A0In Section 9, traceroute talks about it =96 but i= t > isn=92t defined. =A0As I understand the potential uses of LISP, an idea i= s > to v6 in v4 automatic tunneling & vice versa =96 so it=92s very strange t= o > me that those packet formats aren=92t defined. > > > Your EIDs and RLOCs can be anything. Why the specs should define EID in I= Pv6 > and RLOCs in IPv4? A very nice feature of LISP is that you can mix protoc= ol > families, having v4 on v6 or viceversa, beside the v6 on v6 and v4 on v4. > Concerning the packet format, there is no use in adding all possible case= s > in the specs. The text is sufficiently clear on how to build packet in al= l > cases. [Alia] No text in Section 5 indicates that the 2 encapsulations defined clearly (IPv4 in IPv4 and IPv6 in IPv6) are not the only ones to be supported. Do you feel that the claim that there is an outer header and an inner header is sufficient? A specification must be implementable - and inter-operate. Without even trivial definitions of packet formats or the statement of the set that can exist, I am dubious that this draft gives the necessary detail. Please remember that the goal is not for only those actively collaborating on LISP specifications to be able to read and understand the drafts. Obviously, I can infer how to build IPv6 in IPv4 and vice versa - but the explicit statement of the two formats that are supported and the fact that the others are not there strongly implies that they should not be supported or expected. > 6. On p.23 in the 2nd to last paragraph, it seems that an ETR MUST do > fragment reassembly (at line rate) > > Not true. It is clearly stated that ETR treats the packet independently a= nd > does not perform reassembly. [Alia] If the ITR takes a packet, encapsulates it with an outer header, and then sends it with DF=3D0 through a network that fragments that packet - either the ETR must do reassembly or only the first fragment will make it to the destination host and be discarded eventually when no second (or further) fragments are received. The intermediate router that fragments the packet will not be LISP-aware or know to add an inner header to the second (or further) fragments. Please explain how this is not the case - since it is clearly stated that the ITR can set DF=3D0. > just in case the ITR (or an > attacker) chooses to set the DF bit to 0 and there is an MTU issue? > That isn=92t explicitly specified as a MUST =96 but the rest of the > language makes it pretty clear that=92s the case? =A0I really don=92t > understand the reasoning for this. =A0Wouldn=92t it be much cleaner and > easier for the ITR to fragment packets when it encapsulates them? > Forcing reassembly at the ETR requires queuing of the packets and > makes more attack vectors and complications=85 > > 7. For the virtualization/segmentation, how is the Source-EID AFI & > Source EID Address of use in the Mapping Request? =A0If there can be > multiple instances behind an RLOC, doesn=92t an instance ID need to be > there also? =A0=A0This area seems slightly described in the draft for the > traffic, but not for learning mappings. > > 8. Sec 6.1.3, =93For the initial case, the destination IP address used > for the Map-Request is the destination-EID from the packet which had a > mapping cache lookup failure. =A0For the latter 2 cases, the destination > IP address used for the Map-Request is one of the RLOC addresses from > the locator-set of the map cache entry.=94 =A0=A0How is the receiver of t= he > Map-Request supposed to know whether an EID or RLOC is being used?!? > > 9. On p.33, the Record TTL specifies how long the entry is stored??? > How does that go with the cache being locally managed? =A0=A0Having it be > the length of time that the mapping is good for makes some sense. > > Which is what the specs actually say. You can store for TTL time the > mapping, then you have to refresh if you still want to use it. The cache > management is local. [Alia] No, that is not what the spec says. It says "Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping." That doesn't sound like local cache management to me. The sender is clearl= y specifying to the receiver how long to store the mapping - and there's even a value given the recipient control on how long to store the mapping. > 10. Related to the Record TTL & cache storage, the description of how > to handle mappings and expirations needs much better description. =A0A > single case where a prefix has more specific prefixes that route > differently is shown =96 but not the implications of handling that as > more mappings are added and removed. =A0I think this is largely a > question of better language. > > =A0However, it is also unclear how an ITR > doing cache management knows which entries to remove and the > connections between them. > > =A0Related, would an ETR announce mappings > for instance for 3 =A0/24 instead of the /23 and one exception /24? > What if the ETR doesn=92t own the exception /24? =A0I think more policy > and explanation is really needed here. > > > How can you have the right to origin a mapping announce of a /23 when you > own only a part of it?? [Alia] That makes sense - pity there isn't clarification in the draft. I found the section on needing multiple prefixes to be returned for a mapping to be rather challenging to understand the intent. I'm also concerned for cache management on how it handles not knowing how much space a new mapping may require. I am having a hard time understanding how LISP with its caches isn't just a victim waiting for an attack - but I guess the theory is that it is experimental so it and alternatives can be played with. > 11. If the cache is =93locally managed=94, then a good description of the > rules that the cache MUST follow should be in the draft. > > I totally disagree. This is an implementation issue. [Alia] So it is an implementation issue if my cache runs out of space and can only store 2 of the 4 prefixes that are sent in response to a mapping? It is an implementation issue if I decide to purge a prefix that was actually a hole in a larger prefix? It is an implementation issue if I ignore the Record TTL and pitch mappings after 5 minutes? > =A0=A0There > clearly are some and the issues are scattered. > > 12. I suspect that I can get more context from other LISP drafts (and > plan to do so), but I don=92t see how the mapping service isn=92t a > normative reference? > > References will be re-organized before going for LC. [Alia] That may help. I know that there are implementations of LISP - but I find the lack of clarity and details on issues around liveness, looping, and so on to be distinct challenges to interop and safe operation. Alia > Luigi > > =A0=A0I feel like there should be a framework draft =96 > perhaps the individual deployment draft is intended in its place?? > > Perhaps it is because this is intended to be experimental, but I find > the draft, writing, and consistency to be significantly rough compared > to what I=92d expect for a draft about to enter WG last call. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > From damien.saucez@uclouvain.be Thu Apr 21 23:26:25 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7CE8DE07DC for ; Thu, 21 Apr 2011 23:26:25 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KYxuZarh5SS for ; Thu, 21 Apr 2011 23:26:24 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfc.amsl.com (Postfix) with ESMTP id 61DF5E070B for ; Thu, 21 Apr 2011 23:26:24 -0700 (PDT) Received: from [130.104.228.23] (unknown [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3F30EF299A; Fri, 22 Apr 2011 08:26:14 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be 3F30EF299A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1303453574; bh=4IAmj1wZtB0btdXw1aVwSyWz4tvMeNsyalagNr7aUVE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O7ZSaT43w2YErG1Jf1AAU51SLrYm4kv5mEdSJFzUlo3c+9HEURo9h1Gh46Z9BaGiY vrw2vufPEBiW1Gsht4DtnRkqQ3rJnUoTeHHKIqY72Zjj7B0HYBqWDp1XOrBKQLAM5J myQRrAjVqydbh/80Vt+D02tiuhbDF0AfY+sJQ0x4= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Damien Saucez In-Reply-To: Date: Fri, 22 Apr 2011 08:26:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D9F5E06.8010206@ac.upc.edu> <4D9F5EDA.2080506@joelhalpern.com> To: LISP WG X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-4.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 3F30EF299A.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [lisp] Fwd: New Version Notificationfor draft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 06:26:25 -0000 +1 Damien Saucez On 21 Apr 2011, at 22:27, Vina Ermagan (vermagan) wrote: >=20 > I support adoption of this document by the WG. >=20 > Thanks, > Vina Ermagan >=20 >> -----Original Message----- >> From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 >> Behalf Of Joel M. Halpern >> Sent: Friday, April 08, 2011 12:16 PM >> To: Lor=E1nd Jakab >> Cc: LISP WG >> Subject: Re: [lisp] Fwd: New Version Notificationfor=20 >> draft-jakab-lisp-deployment-03 >>=20 >> Thank you Lor=E1nd. >> This starts a two week call for working group adoption of this=20 >> document.=20 >> Please respond to the list indicating whether you would like=20 >> the WG to use this document as the basis for its work on=20 >> documenting deployment considerations, or whether you see a=20 >> difficulty with such adoption. >>=20 >> Thank you, >> Joel (and Terry) >>=20 >> On 4/8/2011 3:12 PM, Lor=E1nd Jakab wrote: >>> Folks, >>>=20 >>> We just posted an updated -03 addressing Jari's comment from Prague=20= >>> and some other minor editorial changes. >>>=20 >>> We would like to kindly ask the chairs to consider the=20 >> adoption of the=20 >>> document as a working group item. >>>=20 >>> Thank you, >>> -Lorand Jakab >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for=20 >> draft-jakab-lisp-deployment-03 >>> Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) >>> From: IETF I-D Submission Tool >>> To: ljakab@ac.upc.edu >>> CC: acabello@ac.upc.edu, fcoras@ac.upc.edu,=20 >> jordi.domingo@ac.upc.edu, >>> darlewis@cisco.com >>>=20 >>>=20 >>>=20 >>> A new version of I-D, draft-jakab-lisp-deployment-03.txt has=20 >> been successfully submitted by Lorand Jakab and posted to the=20 >> IETF repository. >>>=20 >>> Filename: draft-jakab-lisp-deployment >>> Revision: 03 >>> Title: LISP Network Element Deployment Considerations >>> Creation_date: 2011-04-08 >>> WG ID: Independent Submission >>> Number_of_pages: 21 >>>=20 >>> Abstract: >>> This document discusses the different scenarios for the=20 >> deployment of=20 >>> the new network elements introduced by the Locator/Identifier=20 >>> Separation Protocol (LISP). >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Fri Apr 22 02:17:29 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 02760E078E for ; Fri, 22 Apr 2011 02:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75ZH7pHP4hjh for ; Fri, 22 Apr 2011 02:17:26 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfc.amsl.com (Postfix) with ESMTP id 5A8BCE0692 for ; Fri, 22 Apr 2011 02:17:26 -0700 (PDT) Received: from [192.168.2.101] (p4FC25A37.dip.t-dialin.net [79.194.90.55]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 021957000585; Fri, 22 Apr 2011 11:17:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-886612562 From: Luigi Iannone In-Reply-To: Date: Fri, 22 Apr 2011 11:17:23 +0200 Message-Id: <7F3E52E0-5255-4E43-946F-3368C24533A8@net.t-labs.tu-berlin.de> References: To: Alia Atlas X-Mailer: Apple Mail (2.1084) Cc: lisp Subject: Re: [lisp] comments and questions on draft-ietf-lisp-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 09:17:29 -0000 --Apple-Mail-10-886612562 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alia, On Apr 21, 2011, at 11:31 PM, Alia Atlas wrote: > Hi Luigi, >=20 > I appreciate your response, though I would have preferred more answers > and fewer assertions. =20 Oscar Wilde said: "Be careful what you wish for, it might come true" ;-) Let me try to provide some answer inline.=20 [snip] >>=20 >> 1. For instance, a mapping service is required =96 but the role and >> assumptions for that mapping service are never described. The = Packet >> Flow Sequence (4.1) was helpful, but doesn=92t contain enough details = to >> be clear. Who are the LISP Map-Requests sent to? How is this known? >>=20 >> In point 2 of the example it is clearly stated that the specific = method is >> not described in the example itself. >> For that example you can think to the mapping system as a black box = that you >> can query in order to retrieve the needed mappings. >=20 > [Alia] I do not need the Mapping Service to be defined here. I am > looking for a brief description of what a mapping service is. I'm > looking for the black-box architectural definition of a Mapping > Service - not the white-box or internal detailed description. >=20 > Without such a definition, I can only see the Mapping Service as an > Oracle - and the interactions between the ITR and ETR are not clear. >=20 IMHO the text is sufficient for the example. You can safely consider the = mapping system as an oracle for the that specific example. >> 2. The idea of using LISP for traffic-engineering is scattered = through >> the draft, but there is no clear example or description of how to do >> so. This also applies to the use of anycast. >>=20 >>=20 >> The draft is about protocol specification not about the = use/deployment of >> LISP, hence IMHO there is no need to go deep in the TE topic. Even = the >> deployment draft cannot be IMO exhaustive on that topic. How to do TE = is up >> to the operators. >=20 > [Alia] I am more familiar with OSPF/ISIS/MPLS specifications and their > completeness. Just because this is experimental doesn't mean that it > shouldn't be clearly enough defined to be comprehensible and > understood. >=20 > I am looking for something that pulls out and describes briefly what > TE is meant or intended. I understand, of course, that by providing > different RLOCs for various EIDs one can direct traffic in different > directions. A few examples would aid comprehension substantially. >=20 IMHO the text is already there and examples are also there when = appropriate with the context. >> 3. On p. 9, it specifies for the EID-to-RLOC Database that =93the = same >> database mapping entries MUST be configured on all ETRs for a given >> site.=94 Later in the draft, it is said that they can be = transiently >> different =96 but what is the impact there? How is/should a >> misconfiguration be detected much less enforced? What are the >> consequences of a misconfiguration & how would an operator deal with >> it? >>=20 >>=20 >> There is no use in document this. Is impossible to document all = possible >> misconfigurations, their consequences, and their fixes. >> This applies also to your next point. >=20 > [Alia] A protocol exists in a network with operators. =46rom reading > this draft, it is NOT > clear what the consequences of misconfiguration are nor how they would > be detected. Is it simply that traffic may be routed differently > depending upon which ETR a Map-Reply is heard from? Is it that > traffic will oscillate between the different answers provided by the > ETRs? I still do not see why we should document all of these cases. First = because is impossible to document all of them, second because we would = document only what we think would happen. It does not buy you anything.=20= >=20 >> 4. How is looping prevented when doing re-encapsulation of packets? >> What safety measures exist to prevent/minimize looping when there are >> transient EID-to-RLOC mappings? Obviously, TTL helps eventually to >> discard packets, but that isn=92t sufficient. >=20 > [Alia] Where and how is consistency guaranteed by LISP? This is not a > misconfiguration > question! Looping is traditionally avoided in overlay networks by > staying in the overlay network. With MPLS-TE, LSPs can be advertised > into the IGP as adjacencies that are then considered by the IGP's SPF > computation. >=20 > =46rom this draft, I cannot clearly tell either when re-encapsulation = of > packets is required nor how and when looping is prevented. In > OSPF/ISIS, the opportunity for loops are well understood and occur > only during convergence times. >=20 > LISP doesn't explicitly have convergence... Has been proved that BGP does not have convergence neither... it still = works. But what exactly is your point here? [snip] >=20 > [Alia] No text in Section 5 indicates that the 2 encapsulations > defined clearly (IPv4 in IPv4 and IPv6 in IPv6) are not the only ones > to be supported. Do you feel that the claim that there is an outer > header and an inner header is sufficient? >=20 > A specification must be implementable - and inter-operate. Without > even trivial definitions of packet formats or the statement of the set > that can exist, I am dubious that this draft gives the necessary > detail. Please remember that the goal is not for only those actively > collaborating on LISP specifications to be able to read and understand > the drafts. >=20 > Obviously, I can infer how to build IPv6 in IPv4 and vice versa - but > the explicit statement of the two formats that are supported and the > fact that the others are not there strongly implies that they should > not be supported or expected. >=20 As an implementor even if those packets format would be defined in the = document I would skip reading them.=20 Why you say that it implies that they should not be supported or = expected?=20 The text clearly says that it is not worth to provide pictures for every = single case. >> 6. On p.23 in the 2nd to last paragraph, it seems that an ETR MUST do >> fragment reassembly (at line rate) >>=20 >> Not true. It is clearly stated that ETR treats the packet = independently and >> does not perform reassembly. >=20 > [Alia] If the ITR takes a packet, encapsulates it with an outer > header, and then sends it with DF=3D0 through a network that fragments > that packet - either the ETR must do reassembly or only the first > fragment will make it to the destination host and be discarded > eventually when no second (or further) fragments are received. The > intermediate router that fragments the packet will not be LISP-aware > or know to add an inner header to the second (or further) fragments. > Please explain how this is not the case - since it is clearly stated > that the ITR can set DF=3D0. Got your point. The example you make is correct. But in the original = text there is a SHOULD, is not enough for you? [snip] >> 9. On p.33, the Record TTL specifies how long the entry is stored??? >> How does that go with the cache being locally managed? Having it be >> the length of time that the mapping is good for makes some sense. >>=20 >> Which is what the specs actually say. You can store for TTL time the >> mapping, then you have to refresh if you still want to use it. The = cache >> management is local. >=20 > [Alia] No, that is not what the spec says. It says >=20 > "Record TTL: The time in minutes the recipient of the Map-Reply will > store the mapping. If the TTL is 0, the entry SHOULD be removed > from the cache immediately. If the value is 0xffffffff, the > recipient can decide locally how long to store the mapping." >=20 > That doesn't sound like local cache management to me. The sender is = clearly > specifying to the receiver how long to store the mapping - and there's > even a value > given the recipient control on how long to store the mapping. The text says how long the mapping is valid.=20 1) TTL =3D 0xffffffff you keep the mapping as long as you wish (consider = it always valid). 2) TTL =3D X : the mapping is valid only X period of time. When this = time is expired you SHOULD not use the mapping, hence you SHOULD delete = it from your cache otherwise your forwarding engine will use it. [snip] >=20 >>=20 >=20 > [Alia] That makes sense - pity there isn't clarification in the draft. > I found the section on needing multiple prefixes to be returned for a > mapping to be rather challenging to understand the intent. I'm also > concerned for cache management on how it handles not knowing how much > space a new mapping may require. >=20 > I am having a hard time understanding how LISP with its caches isn't > just a victim waiting for an attack - but I guess the theory is that > it is experimental so it and alternatives can be played with. I am not sure if you refer to security issues here, for that there is a = different document. >=20 >> 11. If the cache is =93locally managed=94, then a good description of = the >> rules that the cache MUST follow should be in the draft. >>=20 >> I totally disagree. This is an implementation issue. >=20 > [Alia] So it is an implementation issue if my cache runs out of space > and can only store 2 of the 4 prefixes that are sent in response to a > mapping? =20 Yes. Choose your replacement algorithm. > It is an implementation issue if I decide to purge a prefix > that was actually a hole in a larger prefix? =20 What do you mean by "hole"? > It is an implementation > issue if I ignore the Record TTL and pitch mappings after 5 minutes? You are not respecting the protocol and I do not see your point here. [snip] Luigi= --Apple-Mail-10-886612562 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Alia,

On Apr 21, 2011, at 11:31 PM, Alia Atlas = wrote:

Hi Luigi,

I appreciate your response, though I = would have preferred more answers
and fewer assertions. =  

Oscar Wilde said: "Be = careful what you wish for, it might come true" ;-)

Let me try to provide some = answer inline. 

 [snip]

1. For instance, a mapping service is required =96 but the = role and
assumptions for that = mapping service are never described.   The = Packet
Flow Sequence (4.1) was = helpful, but doesn=92t contain enough details = to
be clear.  Who are the = LISP Map-Requests sent to?  How is this = known?

In point 2 of = the example it is clearly stated that the specific method = is
not described in the = example itself.
For that = example you can think to the mapping system as a black box that = you
can query in order to = retrieve the needed mappings.

[Alia] I do not need = the Mapping Service to be defined here.  I am
looking for a = brief description of what a mapping service is.  I'm
looking for = the black-box architectural definition of a Mapping
Service - not the = white-box or internal detailed description.

Without such a = definition, I can only see the Mapping Service as an
Oracle - and the = interactions between the ITR and ETR are not = clear.


IMHO the text is = sufficient for the example. You can safely consider the mapping system = as an oracle for the that specific = example.


2. The idea of using LISP = for traffic-engineering is scattered through
the draft, but there is no clear example or description of = how to do
so. =    This also applies to the use of = anycast.


The draft is = about protocol specification not about the use/deployment = of
LISP, hence IMHO there is = no need to go deep in the TE topic. Even the
deployment draft cannot be IMO exhaustive on that topic. = How to do TE is up
to the = operators.

[Alia] I am more familiar with = OSPF/ISIS/MPLS specifications and their
completeness.  Just = because this is experimental doesn't mean that it
shouldn't be = clearly enough defined to be comprehensible and
understood.

I am looking for something that pulls out and = describes briefly what
TE is meant or intended.  I understand, = of course, that by providing
different RLOCs for various EIDs one can = direct traffic in different
directions.  A few examples would = aid comprehension = substantially.


IMHO the = text is already there and examples are also there when appropriate with = the context.


3. On p. 9,  it = specifies for the EID-to-RLOC Database that =93the = same
database mapping entries = MUST be configured on all ETRs for a given
site.=94   Later in the draft, it is said that = they can be transiently
different =96 but what is the impact there?  How = is/should a
misconfiguration = be detected much less enforced?  What are = the
consequences of a = misconfiguration & how would an operator deal = with
it?


There is no use = in document this. Is impossible to document all = possible
misconfigurations, = their consequences,  and their fixes.
This applies also to your next = point.

[Alia] A protocol exists in a network with = operators.  =46rom reading
this draft, it is NOT
clear what = the consequences of misconfiguration are nor how they would
be = detected.  Is it simply that traffic may be routed = differently
depending upon which ETR a Map-Reply is heard from? =  Is it that
traffic will oscillate between the different answers = provided by the
ETRs?

I = still do not see why we should document all of these cases. First = because is impossible to document all of them, second because we would = document only what we think would happen. It does not buy you = anything. 



4. How is looping = prevented when doing re-encapsulation of = packets?
What safety measures = exist to prevent/minimize looping when there = are
transient EID-to-RLOC = mappings?  Obviously, TTL helps eventually = to
discard packets, but that = isn=92t sufficient.

[Alia] Where and how is = consistency guaranteed by LISP?  This is not = a
misconfiguration
question!  Looping is traditionally = avoided in overlay networks by
staying in the overlay network. =  With MPLS-TE, LSPs can be advertised
into the IGP as = adjacencies that are then considered by the IGP's = SPF
computation.

=46rom this draft, I cannot clearly tell = either when re-encapsulation of
packets is required nor how and when = looping is prevented.  In
OSPF/ISIS, the opportunity for loops = are well understood and occur
only during convergence = times.

LISP doesn't explicitly have = convergence...

Has been proved = that BGP does not have convergence neither... it still = works.

But what exactly is your point = here?

[snip]


[Alia] No text in Section 5 indicates that the 2 = encapsulations
defined clearly (IPv4 in IPv4 and IPv6 in IPv6) are = not the only ones
to be supported.  Do you feel that the claim = that there is an outer
header and an inner header is = sufficient?

A specification must be implementable - and = inter-operate.  Without
even trivial definitions of packet = formats or the statement of the set
that can exist, I am dubious that = this draft gives the necessary
detail.  Please remember that the = goal is not for only those actively
collaborating on LISP = specifications to be able to read and understand
the = drafts.

Obviously, I can infer how to build IPv6 in IPv4 and vice = versa - but
the explicit statement of the two formats that are = supported and the
fact that the others are not there strongly implies = that they should
not be supported or = expected.


As an = implementor even if those packets format would be defined in the = document I would skip reading them. 

Why = you say that it implies that they should not be supported or = expected? 

The text clearly says that it = is not worth to provide pictures for every single = case.


6. On p.23 in the 2nd to last paragraph, it seems that an = ETR MUST do
fragment = reassembly (at line rate)

Not true. It is = clearly stated that ETR treats the packet independently = and
does not perform = reassembly.

[Alia] If the ITR takes a packet, = encapsulates it with an outer
header, and then sends it with DF=3D0 = through a network that fragments
that packet - either the ETR must do = reassembly or only the first
fragment will make it to the destination = host and be discarded
eventually when no second (or further) = fragments are received.  The
intermediate router that fragments = the packet will not be LISP-aware
or know to add an inner header to = the second (or further) fragments.
Please explain how this is not the = case - since it is clearly stated
that the ITR can set = DF=3D0.

Got your point. The = example you make is correct. But in the original text there is a SHOULD, = is not enough for = you?

[snip]

9. On p.33, the Record TTL = specifies how long the entry is stored???
How does that go with the cache being locally managed? =   Having it be
the = length of time that the mapping is good for makes some = sense.

Which is what = the specs actually say. You can store for TTL time = the
mapping, then you have to = refresh if you still want to use it. The = cache
management is = local.

[Alia] No, that is not what the spec says. =  It says

"Record TTL:  The time in minutes the = recipient of the Map-Reply will
     store = the mapping.  If the TTL is 0, the entry SHOULD be removed
=      from the cache immediately.  If the = value is 0xffffffff, the
     recipient can = decide locally how long to store the mapping."

That doesn't sound = like local cache management to me.  The sender is = clearly
specifying to the receiver how long to store the mapping - = and there's
even a value
given the recipient control on how long = to store the mapping.

The text = says how long the mapping is valid. 

1) = TTL =3D 0xffffffff you keep the mapping as long as you wish (consider it = always valid).
2) TTL =3D X : the mapping is valid only X = period of time. When this time is expired you SHOULD not use the = mapping, hence you SHOULD delete it from your cache otherwise your = forwarding engine will use it.

[snip]



[Alia] That makes sense - pity there = isn't clarification in the draft.
I found the section on needing multiple prefixes to = be returned for a
mapping to be rather challenging to understand the = intent.  I'm also
concerned for cache management on how it = handles not knowing how much
space a new mapping may = require.

I am having a hard time understanding how LISP with its = caches isn't
just a victim waiting for an attack - but I guess the = theory is that
it is experimental so it and alternatives can be = played with.

I am not sure if = you refer to security issues here, for that there is a different = document.


11. If the cache is =93locally managed=94, then a good = description of the
rules that = the cache MUST follow should be in the = draft.

I totally = disagree. This is an implementation issue.

[Alia] So = it is an implementation issue if my cache runs out of space
and can = only store 2 of the 4 prefixes that are sent in response to = a
mapping?  

Yes. Choose = your replacement algorithm.

It = is an implementation issue if I decide to purge a prefix
that was = actually a hole in a larger prefix? =  

What do you mean by = "hole"?

It is an = implementation
issue if I ignore the Record TTL and pitch mappings = after 5 minutes?

You are not = respecting the protocol and I do not see your point = here.

[snip]

Luigi= --Apple-Mail-10-886612562-- From fmaino@cisco.com Fri Apr 22 05:56:29 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7D82EE067C for ; Fri, 22 Apr 2011 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DIIsEOvnsEn for ; Fri, 22 Apr 2011 05:56:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 26B8CE0664 for ; Fri, 22 Apr 2011 05:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=6043; q=dns/txt; s=iport; t=1303476988; x=1304686588; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=qhBInxTkb9VWagkVIvK57G2B5O/J6fm1equFck7rfs0=; b=kSixUrKFkTOGCrt/nec0ar/y8vfGeVXajDLMIvs5Gb9JjUqroiojAk62 eUFHjOV2dUmTU4HdzVl5z5RgBcIiMpNOk5P9ri9Do24IDnv0zy2kWSW2Q hxoE87XXfhtSGJcj8yohGgZbwYRa2cPlLMnlHptQl8rNA/FTDxmlbfwI0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJ6sU2tJV2Y/2dsb2JhbACEUKEOd6ZXi1yQfoR5fQSCA4NxiDk X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208,217";a="434822529" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2011 12:56:27 +0000 Received: from sjc-vpn7-747.cisco.com (sjc-vpn7-747.cisco.com [10.21.146.235]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3MCuQFI023420 for ; Fri, 22 Apr 2011 12:56:27 GMT Message-ID: <4DB17AF8.4050003@cisco.com> Date: Fri, 22 Apr 2011 05:56:24 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: lisp@ietf.org References: <4D9F5E06.8010206@ac.upc.edu> In-Reply-To: <4D9F5E06.8010206@ac.upc.edu> Content-Type: multipart/alternative; boundary="------------070309050304090401040506" Subject: Re: [lisp] Fwd: New Version Notification fordraft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:56:29 -0000 This is a multi-part message in MIME format. --------------070309050304090401040506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this document as a WG item. Fabio On 4/8/11 12:12 PM, Loránd Jakab wrote: > > Folks, > > We just posted an updated -03 addressing Jari's comment from Prague and > some other minor editorial changes. > > We would like to kindly ask the chairs to consider the adoption of the > document as a working group item. > > Thank you, > -Lorand Jakab > > -------- Original Message -------- > Subject: New Version Notification for > draft-jakab-lisp-deployment-03 > Date: Fri, 8 Apr 2011 08:11:06 -0700 (PDT) > From: IETF I-D Submission Tool > To: ljakab@ac.upc.edu > CC: acabello@ac.upc.edu, fcoras@ac.upc.edu, jordi.domingo@ac.upc.edu, > darlewis@cisco.com > > > > A new version of I-D, draft-jakab-lisp-deployment-03.txt has been > successfully submitted by Lorand Jakab and posted to the IETF repository. > > Filename: draft-jakab-lisp-deployment > Revision: 03 > Title: LISP Network Element Deployment Considerations > Creation_date: 2011-04-08 > WG ID: Independent Submission > Number_of_pages: 21 > > Abstract: > This document discusses the different scenarios for the deployment of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > > The IETF Secretariat. > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------070309050304090401040506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I support adoption of this document as a WG item.

Fabio

On 4/8/11 12:12 PM, Loránd Jakab wrote:
[lisp] Fwd: New Version Notification fordraft-jakab-lisp-deployment-03

Folks,

We just posted an updated -03 addressing Jari's comment from Prague and
some other minor editorial changes.

We would like to kindly ask the chairs to consider the adoption of the
document as a working group item.

Thank you,
-Lorand Jakab

-------- Original Message --------
Subject:        New Version Notification for draft-jakab-lisp-deployment-03
Date:   Fri, 8 Apr 2011 08:11:06 -0700 (PDT)
From:   IETF I-D Submission Tool <idsubmission@ietf.org>
To:     ljakab@ac.upc.edu
CC:     acabello@ac.upc.edu, fcoras@ac.upc.edu, jordi.domingo@ac.upc.edu,
darlewis@cisco.com



A new version of I-D, draft-jakab-lisp-deployment-03.txt has been successfully submitted by Lorand Jakab and posted to the IETF repository.

Filename:        draft-jakab-lisp-deployment
Revision:        03
Title:           LISP Network Element Deployment Considerations
Creation_date:   2011-04-08
WG ID:           Independent Submission
Number_of_pages: 21

Abstract:
This document discusses the different scenarios for the deployment of
the new network elements introduced by the Locator/Identifier
Separation Protocol (LISP).
                                                                                 


The IETF Secretariat.



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



-- 
Fabio Maino
fmaino@cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------070309050304090401040506-- From vimoreno@cisco.com Fri Apr 22 06:35:03 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15AA1E0740 for ; Fri, 22 Apr 2011 06:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.531 X-Spam-Level: X-Spam-Status: No, score=-8.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA0kU8iWdNCr for ; Fri, 22 Apr 2011 06:35:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id BAD69E0745 for ; Fri, 22 Apr 2011 06:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vimoreno@cisco.com; l=10787; q=dns/txt; s=iport; t=1303479301; x=1304688901; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=SOQI1UX0MnCf4vJUYdwjbc82+imYhpJoDGCJ8QWJn/A=; b=Zh8bL/0lRb/XWHva7pmkxPXxohLxm90GDTXwSyxpKteKcvYyF51CPwHS GhGjUaRZcqeVEXCcuFXMltgTkQIPqh2NOFaAg1BTHnj6o4MDqLoQzNWsq Z9syqwQ+PbKOi13C51jWvWNRLfkOFTvSYjzkJMyDK0PAUr3ThA9DM/Zob I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEGAGKDsU2rRDoG/2dsb2JhbACEUKAEgQgCd4hwnV6LXJEEgSmDUH0EggODcYg5hA6GIA X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208,217";a="685758841" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2011 13:35:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3MDZ1kf022237 for ; Fri, 22 Apr 2011 13:35:01 GMT Received: from xmb-sjc-212.amer.cisco.com ([171.70.151.141]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 06:35:01 -0700 Received: from 128.107.191.114 ([128.107.191.114]) by xmb-sjc-212.amer.cisco.com ([171.70.151.141]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Apr 2011 13:35:00 +0000 References: <4D9F5E06.8010206@ac.upc.edu> <4DB17AF8.4050003@cisco.com> Content-Transfer-Encoding: 7bit From: "Victor Moreno (vimoreno)" Content-Type: multipart/alternative; boundary="Apple-Mail-3-902059440"; charset="utf-8" thread-topic: [lisp] Fwd: New Version Notificationfordraft-jakab-lisp-deployment-03 thread-index: AcwA8hQRetJCA0HqR4OLOkMusPo7yw== In-Reply-To: <4DB17AF8.4050003@cisco.com> Message-ID: Date: Fri, 22 Apr 2011 06:34:49 -0700 To: "Fabio Maino" MIME-Version: 1.0 (iPhone Mail 8C148a) X-OriginalArrivalTime: 22 Apr 2011 13:35:01.0069 (UTC) FILETIME=[145DF7D0:01CC00F2] Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: New Version Notificationfordraft-jakab-lisp-deployment-03 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 13:35:03 -0000 --Apple-Mail-3-902059440 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 KzENCg0KVmljdG9yDQoNCk9uIEFwciAyMiwgMjAxMSwgYXQgNTo1NiBBTSwgIkZhYmlvIE1haW5v IiA8Zm1haW5vQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj4gSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQgYXMgYSBXRyBpdGVtLiANCj4gDQo+IEZhYmlvDQo+IA0KPiBPbiA0LzgvMTEg MTI6MTIgUE0sIExvcsODwqFuZCBKYWthYiB3cm90ZToNCj4+IA0KPj4gRm9sa3MsDQo+PiANCj4+ IFdlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQgLTAzIGFkZHJlc3NpbmcgSmFyaSdzIGNvbW1lbnQg ZnJvbSBQcmFndWUgYW5kDQo+PiBzb21lIG90aGVyIG1pbm9yIGVkaXRvcmlhbCBjaGFuZ2VzLg0K Pj4gDQo+PiBXZSB3b3VsZCBsaWtlIHRvIGtpbmRseSBhc2sgdGhlIGNoYWlycyB0byBjb25zaWRl ciB0aGUgYWRvcHRpb24gb2YgdGhlDQo+PiBkb2N1bWVudCBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRl bS4NCj4+IA0KPj4gVGhhbmsgeW91LA0KPj4gLUxvcmFuZCBKYWthYg0KPj4gDQo+PiAtLS0tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+PiBTdWJqZWN0OiDDgiDDgiDDgiDDgiDDgiDD giAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qYWthYi1saXNwLWRlcGxveW1l bnQtMDMNCj4+IERhdGU6IMOCICBGcmksIDggQXByIDIwMTEgMDg6MTE6MDYgLTA3MDAgKFBEVCkN Cj4+IEZyb206IMOCICBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgPGlkc3VibWlzc2lvbkBpZXRm Lm9yZz4NCj4+IFRvOiDDgiDDgiDDgiAgbGpha2FiQGFjLnVwYy5lZHUNCj4+IENDOiDDgiDDgiDD giAgYWNhYmVsbG9AYWMudXBjLmVkdSwgZmNvcmFzQGFjLnVwYy5lZHUsIGpvcmRpLmRvbWluZ29A YWMudXBjLmVkdSwNCj4+IGRhcmxld2lzQGNpc2NvLmNvbQ0KPj4gDQo+PiANCj4+IA0KPj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpha2FiLWxpc3AtZGVwbG95bWVudC0wMy50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMb3JhbmQgSmFrYWIgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPj4gDQo+PiBGaWxlbmFtZTrDgiDDgiDDgiDDgiDDgiDD giDDgiAgZHJhZnQtamFrYWItbGlzcC1kZXBsb3ltZW50DQo+PiBSZXZpc2lvbjrDgiDDgiDDgiDD giDDgiDDgiDDgiAgMDMNCj4+IFRpdGxlOsOCICDDgiDDgiDDgiDDgiDDgiDDgiDDgiDDgiAgTElT UCBOZXR3b3JrIEVsZW1lbnQgRGVwbG95bWVudCBDb25zaWRlcmF0aW9ucw0KPj4gQ3JlYXRpb25f ZGF0ZTrDgiDDgiAgMjAxMS0wNC0wOA0KPj4gV0cgSUQ6w4IgIMOCIMOCIMOCIMOCIMOCIMOCIMOC IMOCICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQo+PiBOdW1iZXJfb2ZfcGFnZXM6IDIxDQo+PiAN Cj4+IEFic3RyYWN0Og0KPj4gVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdGhlIGRpZmZlcmVudCBz Y2VuYXJpb3MgZm9yIHRoZSBkZXBsb3ltZW50IG9mDQo+PiB0aGUgbmV3IG5ldHdvcmsgZWxlbWVu dHMgaW50cm9kdWNlZCBieSB0aGUgTG9jYXRvci9JZGVudGlmaWVyDQo+PiBTZXBhcmF0aW9uIFBy b3RvY29sIChMSVNQKS4NCj4+IMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOC IMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOC IMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOC IMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOC IMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIMOCIA0KPj4gDQo+PiANCj4+IFRoZSBJRVRG IFNlY3JldGFyaWF0Lg0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IGxpc3AgbWFpbGluZyBsaXN0DQo+PiBsaXNwQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3ANCj4+ IA0KPiANCj4gDQo+IC0tIA0KPiBGYWJpbyBNYWlubw0KPiBmbWFpbm9AY2lzY28uY29tDQo+IA0K PiBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KPiBodHRwOi8vd3d3LmNp c2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbGlzcCBt YWlsaW5nIGxpc3QNCj4gbGlzcEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xpc3ANCg== --Apple-Mail-3-902059440 Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj4rMTxicj48YnI+VmljdG9yPC9kaXY+ PGRpdj48YnI+T24gQXByIDIyLCAyMDExLCBhdCA1OjU2IEFNLCAiRmFiaW8gTWFpbm8iICZsdDs8 YSBocmVmPSJtYWlsdG86Zm1haW5vQGNpc2NvLmNvbSI+Zm1haW5vQGNpc2NvLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2Pg0KDQogICAgSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBXRyBp dGVtLiA8YnI+DQogICAgPGJyPg0KICAgIEZhYmlvPGJyPg0KICAgIDxicj4NCiAgICBPbiA0Lzgv MTEgMTI6MTIgUE0sIExvcsODwqFuZCBKYWthYiB3cm90ZToNCiAgICA8YmxvY2txdW90ZSBjaXRl PSJtaWQ6NEQ5RjVFMDYuODAxMDIwNkBhYy51cGMuZWR1IiB0eXBlPSJjaXRlIj4NCiAgICAgIA0K ICAgICAgDQogICAgICANCiAgICAgIDwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3Jt YXQgLS0+DQogICAgICA8cD48Zm9udCBzaXplPSIyIj5Gb2xrcyw8YnI+DQogICAgICAgICAgPGJy Pg0KICAgICAgICAgIFdlIGp1c3QgcG9zdGVkIGFuIHVwZGF0ZWQgLTAzIGFkZHJlc3NpbmcgSmFy aSdzIGNvbW1lbnQgZnJvbQ0KICAgICAgICAgIFByYWd1ZSBhbmQ8YnI+DQogICAgICAgICAgc29t ZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgY2hhbmdlcy48YnI+DQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIFdlIHdvdWxkIGxpa2UgdG8ga2luZGx5IGFzayB0aGUgY2hhaXJzIHRvIGNvbnNpZGVy IHRoZQ0KICAgICAgICAgIGFkb3B0aW9uIG9mIHRoZTxicj4NCiAgICAgICAgICBkb2N1bWVudCBh cyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIFRo YW5rIHlvdSw8YnI+DQogICAgICAgICAgLUxvcmFuZCBKYWthYjxicj4NCiAgICAgICAgICA8YnI+ DQogICAgICAgICAgLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLTxicj4NCiAgICAg ICAgICBTdWJqZWN0OiDDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4Im bmJzcDsgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KICAgICAgICAgIGRyYWZ0LWpha2Fi LWxpc3AtZGVwbG95bWVudC0wMzxicj4NCiAgICAgICAgICBEYXRlOiDDgiZuYnNwOyBGcmksIDgg QXByIDIwMTEgMDg6MTE6MDYgLTA3MDAgKFBEVCk8YnI+DQogICAgICAgICAgRnJvbTogw4ImbmJz cDsgSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5 NkUiIGhyZWY9Im1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmciPiZsdDs8YSBocmVmPSJtYWls dG86aWRzdWJtaXNzaW9uQGlldGYub3JnIj5pZHN1Ym1pc3Npb25AaWV0Zi5vcmc8L2E+Jmd0Ozwv YT48YnI+DQogICAgICAgICAgVG86IMOCJm5ic3A7w4ImbmJzcDvDgiZuYnNwOyA8YSBjbGFzcz0i bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bGpha2FiQGFjLnVwYy5lZHUi PjxhIGhyZWY9Im1haWx0bzpsamFrYWJAYWMudXBjLmVkdSI+bGpha2FiQGFjLnVwYy5lZHU8L2E+ PC9hPjxicj4NCiAgICAgICAgICBDQzogw4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7IDxhIGNsYXNz PSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphY2FiZWxsb0BhYy51cGMu ZWR1Ij48YSBocmVmPSJtYWlsdG86YWNhYmVsbG9AYWMudXBjLmVkdSI+YWNhYmVsbG9AYWMudXBj LmVkdTwvYT48L2E+LCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt YWlsdG86ZmNvcmFzQGFjLnVwYy5lZHUiPjxhIGhyZWY9Im1haWx0bzpmY29yYXNAYWMudXBjLmVk dSI+ZmNvcmFzQGFjLnVwYy5lZHU8L2E+PC9hPiwNCiAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86am9yZGkuZG9taW5nb0BhYy51cGMuZWR1 Ij48YSBocmVmPSJtYWlsdG86am9yZGkuZG9taW5nb0BhYy51cGMuZWR1Ij5qb3JkaS5kb21pbmdv QGFjLnVwYy5lZHU8L2E+PC9hPiw8YnI+DQogICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGlu ay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRhcmxld2lzQGNpc2NvLmNvbSI+PGEgaHJlZj0i bWFpbHRvOmRhcmxld2lzQGNpc2NvLmNvbSI+ZGFybGV3aXNAY2lzY28uY29tPC9hPjwvYT48YnI+ DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAg ICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpha2FiLWxpc3AtZGVwbG95bWVudC0wMy50 eHQgaGFzDQogICAgICAgICAgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExvcmFuZCBK YWthYiBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgICAgICAgIElFVEYgcmVwb3NpdG9yeS48YnI+DQog ICAgICAgICAgPGJyPg0KICAgICAgICAgIEZpbGVuYW1lOsOCJm5ic3A7w4ImbmJzcDvDgiZuYnNw O8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7IGRyYWZ0LWpha2FiLWxpc3AtZGVwbG95 bWVudDxicj4NCiAgICAgICAgICBSZXZpc2lvbjrDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZu YnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwOyAwMzxicj4NCiAgICAgICAgICBUaXRsZTrDgiZu YnNwOyDDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZu YnNwO8OCJm5ic3A7IExJU1AgTmV0d29yayBFbGVtZW50IERlcGxveW1lbnQNCiAgICAgICAgICBD b25zaWRlcmF0aW9uczxicj4NCiAgICAgICAgICBDcmVhdGlvbl9kYXRlOsOCJm5ic3A7w4ImbmJz cDsgMjAxMS0wNC0wODxicj4NCiAgICAgICAgICBXRyBJRDrDgiZuYnNwOyDDgiZuYnNwO8OCJm5i c3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7IEluZGVw ZW5kZW50IFN1Ym1pc3Npb248YnI+DQogICAgICAgICAgTnVtYmVyX29mX3BhZ2VzOiAyMTxicj4N CiAgICAgICAgICA8YnI+DQogICAgICAgICAgQWJzdHJhY3Q6PGJyPg0KICAgICAgICAgIFRoaXMg ZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9zIGZvciB0aGUNCiAgICAg ICAgICBkZXBsb3ltZW50IG9mPGJyPg0KICAgICAgICAgIHRoZSBuZXcgbmV0d29yayBlbGVtZW50 cyBpbnRyb2R1Y2VkIGJ5IHRoZSBMb2NhdG9yL0lkZW50aWZpZXI8YnI+DQogICAgICAgICAgU2Vw YXJhdGlvbiBQcm90b2NvbCAoTElTUCkuPGJyPg0Kw4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4Im bmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZu YnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5i c3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJz cDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNw O8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7 w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvD giZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OC Jm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4Im bmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZu YnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5i c3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7w4ImbmJzcDvDgiZuYnNwO8OCJm5ic3A7PGJyPg0K ICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgVGhlIElFVEYgU2VjcmV0 YXJpYXQuPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGJy Pg0KICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KICAgICAgICAgIGxpc3AgbWFpbGluZyBsaXN0PGJyPg0KICAgICAgICAgIDxhIGNs YXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpsaXNwQGlldGYub3Jn Ij48YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT48L2E+PGJy Pg0KICAgICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpc3AiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbGlzcDwvYT48L2E+PGJyPg0KICAgICAgICA8L2ZvbnQ+DQogICAgICA8L3A+DQog ICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAgPHByZSBjbGFzcz0ibW96 LXNpZ25hdHVyZSIgY29scz0iNzIiPi0tIA0KRmFiaW8gTWFpbm8NCjxhIGNsYXNzPSJtb3otdHh0 LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpmbWFpbm9AY2lzY28uY29tIj48YSBocmVm PSJtYWlsdG86Zm1haW5vQGNpc2NvLmNvbSI+Zm1haW5vQGNpc2NvLmNvbTwvYT48L2E+DQoNCkZv ciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdf YnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28u Y29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDov L3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5o dG1sPC9hPjwvYT4NCjwvcHJlPg0KICANCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPmxpc3AgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48c3Bhbj48YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT48 L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbGlzcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwPC9h Pjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-3-902059440-- From ljakab@ac.upc.edu Mon Apr 25 04:19:45 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57AB2E071F for ; Mon, 25 Apr 2011 04:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jt-s3DgCouF for ; Mon, 25 Apr 2011 04:19:44 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfc.amsl.com (Postfix) with ESMTP id 422E9E070D for ; Mon, 25 Apr 2011 04:19:43 -0700 (PDT) Received: from [192.168.1.133] (130.226.23.95.dynamic.jazztel.es [95.23.226.130]) by gw.ac.upc.edu (Postfix) with ESMTP id C432B6B02E4; Mon, 25 Apr 2011 13:19:40 +0200 (CEST) Message-ID: <4DB558CD.3060704@ac.upc.edu> Date: Mon, 25 Apr 2011 13:19:41 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: LISP WG OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] LISP support in Wireshark X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 11:19:45 -0000 Folks, As some of you know, I have been maintaining a patch to add LISP packet dissection support in Wireshark for almost a year now. This personal project has reached an important milestone today, as it was accepted for inclusion into the official Wireshark tree by the upstream developers, and committed as revision 36845 in SVN trunk. You can get the code with: svn co http://anonsvn.wireshark.org/wireshark/trunk wireshark This means that the next development release of Wireshark (v1.5.2) will include LISP support. Since the Wireshark project releases binaries for development releases, compiling from source will not be necessary at that point, and you will be able to download and install binaries from the official Wireshark download page with LISP support. This will be useful especially for those who (for whatever reason) need to use Wireshark on Windows, where compiling from source is a complex and time consuming endeavor (I actually was too discouraged to try it myself). Once the 1.6.x next stable branch of Wireshark will be released, LISP support will become even more ubiquitous, as distributions update to shipping with that branch by default. As always, feedback is welcome, and I'm especially grateful for .pcap files with packets that are currently not correctly decoded by my patch. Note that if you need the latest features (I'm already working on additional stuff), you should still keep tabs on my Wireshark page: http://lisp.ccaba.upc.edu/wireshark/ -Lori From jmh@joelhalpern.com Mon Apr 25 07:55:16 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 04A51E06F5 for ; Mon, 25 Apr 2011 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tufZwEDqeWUO for ; Mon, 25 Apr 2011 07:55:15 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfc.amsl.com (Postfix) with ESMTP id 3E8CFE0696 for ; Mon, 25 Apr 2011 07:55:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E64AA430107; Mon, 25 Apr 2011 07:55:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.1.14] (pool-96-245-82-167.phlapa.fios.verizon.net [96.245.82.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 77A414300FD; Mon, 25 Apr 2011 07:55:14 -0700 (PDT) Message-ID: <4DB58B52.9030004@joelhalpern.com> Date: Mon, 25 Apr 2011 10:55:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: Re: LISP Security issues X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 14:55:16 -0000 There are a number of security dimensions, AKM being one example, where the tradeoffs we have made are quite sensible for an experiment, but will need revisitng, and probably new work, before we can go for proposed standard. After discussion with the security community, the proposal is to add a disclaimer early in the document. ( I would guess this would go in the Introduction, with a clear heading like "issues relative to standardization". Below is text Sam has crafted as a starting point for us. Can folks live with it? Yours, Joel -------- Original Message -------- Subject: Re: LISP Security issues Date: Mon, 25 Apr 2011 10:13:22 -0400 From: Sam Hartman To: Joel M. Halpern CC: Turner, Sean P. , Sam Hartman , Stephen Farrell , Terry Manderson I propose the following for the LISP base spec. This document represents the thinking of the LISP working group. However, as work continued to develop the LISP specification there were a number of issues identified where additional discussions including other parts of the IETF will be required surrounding issues such as security and encapsulation. As specific examples, the discussion of how LISP interacts with BCP 107's guidance on automated key management is ongoing. This and other issues would need to be resolved before standardization of LISP. Accounting for these concerns may significantly change tradeoffs underlying design decisions in LISP; it is important that deferring these discussions in order to publish an experimental protocol sooner not restrict a standardized solution that balances concerns of all areas of the IETF. Things I think are important here: 1) issues exist both for securit and other things 2) Discussions of these issues are ongoing|need to happen prior to standardization (take your pick) 3) Encompassing more things may change tradeoffs 4) By agreeing not to block on solving these problems now we're agreeing that what we publish now does not restrict what we do in the future I'm not attached to specific wording provided we make these points. ... From darlewis@cisco.com Mon Apr 25 09:59:38 2011 Return-Path: X-Original-To: lisp@ietfc.amsl.com Delivered-To: lisp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 867C7E073F for ; Mon, 25 Apr 2011 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v-QxpVNbt6F for ; Mon, 25 Apr 2011 09:59:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 785B2E06AE for ; Mon, 25 Apr 2011 09:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=3119; q=dns/txt; s=iport; t=1303750777; x=1304960377; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wDG7/fscpzQpxt6XqkXbhw/JkwFA91Lq0L0ATXdjnHI=; b=YXRPXRr/zHUq9iKXPO8oi1pZVTwcLe8rA97N/3XDkepSW3emQwsSH6ts gMrAZYbCJko2AKp36NCmPiDS1ek6Lg1fdap9UY2zrVwciV7mGqmtz64XO 2Zx/NMJQHGQj6Oc4FZSlCYskkLA89rydFtIbYlBCtYo7x7alc33AKP8AP w=; X-IronPort-AV: E=Sophos;i="4.64,265,1301875200"; d="scan'208";a="344038529" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 25 Apr 2011 16:59:14 +0000 Received: from sjc-vpn6-1469.cisco.com (sjc-vpn6-1469.cisco.com [10.21.125.189]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3PGxEP6009426; Mon, 25 Apr 2011 16:59:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <4DB58B52.9030004@joelhalpern.com> Date: Mon, 25 Apr 2011 09:59:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB58B52.9030004@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: Re: LISP Security issues X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:59:38 -0000 The security relationship between the MS and ETR specified in a the = current text, while simple, is an atomic entity that can easily be = modified in the future (its simplicity makes it very automation = friendly, by the way) without wholesale protocol changes. I fact, I = really can't see any change to that mechanism that would change the core = assumptions about LISP or its mapping infrastructure. But at this point, i'd prefer adding a description of this mole hill, = rather than fighting over its size. -Darrel On Apr 25, 2011, at 7:55 AM, Joel M. Halpern wrote: > There are a number of security dimensions, AKM being one example, = where the tradeoffs we have made are quite sensible for an experiment, = but will need revisitng, and probably new work, before we can go for = proposed standard. >=20 > After discussion with the security community, the proposal is to add a = disclaimer early in the document. ( I would guess this would go in the = Introduction, with a clear heading like "issues relative to = standardization". >=20 > Below is text Sam has crafted as a starting point for us. > Can folks live with it? >=20 > Yours, > Joel >=20 > -------- Original Message -------- > Subject: Re: LISP Security issues > Date: Mon, 25 Apr 2011 10:13:22 -0400 > From: Sam Hartman > To: Joel M. Halpern > CC: Turner, Sean P. , Sam Hartman = , Stephen Farrell , = Terry Manderson >=20 >=20 > I propose the following for the LISP base spec. >=20 > This document represents the thinking of the LISP working > group. However, as work continued to develop the LISP specification > there were a number of issues identified where additional discussions > including other parts of the IETF will be required surrounding issues > such as security and encapsulation. As specific examples, the = discussion > of how LISP interacts with BCP 107's guidance on automated key > management is ongoing. This and other issues would need to be resolved = before standardization of LISP. Accounting for these concerns may = significantly > change tradeoffs underlying design decisions in LISP; it is important > that deferring these discussions in order to publish an experimental > protocol sooner not restrict a standardized solution that balances > concerns of all areas of the IETF. >=20 > Things I think are important here: >=20 > 1) issues exist both for securit and other things > 2) Discussions of these issues are ongoing|need to happen prior to > standardization (take your pick) > 3) Encompassing more things may change tradeoffs > 4) By agreeing not to block on solving these problems now we're = agreeing > that what we publish now does not restrict what we do in the future >=20 > I'm not attached to specific wording provided we make these points. >=20 >=20 > ... > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Internet-Drafts@ietf.org Tue Apr 26 15:00:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05AE076F; Tue, 26 Apr 2011 15:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk4URpvFz4bg; Tue, 26 Apr 2011 15:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF975E07AA; Tue, 26 Apr 2011 15:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110426220001.17741.36974.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2011 15:00:01 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : D. Farinacci, et al. Filename : draft-ietf-lisp-12.txt Pages : 88 Date : 2011-04-26 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-26145105.I-D@ietf.org> --NextPart-- From jsw@inconcepts.biz Wed Apr 27 22:31:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A482E068C for ; Wed, 27 Apr 2011 22:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtQFBXKzM6GP for ; Wed, 27 Apr 2011 22:31:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB4CE0688 for ; Wed, 27 Apr 2011 22:31:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so2083497vxg.31 for ; Wed, 27 Apr 2011 22:31:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.181.198 with SMTP id bz6mr826149vcb.192.1303968710020; Wed, 27 Apr 2011 22:31:50 -0700 (PDT) Received: by 10.220.181.1 with HTTP; Wed, 27 Apr 2011 22:31:49 -0700 (PDT) X-Originating-IP: [96.28.66.189] Date: Thu, 28 Apr 2011 01:31:49 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [lisp] Mapping Service negative cache replies X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 05:31:51 -0000 Dear List, I've had several off-list discussions with some vendor folks, and otherwise, working hard on LISP. I see that the issue of cache thrashing is currently left entirely up to the implementor to handle. I may be unaware of some body of work on this topic, however, I believe the current language in draft-ietf-lisp-ms-07, below, eliminates a needed means of reducing negative mapping cache size on an ITR. >From section 4.4 Map-Resolver Processing: To minimize the number of negative cache entries needed by an ITR, the Map-Resolver should return the least-specific prefix which both matches the original query and does not match any EID-prefix known to exist in the LISP-capable infrastructure. This is a good approach in most circumstances, where there are few packets to unknown destinations (few "punts" to the control-plane.) It breaks down, however, in the event the ITR needs to process a large amount of packets to unknown destinations, such as: * a deliberate DoS attack on the ITR from within * reply packets to an external DoS attack with false, random source address= es * a malicious worm searching for hosts to infect * etc. All of the above contribute to FIB churn. They may also cause a large number of negative mapping cache entries to be populated on the ITR. To demonstrate how the mechanism in draft-ietf-lisp-ms-07 is not ideal in this situation, all you must do is emulate the existing IPv6 routing table, which contains numerous, costly-to-express holes. For example, current ARIN IPv6 allocations to ISPs are /32 in size but are aligned on /23 boundaries. These holes between "adjacent" (minus holes) /32 ISP allocations allow a malicious person to cause an ITR to learn nine (9) negative mapping cache entries between each two /32 allocations, if one was utilizing LISP on Internet-scale, and LISP were widely-deployed. The draft language does not leave room for alternatives, but it probably should. A different mechanism works better in this situation, allowing the ITR to learn about all feasible prefix mappings within a given supernet. This may allow the ITR to reduce its number of negative cache entries dramatically by installing a far smaller number of positive mappings (to control-plane cache for possible use, or to FIB.) This is of more importance than is immediately obvious, because one must consider the cost of "punts" to the control-plane in order to drive the learning process. These punts must be policed somehow, and surely, they will be by vendor implementations with a "hardware FIB" and a "software negative cache." However, when faced with a large volume of punts (packets to unknown destinations, causing a negative cache hit or a new Mapping Service inquiry), an implementation might choose to actually install negative mappings into his FIB, preventing these known-bad punts from reaching the control-plane *and* preventing them from contenting for policer conformance with other punts which are needed to learn new mappings for legitimate traffic. This means the cost of pushing some negative cache entries into the FIB should be considered, and the cost of doing so should be able to be minimized by the implementation. I suggest the Mapping Service specification leave room for an ITR that wishes to request all mappings within a given subset of the feasible routing table. This gives the implementor additional options for dealing with malicious traffic which may drive its negative mapping cache to a large size, and perhaps consume precious FIB resources as well. Darrel Lewis tells me there was a similar capability in a router with "on-demand FIB compression." While the application differs in this case, the principle is the same. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From Internet-Drafts@ietf.org Thu Apr 28 00:00:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61069E06B6; Thu, 28 Apr 2011 00:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6tGbnkmcptE; Thu, 28 Apr 2011 00:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A071E06C3; Thu, 28 Apr 2011 00:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110428070001.9708.67655.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2011 00:00:01 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-08.txt Pages : 17 Date : 2011-04-27 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-ms-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-27234725.I-D@ietf.org> --NextPart-- From lear@cisco.com Thu Apr 28 01:06:09 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B676DE06C8 for ; Thu, 28 Apr 2011 01:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.97 X-Spam-Level: X-Spam-Status: No, score=-109.97 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWkEeOjqC2eV for ; Thu, 28 Apr 2011 01:06:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0EE06A6 for ; Thu, 28 Apr 2011 01:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=4288; q=dns/txt; s=iport; t=1303977968; x=1305187568; h=message-id:date:from:mime-version:to:subject; bh=nTxmYexNmT380/16crMiAWbv+VruXaptaTjtlotLzj0=; b=MSnRqw8afU5Gi9yTufQe45YbZwXoPgNz3CZtg3KUadHA3vLntxsWsbAG EqUQX8XR++vDm4XQ9gIlBuLWURWUS6ZcRJeJtS2GFetjH4hIstWJxwU4I X0R+2RL2raj4h734tsvprt7cdwpbRSobCSfZY6M3XRKPEeWYMhCRgVVJx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtADALAeuU2Q/khMgWdsb2JhbACEUaErFAEBFiYlpE+BHYtlkRyDEoFnfQSOXI4L X-IronPort-AV: E=Sophos;i="4.64,279,1301875200"; d="scan'208,217";a="27656803" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Apr 2011 08:06:07 +0000 Received: from dhcp-10-55-86-187.cisco.com (dhcp-10-55-86-187.cisco.com [10.55.86.187]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3S8677l031825 for ; Thu, 28 Apr 2011 08:06:07 GMT Message-ID: <4DB91FD5.9010303@cisco.com> Date: Thu, 28 Apr 2011 10:05:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "lisp@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070109020504000202010605" Subject: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:06:09 -0000 This is a multi-part message in MIME format. --------------070109020504000202010605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Joel, I'm sorry this came up while I was on holiday, but as I told Sam, I object to the text as proposed in the current version (-12). I have the following issues with that text: * LISP as an experimental specification should be treated no differently than any other experimental specification. So far as I know, that sort of text does not appear in similar works. * It states what amounts to the obvious. Experimental specifications are NEVER held up to the same scrutiny as standards. Standards must consider and respond to BCP 107, as well as a whole raft of other work. * It's the wrong place for this sort of text. The right place would be a charter. Here what is happening is that people are attempting to assert what should be in a future charter. Procedurally, that's inappropriate. * Blithely stating that the Security Area has concerns about BCP 107 does not take into account the nature of the problem at hand, and provides no additional guidance to the developers on how to correct any potential flaws. With all of that in mind I propose the following changes: 1. Remove entirely the new text from Section 1. 2. Remove Section 12.1, and replace it with a specific concern, and not some vague statement, perhaps of the following form (assuming I can divine what they are actually concerned about): LISP makes use of a keying approach that is meant to scale in an operational environment that cannot on its own rely on additional connectivity. As the approach is new there may be as of yet undiscovered threats associated with it. Further research in this area is encouraged. Eliot --------------070109020504000202010605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Joel,

I'm sorry this came up while I was on holiday, but as I told Sam, I object to the text as proposed in the current version (-12).  I have the following issues with that text:
  • LISP as an experimental specification should be treated no differently than any other experimental specification.  So far as I know, that sort of text does not appear in similar works.
  • It states what amounts to the obvious.  Experimental specifications are NEVER held up to the same scrutiny as standards.  Standards must consider and respond to BCP 107, as well as a whole raft of other work.
  • It's the wrong place for this sort of text.  The right place would be a charter.  Here what is happening is that people are attempting to assert what should be in a future charter.  Procedurally, that's inappropriate.
  • Blithely stating that the Security Area has concerns about BCP 107 does not take into account the nature of the problem at hand, and provides no additional guidance to the developers on how to correct any potential flaws.

With all of that in mind I propose the following changes:

1.  Remove entirely the new text from Section 1.
2.  Remove Section 12.1, and replace it with a specific concern, and not some vague statement, perhaps of the following form (assuming I can divine what they are actually concerned about):

LISP makes use of a keying approach that is meant to scale in an operational environment that cannot on its own rely on additional connectivity.  As the approach is new there may be as of yet undiscovered threats associated with it.  Further research in this area is encouraged.
Eliot
--------------070109020504000202010605-- From jmh@joelhalpern.com Thu Apr 28 06:00:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031AE070A for ; Thu, 28 Apr 2011 06:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.736 X-Spam-Level: X-Spam-Status: No, score=-102.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaANQgjQw09J for ; Thu, 28 Apr 2011 06:00:14 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFABE0701 for ; Thu, 28 Apr 2011 06:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F323E43009F; Thu, 28 Apr 2011 06:00:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 453BF4300D1; Thu, 28 Apr 2011 06:00:13 -0700 (PDT) Message-ID: <4DB964DC.5020801@joelhalpern.com> Date: Thu, 28 Apr 2011 09:00:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eliot Lear References: <4DB91FD5.9010303@cisco.com> In-Reply-To: <4DB91FD5.9010303@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:00:14 -0000 Let me suggest a couple of pieces here: Firstly, neither I nor Terry claim that this text adds anything useful. Even the folks asking that the text be added do not claim it helps an implementor. Given how little text this is, if it helps some problem, I can live with it. While the specific text was proposed by Sam, the problem is not his. It was the security ADs who, when asked, said that there is a major issue with the absence of AKM. Apparently, the security area has gotten really hard nosed about that. Neither Terry nor I felt that the specs should be held up while we develop and document suitable AKM. So we worked with the security ADs to head off a discuss. This text was sufficient. Reportedly, part of the problem is that other folks have been abusing experimental publication. Therefore, ALL IETF Experimental publication should expect to face higher security bars than they have in the past. Whether other folks will choose to, and be enabled to, use the same strategy we are using is yet to be seen. Yours, Joel On 4/28/2011 4:05 AM, Eliot Lear wrote: > Joel, > > I'm sorry this came up while I was on holiday, but as I told Sam, I > object to the text as proposed in the current version (-12). I have the > following issues with that text: > > * LISP as an experimental specification should be treated no > differently than any other experimental specification. So far as > I know, that sort of text does not appear in similar works. > * It states what amounts to the obvious. Experimental > specifications are NEVER held up to the same scrutiny as > standards. Standards must consider and respond to BCP 107, as > well as a whole raft of other work. > * It's the wrong place for this sort of text. The right place would > be a charter. Here what is happening is that people are > attempting to assert what should be in a future charter. > Procedurally, that's inappropriate. > * Blithely stating that the Security Area has concerns about BCP 107 > does not take into account the nature of the problem at hand, and > provides no additional guidance to the developers on how to > correct any potential flaws. > > > With all of that in mind I propose the following changes: > > 1. Remove entirely the new text from Section 1. > 2. Remove Section 12.1, and replace it with a specific concern, and not > some vague statement, perhaps of the following form (assuming I can > divine what they are actually concerned about): > > LISP makes use of a keying approach that is meant to scale in an > operational environment that cannot on its own rely on additional > connectivity. As the approach is new there may be as of yet > undiscovered threats associated with it. Further research in this > area is encouraged. > > Eliot > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Thu Apr 28 19:04:11 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6681E0715 for ; Thu, 28 Apr 2011 19:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+3-o4fjgSla for ; Thu, 28 Apr 2011 19:04:11 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1A286E0684 for ; Thu, 28 Apr 2011 19:04:11 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 28 Apr 2011 19:04:10 -0700 From: Terry Manderson To: "Joel M. Halpern" , Eliot Lear Date: Thu, 28 Apr 2011 19:04:06 -0700 Thread-Topic: [lisp] New Issue: security text in the document Thread-Index: AcwFpESKGThnytzkSpGW2QNhnCKNgAAbXOQX Message-ID: In-Reply-To: <4DB964DC.5020801@joelhalpern.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 02:04:11 -0000 To add to Joel's email, and to be quite clear that this text does not detract from the work which has been put into the LISP experiment. The plain observation is that this text comes at the request of the Sec-ADs and the authors have plainly recognized that in the title of "IETF Security Area Statement". I should point out that while BCP 107 isn't, from what I could see in a triage of experimental RFCs (http://www.apps.ietf.org/rfc/explist.html), specifically mentioned it IS worth noting that vague text highlighting what hasn't been addressed in an experimental RFCs before they could be considered for a standarization effort is dotted throughout the set of experimental RFCs. It is further worth noting that the LISP work looks more like a standard track document than any other experimental RFC I have read, and indeed some standards track RFCs I have read! This is ultimately a huge compliment to the authors and the LISP working group but that also may lull an unwary reader into thinking this work is standards track at this point in time. It= s easy to slip into this state given that LISP is an INT area working group, and not an IRTF research group. Procedurally, as Joel points out, if this text addresses a discuss item in publication processing - then I am supportive of it. As I see it the LISP document(s) are 99.95% done. Lets move forward. Cheers Terry On 28/04/11 11:00 PM, "Joel M. Halpern" wrote: > Let me suggest a couple of pieces here: >=20 > Firstly, neither I nor Terry claim that this text adds anything useful. > Even the folks asking that the text be added do not claim it helps an > implementor. Given how little text this is, if it helps some problem, I > can live with it. >=20 > While the specific text was proposed by Sam, the problem is not his. It > was the security ADs who, when asked, said that there is a major issue > with the absence of AKM. Apparently, the security area has gotten > really hard nosed about that. Neither Terry nor I felt that the specs > should be held up while we develop and document suitable AKM. So we > worked with the security ADs to head off a discuss. This text was > sufficient. >=20 > Reportedly, part of the problem is that other folks have been abusing > experimental publication. Therefore, ALL IETF Experimental publication > should expect to face higher security bars than they have in the past. > Whether other folks will choose to, and be enabled to, use the same > strategy we are using is yet to be seen. >=20 > Yours, > Joel >=20 > On 4/28/2011 4:05 AM, Eliot Lear wrote: >> Joel, >>=20 >> I'm sorry this came up while I was on holiday, but as I told Sam, I >> object to the text as proposed in the current version (-12). I have the >> following issues with that text: >>=20 >> * LISP as an experimental specification should be treated no >> differently than any other experimental specification. So far as >> I know, that sort of text does not appear in similar works. >> * It states what amounts to the obvious. Experimental >> specifications are NEVER held up to the same scrutiny as >> standards. Standards must consider and respond to BCP 107, as >> well as a whole raft of other work. >> * It's the wrong place for this sort of text. The right place would >> be a charter. Here what is happening is that people are >> attempting to assert what should be in a future charter. >> Procedurally, that's inappropriate. >> * Blithely stating that the Security Area has concerns about BCP 107 >> does not take into account the nature of the problem at hand, and >> provides no additional guidance to the developers on how to >> correct any potential flaws. >>=20 >>=20 >> With all of that in mind I propose the following changes: >>=20 >> 1. Remove entirely the new text from Section 1. >> 2. Remove Section 12.1, and replace it with a specific concern, and not >> some vague statement, perhaps of the following form (assuming I can >> divine what they are actually concerned about): >>=20 >> LISP makes use of a keying approach that is meant to scale in an >> operational environment that cannot on its own rely on additional >> connectivity. As the approach is new there may be as of yet >> undiscovered threats associated with it. Further research in this >> area is encouraged. >>=20 >> Eliot >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 lear@cisco.com Fri Apr 29 03:38:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5AE067E for ; Fri, 29 Apr 2011 03:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.012 X-Spam-Level: X-Spam-Status: No, score=-110.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7alTpGrqj00o for ; Fri, 29 Apr 2011 03:38:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3A267E062A for ; Fri, 29 Apr 2011 03:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=8382; q=dns/txt; s=iport; t=1304073526; x=1305283126; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ymVZYuzw5ZsyqvyBYCM3wuYOFnN3IZpm9pVBWdjd/dg=; b=OCmVAjkBRD2stDh6xRch/+Z2a3Tnv9p9lJzWpP1zGkhHzBy9klCmyyBe 0Z2VedqJe0X3yiJKYUB2nI2uOuSWVyAZxwTjzQIeB/IRFu4hmuqGHRNvz QjuV/+OOtmUvK62GaQsz5YkWD4/Itl5e4pmc45N+30EsPq2rQUsxGFfTl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAIGUuk2Q/khLgWdsb2JhbACEUaEzFAEBFiYlqDiLZZEdgSmBbYFngQEEjmiOHA X-IronPort-AV: E=Sophos;i="4.64,287,1301875200"; d="scan'208";a="27888014" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Apr 2011 10:38:45 +0000 Received: from dhcp-10-55-81-98.cisco.com (dhcp-10-55-81-98.cisco.com [10.55.81.98]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3TAciXk006473; Fri, 29 Apr 2011 10:38:44 GMT Message-ID: <4DBA9518.5040506@cisco.com> Date: Fri, 29 Apr 2011 12:38:16 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 10:38:51 -0000 Terry, Joel, I appreciate your efforts to move this work forward. I also appreciate the security area's desire to see that work adhere to appropriate standards. HOWEVER, the manner which this matter was raised before the security area without proper consultation of this working group was entirely inappropriate. The attempt to bypass the normal charter and review process for standards remains inappropriate. No evaluation on the part of the security area has been demonstrated to indicate that an automated key process would be appropriate here, so saying one would be required is factually unsupported. Having an internal process discussion in a specification is also confusing, and inappropriate. It makes it seem as though that there are two IETFs- the Security Area and everyone else. What's more, anyone wishing to take part in the experiment would likely and rightly say, "Who cares?" Statements about how this might change the underlying structure of LISP are a throwback to people not wanting to pre-determine that this work will be The Solution. Our own processes require rough consensus to begin standardization in a working group, rough consensus to conclude the work, and a lack of substantial objection from any one area in the IESG for that work to go forward as a standard. As that is always true for any work, mentioning it this document is also inappropriate. Therefore, I continue to object, for these reasons and those I previously stated. In the spirit of compromise, however, I would propose the following alternative, which would address most of my concerns: In Section 2: OLD: This experimental specification does not address automated key management which would be required for an Internet standard equivalent. See Section 12.1 for further security details. NEW: This experimental specification does not address automated key management, which may be required for an Internet standard. See Section 12.1 for further security details. In Section 12.1: OLD: 12.1. IETF Security Area Statement This document represents the thinking of the LISP working group. The Security Area of the IETF believes there is an open security issue how LISP interacts with BCP 107's guidance on automated key management. This and other issues would need to be resolved before standardization of LISP. Accounting for these concerns may change the underlying design of LISP. It is important that deferring these discussions in order to publish an experimental protocol sooner not restrict a standardized solution that balances concerns of all areas of the IETF. NEW: 12.1. Automated Key Management BCP 107 provides for best practices on automated key management, including when it should be used. This experimental specification has not addressed key management. In future work, such as standardization, it is anticipated that automated key management will be addressed. This properly leaves deciding how it will be addressed and whether it MUST be addressed to the standardization process, while at the same time acknowledging the open issue. It also gets most of the process discussion out of the document. I'd propose that if the security ADs object to this wording, they bring their objections here, so that a DISCUSS can be avoided. Eliot On 4/29/11 4:04 AM, Terry Manderson wrote: > To add to Joel's email, and to be quite clear that this text does not > detract from the work which has been put into the LISP experiment. > > The plain observation is that this text comes at the request of the Sec-ADs > and the authors have plainly recognized that in the title of "IETF Security > Area Statement". > > I should point out that while BCP 107 isn't, from what I could see in a > triage of experimental RFCs (http://www.apps.ietf.org/rfc/explist.html), > specifically mentioned it IS worth noting that vague text highlighting what > hasn't been addressed in an experimental RFCs before they could be > considered for a standarization effort is dotted throughout the set of > experimental RFCs. > > It is further worth noting that the LISP work looks more like a standard > track document than any other experimental RFC I have read, and indeed some > standards track RFCs I have read! This is ultimately a huge compliment to > the authors and the LISP working group but that also may lull an unwary > reader into thinking this work is standards track at this point in time. Its > easy to slip into this state given that LISP is an INT area working group, > and not an IRTF research group. > > Procedurally, as Joel points out, if this text addresses a discuss item in > publication processing - then I am supportive of it. As I see it the LISP > document(s) are 99.95% done. Lets move forward. > > Cheers > Terry > > On 28/04/11 11:00 PM, "Joel M. Halpern" wrote: > >> Let me suggest a couple of pieces here: >> >> Firstly, neither I nor Terry claim that this text adds anything useful. >> Even the folks asking that the text be added do not claim it helps an >> implementor. Given how little text this is, if it helps some problem, I >> can live with it. >> >> While the specific text was proposed by Sam, the problem is not his. It >> was the security ADs who, when asked, said that there is a major issue >> with the absence of AKM. Apparently, the security area has gotten >> really hard nosed about that. Neither Terry nor I felt that the specs >> should be held up while we develop and document suitable AKM. So we >> worked with the security ADs to head off a discuss. This text was >> sufficient. >> >> Reportedly, part of the problem is that other folks have been abusing >> experimental publication. Therefore, ALL IETF Experimental publication >> should expect to face higher security bars than they have in the past. >> Whether other folks will choose to, and be enabled to, use the same >> strategy we are using is yet to be seen. >> >> Yours, >> Joel >> >> On 4/28/2011 4:05 AM, Eliot Lear wrote: >>> Joel, >>> >>> I'm sorry this came up while I was on holiday, but as I told Sam, I >>> object to the text as proposed in the current version (-12). I have the >>> following issues with that text: >>> >>> * LISP as an experimental specification should be treated no >>> differently than any other experimental specification. So far as >>> I know, that sort of text does not appear in similar works. >>> * It states what amounts to the obvious. Experimental >>> specifications are NEVER held up to the same scrutiny as >>> standards. Standards must consider and respond to BCP 107, as >>> well as a whole raft of other work. >>> * It's the wrong place for this sort of text. The right place would >>> be a charter. Here what is happening is that people are >>> attempting to assert what should be in a future charter. >>> Procedurally, that's inappropriate. >>> * Blithely stating that the Security Area has concerns about BCP 107 >>> does not take into account the nature of the problem at hand, and >>> provides no additional guidance to the developers on how to >>> correct any potential flaws. >>> >>> >>> With all of that in mind I propose the following changes: >>> >>> 1. Remove entirely the new text from Section 1. >>> 2. Remove Section 12.1, and replace it with a specific concern, and not >>> some vague statement, perhaps of the following form (assuming I can >>> divine what they are actually concerned about): >>> >>> LISP makes use of a keying approach that is meant to scale in an >>> operational environment that cannot on its own rely on additional >>> connectivity. As the approach is new there may be as of yet >>> undiscovered threats associated with it. Further research in this >>> area is encouraged. >>> >>> Eliot >>> >>> >>> >>> _______________________________________________ >>> 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 luigi@net.t-labs.tu-berlin.de Fri Apr 29 05:56:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36718E074D for ; Fri, 29 Apr 2011 05:56:24 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXMhc4mMUXgU for ; Fri, 29 Apr 2011 05:56:23 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfa.amsl.com (Postfix) with ESMTP id 91043E074A for ; Fri, 29 Apr 2011 05:56:23 -0700 (PDT) Received: from dyn100.net.t-labs.tu-berlin.de (dyn100.net.t-labs.tu-berlin.de [130.149.220.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 06A527000584; Fri, 29 Apr 2011 14:56:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <4DBA9518.5040506@cisco.com> Date: Fri, 29 Apr 2011 14:56:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06E873CA-878A-4212-A3E1-EFC505951884@net.t-labs.tu-berlin.de> References: <4DBA9518.5040506@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 12:56:24 -0000 Hi All, while I can understand the point raised by the security area people and = I can live with such kind of text in the document, I think that the = proposed text is rather vague. (see specific comment inline) On Apr 29, 2011, at 12:38 PM, Eliot Lear wrote: >=20 >=20 > OLD: >=20 > 12.1. IETF Security Area Statement >=20 > This document represents the thinking of the LISP working group. = The > Security Area of the IETF believes there is an open security issue > how LISP interacts with BCP 107's guidance on automated key > management. This and other issues would need to be resolved before What are the "other issues"? It sounds like there are plenty of other = unresolved issues, which IMHO is not the case. > standardization of LISP. Accounting for these concerns may change Which "concerns"? "other issues" is not a list of concerns. My personal opinion is that the two points above give the wrong message. It is my personal opinion that is not fair with respect of the work done = by the working group to give such fuzzy message, where it looks like the = WG did not do an accurate job. Having to choose, I prefer the text proposed by Eliot. Luigi > the underlying design of LISP. It is important that deferring these > discussions in order to publish an experimental protocol sooner not > restrict a standardized solution that balances concerns of all areas > of the IETF. >=20 >=20 From jmh@joelhalpern.com Fri Apr 29 06:30:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1FE06B7 for ; Fri, 29 Apr 2011 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGaSNu+vlFNy for ; Fri, 29 Apr 2011 06:30:38 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5F3E0674 for ; Fri, 29 Apr 2011 06:30:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC9554300F1; Fri, 29 Apr 2011 06:30:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id A6FA04300EC; Fri, 29 Apr 2011 06:30:36 -0700 (PDT) Message-ID: <4DBABD7B.1010106@joelhalpern.com> Date: Fri, 29 Apr 2011 09:30:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eliot Lear References: <4DBA9518.5040506@cisco.com> In-Reply-To: <4DBA9518.5040506@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 13:30:42 -0000 I would really prefer not to make those changes. In terms of process, the issue was originally raised quite properly to the working group quite a long time ago, by Sam. The WG did not choose to do anything about it, which is reasonable, and in my view the right thing to do. In reviewing open tickets, the chairs looked at this, and went and talked to the security ADs to find out how big an issue the security area thought this was. The first answer was "show stopper." We then worked with them to develop something that was doable now, did not denigrate or interfere with the work, but would remove the roadblock. There is no question that the security area would insist on AKM for any of the keys involved (arguably, the ALT keys could get out of it by pointing to BGP, but maybe not even that.) So the wording changes you suggest would, to the extent they matter, mislead people. Given that we have good reason to believe that the secruity area will accept these words (although they will be taking another look during IETF last call, as is there right), I would very much prefer to stay with what we have. The work to negotiate wording was not done on the working group mailing list. So? We can either waste a lot of time trying to negotiate weaker words, for no real benefit to us, or we can try to get this done. I have no desire to become the working group that leads the fight for better IESG handling of experimental RFCs. Terry's and my goal is to do enough that a workable document can be published. Yes, I would like to see better handling at the IESG of experimental documents. It may even be possible to improve that. It may well be that the confusion in the handling of our documents will be a good example for them. But, by being cooperative on this, we are in a better position to deal with other issues. (I only wish I did not expect far larger pushback with significantly more difficulty in getting to a resolution that is acceptable to us all. I have seen IESG notes that basically declare documents to be bad pieces of work. Neither Terry nor I will accept them doing that to this WG and its products.) Yours, Joel On 4/29/2011 6:38 AM, Eliot Lear wrote: > Terry, Joel, > > I appreciate your efforts to move this work forward. I also appreciate > the security area's desire to see that work adhere to appropriate > standards. HOWEVER, the manner which this matter was raised before the > security area without proper consultation of this working group was > entirely inappropriate. The attempt to bypass the normal charter and > review process for standards remains inappropriate. No evaluation on > the part of the security area has been demonstrated to indicate that an > automated key process would be appropriate here, so saying one would be > required is factually unsupported. Having an internal process > discussion in a specification is also confusing, and inappropriate. It > makes it seem as though that there are two IETFs- the Security Area and > everyone else. What's more, anyone wishing to take part in the > experiment would likely and rightly say, "Who cares?" > > Statements about how this might change the underlying structure of LISP > are a throwback to people not wanting to pre-determine that this work > will be The Solution. Our own processes require rough consensus to > begin standardization in a working group, rough consensus to conclude > the work, and a lack of substantial objection from any one area in the > IESG for that work to go forward as a standard. As that is always true > for any work, mentioning it this document is also inappropriate. > > Therefore, I continue to object, for these reasons and those I > previously stated. In the spirit of compromise, however, I would > propose the following alternative, which would address most of my concerns: > > > In Section 2: > > OLD: > > This experimental specification does not address automated key > management which would be required for an Internet standard > equivalent. See Section 12.1 for further security details. > > > NEW: > > This experimental specification does not address automated key > management, which may be required for an Internet standard. > See Section 12.1 for further security details. > > > In Section 12.1: > > > OLD: > > 12.1. IETF Security Area Statement > > This document represents the thinking of the LISP working group. The > Security Area of the IETF believes there is an open security issue > how LISP interacts with BCP 107's guidance on automated key > management. This and other issues would need to be resolved before > standardization of LISP. Accounting for these concerns may change > the underlying design of LISP. It is important that deferring these > discussions in order to publish an experimental protocol sooner not > restrict a standardized solution that balances concerns of all areas > of the IETF. > > > NEW: > > 12.1. Automated Key Management > > BCP 107 provides for best practices on automated key management, > including when it should be used. This experimental specification > has not addressed key management. In future work, such as > standardization, it is anticipated that automated key management will > be addressed. > > > > This properly leaves deciding how it will be addressed and whether it > MUST be addressed to the standardization process, while at the same time > acknowledging the open issue. It also gets most of the process > discussion out of the document. I'd propose that if the security ADs > object to this wording, they bring their objections here, so that a > DISCUSS can be avoided. > > Eliot > > On 4/29/11 4:04 AM, Terry Manderson wrote: >> To add to Joel's email, and to be quite clear that this text does not >> detract from the work which has been put into the LISP experiment. >> >> The plain observation is that this text comes at the request of the Sec-ADs >> and the authors have plainly recognized that in the title of "IETF Security >> Area Statement". >> >> I should point out that while BCP 107 isn't, from what I could see in a >> triage of experimental RFCs (http://www.apps.ietf.org/rfc/explist.html), >> specifically mentioned it IS worth noting that vague text highlighting what >> hasn't been addressed in an experimental RFCs before they could be >> considered for a standarization effort is dotted throughout the set of >> experimental RFCs. >> >> It is further worth noting that the LISP work looks more like a standard >> track document than any other experimental RFC I have read, and indeed some >> standards track RFCs I have read! This is ultimately a huge compliment to >> the authors and the LISP working group but that also may lull an unwary >> reader into thinking this work is standards track at this point in time. Its >> easy to slip into this state given that LISP is an INT area working group, >> and not an IRTF research group. >> >> Procedurally, as Joel points out, if this text addresses a discuss item in >> publication processing - then I am supportive of it. As I see it the LISP >> document(s) are 99.95% done. Lets move forward. >> >> Cheers >> Terry >> >> On 28/04/11 11:00 PM, "Joel M. Halpern" wrote: >> >>> Let me suggest a couple of pieces here: >>> >>> Firstly, neither I nor Terry claim that this text adds anything useful. >>> Even the folks asking that the text be added do not claim it helps an >>> implementor. Given how little text this is, if it helps some problem, I >>> can live with it. >>> >>> While the specific text was proposed by Sam, the problem is not his. It >>> was the security ADs who, when asked, said that there is a major issue >>> with the absence of AKM. Apparently, the security area has gotten >>> really hard nosed about that. Neither Terry nor I felt that the specs >>> should be held up while we develop and document suitable AKM. So we >>> worked with the security ADs to head off a discuss. This text was >>> sufficient. >>> >>> Reportedly, part of the problem is that other folks have been abusing >>> experimental publication. Therefore, ALL IETF Experimental publication >>> should expect to face higher security bars than they have in the past. >>> Whether other folks will choose to, and be enabled to, use the same >>> strategy we are using is yet to be seen. >>> >>> Yours, >>> Joel >>> >>> On 4/28/2011 4:05 AM, Eliot Lear wrote: >>>> Joel, >>>> >>>> I'm sorry this came up while I was on holiday, but as I told Sam, I >>>> object to the text as proposed in the current version (-12). I have the >>>> following issues with that text: >>>> >>>> * LISP as an experimental specification should be treated no >>>> differently than any other experimental specification. So far as >>>> I know, that sort of text does not appear in similar works. >>>> * It states what amounts to the obvious. Experimental >>>> specifications are NEVER held up to the same scrutiny as >>>> standards. Standards must consider and respond to BCP 107, as >>>> well as a whole raft of other work. >>>> * It's the wrong place for this sort of text. The right place would >>>> be a charter. Here what is happening is that people are >>>> attempting to assert what should be in a future charter. >>>> Procedurally, that's inappropriate. >>>> * Blithely stating that the Security Area has concerns about BCP 107 >>>> does not take into account the nature of the problem at hand, and >>>> provides no additional guidance to the developers on how to >>>> correct any potential flaws. >>>> >>>> >>>> With all of that in mind I propose the following changes: >>>> >>>> 1. Remove entirely the new text from Section 1. >>>> 2. Remove Section 12.1, and replace it with a specific concern, and not >>>> some vague statement, perhaps of the following form (assuming I can >>>> divine what they are actually concerned about): >>>> >>>> LISP makes use of a keying approach that is meant to scale in an >>>> operational environment that cannot on its own rely on additional >>>> connectivity. As the approach is new there may be as of yet >>>> undiscovered threats associated with it. Further research in this >>>> area is encouraged. >>>> >>>> Eliot >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 jmh@joelhalpern.com Fri Apr 29 06:38:08 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB52DE0674 for ; Fri, 29 Apr 2011 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1P8pryoUyQu for ; Fri, 29 Apr 2011 06:38:04 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC033E06BF for ; Fri, 29 Apr 2011 06:38:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B23554300E4; Fri, 29 Apr 2011 06:38:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id E69BB4300E5; Fri, 29 Apr 2011 06:38:03 -0700 (PDT) Message-ID: <4DBABF3B.3080407@joelhalpern.com> Date: Fri, 29 Apr 2011 09:38:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Luigi Iannone References: <4DBA9518.5040506@cisco.com> <06E873CA-878A-4212-A3E1-EFC505951884@net.t-labs.tu-berlin.de> In-Reply-To: <06E873CA-878A-4212-A3E1-EFC505951884@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] New Issue: security text in the document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 13:38:08 -0000 There are several reasons I would prefer that we leave the text vague. The primary one is that I do not want to get into an extended analysis and debate about what hypothetical issues we would have to address if we sometime in the ill-defined future want to go for PS. An example of one we will probably need in the security area is some variant on the SIDR work. But that is the easy case. There are also likely to be arguments for "refinements" in other areas. Many of them probably not needed. We can either waste another year having all those fights, or we can have vague wording. Yours, Joel On 4/29/2011 8:56 AM, Luigi Iannone wrote: > Hi All, > > while I can understand the point raised by the security area people and I can live with such kind of text in the document, I think that the proposed text is rather vague. (see specific comment inline) > > On Apr 29, 2011, at 12:38 PM, Eliot Lear wrote: > >> >> >> OLD: >> >> 12.1. IETF Security Area Statement >> >> This document represents the thinking of the LISP working group. The >> Security Area of the IETF believes there is an open security issue >> how LISP interacts with BCP 107's guidance on automated key >> management. This and other issues would need to be resolved before > > What are the "other issues"? It sounds like there are plenty of other unresolved issues, which IMHO is not the case. > >> standardization of LISP. Accounting for these concerns may change > > Which "concerns"? "other issues" is not a list of concerns. > > My personal opinion is that the two points above give the wrong message. > > It is my personal opinion that is not fair with respect of the work done by the working group to give such fuzzy message, where it looks like the WG did not do an accurate job. > > Having to choose, I prefer the text proposed by Eliot. > > Luigi > > >> the underlying design of LISP. It is important that deferring these >> discussions in order to publish an experimental protocol sooner not >> restrict a standardized solution that balances concerns of all areas >> of the IETF. >> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:57:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DA4E06C0 for ; Fri, 29 Apr 2011 09:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POy2oOWY88P7 for ; Fri, 29 Apr 2011 09:57:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D68A9E06AD for ; Fri, 29 Apr 2011 09:57:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr0M-0005zT-2w; Fri, 29 Apr 2011 09:57:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:57:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/33#comment:4 Message-ID: <077.3ef6a65db81848843ca3ba99fb0c0f31@trac.tools.ietf.org> References: <068.55f561e469bb5634357c136824b60322@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <068.55f561e469bb5634357c136824b60322@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:57:29 -0000 #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 33. Make more clear in the Routing Locator Selection section what an ITR should do when it sees an R-bit of 0 in a locator- record of a Map-Reply. * Tracker item 33. Add paragraph to the EID Reachability section indicating that site parittioning is under investigation. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: resolved Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:57:41 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E37E06F0 for ; Fri, 29 Apr 2011 09:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs6TTqydthCS for ; Fri, 29 Apr 2011 09:57:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 639A7E06E8 for ; Fri, 29 Apr 2011 09:57:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr0Z-00078l-Rt; Fri, 29 Apr 2011 09:57:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:57:35 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/33#comment:5 Message-ID: <077.c496a5e42df90da1baa2fd63cfab9138@trac.tools.ietf.org> References: <068.55f561e469bb5634357c136824b60322@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <068.55f561e469bb5634357c136824b60322@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:57:41 -0000 #33: Editorial Issues Section 7 of draft-ietf-lisp-06.txt Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: editorial | Status: closed Priority: trivial | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:58:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C7EE06DA for ; Fri, 29 Apr 2011 09:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v001RThlnI5M for ; Fri, 29 Apr 2011 09:58:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2B77FE06AD for ; Fri, 29 Apr 2011 09:58:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr18-0007gI-Vu; Fri, 29 Apr 2011 09:58:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:58:10 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/58#comment:3 Message-ID: <077.8633725ebff34b0c8e387ce6a14c11dd@trac.tools.ietf.org> References: <068.b86df5c81bd78f6f83a111888ad19f8f@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <068.b86df5c81bd78f6f83a111888ad19f8f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:58:16 -0000 #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 58. Added last paragraph of Security Considerations section about how to protect inner header EID address spoofing attacks. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:58:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1EE06FE for ; Fri, 29 Apr 2011 09:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LXKqaa89-tY for ; Fri, 29 Apr 2011 09:58:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 66222E06FC for ; Fri, 29 Apr 2011 09:58:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr1H-0007gq-FK; Fri, 29 Apr 2011 09:58:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:58:19 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/58#comment:4 Message-ID: <077.4e65d97ac66c51aed66933def016132b@trac.tools.ietf.org> References: <068.b86df5c81bd78f6f83a111888ad19f8f@trac.tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <068.b86df5c81bd78f6f83a111888ad19f8f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:58:24 -0000 #58: LISP breaking RPF and used as anonymization service (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:59:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E87E06A1 for ; Fri, 29 Apr 2011 09:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-1ljxXDtT-E for ; Fri, 29 Apr 2011 09:59:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDFCE069F for ; Fri, 29 Apr 2011 09:59:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr23-0007hX-Fk; Fri, 29 Apr 2011 09:59:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:59:07 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/87#comment:1 Message-ID: <066.3ea97562bb6ccd1d53d22122d689eff3@trac.tools.ietf.org> References: <057.9d980920e9bd162c07874463eac20c57@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <057.9d980920e9bd162c07874463eac20c57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #87: On reusing globally routed address block as EID-prefix (comment 11 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:59:12 -0000 #87: On reusing globally routed address block as EID-prefix (comment 11 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 87. Once again reword the definition of the EID-prefix to reflect recent comments. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:59:23 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1931AE069F for ; Fri, 29 Apr 2011 09:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4thpg1ratkst for ; Fri, 29 Apr 2011 09:59:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id C1418E06D3 for ; Fri, 29 Apr 2011 09:59:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr2D-0007hb-OY; Fri, 29 Apr 2011 09:59:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:59:17 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/87#comment:2 Message-ID: <066.2e5b720f00f15f2b0f6bc50be501560f@trac.tools.ietf.org> References: <057.9d980920e9bd162c07874463eac20c57@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <057.9d980920e9bd162c07874463eac20c57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #87: On reusing globally routed address block as EID-prefix (comment 11 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:59:23 -0000 #87: On reusing globally routed address block as EID-prefix (comment 11 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:59:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F5AE069F for ; Fri, 29 Apr 2011 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcrIEfe1oTfl for ; Fri, 29 Apr 2011 09:59:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 22518E06EA for ; Fri, 29 Apr 2011 09:59:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr2a-0007hz-PT; Fri, 29 Apr 2011 09:59:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:59:40 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/95#comment:2 Message-ID: <066.73ac98f3d37593a06cbae8fa9988b899@trac.tools.ietf.org> References: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:59:48 -0000 #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 95. Change "eliminate" to "defer" in section 4.1. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 09:59:56 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A577E06F1 for ; Fri, 29 Apr 2011 09:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 473Sju0PkiAs for ; Fri, 29 Apr 2011 09:59:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A9E18E06FC for ; Fri, 29 Apr 2011 09:59:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr2j-0007i6-VO; Fri, 29 Apr 2011 09:59:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org X-Trac-Project: lisp Date: Fri, 29 Apr 2011 16:59:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/95#comment:3 Message-ID: <066.b472e3b8653bed304c715acd46086cfa@trac.tools.ietf.org> References: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-Trac-Ticket-ID: 95 In-Reply-To: <057.d5d01bfa13c7250cdec5b89a66e6ac0e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:59:56 -0000 #95: On eliminating vs. deferring mapping lookup (comment 15 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:00:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AC5E069F for ; Fri, 29 Apr 2011 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waR7+m0-NC4t for ; Fri, 29 Apr 2011 10:00:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 78A38E06F1 for ; Fri, 29 Apr 2011 10:00:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr37-0000sV-O2; Fri, 29 Apr 2011 10:00:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:00:13 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/108#comment:3 Message-ID: <066.d7dc993900a874de5907ba953d6c37aa@trac.tools.ietf.org> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:00:22 -0000 #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 108. Make clear the R-bit does not define RLOC path reachability. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: resolved Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:00:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA7E06D3 for ; Fri, 29 Apr 2011 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XGAhWNFWd3C for ; Fri, 29 Apr 2011 10:00:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 87611E06FE for ; Fri, 29 Apr 2011 10:00:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr3G-0002V5-2S; Fri, 29 Apr 2011 10:00:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:00:22 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/108#comment:4 Message-ID: <066.1490fa434af376b9c5453ab13a4fdde0@trac.tools.ietf.org> References: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-Trac-Ticket-ID: 108 In-Reply-To: <057.e05715fe3dc7985fc8019f02b0aabd49@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, terry.manderson@icann.org, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:00:30 -0000 #108: "R" bit in Map-Reply message format (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: editorial | Status: closed Priority: minor | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:00:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D697FE0710 for ; Fri, 29 Apr 2011 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdgdk5erlmV5 for ; Fri, 29 Apr 2011 10:00:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 72046E0716 for ; Fri, 29 Apr 2011 10:00:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr3Z-0007DY-Dc; Fri, 29 Apr 2011 10:00:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:00:41 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/107#comment:1 Message-ID: <066.78a2d0f52bcdab9bef45e17b9a264208@trac.tools.ietf.org> References: <057.6c572dbc28a86db1374edfbd5b635558@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <057.6c572dbc28a86db1374edfbd5b635558@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:00:46 -0000 #107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 107. Indicate that weights are relative to each other versus requiring an addition of up to 100%. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:00:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0902E0722 for ; Fri, 29 Apr 2011 10:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elCmcAgJ4miM for ; Fri, 29 Apr 2011 10:00:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8162BE0720 for ; Fri, 29 Apr 2011 10:00:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr3h-0000YP-Fg; Fri, 29 Apr 2011 10:00:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:00:49 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/lisp/trac/ticket/107#comment:2 Message-ID: <066.ef3435b535096a295f10edcdbad3c1a4@trac.tools.ietf.org> References: <057.6c572dbc28a86db1374edfbd5b635558@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <057.6c572dbc28a86db1374edfbd5b635558@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:00:54 -0000 #107: "Weight" in Map-Reply Message Format (comment 22 reported by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:02:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9FFE0717 for ; Fri, 29 Apr 2011 10:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BJkUz92Nndt for ; Fri, 29 Apr 2011 10:02:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id AFED6E0710 for ; Fri, 29 Apr 2011 10:02:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr5Z-0006B2-Ow; Fri, 29 Apr 2011 10:02:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:02:45 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/70#comment:6 Message-ID: <077.e2efcbd39c4f58bd633f32882666412a@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #70: Client not respecting RLOC weights (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:02:51 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Changes (by luigi@…): * status: reopened => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 70. Added text to security section on what the implications could be if an ITR does not obey priority and weights from a Map-Reply message. -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:03:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91D5E073A for ; Fri, 29 Apr 2011 10:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpuMu07FdQ2R for ; Fri, 29 Apr 2011 10:02:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC2AE06FF for ; Fri, 29 Apr 2011 10:02:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr5k-0006Ba-FE; Fri, 29 Apr 2011 10:02:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:02:56 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/lisp/trac/ticket/70#comment:7 Message-ID: <077.0501c1ab3ccff9da10e47910a8ced87e@trac.tools.ietf.org> References: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <068.7ad8426e5defed8efc75a91b3b935546@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, yakov@juniper.net, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #70: Client not respecting RLOC weights (from Y. Rekhter's review) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:03:03 -0000 #70: Client not respecting RLOC weights (from Y. Rekhter's review) Changes (by luigi@…): * status: resolved => closed -- ------------------------------------------+--------------------------------- Reporter: luigi@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | ------------------------------------------+--------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:03:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6605E0741 for ; Fri, 29 Apr 2011 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPyygFYuHajj for ; Fri, 29 Apr 2011 10:03:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 760FEE0710 for ; Fri, 29 Apr 2011 10:03:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr64-0006Br-Ec; Fri, 29 Apr 2011 10:03:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:03:16 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/54#comment:1 Message-ID: <066.9e6f5d99f2d05ca4f99c09de11065f86@trac.tools.ietf.org> References: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:03:20 -0000 #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) Changes (by luigi@…): * status: new => resolved * resolution: => fixed Comment: The issue has been fixed in version -12 of the draft as described in section B.1: * Tracker item 54. Added text to the new section titled "Packets Egressing a LISP Site" to describe the implications when two or more ITRs exist at a site where only one ITR is used for egress traffic and when there is a shift of traffic to the others, how the map-cache will need to be populated in those new egress ITRs. -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: resolved Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues From trac+lisp@trac.tools.ietf.org Fri Apr 29 10:03:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D00E06B9 for ; Fri, 29 Apr 2011 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlkUfjSg608d for ; Fri, 29 Apr 2011 10:03:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77DE0747 for ; Fri, 29 Apr 2011 10:03:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFr6D-0006C0-5G; Fri, 29 Apr 2011 10:03:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lisp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: luigi@net.t-labs.tu-berlin.de X-Trac-Project: lisp Date: Fri, 29 Apr 2011 17:03:24 -0000 X-URL: http://tools.ietf.org/lisp/ X-Trac-Ticket-URL: http://64.170.98.42/wg/lisp/trac/ticket/54#comment:2 Message-ID: <066.e44a43b09eee85cac041e1d8ce30500c@trac.tools.ietf.org> References: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <057.093d2c7c4ec1aa4a073e2bbc71fa8fba@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: luigi@net.t-labs.tu-berlin.de, lisp@ietf.org X-SA-Exim-Mail-From: trac+lisp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: lisp@ietf.org Subject: Re: [lisp] #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 17:03:34 -0000 #54: ITR failures and implications on connectivity restoration time (review by Y. Rekhter) Changes (by luigi@…): * status: resolved => closed -- -------------------------------+-------------------------------------------- Reporter: wmhaddad@… | Owner: Type: technical | Status: closed Priority: major | Component: draft-ietf-lisp Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: lisp LISP WG document issues