From menth@informatik.uni-wuerzburg.de Mon Jul 5 03:07:13 2010 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 CB67B3A6834 for ; Mon, 5 Jul 2010 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 R-CqHK1kR0k2 for ; Mon, 5 Jul 2010 03:07:12 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 819243A67C0 for ; Mon, 5 Jul 2010 03:07:12 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9514D5AC93 for ; Mon, 5 Jul 2010 12:07:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 929DF5AC64 for ; Mon, 5 Jul 2010 12:07:09 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 71BC25CCD0 for ; Mon, 5 Jul 2010 12:07:09 +0200 (CEST) Message-ID: <4C31AECD.9040200@informatik.uni-wuerzburg.de> Date: Mon, 05 Jul 2010 12:07:09 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: lisp@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] [Fwd: New Version Notification for draft-klein-lisp-mn-nat-traversal-00] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: 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, 05 Jul 2010 10:07:13 -0000 Hi all, we submitted a draft on "NAT Traversal for LISP Mobile Node" which is available at http://tools.ietf.org/html/draft-klein-lisp-mn-nat-traversal A more illustrative paper version of this draft is available at http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth10-Sub-2.pdf Kind regards, Michael -------- Original-Nachricht -------- Betreff: New Version Notification for draft-klein-lisp-mn-nat-traversal-00 Datum: Mon, 5 Jul 2010 02:13:36 -0700 (PDT) Von: IETF I-D Submission Tool An: dominik.klein@informatik.uni-wuerzburg.de CC: hartmann@informatik.uni-wuerzburg.de,menth@informatik.uni-wuerzburg.de A new version of I-D, draft-klein-lisp-mn-nat-traversal-00.txt has been successfully submitted by Dominik Klein and posted to the IETF repository. Filename: draft-klein-lisp-mn-nat-traversal Revision: 00 Title: NAT Traversal for LISP Mobile Node Creation_date: 2010-07-05 WG ID: Independent Submission Number_of_pages: 12 Abstract: The Locator/Identifier Separation Protocol (LISP) is a new naming and addressing architecture to solve the Internet's routing scaling problem. It separates global routing in the Internet from local routing and naming in end-user networks. The basic LISP architecture does not support mobility. The mobility extension LISP Mobile Node (LISP-MN) describes a mechanism that extends LISP to support mobile nodes and enables them to roam into LISP and non-LISP networks while being reachable under the same address. Currently, LISP-MN does not support networks that use network address translation (NAT). This document presents an extension for LISP-MN that makes LISP mobile nodes behind a NAT globally reachable. The IETF Secretariat. -- PD Dr. habil. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From kotikalapudi.sriram@nist.gov Tue Jul 6 14:27:54 2010 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 CD5773A69F4 for ; Tue, 6 Jul 2010 14:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM5lm9NZ79FA for ; Tue, 6 Jul 2010 14:27:53 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 175E43A67AF for ; Tue, 6 Jul 2010 14:27:52 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o66LReJJ013708; Tue, 6 Jul 2010 17:27:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 6 Jul 2010 17:27:40 -0400 From: "Sriram, Kotikalapudi" To: "lisp@ietf.org" Date: Tue, 6 Jul 2010 17:27:02 -0400 Thread-Topic: Updated EEMDP proposal for managing holes in maps Thread-Index: AcsdTqhfIkdORkDTScOtc0jtO+utUwAAhi8g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: [lisp] Updated EEMDP proposal for managing holes in maps 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, 06 Jul 2010 21:27:55 -0000 Based on feedback from the March 2010 LISP WG meeting, we have made changes and added more details to the EEMDP (Enhanced Efficiency of Mapping Distribution Protocols) proposal. The revised set of slides is at: http://www.antd.nist.gov/~ksriram/EEMDP_Slides_July2010.pdf The revised detailed document can be found at: http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf Changes include: (1) Got rid of the idea of notifying the NML (Next More-Specific Length). It was Case 4 in my IETF 77 (March 2010) slides, and didn't make sense. Now Case 4 (see slide 14 in the revised set) is about communicating a partial prioritized subset of more specifics (holes) that are requested more often than others (based on measurements). The idea is to avoid having to send a long list of map exceptions (should that be the case in some situations), and instead send a prioritized subset (possibly based on map request frequency). Note that the other three cases (Cases 1, 2, 3) are the same as before which found acceptance at the March 2010 LISP WG meeting. (2) We now provide quite a bit of additional data/plots based measurements/analysis to show the extent to which holes are evident in the Internet (Routeviews) trace data, and how much proliferation of map messages they cause. We compare the max # map responses attributable to presence of holes with and without EEMDP (see slide 17). For those, who attended my talk at IETF 77 (LISP WG), the new or revised material can be found on slides 6, 8, 9, and 14 through 17. Further comments, suggestions welcome. Sriram K. Sriram http://www.antd.nist.gov/~ksriram/ From damien.saucez@uclouvain.be Mon Jul 12 02:58:09 2010 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 C99323A686E for ; Mon, 12 Jul 2010 02:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4tqtEy7cWbW for ; Mon, 12 Jul 2010 02:58:08 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 719AA3A67A5 for ; Mon, 12 Jul 2010 02:58:08 -0700 (PDT) Received: from [192.168.1.101] (LMontsouris-152-62-6-93.w80-13.abo.wanadoo.fr [80.13.5.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F116C1C60E3; Mon, 12 Jul 2010 11:57:31 +0200 (CEST) From: Damien Saucez Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-18--26270269 Date: Mon, 12 Jul 2010 11:57:20 +0200 References: To: lisp@ietf.org Message-Id: <769B989B-9A7D-43DB-926A-BC7548E67A37@uclouvain.be> X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: clamav-milter 0.96-exp at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (sender authenticated); receiver=; client-ip=80.13.5.93; helo=[192.168.1.101] Received-SPF: Pass (sender authenticated); receiver=; client-ip=80.13.5.93; envelope-from= X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F116C1C60E3.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Fwd: I-D Action:draft-saucez-lisp-security-01.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: Mon, 12 Jul 2010 09:58:09 -0000 --Apple-Mail-18--26270269 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, We have updated our draft about the security issues in LISP. Thank you = to send your comments. We would like to organize a meeting at the lobby @Maastricht to discuss = the techniques we could use to tackle these (or at least some of these) = issues. Regards, Damien Saucez >> From: Internet-Drafts@ietf.org >> Date: July 12, 2010 10:00:02 AM GMT+02:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-saucez-lisp-security-01.txt=20 >> Reply-To: internet-drafts@ietf.org >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : LISP Security Threats >> Author(s) : D. Saucez, et al. >> Filename : draft-saucez-lisp-security-01.txt >> Pages : 24 >> Date : 2010-07-12 >>=20 >> This draft analyses some of the threats against the security of the >> Locator/Identifier Separation Protocol and proposes a set of >> recommendations to mitigate some of the identified security risks. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-saucez-lisp-security-01.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 --Apple-Mail-18--26270269 Content-Type: multipart/mixed; boundary=Apple-Mail-19--26270268 --Apple-Mail-19--26270268 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: July 12, 2010 10:00:02 AM = GMT+02:00
Subject: I-D = Action:draft-saucez-lisp-security-01.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : LISP = Security Threats
Author(s) =       : D. Saucez, et al.
Filename =        : = draft-saucez-lisp-security-01.txt
Pages =           : = 24
= Date =            : = 2010-07-12

This draft analyses some of the threats against the = security of the
Locator/Identifier Separation Protocol and proposes a = set of
recommendations to mitigate some of the identified security = risks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saucez-lisp-security-01.txt=

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
= --Apple-Mail-19--26270268 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain<BR>Content-ID: &lt;2010-07-12005210.I-D@ietf.org&gt;<BR><BR>
--Apple-Mail-19--26270268 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--Apple-Mail-19--26270268-- --Apple-Mail-18--26270269-- From dino@cisco.com Mon Jul 12 07:53:38 2010 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 318E93A6974 for ; Mon, 12 Jul 2010 07:53:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLqS-+zywtpq for ; Mon, 12 Jul 2010 07:53:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 559283A690C for ; Mon, 12 Jul 2010 07:53:37 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN7JOkyrR7Ht/2dsb2JhbACgPnGkdZpJhScEg3uEUQ X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208";a="225103212" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 12 Jul 2010 14:53:33 +0000 Received: from [172.20.25.33] (sjc-vpn2-882.cisco.com [10.21.115.114]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6CErWks020024; Mon, 12 Jul 2010 14:53:33 GMT Message-Id: <14CF5CBF-2B4B-486B-889B-53884F1ED04A@cisco.com> From: Dino Farinacci To: Damien Saucez In-Reply-To: <769B989B-9A7D-43DB-926A-BC7548E67A37@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Jul 2010 07:53:32 -0700 References: <769B989B-9A7D-43DB-926A-BC7548E67A37@uclouvain.be> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: I-D Action:draft-saucez-lisp-security-01.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: Mon, 12 Jul 2010 14:53:38 -0000 > Dear all, > > We have updated our draft about the security issues in LISP. Thank > you to > send your comments. > > We would like to organize a meeting at the lobby @Maastricht to > discuss the > techniques we could use to tackle these (or at least some of these) > issues. Thanks Damien. I can make myself available anytime. Dino > > Regards, > > Damien Saucez > >>> From: Internet-Drafts@ietf.org >>> Date: July 12, 2010 10:00:02 AM GMT+02:00 >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-saucez-lisp-security-01.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : LISP Security Threats >>> Author(s) : D. Saucez, et al. >>> Filename : draft-saucez-lisp-security-01.txt >>> Pages : 24 >>> Date : 2010-07-12 >>> >>> This draft analyses some of the threats against the security of the >>> Locator/Identifier Separation Protocol and proposes a set of >>> recommendations to mitigate some of the identified security risks. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-saucez-lisp- >>> security-01.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. > Content-Type: text/plain<BR>Content-ID: &lt;2010-07-12005210.I-D@ietf.org > &gt;<BR><BR>
> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rw@firstpr.com.au Tue Jul 13 09:05:19 2010 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 0B5163A67B2 for ; Tue, 13 Jul 2010 09:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfGszAeGqj1r for ; Tue, 13 Jul 2010 09:05:17 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 2D6AD3A699C for ; Tue, 13 Jul 2010 09:05:17 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 09DED176220; Wed, 14 Jul 2010 02:05:24 +1000 (EST) Message-ID: <4C3C8EC0.6070704@firstpr.com.au> Date: Wed, 14 Jul 2010 02:05:20 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dominik Klein , Matthias Hartmann , Michael Menth , LISP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] draft-klein-lisp-mn-nat-traversal-00 and TTR Mobility 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, 13 Jul 2010 16:05:19 -0000 Hi Dominik, Matthias, Michael and other LISP folk, The new I-D: http://tools.ietf.org/html/draft-klein-lisp-mn-nat-traversal-00 seems to result in two separate tunnels, with the data directions shown with arrows. Both are established by the MN, and the destinations: NTR Nat Traversal Router PETR Proxy ETR while architecturally different and developed at different times by different people, are both (typically, at least) intended to be co-located with the MS: ITR ->-\ \ ITR -->---NTR--->-----\ / . \ ITR ->-/ . \ . MN . / Non-EID } . / destination } --<--PETR--<-----/ hosts } These PETR arrangements are described in: http://tools.ietf.org/html/draft-meyer-lisp-mn-01#section-7.2 The rest of section 7 concerns packets leaving the MN, addressed to EID-addresses, in various circumstances. I haven't tried to understand these variations. However, none of them will work for a MN behind NAT, because the outgoing packets have EID source addresses, and we can't be 100% sure the network behind the NAT, or the NAT box itself, will let them out. It is reasonable to assume the contrary - that such packets would be dropped. So I think all the outgoing packets need to go to what you currently think of as the PETR. Then, some will be forwarded to non-EID destinations and the rest will be handled by an ITR function in the same device, or perhaps nearby. The concept of a MN tunneling to another router, in part so it can work behind one or more levels of NAT, was first described as part of my original TTR (Translating Tunnel Router) Mobility description in June 2007, towards the end: http://www.ietf.org/mail-archive/web/ram/current/msg01518.html The MN establishes the tunnel to the TTR, It is a 2-way tunnel, which can be encrypted and have its own Path MTU Discovery arrangements, since it is just between the MN and the TTR, both of which are part of the Ivip or whatever architecture. In addition, the MN can be on an address which itself is provided with this mobility mechanism. In principle, any number of recursions of NAT and this form of mobility can be used, in any order. In all cases, the MN can tunnel to anywhere in the Internet, including to any of the TTRs. TTRs are all around the Net, as commercial services from one of multiple TTR Mobility companies. The MN pays for services from one of these companies, and the MN has special tunneling software to connect to nearby TTRs of that company. That company need have no relationship with any ISP the MN is using, or with whoever the MN obtains their EID (LISP) space from. However, the MN user does need to give control of the mapping of their one or more EID prefixes to the TTR company. I think it is a bad idea having a MN trying to control the mapping of its own EID prefixes. The TTR acts as an ETR for this and multiple other MNs. The MN establishes the tunnel to the TTR, and it is used for two-way data exchange to and from the TTR, as well as for management traffic for the special tunneling software in the MN. Apart from this software, the MN is an ordinary host. It can use any access network. The TTR system is separate from access networks and there is no need for any MIP systems - though the MN could be using MIP. TTR Mobility will work for IPv4 and IPv6 - with correspondent hosts being unmodified hosts, or any other hosts using Ivip (or whatever other Core-Edge Separation architecture, since TTR Mobility could be adapted to LISP too). The MN gets to keep its EID space wherever it goes, and as long as it uses a generally nearby TTR, there will be little path stretch. There is no fixed "home agent". The EID space is just like any other LISP EID prefix. The TTR handles outgoing packets - either forwarding them directly to their destination hosts or performing an ITR operation on them so they are tunneled to the correct ETR. (The TTR could just emit them and let them be forwarded to the nearest Ivip DITR or LISP PTR, but I generally assume that each TTR has an inbuilt, or nearby, ITR.) The main benefits of TTR Mobility are: 1 - As with lisp-mn-nat-traversal, the mapping doesn't change when the MN changes its CoA. This is a huge benefit. The MN simply makes another tunnel to the currently used TTR. The mapping only changes when a new TTR is used - and this is typically desirable if the MN moves more than about 1000km or more from the currently used TTR. So most MNs could be hopping around various access networks in a city, or medium- sized country, changing their CoAs second-by-second - and using multiple CoAs simultaneously on multiple access networks - and will still use the same TTR, with consequently no need for mapping changes from one month to the next. 2 - The MN typically uses a nearby TTR, so there is little stretch. 3 - If the MN suddenly finds itself connected far from the TTR, it still makes a tunnel to it, and continues operation. It is up to the TTR company, with its tunneling software in the MN, to figure this out and get the MN to tunnel to a closer TTR. When this has been done, the mapping can be changed to the new TTR. Since both tunnels can be active at the same time, there is no loss of data as the mapping changes from one TTR to the other. 4 - A single 2-way tunnel handles all traffic in and out of the MN. TTR Mobility has been fully documented for nearly two years: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem 2008-08-25 Robin Whittle, First Principles, Rosanna, Vic, Australia Steven Russert (previously of) Boeing Phantom Works, Seattle. Since then, it has received little attention. However, with the 07 and 08 revisions a week ago, Fred Templin's IRON architecture has been significantly redesigned to use TTR Mobility principles for all networks, not just mobile networks or MNs: http://tools.ietf.org/html/draft-templin-iron-08 I am still reading this, and am discussing it with Fred on the RRG list. - Robin From menth@informatik.uni-wuerzburg.de Tue Jul 13 09:29:28 2010 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 D2ABE3A6A81 for ; Tue, 13 Jul 2010 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_40=-0.185, 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 Vv03102t83VD for ; Tue, 13 Jul 2010 09:29:26 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 7E54C3A6A87 for ; Tue, 13 Jul 2010 09:29:25 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2AD205ACBF; Tue, 13 Jul 2010 18:29:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 282F75AC9B; Tue, 13 Jul 2010 18:29:34 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 04E975CCD7; Tue, 13 Jul 2010 18:29:34 +0200 (CEST) Message-ID: <4C3C9444.1000601@informatik.uni-wuerzburg.de> Date: Tue, 13 Jul 2010 18:28:52 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Robin Whittle References: <4C3C8EC0.6070704@firstpr.com.au> In-Reply-To: <4C3C8EC0.6070704@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: LISP WG Subject: Re: [lisp] draft-klein-lisp-mn-nat-traversal-00 and TTR Mobility X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: 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, 13 Jul 2010 16:29:28 -0000 Hi Robin, Robin Whittle schrieb: > Hi Dominik, Matthias, Michael and other LISP folk, > > The new I-D: > > http://tools.ietf.org/html/draft-klein-lisp-mn-nat-traversal-00 > > seems to result in two separate tunnels, with the data directions > shown with arrows. Both are established by the MN, and the destinations: > > NTR Nat Traversal Router > PETR Proxy ETR > > while architecturally different and developed at different times by > different people, are both (typically, at least) intended to be > co-located with the MS: > > ITR ->-\ > \ > ITR -->---NTR--->-----\ > / . \ > ITR ->-/ . \ > . MN > . / > Non-EID } . / > destination } --<--PETR--<-----/ > hosts } > > These PETR arrangements are described in: > > http://tools.ietf.org/html/draft-meyer-lisp-mn-01#section-7.2 > > The rest of section 7 concerns packets leaving the MN, addressed to > EID-addresses, in various circumstances. I haven't tried to > understand these variations. However, none of them will work for a > MN behind NAT, because the outgoing packets have EID source > addresses, and we can't be 100% sure the network behind the NAT, or > the NAT box itself, will let them out. It is reasonable to assume > the contrary - that such packets would be dropped. > We assume that the MN encapsulates the packets with the local care-of-address obtained from the host network and, therefore, outgoing packet have a source address that falls into the correct address range so that they are able to cross the border router after NAT has been performed. See Fig. 4 in http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth10-Sub-2.pdf for illustration. Regards, Michael -- PD Dr. habil. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From terry.manderson@icann.org Tue Jul 13 23:24:41 2010 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 378BC3A699D for ; Tue, 13 Jul 2010 23:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_OFFER2=2.545, 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 80+hyhH07YQb for ; Tue, 13 Jul 2010 23:24:40 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 3A2D33A68C6 for ; Tue, 13 Jul 2010 23:24:40 -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; Tue, 13 Jul 2010 23:24:49 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Tue, 13 Jul 2010 23:24:48 -0700 Thread-Topic: IETF78 draft agenda Thread-Index: AcsjHUIWctLKF29FbkiFPaV+o6kpSQ== 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] IETF78 draft agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 06:24:41 -0000 Folks,=20 Some administration for the upcoming IETF 78. (co-chair hat gaffer taped on= ) A draft agenda has been uploaded (http://www.ietf.org/proceedings/78/agenda/lisp.txt), please look over the agenda with respect to: * WG Document Authors/editors: Updates are expected from you, please be prepared to cover document updates, issues, and document future. (it might be good to reflect on the WG milestones) * Individual draft authors: Please be prepared to present to the time allotted - we will do our best to make sure everyone has an opportunity to present however we are sensitive to the current state of the WG compared to the chartered milestones. If you are presenting please have your slides to me (I prefer pdf so that everyone can open them) by midnight Saturday July 24th (Maastricht time please!) for materials upload so that any remote followers aren't left in the dark. For any concerns regarding the draft agenda, items, and times, please email me ASAP. For all other WG members, now would be a really good time to review the documents, especially the new WG document draft-ietf-lisp-lig-00. Cheers Terry From rw@firstpr.com.au Wed Jul 14 03:35:08 2010 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 D54213A6A12 for ; Wed, 14 Jul 2010 03:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8m0VDDauSzu for ; Wed, 14 Jul 2010 03:35:06 -0700 (PDT) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id DE1D63A6A35 for ; Wed, 14 Jul 2010 03:34:53 -0700 (PDT) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id EF0461760B4; Wed, 14 Jul 2010 20:34:09 +1000 (EST) Message-ID: <4C3D929F.5090204@firstpr.com.au> Date: Wed, 14 Jul 2010 20:34:07 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: LISP WG References: <4C3C8EC0.6070704@firstpr.com.au> <4C3C9444.1000601@informatik.uni-wuerzburg.de> In-Reply-To: <4C3C9444.1000601@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] draft-klein-lisp-mn-nat-traversal-00 and TTR Mobility X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 10:35:08 -0000 Hi Michael, You wrote: >> The rest of section 7 concerns packets leaving the MN, addressed to >> EID-addresses, in various circumstances. I haven't tried to >> understand these variations. However, none of them will work for a >> MN behind NAT, because the outgoing packets have EID source >> addresses, and we can't be 100% sure the network behind the NAT, or >> the NAT box itself, will let them out. It is reasonable to assume >> the contrary - that such packets would be dropped. > > We assume that the MN encapsulates the packets with the local > care-of-address obtained from the host network and, therefore, outgoing > packet have a source address that falls into the correct address range > so that they are able to cross the border router after NAT has been > performed. See Fig. 4 in > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth10-Sub-2.pdf > for illustration. Sorry, what I wrote was confusing. I wasn't suggesting that your approach to tunneling wouldn't work. What I meant was that for LISP or anything like it to work with the MN behind NAT, the MN needs to use one or more tunnels for all traffic packets - and that you might as well use a single two-way tunnel for all of it. I just remembered that mobility was ruled out of scope for the WG and therefore this list. As far as I know, this is still the case, though I notice it is to be discussed in Maastricht. Unless I hear otherwise, I will continue this discussion off-list. - Robin From darlewis@cisco.com Tue Jul 20 13:56:37 2010 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 EBD7C3A6954 for ; Tue, 20 Jul 2010 13:56:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo5pDMRll0iA for ; Tue, 20 Jul 2010 13:56:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E07143A6902 for ; Tue, 20 Jul 2010 13:56:36 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 20:56:52 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKupwD002875; Tue, 20 Jul 2010 20:56:52 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: Date: Tue, 20 Jul 2010 13:58:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1600233A-638C-4175-9FBC-00996A73A741@cisco.com> References: To: Terry Manderson X-Mailer: Apple Mail (2.1081) Cc: "lisp@ietf.org" Subject: Re: [lisp] More work needed I think. 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, 20 Jul 2010 20:56:38 -0000 Terry, All. My apologies for the lateness of this response. =20 I'm going to start sending out responses to the issues raised by the = thorough reviews of Demitri, Yakov, and others. The authors have = carefully reviewed each and every issue and are in the midst of = preparing detailed responses. The first batch of responses will be for those issues which the authors = either request more feedback from the list members, request suggested = text from the reviewers, or disagree with the reviewers' comments. For = each email, I'll reference the issue number, and copy the original = comment and our response. Other list members should feel free to reply = to our response - in no way are we attempting to close discussion on an = issue based on this first response! The second batch of responses address issues that will result in text = changes. These responses will be coming along in the next day or two. = Some of this second batch are technical (so the text change is usually = quite straight forward) and some were editorial (and resulted in quite a = bit of changes for readability). In addition to email responses, the = change log at the end of the draft (draft-ietf-lisp) will document these = substantive changes. Thanks again for taking the time out to provide the detailed reviews, = I'm positive they will result in a much stronger draft. -Darrel (on behalf of the draft-ietf-lisp co-authors) On May 24, 2010, at 10:27 PM, Terry Manderson wrote: > WG Chair hat =3D on >=20 > Hi Folks, >=20 > I was just taking a look at the number of outstanding issues for the = LISP WG > documents. I count 97 in total. ( http://tools.ietf.org/wg/lisp/ ) >=20 > Maastricht is barely 9 weeks away. So nearly 11 items would have to be > addressed per week for the next 9 weeks for us to go to Maastricht in = a > healthy position. >=20 > It would be great if we could have some action, be that discussion or > otherwise, on these! >=20 > Cheers, > Terry >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From darlewis@cisco.com Tue Jul 20 14:00:27 2010 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 7317F3A6902 for ; Tue, 20 Jul 2010 14:00: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBbzSkqXxWaW for ; Tue, 20 Jul 2010 14:00:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 968823A65A5 for ; Tue, 20 Jul 2010 14:00:26 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:00:42 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL0gSD022105; Tue, 20 Jul 2010 21:00:42 GMT From: Darrel Lewis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:02:17 -0700 Message-Id: <1E2415A2-23F2-4F3F-B2ED-2E096C8AE10B@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Map Reply Sent when EID is unreachable (41) 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, 20 Jul 2010 21:00:27 -0000 Issue Title (number): Map Reply Sent when EID is unreachable (41) Draft Section: 4.1 pt 4 Issue Description: Map Reply Sent with EID is unreachable Comments: Section 4.1 point 4 supposedly if there the destination EID is not found in the ETR's EID-to-RLOC database the packet gets dropped ? On the other hand how to prevent that a Map Reply is sent in response for EID prefix not reachable but statically configured in the ETR's EID-to-RLOC database. The case of ETR responding with =93coarser EID-RLOC=94 mapping due e.g. to sub-segmentation is partially addressed in Section 6.1.5.1=20 Response: Dear Dimitri- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. Our feeling is that reachability is not tied to = the mapping =20 system. In your above case, the ITR should always have a mapping and one = or more of the documented RLOC reachability algorithms can be used. Please = feel free=20 to continue discussion of your issue on the LISP working group mailing = list,=20 lisp@ietf.org. Should dissuasion result in WG consensus that changes are=20= required, the authors will incorporate appropriate text into a future = version=20 of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:00:47 2010 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 4ECF63A65A5 for ; Tue, 20 Jul 2010 14:00:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu6xkRIvXQs7 for ; Tue, 20 Jul 2010 14:00:46 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B76EB3A6892 for ; Tue, 20 Jul 2010 14:00:45 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:01:01 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL0gSE022105; Tue, 20 Jul 2010 21:01:01 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:02:36 -0700 Message-Id: <9F6450A3-6DDE-499B-901D-DE6CC570F9F6@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP vs PI addressing (44) 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, 20 Jul 2010 21:00:47 -0000 Issue Title (number): LISP vs PI addressing (44) Draft Section: 1 Issue Description: How does LISP compare to existing PI users Comments: What LISP offers to audiences which are already using PI? Response: Dear Yakov Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. In this case, this draft is an experimental protocol specification it seems out of place to discuss the benefits of existing PI multihoming at length. Please feel free to continue discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:02:20 2010 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 CB2AB3A6899 for ; Tue, 20 Jul 2010 14:02:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p2WGXIBjY2c for ; Tue, 20 Jul 2010 14:02:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E5EE33A6964 for ; Tue, 20 Jul 2010 14:02:19 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:02:35 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL2Zu1011778; Tue, 20 Jul 2010 21:02:35 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:04:10 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP Cache Handling (46) 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, 20 Jul 2010 21:02:20 -0000 Issue Title (number): LISP Cache Handling (46) Draft Section: ? Security ? Issue Description: LISP Cache Thrashing Comments: Cache thrashing by hosts within a site results in sending packets to a = large span of addresses and create a huge amount of LISP control = traffic. Response: Dear Dimitri- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We feel that existing text adequately describes = cache=20 management behavior. Please feel free to continue discussion of your = issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will = incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:02:39 2010 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 466633A69FB for ; Tue, 20 Jul 2010 14:02:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxBjNzXRAvqp for ; Tue, 20 Jul 2010 14:02:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 63AAC3A6A50 for ; Tue, 20 Jul 2010 14:02:37 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:02:53 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL2Zu2011778; Tue, 20 Jul 2010 21:02:53 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:04:27 -0700 Message-Id: <7638F2D2-228D-4675-A33E-156DA4D0EF73@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP vs Multihoming w NAT (45) 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, 20 Jul 2010 21:02:39 -0000 Issue Title (number): LISP vs Multihoming w NAT (45) Draft Section: 1 Issue Description: How does LISP compare to NAT... Comments: What LISP offers to audiences which are using NAT? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. In this case, this draft is an experimental protocol specification it seems out of place to discuss how sites use NAT at length. Please feel free to continue discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:03:54 2010 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 6F26B3A6891 for ; Tue, 20 Jul 2010 14:03:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2UO95xsYZma for ; Tue, 20 Jul 2010 14:03:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8A6E03A6899 for ; Tue, 20 Jul 2010 14:03:53 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:04:08 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL47eB006227; Tue, 20 Jul 2010 21:04:07 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:05:41 -0700 Message-Id: <4AEEFE98-8B8E-4924-A1F3-E22DE0931168@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): EID Reachability (53) 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, 20 Jul 2010 21:03:54 -0000 Issue Title (number): EID Reachability (53) Draft Section: ? Issue Description: What to do when ETR1 cannot reach its EID prefix but = ETR2 can? Comments: Suppose a certain EID's mapping entry -returned at some point in the = past in the MAP-Reply by ETR2- lists the RLOCs of two ETRs (ETR1 and = ETR2). Suppose that later on, due to connectivity issues with the site, = ETR1 is able to reach the EID but ETR2 is not. Is there some means by which traffic is expected to reliably reach the = EID in this case? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. Remember that on-going locator reachability is = not conveyed by the initial Map-Reply. Please feel free to continue discussion of = your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:05:04 2010 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 BD7793A6B4E for ; Tue, 20 Jul 2010 14:05:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXDQu6jkzA+1 for ; Tue, 20 Jul 2010 14:05:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6E7893A6B2D for ; Tue, 20 Jul 2010 14:04:58 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:05:14 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIU013345; Tue, 20 Jul 2010 21:05:14 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:06:48 -0700 Message-Id: <2098B4CF-073D-4DAE-8FBD-E7D07A6E47FB@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): ITR Failure Restoration (54) 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, 20 Jul 2010 21:05:04 -0000 Issue Title (number): ITR Failure Restoration (54) Draft Section: ? Issue Description: The Impact of ITR failure on other ITRs Comments: A scenario where an ITR fails would result in shifting a large fraction or all the flows that used to go through one ITR to another ITR. Note that in this scenario the arrival rate of the flows at the new ITR is determined by the total number of flows being shifted (e.g., in the case of an ITR failure it is the number of flows that used to go through the old ITR), and not by the steady state arrival rate of flows. Therefore, in this scenario the rate with which the new ITR has to resolve EID-RLOC mapping is determined not by the arrival rate of flows in the steady state, but by the total number of flows being moved to the new ITR, and the latter may be significantly higher than the former. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but are cannot determine whether changes should be made to the document. We think you are correct about your observation above and would like to see further discussions on this topic on the list. Please bring this issue to the LISP working group mailing list, lisp@ietf.org, for further discussion. Should the WG reach consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:05:44 2010 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 851A63A6B59 for ; Tue, 20 Jul 2010 14:05: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiruMfBJ4HIR for ; Tue, 20 Jul 2010 14:05:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 91D773A65A5 for ; Tue, 20 Jul 2010 14:05:38 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:05:54 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIV013345; Tue, 20 Jul 2010 21:05:54 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:07:28 -0700 Message-Id: <38035F61-3D9B-4F26-8577-2630725EA8EE@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): ETR Failure Restoration (55) 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, 20 Jul 2010 21:05:44 -0000 Issue Title (number): ETR Failure Restoration (55) Draft Section: ? Issue Description: ETR failure on ITR restoration Comments: In today's routing global BGP convergence is NOT required for = connectivity restoration. In other words, IP connectivity restoration takes less time=20= than what it takes to propagate fault information throughout the Internet (or for that matter even throughout a site). With LISP connectivity, restoration requires to propagate fault all the way to the ITRs. In addition, if one relies on Loc-Status-Bits to=20 determine that a particular RLOC is down, connectivity restoration would also require to propagate fault information from one ITR to = another.=20 In some case this may not be feasible (e.g., ETRs are PEs). And even in the cases where it is feasible, that is likely to increase connectivity restoration time. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but are cannot determine whether changes = should be made to the document. We would like to make the comment that = fault-detection in the data plane is much faster than queuing routing = updates along the way from failure to all sources. We would like to = encourage you to please bring this issue to the LISP working group = mailing list, lisp@ietf.org, for further discussion. Should the WG reach = consensus that changes are required, the authors will incorporate = appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:06:07 2010 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 6A1273A6A5C for ; Tue, 20 Jul 2010 14:06:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw3YJnX6vyuW for ; Tue, 20 Jul 2010 14:06:06 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 788A53A6B57 for ; Tue, 20 Jul 2010 14:06:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:06:22 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIW013345; Tue, 20 Jul 2010 21:06:22 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:07:56 -0700 Message-Id: <8C8EF964-02AC-4812-8F3D-C1AC6C295371@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): How to determine EIDs not forwardable on the routable(57) 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, 20 Jul 2010 21:06:07 -0000 Issue Title (number): How to determine EIDs not forwardable on the = routable(57) Draft Section: 7 Issue Description: How does an ITR determine if the destination is LISP Comments: How does one determine whether the outer destination address "contains an EID which is not intended to be forwarded on the routable topology" ? Please answer this question both for IPv6 and for IPv4.=20 Response:=20 Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We feel that this subject is thoroughly covered = in the draft-ietf-lisp-alt and draft-ietf-lisp-ms specifications. Please = feel free to continue discussion of your issue on the LISP working group=20 mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text=20= into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:06:18 2010 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 B21833A6B64 for ; Tue, 20 Jul 2010 14:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO1W7aX6ICuC for ; Tue, 20 Jul 2010 14:06:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DFD683A6B4C for ; Tue, 20 Jul 2010 14:06:16 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:06:32 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIX013345; Tue, 20 Jul 2010 21:06:32 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:08:07 -0700 Message-Id: <7FCA5DFC-CC0C-4DF7-AA0B-F79B8CD2F74B@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP and uRPF and Anonomous Tunneling(58) 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, 20 Jul 2010 21:06:18 -0000 Issue Title (number): LISP and uRPF and Anonomous Tunneling(58) Draft Section: 12 Issue Description: General LISP Security issues. Comments: There are many comments above that relate to security. Grep for "security" or "attack". Other possible issues that come to mind that should be explored here are whether LISP breaks RPF, and whether the ubiquitous tunneling infrastructure could be reused as a botnet anonymization service. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but are unclear on the nature of the issue. Can you please elaborate and clarify your concerns? If you can provide the specific text that you want to see changed, along with the replacement text that you'd like to see incorporated, that would be greatly appreciated. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:06:55 2010 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 E305F3A6A7A for ; Tue, 20 Jul 2010 14:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DaDXDrJnBYY for ; Tue, 20 Jul 2010 14:06:55 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0F8D03A65A5 for ; Tue, 20 Jul 2010 14:06:54 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:07:09 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIY013345; Tue, 20 Jul 2010 21:07:09 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:08:44 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP-TE and ETR(63) 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, 20 Jul 2010 21:06:56 -0000 Issue Title (number): LISP-TE and ETR(63) Draft Section: 8.3 Issue Description: General LISP-TE issues Comments: This is part of Comment 38 Section 8.2 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. The above means that at the minimum the price of resilience between the CE routers is the inability to support traffic engineering? Specifically, the ISP loses any influence over the choice of which ETR should be used to reach the multi-homed enterprise. Moreover, if CEs are xTRs and use anycast addresses, then RLOCs are anycast addresses as well, and thus can not be topologically significant. Thus if an enterprise is multi-homed to two (or more) ISPs, then use of anycast addresses for CEs would require to route such addresses as /32 throughout the whole Internet. Also, if anycast addresses are used as RLOCs, then how would one deal with a situation where initially both ETR1 and ETR2 advertise 10.1.1/24 and 10.1.2/24, ITR1 routes traffic for 10.1.1.1 to ETR1, but then ETR1, while still being up, loses connectivity to 10.1.1/24? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We do however feel that this information could = be very useful in a 'deployment guide' or 'uses' type draft document. Please = feel free to continue discussion of your issue on the LISP working group = mailing list, lisp@ietf.org. Should discussion result in WG consensus that = changes are required, the authors will incorporate appropriate text into a = future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:07:20 2010 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 DCB553A69FB for ; Tue, 20 Jul 2010 14:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTLsNp60ueJF for ; Tue, 20 Jul 2010 14:07:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 710673A6B52 for ; Tue, 20 Jul 2010 14:07:19 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:07:35 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIZ013345; Tue, 20 Jul 2010 21:07:35 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:09:09 -0700 Message-Id: <2D0A5C58-4D61-4C95-B312-997897888735@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Host BAsed Implementation (64) 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, 20 Jul 2010 21:07:21 -0000 Issue Title (number): Host BAsed Implementation (64) Draft Section: 8 Issue Description: Host Implementations Comments: Section 8 This section doesn't discuss host based LISP implementations, which seems a possibility as it is discussed under mobility. What are the implications be of host based LISP on the control plane load and does two headers restriction create a problem for host based LISP? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments and have determined that they address one or more issues that are outside of the current scope of the LISP working group. Should the LISP WG charter be revised in the future, we encourage you to re-submit your comments at that time. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:07:51 2010 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 8E7413A6964 for ; Tue, 20 Jul 2010 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMOJUtnomdTm for ; Tue, 20 Jul 2010 14:07:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 754F43A6A5C for ; Tue, 20 Jul 2010 14:07:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:08:04 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIa013345; Tue, 20 Jul 2010 21:08:04 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:09:38 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LSB handling details (66) 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, 20 Jul 2010 21:07:51 -0000 Issue Title (number): LSB handling details (66) Draft Section: 6.5 Issue Description: LSB handling and encoding =20 Comments: Section 6.5 the section does not actually explain which messages are used to update the list of Loc-Reach or Loc-Status bits. If it is data traffic-driven then the mechanism is again dependent on the symmetry of the reverse path and the packet rate but also packet differential delays between packets. In the latter case, it is not clear how ITR could retrieve the correct RLOCs to be used if a sequence of 8 packets sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC (indicated as available at arrival of the 8th packet) is received as 1,0,0,0,0,0,0,0. The section makes a long digression on ordering locator set this is not the issue without a sequence number it will never be possible for the receiving ITR to determine the actual state of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep track of who requested mappings upon communication they should tell the state of their mapping but also their transition.=20 This identifies a real problem; i.e., the locator status bits are contextually dependent on the locator set that was advertised, but there is no explicit binding between them and the particular locator set to which they relate. Thus, any version skew between ITR and ETR will result in misinterpretation of the locator status bits.=20 Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We think that the use of version numbers will = help this. Its also important to note that LSBs are a hint and a = request/reply=20 exchange will confirm from the R-bits of the locators in the locator-set = which=20 are reachable or not. Please feel free to continue discussion of your = issue=20 on the LISP working group mailing list, lisp@ietf.org. Should discussion=20= result in WG consensus that changes are required, the authors will=20 incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:08:04 2010 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 D711E3A6B6B for ; Tue, 20 Jul 2010 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB9kqvOginmf for ; Tue, 20 Jul 2010 14:08:04 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 080553A6B63 for ; Tue, 20 Jul 2010 14:08:04 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:08:19 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KL5DIb013345; Tue, 20 Jul 2010 21:08:19 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:09:54 -0700 Message-Id: <6728F234-9890-4D78-BC50-723C357E6DD1@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Source of Negative Map Reply (68) 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, 20 Jul 2010 21:08:05 -0000 Issue Title (number): Source of Negative Map Reply (68) Draft Section: 6.1.5 Issue Description: Whats the source of the packet on a negative = map-reply Comments: Section 6.1.5 EID-to-RLOC UDP Map-Reply message When sending a Map-Reply message, the destination address is copied from the source address of the Map-Request or Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local locator addresses listed in the locator-set of any mapping record in the message. What is the source address for a negative reply, which has a zero length locator -set ?=20 Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. The answer to this can be found in the MS spec (draft-ietf-lisp-ms). The source of the Map-Reply is one of the = map-resolvers=20 IP addresses. Please feel free to continue discussion of your issue on = the=20 LISP working group mailing list, lisp@ietf.org. Should discussion result = in=20 WG consensus that changes are required, the authors will incorporate=20 appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:09:50 2010 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 9094B3A6B2A for ; Tue, 20 Jul 2010 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFU-ljP0Qk2A for ; Tue, 20 Jul 2010 14:09:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A1D5C3A69FB for ; Tue, 20 Jul 2010 14:09:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:10:04 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLA48h027344; Tue, 20 Jul 2010 21:10:04 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:11:38 -0700 Message-Id: <26AEF390-AEF7-4CC4-8338-75EBD9CF556F@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Map-Reply Security (69) 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, 20 Jul 2010 21:09:50 -0000 Issue Title (number): Map-Reply Security (69) Draft Section: 6.1.5.1 Issue Description: Solution inaduquate Comments: This is Comment 25 of Rekhter's review Section 6.1.5.1 This section correctly identifies an attack where an ETR overclaims, saying that it owns a larger span of prefixes than it really does. The proposed solutions seem inadequate; in particular, the limiting the mask-length that you'll accept from a given ETR seems weak. I.e., how could an ITR determine a "configured prefix length" for a given EID prefix? This is a serious deficiency. It is somewhat analogous to the weakness of the BGP routing system, except that it is much less amenable to auditing than BGP (since the mapping data is only presented on demand, an auditor can't simply get a feed) and there are many more machines playing than in the BGP system. (Note by Darrel- there is an existing issue (i think 27) in the tracker = covering this topic.) Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but are cannot determine whether changes = should be made to the document. A partial answer is that the mapping system can protect against this threat. If a site is overclaiming due to a=20 configuration error, the map-server will detect it. Since this is an=20 existing open issue, there is work on signing Map-Replies that can help = this=20 situation. We want to emphasize that is work in progress (initiated by = the earlier comments of Sam Hartman and others). Please bring this=20 issue to the LISP working group mailing list, lisp@ietf.org, for further=20= discussion. Should the WG reach consensus that changes are required, the=20= authors will incorporate appropriate text into a future version of the = draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:10:44 2010 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 2EC0C3A69FB for ; Tue, 20 Jul 2010 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0-94RoTmwde for ; Tue, 20 Jul 2010 14:10:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5A0363A6B40 for ; Tue, 20 Jul 2010 14:10:42 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:10:58 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLA48i027344; Tue, 20 Jul 2010 21:10:57 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:12:32 -0700 Message-Id: <66A43B95-C125-4080-BAC8-69F3B8DB78B1@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): ITR ignoring weights (70) 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, 20 Jul 2010 21:10:44 -0000 Issue Title (number): ITR ignoring weights (70) Draft Section: 6.2 Issue Description: ITR ignoring weights Comments: This is part of Comment 26 of Rekhter's review Section 6.2 Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. If the client can gain some advantage (or thinks it can) by ignoring the server's weighting, it will. There should be some consideration of whether this is a problem, and if so, how to address it. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. Implementations must adhere to the specification. Please feel free to continue discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:11:26 2010 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 378C43A69FB for ; Tue, 20 Jul 2010 14:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSqe4UHn3Ye5 for ; Tue, 20 Jul 2010 14:11:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8733E3A6B2B for ; Tue, 20 Jul 2010 14:11:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:11:40 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLA48j027344; Tue, 20 Jul 2010 21:11:40 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:13:14 -0700 Message-Id: <2CB34DF7-285E-4C29-8301-D649127FE257@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Cache Lookup Performance (39) 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, 20 Jul 2010 21:11:26 -0000 Issue Title (number): Cache Lookup Performance (39) Draft Section: 4.1 and 6 Issue Description: Cache management Comments: Section 4.1 point 2 (same remark applies to Section 6) misses an important aspect how the mapping is performed the first time a new destination EID is seen at ITR and how subsequent maps are performed. It seems that a) EID-to-RLOC Cache must be first entirely scanned for each incoming packet at ITR (not only the first one) and then if there is no entry i) Data probe i.e. copy the destination EID value in the destination RLOC field (for LISP 1.5) or ii) originate a Map Request; otherwise use the corresponding RLOC value in the retrieved entry as destination RLOC. Needless to say that the delay is proportional to the number of entries in the cache. Nothing is being said if the cache is full (which entry should be replaced i.e. the least frequently used, the least recently used, or the least recently replaced entry).=20 Response: Dear Dimitri Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the = document are warranted at this time. In this case we'd like to leave = the details of caching design up to the implementers. Please feel free = to continue discussion of your issue on the LISP working group mailing = list, lisp@ietf.org. Should discussion result in WG consensus that = changes are required, the authors will incorporate appropriate text into = a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:14:08 2010 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 D797A3A6961 for ; Tue, 20 Jul 2010 14:14:08 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BpPwPCRk57d for ; Tue, 20 Jul 2010 14:14:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 67FC63A69FB for ; Tue, 20 Jul 2010 14:14:07 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:14:23 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLENbs000086; Tue, 20 Jul 2010 21:14:23 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:15:57 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): EID to RLOC selection (71) 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, 20 Jul 2010 21:14:09 -0000 Issue Title (number): EID to RLOC selection (71) Draft Section: 6.2 Issue Description: EID-to-RLOC selection Comments: Section 6.2 RLOC reachability can determined and selected but there is no description on how the EID-to-RLOC selection is performed. Response: Dear Dimitri- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. Selection of the EID-to-RLOC is exactly what mapping database specifications are for. This issue is defined in separate drafts on purpose. See MS, ALT, EMACs, CONS, and NERD specs. Please feel free to continue discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:14:14 2010 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 F0D513A6BB6 for ; Tue, 20 Jul 2010 14:14:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBH1JJqEN6lz for ; Tue, 20 Jul 2010 14:14:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1DFC83A6B6F for ; Tue, 20 Jul 2010 14:14:14 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:14:30 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLENbt000086; Tue, 20 Jul 2010 21:14:29 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:16:04 -0700 Message-Id: <6345423B-D423-48B4-8A00-939A519A37B1@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): EID to RLOC selection (73) 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, 20 Jul 2010 21:14:15 -0000 Issue Title (number): EID to RLOC selection (73) Draft Section: 6.3 Issue Description: Locator Liveness Description Improvements Comments: * Tunnel Liveness - The document says little about what happens when = a=20 tunnel connecting iTR to eTR fails? Does temporary black-holing result? What is the restoration mechanism?=20 Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. The authors feel this topic is dicussed at = length=20 in the Locator Liveness section. Please feel free to continue = discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will = incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:14:33 2010 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 4E63C3A6961 for ; Tue, 20 Jul 2010 14:14: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLQRSIQDMK9t for ; Tue, 20 Jul 2010 14:14:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1E8753A6944 for ; Tue, 20 Jul 2010 14:14:32 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:14:48 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLENbu000086; Tue, 20 Jul 2010 21:14:47 GMT From: Darrel Lewis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:16:22 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Map-Cache Validation (36) 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, 20 Jul 2010 21:14:33 -0000 Issue Title (number): Map-Cache Validation (36) Draft Section: 3 Issue Description: How does Validation of the map-cache interact with = cache management Comments: Section 3. Validation of =93EID-to-RLOC mappings=94 in cache is defined = as time-based only ? not on frequency of usage neither replacement ? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-xx.txt. The draft = authors have reviewed your comments but are unclear on the nature of the issue. = Can you please elaborate and clarify your concerns? If you can provide the specific text that you want to see changed, along with the replacement text that you'd like to see incorporated, that would be greatly = appreciated. Thanks!= From darlewis@cisco.com Tue Jul 20 14:15:12 2010 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 19B393A6964 for ; Tue, 20 Jul 2010 14:15:10 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGyHsbAIGBvj for ; Tue, 20 Jul 2010 14:14:53 -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 351E13A6979 for ; Tue, 20 Jul 2010 14:14:53 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2010 21:15:09 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLENbv000086; Tue, 20 Jul 2010 21:15:08 GMT From: Darrel Lewis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:16:43 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Header Prepending (38) 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, 20 Jul 2010 21:15:20 -0000 Issue Title (number): Header Prepending (38) Draft Section: 4 Issue Description: Limiting header prepending Comments: Section 4 =93This specification mandates that no more than two LISP headers get prepended to a packet.=94 Is there any mechanism preventing ITR (or TE ITR) to perform additional prepending ? and at which cost ?=20= Recommended Action: As part of section 4, clarify what an ITR should do = if it finds two headers? not sure Dear Dimitri- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. Implementations must adhere to the spec, which = says=20 a maximum of two headers. Please feel free to continue discussion of = your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will = incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:15:59 2010 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 7367E3A6B5A for ; Tue, 20 Jul 2010 14:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QhPoSWf1xyC for ; Tue, 20 Jul 2010 14:15:58 -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 80A5A3A6944 for ; Tue, 20 Jul 2010 14:15:58 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 21:16:14 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtn027107; Tue, 20 Jul 2010 21:16:14 GMT From: Darrel Lewis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:17:48 -0700 Message-Id: <31A2A292-79E4-47B4-98C0-FE79045D1B0B@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Editorial Comments to Section 8 (34) 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, 20 Jul 2010 21:15:59 -0000 Issue Title (number): Editorial Comments to Section 8(34) Draft Section: 8 Issue Description: General LISP edits to section 8 by Demitri and Yakov Comments: =46rom D. Papadimitriou's review: Section 8.1 first paragraph, it is not the location of the source that = determines the =93size=94 of the working set of the EID prefix-to-RLOC = cache but the number of EID prefixes this =93source site=94 has to = reach. The same issue occurs at ETR, small sites may have to be = configured with a large list of EID-to-RLOC mapping entries. Next to = this the granularity of the EID prefix allocation is also important. =46rom Y. Rekhter's review: This is part of Comment 39 By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. This is hard to understand. This is part of Comment 36 ISP is doing the TE, then the site has no control. Recursive = tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. What exactly does "suboptimal" mean here? Response: Dear Dimitri, Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We do however feel that this information could = be=20 very useful in a 'deployment guide' or 'uses' type draft. Please feel = free=20 to continue discussion of your issue on the LISP working group mailing=20= list, lisp@ietf.org. Should discussion result in WG consensus that = changes=20 are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:16:23 2010 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 8DD483A6C36 for ; Tue, 20 Jul 2010 14:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrkVaX+ASWdP for ; Tue, 20 Jul 2010 14:16:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B04CF3A6B5F for ; Tue, 20 Jul 2010 14:16:22 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 21:16:38 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEto027107; Tue, 20 Jul 2010 21:16:38 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:18:13 -0700 Message-Id: <25A2998C-91F7-41C8-8265-752E7358ACAF@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Site location of xTRs (81) 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, 20 Jul 2010 21:16:23 -0000 Issue Title (number): Site Location of xTRs (81) Draft Section: 8.1 Issue Description:=20 Comments: =46rom Y. Rekhter's review Comment 37: Section 8.1 If ITR/ETR are first/last hop routers, then these routers need to be = routable within each site RLOC. This means that if a site changes = providers, the RLOC of these routers would need to change. Therefore, = any ACLs within each site would need to be modified to allow routing on = these RLOCs. In order to clarify the raised issue, the comment has been refined as: Section 8.1 needs to document implications of changing providers (changing RLOCs) on configuration/provisioning of devices within a site. E.g., this section needs to document that if devices within a site use ACLs, then changing providers may require changing configuration on these devices. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. We do however feel that this information could = be=20 very useful in a 'deployment guide' or 'uses' type draft. Please feel = free=20 to continue discussion of your issue on the LISP working group mailing=20= list, lisp@ietf.org. Should discussion result in WG consensus that = changes=20 are required, the authors will incorporate appropriate text into a = future=20 version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:16:47 2010 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 111C53A6B5F for ; Tue, 20 Jul 2010 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl1M+Xb+HObB for ; Tue, 20 Jul 2010 14:16:45 -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 17D933A6809 for ; Tue, 20 Jul 2010 14:16:45 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 21:17:00 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtp027107; Tue, 20 Jul 2010 21:17:00 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:18:35 -0700 Message-Id: <63607455-1854-47EE-8312-C5C5D4F6D496@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Editorial comment about LISP (82) 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, 20 Jul 2010 21:16:47 -0000 Issue Title (number): Editorial comment about LISP (82) Draft Section: Abstract=09 Issue Description: wording of 'simple' Comments: The first sentence says LISP is "simple". Yet such components of LISP as = the additional aspects of MTU and fragmentation, cache management and = reachability management add considerable complexity, not to mention the = operational expense of learning to operate and debug an entirely new = infrastructure. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-xx.txt. The draft = authors have reviewed your comments but are unclear on the nature of the issue. = If you can provide the specific text that you want to see changed, along with = the replacement text that you'd like to see incorporated, that would be greatly = appreciated. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:17:19 2010 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 61D7B3A6964 for ; Tue, 20 Jul 2010 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.277 X-Spam-Level: X-Spam-Status: No, score=-10.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_43=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 hSBY3cDrE+iG for ; Tue, 20 Jul 2010 14:17:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7FFB73A6809 for ; Tue, 20 Jul 2010 14:17:18 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:17:34 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtq027107; Tue, 20 Jul 2010 21:17:34 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:19:08 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Lock in to EID Provider (84) 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, 20 Jul 2010 21:17:19 -0000 Issue Title (number): Lock in to EID Provider (84) Draft Section: 3 Issue Description: Ease of Renumbering Comments: In the Introduction: 3. Easing of renumbering burden when clients change providers. Because host EIDs are numbered from a separate, non-provider- assigned and non-topologically-bound space, they do not need to be renumbered when a client site changes its attachment points to the network. At least with respect to LISP+ALT, this statement is incorrect. Sites = are simply locked in to their EID provider instead of being locked in to = their ISP as they are now. The lock-in would appear to be more severe = than it is today, since unless strong aggregation is preserved, LISP's = entire value proposition is lost. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. The you claim 'lock in' depends on the business = model=20 for EID assignment and mapping service providers. For instance, is a = site=20 numbered from Provider Independent addressing 'locked in' to their RIR? =20= However, we think that there is nothing in the protocol specification=20 requiring or forcing any sort of 'lock in' you claim above. Please feel=20= free to continue discussion of your issue on the LISP working group = mailing=20 list, lisp@ietf.org. Should discussion result in WG consensus that = changes=20 are required, the authors will incorporate appropriate text into a = future=20 version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:18:18 2010 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 EA5173A687C for ; Tue, 20 Jul 2010 14:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xy2aTmmApsV for ; Tue, 20 Jul 2010 14:18:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 05E183A6809 for ; Tue, 20 Jul 2010 14:18:17 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:18:33 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtr027107; Tue, 20 Jul 2010 21:18:33 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:20:08 -0700 Message-Id: <8F9BDDF0-E13E-4A3B-B0D4-A2CABA233CDC@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): PIvsPA (87) 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, 20 Jul 2010 21:18:19 -0000 Issue Title (number): PIvsPA (87) Draft Section: 3 Issue Description: Existing vs New Addressing=20 Comments: Section 3 A globally routed address block (whether PI or PA) is not an EID-prefix. However, a globally routed address block may be removed from global routing and reused as an EID-prefix. A site that receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally routed prefix assigned to RLOCs. The above implies that if an existing site has IPv4 addresses that are = used for global connectivity, and thus act as RLOCs, the site can not = use these addresses as EIDs, unless the site removes them from global = routing, and thus stops using them as RLOCs. Does the spec assume that IPv4 sites that want to use LISP would need to = get another block of IPv4 addresses for the EID prefix ? If yes, then where would these IPv4 addresses come from ? If a site that has IPv4 addresses and uses them for global connectivity = (these addresses act as RLOCs) wants to transition to LISP, but can not = get another block of IPv4 address for the EID-prefix, then how would = that site transition to LISP, and what are the implications on that = site's connectivity during the transition? E.g., could some, but not all, of the border routers of the site during the transition be = xTRs ? If yes, then how would an ITR attract traffic from a site if the = site also has a default route to a non-ITR router ? Does the EID space need to be aggregatable, as if yes, then how would = one accomplish this in the context of IPv4 addresses ? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but are cannot determine whether changes = should be made to the document. Its probable that further discussions on the = topics=20 above would contribute to a usage or deployment draft. Please bring = this=20 issue to the LISP working group mailing list, lisp@ietf.org, for further=20= discussion. Should the WG reach consensus that changes are required, the=20= authors will incorporate appropriate text into a future version of the = draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:18:27 2010 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 E44A93A6C6F for ; Tue, 20 Jul 2010 14:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4-Nhowymeiq for ; Tue, 20 Jul 2010 14:18:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B81223A6A62 for ; Tue, 20 Jul 2010 14:18:26 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 21:18:42 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEts027107; Tue, 20 Jul 2010 21:18:42 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:20:17 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Naming of the Inner Header (89) 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, 20 Jul 2010 21:18:28 -0000 Issue Title (number): Naming of the Inner Header (89) Draft Section: 3 Issue Description: Name of the LISP vs Inner IP header=20 Comments: Section 3: Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. Is LISP redefining the name of the header of the encapsulated packet = from "IP header" to "LISP header"? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. This reference is simply a reference to what = part=20 of the header we are talking about. Please feel free to continue = discussion=20 of your issue on the LISP working group mailing list, lisp@ietf.org.=20 Should discussion result in WG consensus that changes are required, the=20= authors will incorporate appropriate text into a future version of the = draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:18:43 2010 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 8CAEC3A6B6C for ; Tue, 20 Jul 2010 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJzbI7XjFbCB for ; Tue, 20 Jul 2010 14:18:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A4AFB3A6809 for ; Tue, 20 Jul 2010 14:18:42 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:18:58 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtt027107; Tue, 20 Jul 2010 21:18:58 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:20:32 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Limiting number of headers(90) 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, 20 Jul 2010 21:18:43 -0000 Issue Title (number): Limiting number of headers(90) Draft Section: 3 Issue Description: Reincapsulation of Headers Comments: Section 3: Reencapsulating Tunnels: when a packet has no more than one LISP IP header (two IP headers total) and when it needs to be diverted to new RLOC, an ETR can decapsulate the packet (remove the LISP header) and prepend a new tunnel header, with new RLOC, on to the packet. Why re-encapsulation is restricted to packets that only have a single = level of LISP encapsulation? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. To use common jargon, re-encapsulating is is a = 'pop' and then a 'push'. That is all that is meant. Please feel free to = continue=20 discussion of your issue on the LISP working group mailing list, = lisp@ietf.org.=20 Should discussion result in WG consensus that changes are required, the=20= authors will incorporate appropriate text into a future version of the = draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:18:48 2010 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 9B3853A6C78 for ; Tue, 20 Jul 2010 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUqD1QVIweYE for ; Tue, 20 Jul 2010 14:18:47 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 797363A6C7A for ; Tue, 20 Jul 2010 14:18:47 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:19:03 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtu027107; Tue, 20 Jul 2010 21:19:03 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:20:37 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Control Plane Performance (94) 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, 20 Jul 2010 21:18:48 -0000 Issue Title (number): Control Plane Performance (94) Draft Section: 4.1 Issue Description: Control plane performance Comments: Section 4.1 In LISP 1.5, the packet is routed on a different topology which may have EID prefixes distributed and advertised in an aggregatable fashion. In either case, the packet arrives at the ETR. The router is configured to "punt" the packet to the router's processor. Note that the packet is a data plane packet. That means that on ETR the = control plane is used for data plane packet forwarding. What are the = implications of this on control plane performance? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. An ETR implementation can rate-limit Map-Request=20= packets to the control-plane. An ETR's control plane would only need to=20= receive one of such packets to trigger a Map-Reply.=20 Please feel free to continue discussion of your issue on the=20 LISP working group mailing list, lisp@ietf.org. Should discussion result=20= in WG consensus that changes are required, the authors will incorporate=20= appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:19:02 2010 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 8989C3A6C75 for ; Tue, 20 Jul 2010 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5WBlrncxwAy for ; Tue, 20 Jul 2010 14:19:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DDF1E3A6809 for ; Tue, 20 Jul 2010 14:18:59 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 21:19:15 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLGEtv027107; Tue, 20 Jul 2010 21:19:15 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:20:50 -0700 Message-Id: <2D3FC2A4-BF2D-4698-95EE-C07B7313F28C@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP Data Packet Nonce(98) 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, 20 Jul 2010 21:19:02 -0000 Issue Title (number): LISP Data Packet Nonce(98) Draft Section: 5.3 Issue Description: Comments: Section 5.3 LISP Nonce: is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The LISP Nonce does not seem to have a security usage. The choice of the = term "nonce" might lead the reader to think that it does. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. The LISP data-plane nonce could potentially be=20= used by ETRs to detect 3rd party data insertion. So the definition = seems=20 adequate. Please feel free to continue discussion of your issue on the = LISP=20 working group mailing list, lisp@ietf.org. Should discussion result in = WG=20 consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:27:08 2010 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 3E90E3A6966 for ; Tue, 20 Jul 2010 14:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyfhgY-WsEo4 for ; Tue, 20 Jul 2010 14:27:07 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 359553A6925 for ; Tue, 20 Jul 2010 14:27:07 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:27:23 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLRMLY024971; Tue, 20 Jul 2010 21:27:23 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:28:57 -0700 Message-Id: <2A742066-1B88-4864-A672-B8AB2B1ACAED@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): MTU handling Stateless(100) 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, 20 Jul 2010 21:27:08 -0000 Issue Title (number): MTU handling Stateless(100) Draft Section: 5.4.1 / 5.4.2 Issue Description: Stateless vs Statefull MTU Comments: Regarding the "stateless" and "stateful" MTU handling solutions, there = are really two orthogonal parameters at work: whether max MTU is = configured (5.4.1) or learned (5.4.2) and whether the ITR does (5.4.1) = or does not (5.4.2) perform fragmentation. So, there are actually room for two more solutions in the matrix, a configured MTU + = ITR that does not do fragmentation, and a learned MTU + ITR that does do = fragmentation. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. Your comment above is correct, there is room for=20= further solutions. Please feel free to continue discussion of your = issue=20 on the LISP working group mailing list, lisp@ietf.org. Should discussion=20= result in WG consensus that changes are required, the authors will=20 incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:40:27 2010 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 B2B463A6839 for ; Tue, 20 Jul 2010 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo2X58i0h-Fu for ; Tue, 20 Jul 2010 14:40:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D8C743A6892 for ; Tue, 20 Jul 2010 14:40:25 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:40:41 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLefEB010746; Tue, 20 Jul 2010 21:40:41 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:42:16 -0700 Message-Id: <21257A65-B3FA-4A73-AB18-A50877BF276D@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Originating ITR address (102) 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, 20 Jul 2010 21:40:28 -0000 Issue Title (number): Originating ITR address (102) Draft Section: 6.1.2 Issue Description: ITR RLOC Address Comments: Section 6.1.2 Originating ITR RLOC Address: Used to give the ETR the option of returning a Map-Reply in the address-family of this locator. => This does not seem correct. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors have reviewed your comments but do not feel that changes to the document are warranted at this time. This comment was valid for -06, but we believe it was resolved -07 version of this draft. Please feel free to continue discussion of your issue on the LISP working group mailing list, lisp@ietf.org. Should discussion result in WG consensus that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:46:04 2010 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 F23773A6809 for ; Tue, 20 Jul 2010 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR0z3UXSq1dH for ; Tue, 20 Jul 2010 14:46:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DA1673A65A5 for ; Tue, 20 Jul 2010 14:46:02 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 21:46:18 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLkIUt003529; Tue, 20 Jul 2010 21:46:18 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:47:53 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): ETR support of Map-Requests Flood(104) 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, 20 Jul 2010 21:46:04 -0000 Issue Title (number): ETR support of Map-Requests Flood(104) Draft Section: 6.1.3 Issue Description: How Many Map-Requests should an ETR support? Comments: Section 6.1.3 General questions on this section include what is the expected behavior = when an ETR is slashdotted (i.e., is subjected to an unexpected, very = high, continuous load of legitimate queries), a comparison of the = failure mode in this scenario to the behavior of a non-LISP network in = the same scenario, and the related question of what is considered to be a reasonable Map-Request rate to support. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-xx.txt. The draft = authors have reviewed your comments but are cannot determine whether changes = should be made to the document. The authors feel that the topic above might = make=20 an excellent research topic and the results of which might be published=20= in a future 'LISP performance' draft. Please bring this issue to the = LISP working=20 group mailing list, lisp@ietf.org, for further discussion. Should the WG=20= reach consensus that changes are required, the authors will incorporate=20= appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 14:49:51 2010 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 83FC03A6959 for ; Tue, 20 Jul 2010 14:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eT5hazgNcKj for ; Tue, 20 Jul 2010 14:49:49 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 59B173A65A5 for ; Tue, 20 Jul 2010 14:49:49 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:50:05 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLo51X005239; Tue, 20 Jul 2010 21:50:05 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:51:39 -0700 Message-Id: <5B60D835-EA5C-4D0F-A90A-D820E9B10D9A@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): MTU and ICMP Filtering(101) 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, 20 Jul 2010 21:49:51 -0000 Issue Title (number): MTU and ICMP Filtering(101) Draft Section: 5.4.2 Issue Description: Filtering of ICMP messages might be bad. Comments: Section 5.4.2 How would this work if the ITR is behind the firewall, and the firewall = filters ICMP messages? Also, in the case where a large volume of traffic has to be moved from = one ITR to another (e.g., due to ITR failure), it will take time for the = ITR to which the traffic is moved to discover the effective MTU for each = locator mapping, and until this occurs, the traffic will be dropped. Moreover, this ITR could also get overloaded with ICMP Too Big messages, = which could further increase the time required to discover the effective = MTU for each locator mapping. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. While this case is possible the authors assume = the=20 popular use-case will be egress active-active so the map-cache (and=20 therefore information about path MTU) is populated in both boxes. = Please=20 feel free to continue discussion of your issue on the LISP working group=20= mailing list, lisp@ietf.org. Should discussion result in WG consensus=20 that changes are required, the authors will incorporate appropriate text=20= into a future version of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 14:51:55 2010 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 91BE13A65A5 for ; Tue, 20 Jul 2010 14:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+bODj4-miuN for ; Tue, 20 Jul 2010 14:51:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A44893A659C for ; Tue, 20 Jul 2010 14:51:54 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 21:52:10 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLqAGQ019388; Tue, 20 Jul 2010 21:52:10 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 14:53:45 -0700 Message-Id: To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Returning all 3 prefixes (105) 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, 20 Jul 2010 21:51:55 -0000 Issue Title (number): Returning all 3 prefixes (105) Draft Section: 6.1.5 Issue Description:=20 Comments: Section 6.1.5 EID-to-RLOC UDP Map-Reply message 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. Why would those three prefixes be returned? A more general comment is = that what a Map-Reply must return in response to a given Map-Request is = underspecified (or the specification is not comprehensible). To address this perhaps insert something like the following: "When an ETR replies to a Map-Request, it must reply with its EID-prefix that is the best match for the Map-Request. In addition, if it is configured with any EID-prefixes which are more-specifics of the best match EID-prefix that it returns in its Map-Reply, it must return all of those more-specific EID-prefixe s in the same Map-Reply". Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. In your first point, three prefixes are returned=20= because there may be more specific prefixes that want to use a different=20= locator-set. In response to your suggested behavior, we don't think = this=20 will work because for one EID the best match may be the /16, and if a=20 packet is sent to another EID that matches the /24, the ITR won't send=20= a Map-Request for it because it is satisfied with the /16. That will=20 result in the locator-set for the /24 cannot be used. (As an aside,=20 here was a long thread on the required behavior of 'nested EID prefixes=20= on the WG mailing list.) Please feel free to continue discussion of=20 your issue on the LISP working group mailing list, lisp@ietf.org.=20 Should discussion result in WG consensus that changes are required,=20 the authors will incorporate appropriate text into a future version=20 of the draft. Thanks! Darrel, for the LISP document authors= From darlewis@cisco.com Tue Jul 20 15:07:07 2010 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 A28BA3A65A5 for ; Tue, 20 Jul 2010 15:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptDFiAvZ3n4d for ; Tue, 20 Jul 2010 15:07:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0FDA33A6857 for ; Tue, 20 Jul 2010 15:07:05 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 22:07:21 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KM7KGw025385; Tue, 20 Jul 2010 22:07:20 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 15:08:55 -0700 Message-Id: <4D84AC7D-BB0C-4B75-B17F-E59B426C46EE@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Anycasting RLOCs (111) 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, 20 Jul 2010 22:07:07 -0000 Issue Title (number): Anycasting RLOCs (111) Draft Section: ?? Issue Description: Comments: What is the semantics and use of LSB when RLOCs are anycast addresses ? Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the document = are warranted at this time. LSB semantics would mean that if the LSB for an = anycast locator is set, then there is at least one RLOC with that = address that is considered 'up'. Please feel free to continue discussion of your issue on the LISP = working group mailing list, lisp@ietf.org. Should discussion result in = WG consensus that changes are required, the authors will incorporate = appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 15:10:23 2010 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 88EBF3A67D9 for ; Tue, 20 Jul 2010 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaPWBYbW25DM for ; Tue, 20 Jul 2010 15:10:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A25423A67E7 for ; Tue, 20 Jul 2010 15:10:22 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 22:10:38 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMAcud000098; Tue, 20 Jul 2010 22:10:38 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 15:12:12 -0700 Message-Id: <16AE2FC4-53E6-4622-9212-D9B5C0825562@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): Re-encapsulating Tunnels underspecefied (112) 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, 20 Jul 2010 22:10:23 -0000 Issue Title (number): Re-encapsulating Tunnels underspecefied (112) Draft Section: 4-5? Issue Description: Comments: The draft does not provide sufficient details on the use of re-encapsulation. The draft should either provide sufficient details on the use of re-encapsulation, or remove all references to re-encapsulation from the draft. Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but are cannot determine whether changes = should be made to the document. The authors want to allow for the possibility of LISP-TE, since inter-AS announcement of more specific prefixes for TE = purposes is a large minority of the total DFZ's prefixes. We'd like to = see more discussion of this topic and perhaps that discussion could be = captured in a usage/deployment document.=20 Please bring this issue to the LISP working group mailing list,=20 lisp@ietf.org, for further discussion. Should the WG reach consensus=20 that changes are required, the authors will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors From darlewis@cisco.com Tue Jul 20 15:12:40 2010 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 EABA03A67E7 for ; Tue, 20 Jul 2010 15:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt6+aibFe1cz for ; Tue, 20 Jul 2010 15:12:37 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 592793A67D9 for ; Tue, 20 Jul 2010 15:12:37 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 22:12:53 +0000 Received: from sjc-vpn7-1503.cisco.com (sjc-vpn7-1503.cisco.com [10.21.149.223]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMCr9e028473; Tue, 20 Jul 2010 22:12:53 GMT From: Darrel Lewis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 15:14:27 -0700 Message-Id: <596642D9-1C53-433D-9A65-313B0A33DD96@cisco.com> To: lisp@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [lisp] Issue Title (number): LISP for inbound TE (113) 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, 20 Jul 2010 22:12:40 -0000 Issue Title (number): LISP for inbound TE (113) Draft Section: 2, also 6.2 Issue Description: Inbound Traffic Engineering Comments: =46rom Section 2: 4. Traffic engineering capabilities that can be performed by network = elements and do not depend on injecting additional state into the = routing system. This will fall out of the mechanism that is use to = implement the EID/RLOC split (see Section 4).=20 What is described in Section 4 is the use of LISP for outbound/forward = traffic engineering. There is nothing in Section 4 that describes how = LISP could be used to support inbound/return traffic engineering.Either = (a) the draft should add specific details on how LISP supports = inbound/return traffic engineering, or (b) the draft has to explicitly = state that LISP support for traffic engineering is limited to the = outbound/forward traffic only. Response: Dear Yakov- Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors have reviewed your comments but do not feel that changes to the = document are warranted at this time. The authors feel that section 6.2 = on RLOC selection give a detailed example on how an ETR can specify a = site's ingress TE policy. Please feel free to continue discussion of = your issue on the LISP working group mailing list, lisp@ietf.org. Should = discussion result in WG consensus that changes are required, the authors = will incorporate appropriate text into a future version of the draft. Thanks! Darrel, for the LISP document authors= From terry.manderson@icann.org Tue Jul 20 18:03:13 2010 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 5DF303A6A86 for ; Tue, 20 Jul 2010 18:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.286, 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 QccoZQMICEz1 for ; Tue, 20 Jul 2010 18:03:12 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 14A723A6A84 for ; Tue, 20 Jul 2010 18:03:12 -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; Tue, 20 Jul 2010 18:03:28 -0700 From: Terry Manderson To: Darrel Lewis Date: Tue, 20 Jul 2010 18:03:26 -0700 Thread-Topic: [lisp] More work needed I think. Thread-Index: AcsoTiENvUmWqK0mSoim7lJ7O5aA9wAImT1C Message-ID: In-Reply-To: <1600233A-638C-4175-9FBC-00996A73A741@cisco.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] More work needed I think. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 01:03:13 -0000 Darrel, A quick email before I board a flight. Thank you to you, and other the draft authors, for reviewing and responding to the submitted issues. I'm sure it was a significant effort, and you most certainly have my gratitude! Cheers Terry On 21/07/10 6:58 AM, "Darrel Lewis" wrote: > Terry, All. >=20 > My apologies for the lateness of this response. >=20 > I'm going to start sending out responses to the issues raised by the thor= ough > reviews of Demitri, Yakov, and others. The authors have carefully review= ed > each and every issue and are in the midst of preparing detailed responses= . >=20 > The first batch of responses will be for those issues which the authors e= ither > request more feedback from the list members, request suggested text from = the > reviewers, or disagree with the reviewers' comments. For each email, I'= ll > reference the issue number, and copy the original comment and our respons= e. > Other list members should feel free to reply to our response - in no way = are > we attempting to close discussion on an issue based on this first respons= e! >=20 > The second batch of responses address issues that will result in text cha= nges. > These responses will be coming along in the next day or two. Some of thi= s > second batch are technical (so the text change is usually quite straight > forward) and some were editorial (and resulted in quite a bit of changes = for > readability). In addition to email responses, the change log at the end = of > the draft (draft-ietf-lisp) will document these substantive changes. >=20 > Thanks again for taking the time out to provide the detailed reviews, I'm > positive they will result in a much stronger draft. >=20 > -Darrel (on behalf of the draft-ietf-lisp co-authors) >=20 > On May 24, 2010, at 10:27 PM, Terry Manderson wrote: >=20 >> WG Chair hat =3D on >>=20 >> Hi Folks, >>=20 >> I was just taking a look at the number of outstanding issues for the LIS= P WG >> documents. I count 97 in total. ( http://tools.ietf.org/wg/lisp/ ) >>=20 >> Maastricht is barely 9 weeks away. So nearly 11 items would have to be >> addressed per week for the next 9 weeks for us to go to Maastricht in a >> healthy position. >>=20 >> It would be great if we could have some action, be that discussion or >> otherwise, on these! >>=20 >> Cheers, >> Terry >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From damien.saucez@uclouvain.be Wed Jul 28 05:46:39 2010 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 AC1C028C130 for ; Wed, 28 Jul 2010 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2Pp9OgsKvCxe for ; Wed, 28 Jul 2010 05:46:38 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 0CB3028C0E8 for ; Wed, 28 Jul 2010 05:46:37 -0700 (PDT) Received: from dhcp-97f6.meeting.ietf.org (dhcp-97f6.meeting.ietf.org [130.129.151.246]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 457651C6128; Wed, 28 Jul 2010 14:46:14 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp3.sgsi.ucl.ac.be 457651C6128 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1280321174; bh=OXwz5nqJG9iDV8z2N+VO+5AAxptkJ4l1DkNG1Up77CE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zqN4uh3n+o2MWNu1bNNoMkMNj6MB8YYWlZi4qrGIADLShVvqfuStxGPN+uCUOJtYX Kh9hDvzOUQT0f+cHCDjIJTUfOkZFYJ4suujhgfYQDwEQJwgfldKpzTJonGSRRyKian h7vGbc+YgLcsd9+VIHEwcpiTtxjukNqF5/KhUz8g= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Wed, 28 Jul 2010 14:46:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <908730E1-20A5-40EF-BF30-043D274AE921@uclouvain.be> References: To: Darrel Lewis X-Mailer: Apple Mail (2.1081) X-Virus-Scanned: clamav-milter 0.96-exp at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 457651C6128.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] Issue Title (number): LSB handling details (66) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 12:46:39 -0000 Hello, On 20 Jul 2010, at 23:09, Darrel Lewis wrote: > Issue Title (number): LSB handling details (66) > Draft Section: 6.5 > Issue Description: LSB handling and encoding =20 > Comments: >=20 > Section 6.5 the section does not actually explain which messages are > used to update the list of Loc-Reach or Loc-Status bits. If it is data > traffic-driven then the mechanism is again dependent on the symmetry > of the reverse path and the packet rate but also packet differential > delays between packets. In the latter case, it is not clear how ITR > could retrieve the correct RLOCs to be used if a sequence of 8 packets > sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC > (indicated as available at arrival of the 8th packet) is received as > 1,0,0,0,0,0,0,0. The section makes a long digression on ordering > locator set this is not the issue without a sequence number it will > never be possible for the receiving ITR to determine the actual state > of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep > track of who requested mappings upon communication they should tell > the state of their mapping but also their transition.=20 >=20 > This identifies a real problem; i.e., the locator status bits are > contextually dependent on the locator set that was advertised, but > there is no explicit binding between them and the particular locator > set to which they relate. Thus, any version skew between ITR and ETR > will result in misinterpretation of the locator status bits.=20 >=20 >=20 > Response: >=20 > Dear Yakov- >=20 > Thank you for your contribution to draft-ietf-lisp-06.txt. The draft = authors > have reviewed your comments but do not feel that changes to the = document are > warranted at this time. We think that the use of version numbers will = help > this. Its also important to note that LSBs are a hint and a = request/reply=20 > exchange will confirm from the R-bits of the locators in the = locator-set which=20 > are reachable or not. =20 We could imagine to impose the V bit + L bit combination. So everytime = the L bit is set, it is combined with a version number. The version number = is=20 incremented every time LSB changes. In this case, if we have = out-of-order=20 packets, the ETR can ignore the LSB bits in the packets with lower = version=20 numbers. Because it is re-ordering, it is not supposed to have the old = version for more than few seconds (the lifetime packets in the network). If = someone do not want to use the version increment, it can set the special 0-version = which would mean, use the LSB as today (not combined with version). The problem is to know what an xTR has to do when it receives a new = version. Querying the mapping system seem to be irrelevant here has it will not = give=20 feedback about the actual e2e reachability of RLOCs. On the other hand, querying an ETR directly seems to be invalid also as maybe the new = version is related to a change of mapping and thus maybe the ETR is not an ETR anymore! Thanks, Damien Saucez > Please feel free to continue discussion of your issue=20 > on the LISP working group mailing list, lisp@ietf.org. Should = discussion=20 > result in WG consensus that changes are required, the authors will=20 > incorporate appropriate text into a future version of the draft. >=20 > Thanks! > Darrel, for the LISP document authors >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp