From nobody Mon Mar 2 01:48:20 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8F1A700D for ; Mon, 2 Mar 2015 01:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq8YFmqP0SwL for ; Mon, 2 Mar 2015 01:48:17 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D0F1A0363 for ; Mon, 2 Mar 2015 01:48:16 -0800 (PST) Received: by wevm14 with SMTP id m14so32109994wev.8 for ; Mon, 02 Mar 2015 01:48:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=2taxHyM68ezmLOZo95byQNxPlbKoR4ne6XcQO75yUH8=; b=COs96nvEFJ3QN11NueEJmHFZJPyQ5mtMksADLAhcgwtX/Hj1GV/LKskU/aM0RwZCXS zy5zT0TFjiVJjQo/qiNQUFvI30d+t+xq/77pj3LSXaMVcjQNDfqWnKttauM5SEMaZzAd 1t5s3zWvC+15nuXWGBG12caaWTC53voMv+BMRThAHPQj9vQ/I4Gw8n+Fg+QbhoHLzapa 9DhYq3NZevmaCrWlFjWzKU7cvGZB0u/2JQz/2Zm8GnvNIriPsgQSEfF11ZpE6SKibq+a mQGmdoBh7uwrVnOYjzc10ZLH2ePfJX0uY7iR/thqmFygmL8ipsFAkp5+SekMCA6qeN9Y IUIQ== X-Gm-Message-State: ALoCoQkzxfgxnS0KaYBe4cvnZuyzM/qrRaGmfnYm6xlNJawg+M/ZMKorjp19lsxUCTQxmiBJ0UIL X-Received: by 10.194.58.209 with SMTP id t17mr56976490wjq.156.1425289695080; Mon, 02 Mar 2015 01:48:15 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:787a:8f05:3b02:24ae? ([2001:660:330f:a4:787a:8f05:3b02:24ae]) by mx.google.com with ESMTPSA id bx3sm1191887wjc.21.2015.03.02.01.48.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Mar 2015 01:48:13 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_03390FAD-8D06-48FB-84A2-B2091E400367" Message-Id: <4BC9B4D4-175E-4347-887A-8BD0B956C523@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Mon, 2 Mar 2015 10:48:12 +0100 References: <1AC537EE-60A8-4C9A-84D0-8F6C590C2A67@gigix.net> To: LISP mailing list list X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [lisp] LISP WG - Call for Agenda Items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 09:48:19 -0000 --Apple-Mail=_03390FAD-8D06-48FB-84A2-B2091E400367 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, The final agenda for the IETF 92 @ Dallas has been published = (https://datatracker.ietf.org/meeting/92/agenda.html = ) The LISP WG is scheduled to meet on Monday, March 23th, 2015, from 1300 = to 1500 (two hours) Please send your requests for agenda items (Presenter=E2=80=99s name, = ppt title, slot duration)=20 to lisp-chairs@tools.ietf.org by = Sunday, March 8th, 2015. Chairs are going to prioritize requests based on the charter and = milestones. ciao Luigi --Apple-Mail=_03390FAD-8D06-48FB-84A2-B2091E400367 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi All,

The final agenda for = the IETF 92 @ Dallas has been published (https://datatracker.ietf.org/meeting/92/agenda.html)
<= div>
The LISP WG  is scheduled to meet on = Monday, March 23th, 2015, from 1300 to 1500 (two hours)

Please= send your requests for agenda items (Presenter=E2=80=99s name, ppt = title, slot duration) 
to lisp-chairs@tools.ietf.org by Sunday, March 8th, = 2015.

Chairs are going to prioritize requests = based on the charter and = milestones.

ciao

Luigi


= --Apple-Mail=_03390FAD-8D06-48FB-84A2-B2091E400367-- From nobody Tue Mar 3 14:09:23 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7261ACDE5; Tue, 3 Mar 2015 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpgfm6Y2PIEK; Tue, 3 Mar 2015 14:09:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F741A89AF; Tue, 3 Mar 2015 14:09:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 14:09:19 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:09:22 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this document. It is really helpful to have a clear introduction to LISP, and I appreciate the hard work that has gone into producing this text. I have a small Discuss that is easily fixed. The essence is that you should limit this document to a description of LISP and not try to use it to bash other solutions. In Section 4.2 On the contrary BGP is a push architecture, where the required network state is pushed by means of BGP UPDATE messages to BGP speakers. You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol. (I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-) So, my advice is to describe LISP in this document and to not make comments about other systems. It isn't a beauty contest and it isn't wise to try to say "my system is better/different from yours". The solution is to just remove this sentence. Similarly in 7.1 BGP is the standard protocol to implement inter-domain routing. With BGP, routing information are propagated along the network and each autonomous system can implement its own routing policy that will influence the way routing information are propagated. The direct consequence is that an autonomous system cannot precisely control the way the traffic will enter the network. As opposed to BGP, a LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. Let's not get into the "BGP this, BGP that" debate. Just remove the first paragraph and the first four words of the second paragraph. That way you avoid all contention and write a document about LISP. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few questions and editorial nits I hope you will pick up as additional polish. Some of the nits come from Deborah's review as AD in-training --- Section 1 I'm really not comfortable with your text... "Indeed and as pointed out by the unpublished Internet Draft by Noel Chiappa [Chiappa]" This isn't a stable reference and I don't think you need it. You could either rely on the later reference to RFC 4984, reference RFC 6830 itself, or take out the aside "and as... ... [Chiappa]" --- Section 1 has LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses. The "typically" here opens a bit of door. RFC 6830 explains this in the definitions of EID, but seems to be clear that an RLOC is an IP address. If you are opening up the RLOC to be something other than an IP address (a MAC address or even something else?) then how do you deal with: - lack of ICMP - non-uniqueness Possibly you can say that this is "not my problem" since the problem would already exist in the routing system that handles the non-IP addresses. But maybe, for an introduction to the topic this is over- reaching towards the many potential applications rather than the basic explanation of the architecture? But in your own definitions in Section 2, you have Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned topologically to network attachment points and typically routed inter-domain. Neither of which offers any possiblitity to vary "always" into "typically". The again, 3.2 has... EIDs are typically -but not limited to- IPv4 or IPv6 addresses ...and... With LISP, the core uses RLOCs, an RLOC is typically -but not limited to- an IPv4 or IPv6 address Some concistency is needed! In 3.4.1 you finally get there... Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. Why don't you talk about everything in terms of IP adresses and then add a section somewhere near the end to talk about LCAF? --- Section 1 introduces "overlay" and "underlay". I think that a certain class of network engineer understands these concepts really well. And, in my experience, another class has no idea what you are talking about! This would probably show very easily on a simple diagram showing the overlay and underlay networks. But perhaps the summary in the Introduction is launching in a bit deep nd fast? This is probably the hardest part of the document to write: how do you summarise what you haven't yet talked about? There are some bits, however, that really need work. For example... o EIDs have meaning only in the overlay network unless they are leaked into the underlay network. The overlay is the encapsulation relationship between LISP-capable routers. Furthermore EIDs are not assigned from the reserved address blocks. So they have meaning only in one place, unless they have meaning in more than one place? :-) And what is a "resrved address block"? --- Section 3.2 With LISP, LISP sites (edge) and the core of the Internet are interconnected by means of LISP-capable routers (e.g., border routers) using tunnels. I don't think this is right. It is true that LISP sites and the core of the Internet are interconnected by means of LISP-capable routers But the tunnels connect those border routers. So you probably need... LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. --- Section 3.2 OLD A typically distributed database, called the Mapping System, stores mappings between EIDs and RLOCs. NEW A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. --- 3.2 Such LISP capable routers, in most cases, only require a software upgrade. That's a little disconcerting. Can you add to "in most cases"? --- 4.1 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR has to refresh the mapping by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Presumably it doesn't *have to*. It can choose to delete it and not refresh it. Maybe this should be worded as MUST NOT use after the expiration of the TTL. --- Section 5 says The separation between locators and identifiers in LISP was initially proposed for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. RFC 6830 says Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). RFC 4984 says The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. I conclude that Section 5 here is somewhat wrong. --- Section 7.1 "the possibility for a site to issue a different mapping for each remote site, implementing so precise routing policies." Suggest "the possibility for a site to support a different mapping policy for each remote site." --- I think some examination of the classification of normative and informative references would be useful. For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think that is fine because it is where to go for a definition of LISP+ALT. But 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] which turns out to be Informative. --- Appendix A "The LISP system.." Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." --- Appendix A "A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists." Suggest deleting this sentence (unless you want this to look like a Cisco-only initiative). From nobody Tue Mar 3 14:09:26 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7C2181ACDE6; Tue, 3 Mar 2015 14:09:22 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7261ACDE5; Tue, 3 Mar 2015 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpgfm6Y2PIEK; Tue, 3 Mar 2015 14:09:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F741A89AF; Tue, 3 Mar 2015 14:09:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 14:09:19 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:09:22 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this document. It is really helpful to have a clear introduction to LISP, and I appreciate the hard work that has gone into producing this text. I have a small Discuss that is easily fixed. The essence is that you should limit this document to a description of LISP and not try to use it to bash other solutions. In Section 4.2 On the contrary BGP is a push architecture, where the required network state is pushed by means of BGP UPDATE messages to BGP speakers. You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol. (I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-) So, my advice is to describe LISP in this document and to not make comments about other systems. It isn't a beauty contest and it isn't wise to try to say "my system is better/different from yours". The solution is to just remove this sentence. Similarly in 7.1 BGP is the standard protocol to implement inter-domain routing. With BGP, routing information are propagated along the network and each autonomous system can implement its own routing policy that will influence the way routing information are propagated. The direct consequence is that an autonomous system cannot precisely control the way the traffic will enter the network. As opposed to BGP, a LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. Let's not get into the "BGP this, BGP that" debate. Just remove the first paragraph and the first four words of the second paragraph. That way you avoid all contention and write a document about LISP. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few questions and editorial nits I hope you will pick up as additional polish. Some of the nits come from Deborah's review as AD in-training --- Section 1 I'm really not comfortable with your text... "Indeed and as pointed out by the unpublished Internet Draft by Noel Chiappa [Chiappa]" This isn't a stable reference and I don't think you need it. You could either rely on the later reference to RFC 4984, reference RFC 6830 itself, or take out the aside "and as... ... [Chiappa]" --- Section 1 has LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses. The "typically" here opens a bit of door. RFC 6830 explains this in the definitions of EID, but seems to be clear that an RLOC is an IP address. If you are opening up the RLOC to be something other than an IP address (a MAC address or even something else?) then how do you deal with: - lack of ICMP - non-uniqueness Possibly you can say that this is "not my problem" since the problem would already exist in the routing system that handles the non-IP addresses. But maybe, for an introduction to the topic this is over- reaching towards the many potential applications rather than the basic explanation of the architecture? But in your own definitions in Section 2, you have Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned topologically to network attachment points and typically routed inter-domain. Neither of which offers any possiblitity to vary "always" into "typically". The again, 3.2 has... EIDs are typically -but not limited to- IPv4 or IPv6 addresses ...and... With LISP, the core uses RLOCs, an RLOC is typically -but not limited to- an IPv4 or IPv6 address Some concistency is needed! In 3.4.1 you finally get there... Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. Why don't you talk about everything in terms of IP adresses and then add a section somewhere near the end to talk about LCAF? --- Section 1 introduces "overlay" and "underlay". I think that a certain class of network engineer understands these concepts really well. And, in my experience, another class has no idea what you are talking about! This would probably show very easily on a simple diagram showing the overlay and underlay networks. But perhaps the summary in the Introduction is launching in a bit deep nd fast? This is probably the hardest part of the document to write: how do you summarise what you haven't yet talked about? There are some bits, however, that really need work. For example... o EIDs have meaning only in the overlay network unless they are leaked into the underlay network. The overlay is the encapsulation relationship between LISP-capable routers. Furthermore EIDs are not assigned from the reserved address blocks. So they have meaning only in one place, unless they have meaning in more than one place? :-) And what is a "resrved address block"? --- Section 3.2 With LISP, LISP sites (edge) and the core of the Internet are interconnected by means of LISP-capable routers (e.g., border routers) using tunnels. I don't think this is right. It is true that LISP sites and the core of the Internet are interconnected by means of LISP-capable routers But the tunnels connect those border routers. So you probably need... LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. --- Section 3.2 OLD A typically distributed database, called the Mapping System, stores mappings between EIDs and RLOCs. NEW A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. --- 3.2 Such LISP capable routers, in most cases, only require a software upgrade. That's a little disconcerting. Can you add to "in most cases"? --- 4.1 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR has to refresh the mapping by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Presumably it doesn't *have to*. It can choose to delete it and not refresh it. Maybe this should be worded as MUST NOT use after the expiration of the TTL. --- Section 5 says The separation between locators and identifiers in LISP was initially proposed for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. RFC 6830 says Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). RFC 4984 says The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. I conclude that Section 5 here is somewhat wrong. --- Section 7.1 "the possibility for a site to issue a different mapping for each remote site, implementing so precise routing policies." Suggest "the possibility for a site to support a different mapping policy for each remote site." --- I think some examination of the classification of normative and informative references would be useful. For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think that is fine because it is where to go for a definition of LISP+ALT. But 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] which turns out to be Informative. --- Appendix A "The LISP system.." Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." --- Appendix A "A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists." Suggest deleting this sentence (unless you want this to look like a Cisco-only initiative). From nobody Tue Mar 3 22:22:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B31A038E; Tue, 3 Mar 2015 22:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnmaoM1emrQl; Tue, 3 Mar 2015 22:22:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8F1A00E7; Tue, 3 Mar 2015 22:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 22:22:37 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 06:22:39 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-introduction-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that Adrian's Discuss and Comments answered, so I'd encourage you to work through his Comments, as well as his Discuss. Beyond that: In this text: 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. would you ever use "virtual xTRs" with the same outermost IP addresses? If not, fine, but if so, would you need to use different destination ports to disambiguate them? Or does the Instance ID provide enough isolation to meet this need? I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early! Further in the same paragraph, in this text: A particularity of LISP is that UDP packets should include a zero checksum [RFC6935] [RFC6936] that it is not verified in reception, LISP also supports non-zero checksums that may be verified. This decision was made because the typical transport protocols used by the applications already include a checksum, by neglecting the additional UDP encapsulation checksum xTRs can forward packets more efficiently. I'm wobbling between "should include a zero checksum" and "also supports non-zero checksums". Is that text saying something like this? LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing. From nobody Tue Mar 3 22:22:45 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 48F6B1A040C; Tue, 3 Mar 2015 22:22:39 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B31A038E; Tue, 3 Mar 2015 22:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnmaoM1emrQl; Tue, 3 Mar 2015 22:22:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8F1A00E7; Tue, 3 Mar 2015 22:22:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 22:22:37 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 06:22:39 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-introduction-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that Adrian's Discuss and Comments answered, so I'd encourage you to work through his Comments, as well as his Discuss. Beyond that: In this text: 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. would you ever use "virtual xTRs" with the same outermost IP addresses? If not, fine, but if so, would you need to use different destination ports to disambiguate them? Or does the Instance ID provide enough isolation to meet this need? I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early! Further in the same paragraph, in this text: A particularity of LISP is that UDP packets should include a zero checksum [RFC6935] [RFC6936] that it is not verified in reception, LISP also supports non-zero checksums that may be verified. This decision was made because the typical transport protocols used by the applications already include a checksum, by neglecting the additional UDP encapsulation checksum xTRs can forward packets more efficiently. I'm wobbling between "should include a zero checksum" and "also supports non-zero checksums". Is that text saying something like this? LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing. From nobody Wed Mar 4 04:37:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EFC1A0092; Wed, 4 Mar 2015 04:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw5x3xZLfOHq; Wed, 4 Mar 2015 04:37:20 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6431A020D; Wed, 4 Mar 2015 04:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3451; q=dns/txt; s=iport; t=1425472640; x=1426682240; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=88ZvsYvwpAqh4fUMMStMHurp1D3bW9tXZJLef3eGk6Q=; b=GSCAjG++zzD5vuQXlQoXoCpJQE7ePeRQ5V6GH5oGuhqXR22g7ry11XYx dxuuG7dXIy9qlSDooo3stwBv2UKjWRo8JV2CswtXkjLaTNx8Y0aJt/fL7 Ol5HMsZXDm3mFGwrtiOr/4BrwvABTFAoRRW2zPt/76RO238imLtykf0Vw 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5CAAl+/ZU/xbLJq1ahzm4FotqAoFzAQEBAQEBfIQQAQEEI1UBEAsSBgkWCwICCQMCAQIBNw4GAQwBBwEBF4gUvG6aIAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLEoQXVweCaIFDAQSEM4E9i3OBLoQ/gXuBGoVXhh2GWiOCMoE9PYE0gUABAQE X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="asc'?scan'208";a="364646678" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 04 Mar 2015 12:37:17 +0000 Received: from [10.61.107.12] (dhcp-10-61-107-12.cisco.com [10.61.107.12]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t24CbGIr029782; Wed, 4 Mar 2015 12:37:16 GMT Message-ID: <54F6FC7E.9000400@cisco.com> Date: Wed, 04 Mar 2015 13:37:18 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 12:37:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm sorry I didn't catch this earlier (attention elsewhere). On 3/3/15 11:09 PM, Adrian Farrel wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this document. It is really helpful to have a clear > introduction to LISP, and I appreciate the hard work that has gone into= > producing this text. > > I have a small Discuss that is easily fixed. The essence is that you=20 > should limit this document to a description of LISP and not try to use > it to bash other solutions. > > In Section 4.2 > > On the contrary BGP is a > push architecture, where the required network state is pushed by > means of BGP UPDATE messages to BGP speakers. > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mod= e > protocol. > > (I won't say to you that LISP is push mode because a Map-Reply pushes=20 > the mapping information from the map server to the client :-) > > So, my advice is to describe LISP in this document and to not make > comments about other systems. It isn't a beauty contest and it isn't > wise to try to say "my system is better/different from yours". > > The solution is to just remove this sentence. > > Similarly in 7.1 > > BGP is the standard protocol to implement inter-domain routing. Wit= h > BGP, routing information are propagated along the network and each > autonomous system can implement its own routing policy that will > influence the way routing information are propagated. The direct > consequence is that an autonomous system cannot precisely control th= e > way the traffic will enter the network. > > As opposed to BGP, a LISP site can strictly impose via which ETRs th= e > traffic must enter the the LISP site network even though the path > followed to reach the ETR is not under the control of the LISP site.= > > Let's not get into the "BGP this, BGP that" debate. Just remove the=20 > first paragraph and the first four words of the second paragraph. That > way you avoid all contention and write a document about LISP. I would go further. Whether LISP is a pull- or a push architecture (or something else) is entirely a characteristic of the mapping system used. The one in common use today is indeed a pull architecture. The text discussing push/pull, therefore, should be addressed to the mapping system. Eliot --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU9vx/AAoJEIe2a0bZ0nozMnAH/iYTttwDgSoxuuhilNRHNs3M fh13+X4EqotE91i2ewm0GOKDpa2We4h/1WafEa2OLS0Hucb0tdzAq4i7jW9x6vOl LrpcRFFKYJQ6KSGVGZbN/LHUIkVgkNHl6GMWULVjgBx1Ul67mg/5AvmzrOkRSbj6 RznukdhqtZeCaEobi8AFce71uRhuMy4arVRxcwxj4rXFXYr1Z8SjUjRPKFzqBnJO T6BnVodYjqMtNJMPuLRIEuNCIjYaR9h7Fv7Ldpzuq+P44hMwowIQz5fkwVG+Kgm6 ohKeZu+5Iw6duz5+GiJp3el7iIk+0hXjTiykcd8+6i0tuechDxrc0o8tf5sAXPg= =ghAu -----END PGP SIGNATURE----- --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI-- From nobody Wed Mar 4 04:37:25 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 677431A032D; Wed, 4 Mar 2015 04:37:21 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EFC1A0092; Wed, 4 Mar 2015 04:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw5x3xZLfOHq; Wed, 4 Mar 2015 04:37:20 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6431A020D; Wed, 4 Mar 2015 04:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3451; q=dns/txt; s=iport; t=1425472640; x=1426682240; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=88ZvsYvwpAqh4fUMMStMHurp1D3bW9tXZJLef3eGk6Q=; b=GSCAjG++zzD5vuQXlQoXoCpJQE7ePeRQ5V6GH5oGuhqXR22g7ry11XYx dxuuG7dXIy9qlSDooo3stwBv2UKjWRo8JV2CswtXkjLaTNx8Y0aJt/fL7 Ol5HMsZXDm3mFGwrtiOr/4BrwvABTFAoRRW2zPt/76RO238imLtykf0Vw 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5CAAl+/ZU/xbLJq1ahzm4FotqAoFzAQEBAQEBfIQQAQEEI1UBEAsSBgkWCwICCQMCAQIBNw4GAQwBBwEBF4gUvG6aIAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLEoQXVweCaIFDAQSEM4E9i3OBLoQ/gXuBGoVXhh2GWiOCMoE9PYE0gUABAQE X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="asc'?scan'208";a="364646678" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 04 Mar 2015 12:37:17 +0000 Received: from [10.61.107.12] (dhcp-10-61-107-12.cisco.com [10.61.107.12]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t24CbGIr029782; Wed, 4 Mar 2015 12:37:16 GMT Message-ID: <54F6FC7E.9000400@cisco.com> Date: Wed, 04 Mar 2015 13:37:18 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 12:37:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm sorry I didn't catch this earlier (attention elsewhere). On 3/3/15 11:09 PM, Adrian Farrel wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this document. It is really helpful to have a clear > introduction to LISP, and I appreciate the hard work that has gone into= > producing this text. > > I have a small Discuss that is easily fixed. The essence is that you=20 > should limit this document to a description of LISP and not try to use > it to bash other solutions. > > In Section 4.2 > > On the contrary BGP is a > push architecture, where the required network state is pushed by > means of BGP UPDATE messages to BGP speakers. > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mod= e > protocol. > > (I won't say to you that LISP is push mode because a Map-Reply pushes=20 > the mapping information from the map server to the client :-) > > So, my advice is to describe LISP in this document and to not make > comments about other systems. It isn't a beauty contest and it isn't > wise to try to say "my system is better/different from yours". > > The solution is to just remove this sentence. > > Similarly in 7.1 > > BGP is the standard protocol to implement inter-domain routing. Wit= h > BGP, routing information are propagated along the network and each > autonomous system can implement its own routing policy that will > influence the way routing information are propagated. The direct > consequence is that an autonomous system cannot precisely control th= e > way the traffic will enter the network. > > As opposed to BGP, a LISP site can strictly impose via which ETRs th= e > traffic must enter the the LISP site network even though the path > followed to reach the ETR is not under the control of the LISP site.= > > Let's not get into the "BGP this, BGP that" debate. Just remove the=20 > first paragraph and the first four words of the second paragraph. That > way you avoid all contention and write a document about LISP. I would go further. Whether LISP is a pull- or a push architecture (or something else) is entirely a characteristic of the mapping system used. The one in common use today is indeed a pull architecture. The text discussing push/pull, therefore, should be addressed to the mapping system. Eliot --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU9vx/AAoJEIe2a0bZ0nozMnAH/iYTttwDgSoxuuhilNRHNs3M fh13+X4EqotE91i2ewm0GOKDpa2We4h/1WafEa2OLS0Hucb0tdzAq4i7jW9x6vOl LrpcRFFKYJQ6KSGVGZbN/LHUIkVgkNHl6GMWULVjgBx1Ul67mg/5AvmzrOkRSbj6 RznukdhqtZeCaEobi8AFce71uRhuMy4arVRxcwxj4rXFXYr1Z8SjUjRPKFzqBnJO T6BnVodYjqMtNJMPuLRIEuNCIjYaR9h7Fv7Ldpzuq+P44hMwowIQz5fkwVG+Kgm6 ohKeZu+5Iw6duz5+GiJp3el7iIk+0hXjTiykcd8+6i0tuechDxrc0o8tf5sAXPg= =ghAu -----END PGP SIGNATURE----- --W3ialFU7c3HBm7VmICPmw20sS9qU8sVTI-- From nobody Wed Mar 4 09:10:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFAC1A8833; Wed, 4 Mar 2015 09:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmglMxLty1G2; Wed, 4 Mar 2015 09:10:25 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603171A0060; Wed, 4 Mar 2015 09:10:22 -0800 (PST) Received: by pabrd3 with SMTP id rd3so1425765pab.6; Wed, 04 Mar 2015 09:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jx9Gj2z3t4QuPUOxI30amLd0PID4OoQ4gVIZJKmZNWc=; b=yyVMRpqaRr0rSaVGj9IRJGiFlf+xmRB2CsewMcH7Y57VkN4l8UINRcARvqMXlUY7NB LfAvzDQ8QUV7u8he9fy9Nup9ubn117d6U5E+i3+1SXb6yhoaS3uERl2nKa4isMWvbUEl ELqz8Mt/RjkFgIjvZPgiIfv6Ks2dRTJJ5dhArCh9+icBmtE0T0PHAgFze/7H14rRuFxK V2FCV6ADp1AWB+bGOn+JDa5whRHWQSme1ZJumSHK43AgryBTr0g8VbblOTphXfhnuawC qKdd62qmXatJcMB+Q0FKmzlzU6yxbuWTiXHgOtxIgv8nXmzE0P/VgHbyJ55uqRlu//Sz kL4g== X-Received: by 10.68.69.34 with SMTP id b2mr8542140pbu.88.1425489022108; Wed, 04 Mar 2015 09:10:22 -0800 (PST) Received: from ?IPv6:2601:9:4701:1df0:d429:4353:8415:275? ([2601:9:4701:1df0:d429:4353:8415:275]) by mx.google.com with ESMTPSA id i5sm4572859pat.42.2015.03.04.09.10.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 09:10:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Wed, 4 Mar 2015 09:10:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:10:27 -0000 > Appendix A >=20 > "A small group of like-minded personnel from various scattered = locations > within Cisco, spontaneously formed immediately after that workshop, to=20= > work on an idea that came out of informal discussions at the workshop > and on various mailing lists." >=20 > Suggest deleting this sentence (unless you want this to look like a=20 > Cisco-only initiative). The like-minded personnel were (and are) scattered throughout the world. = And it was more than cisco folks that formed post workshop. I agree the cisco reference should be removed. Dino From nobody Wed Mar 4 09:10:34 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0B15C1A8853; Wed, 4 Mar 2015 09:10:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFAC1A8833; Wed, 4 Mar 2015 09:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmglMxLty1G2; Wed, 4 Mar 2015 09:10:25 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603171A0060; Wed, 4 Mar 2015 09:10:22 -0800 (PST) Received: by pabrd3 with SMTP id rd3so1425765pab.6; Wed, 04 Mar 2015 09:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jx9Gj2z3t4QuPUOxI30amLd0PID4OoQ4gVIZJKmZNWc=; b=yyVMRpqaRr0rSaVGj9IRJGiFlf+xmRB2CsewMcH7Y57VkN4l8UINRcARvqMXlUY7NB LfAvzDQ8QUV7u8he9fy9Nup9ubn117d6U5E+i3+1SXb6yhoaS3uERl2nKa4isMWvbUEl ELqz8Mt/RjkFgIjvZPgiIfv6Ks2dRTJJ5dhArCh9+icBmtE0T0PHAgFze/7H14rRuFxK V2FCV6ADp1AWB+bGOn+JDa5whRHWQSme1ZJumSHK43AgryBTr0g8VbblOTphXfhnuawC qKdd62qmXatJcMB+Q0FKmzlzU6yxbuWTiXHgOtxIgv8nXmzE0P/VgHbyJ55uqRlu//Sz kL4g== X-Received: by 10.68.69.34 with SMTP id b2mr8542140pbu.88.1425489022108; Wed, 04 Mar 2015 09:10:22 -0800 (PST) Received: from ?IPv6:2601:9:4701:1df0:d429:4353:8415:275? ([2601:9:4701:1df0:d429:4353:8415:275]) by mx.google.com with ESMTPSA id i5sm4572859pat.42.2015.03.04.09.10.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 09:10:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Wed, 4 Mar 2015 09:10:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:10:27 -0000 > Appendix A >=20 > "A small group of like-minded personnel from various scattered = locations > within Cisco, spontaneously formed immediately after that workshop, to=20= > work on an idea that came out of informal discussions at the workshop > and on various mailing lists." >=20 > Suggest deleting this sentence (unless you want this to look like a=20 > Cisco-only initiative). The like-minded personnel were (and are) scattered throughout the world. = And it was more than cisco folks that formed post workshop. I agree the cisco reference should be removed. Dino From nobody Thu Mar 5 02:38:06 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4B1A0A6A; Thu, 5 Mar 2015 02:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEyn-_gPsmwI; Thu, 5 Mar 2015 02:38:02 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4159A1B2A19; Thu, 5 Mar 2015 02:38:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 11ED71C04C3; Thu, 5 Mar 2015 02:38:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A8EF01C0286; Thu, 5 Mar 2015 02:37:56 -0800 (PST) Message-ID: <54F83200.7020107@joelhalpern.com> Date: Thu, 05 Mar 2015 05:37:52 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , The IESG References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> In-Reply-To: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, Radia Perlman Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:38:04 -0000 I am not sure what would go in the introduction document that would address Radia's concern. Each mapping system document includes security considerations that are specific to that mapping system. The Original BGP based system has one set of properties, the DDT one (which we will be advancing after the blocking documents are cleared) as a different set. The introduction document is not a requirements document driving that work, but rather an explanation. I suppose we could add a short paragraph that notes that individual mapping systems need to address traffic misdirection threats, and that the mapping system interfaces (Map Servers and Map Resolvers, and the protocol between ITRs/ETRs and those components) need to address a multitude of security issues. But would that kind of text really help the introduction? I very much don't want to see this document getting into the question of why not to use DNS as the mapping system, or a DNS clone, or ... One of the keys to the LISP design is that different mapping system designs can be and are being tried. One of the challenges in writing this introduction is to reflect the existing RFCs while allowing for the new work such as DDT that we know the working group plans so as not to obsolete this introduction. Yours, Joel On 3/4/15 9:11 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > It appears the SecDir review didn't make it to LISP list for some reason. > There is one important security request from Radia's review and many > other good suggestions. > > https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html > > Expanding the Security Considerations section would be helpful, here is > the background on the request: > > There is a security considerations section, which focuses on a class of > denial of service attacks. There are presumably security considerations > sections in the other documents, including one that focuses entirely on > security, so it is not necessary that all security issues be brought up > here. That said, I think that if you were to write an "introduction to > security considerations", there are more important ones than the DoS > threat. > in particular, as a routing protocol care must be taken to make sure a > bad > actor cannot attract someone else's traffic with mechanisms like those > we > are trying to address with BGP security. Much of the routing information > is > maintained in a database "like DNS". If it *were* DNS, DNSSEC could be > used > to address the integrity issues. If it is home grown, some equivalent > mechanism will be necessary. Why not use DNS? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please do look at the other suggestions from the review as they should > help clarify a few points in the draft and provide the background needed > for an introduction draft. > https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html > > > From nobody Thu Mar 5 02:38:07 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 210601B2A19; Thu, 5 Mar 2015 02:38:04 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C4B1A0A6A; Thu, 5 Mar 2015 02:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEyn-_gPsmwI; Thu, 5 Mar 2015 02:38:02 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4159A1B2A19; Thu, 5 Mar 2015 02:38:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 11ED71C04C3; Thu, 5 Mar 2015 02:38:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A8EF01C0286; Thu, 5 Mar 2015 02:37:56 -0800 (PST) Message-ID: <54F83200.7020107@joelhalpern.com> Date: Thu, 05 Mar 2015 05:37:52 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , The IESG References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> In-Reply-To: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, Radia Perlman Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:38:04 -0000 I am not sure what would go in the introduction document that would address Radia's concern. Each mapping system document includes security considerations that are specific to that mapping system. The Original BGP based system has one set of properties, the DDT one (which we will be advancing after the blocking documents are cleared) as a different set. The introduction document is not a requirements document driving that work, but rather an explanation. I suppose we could add a short paragraph that notes that individual mapping systems need to address traffic misdirection threats, and that the mapping system interfaces (Map Servers and Map Resolvers, and the protocol between ITRs/ETRs and those components) need to address a multitude of security issues. But would that kind of text really help the introduction? I very much don't want to see this document getting into the question of why not to use DNS as the mapping system, or a DNS clone, or ... One of the keys to the LISP design is that different mapping system designs can be and are being tried. One of the challenges in writing this introduction is to reflect the existing RFCs while allowing for the new work such as DDT that we know the working group plans so as not to obsolete this introduction. Yours, Joel On 3/4/15 9:11 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > It appears the SecDir review didn't make it to LISP list for some reason. > There is one important security request from Radia's review and many > other good suggestions. > > https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html > > Expanding the Security Considerations section would be helpful, here is > the background on the request: > > There is a security considerations section, which focuses on a class of > denial of service attacks. There are presumably security considerations > sections in the other documents, including one that focuses entirely on > security, so it is not necessary that all security issues be brought up > here. That said, I think that if you were to write an "introduction to > security considerations", there are more important ones than the DoS > threat. > in particular, as a routing protocol care must be taken to make sure a > bad > actor cannot attract someone else's traffic with mechanisms like those > we > are trying to address with BGP security. Much of the routing information > is > maintained in a database "like DNS". If it *were* DNS, DNSSEC could be > used > to address the integrity issues. If it is home grown, some equivalent > mechanism will be necessary. Why not use DNS? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please do look at the other suggestions from the review as they should > help clarify a few points in the draft and provide the background needed > for an introduction draft. > https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html > > > From nobody Thu Mar 5 04:08:59 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162471B2BC6; Thu, 5 Mar 2015 04:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHXiKQmJ89y3; Thu, 5 Mar 2015 04:08:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA91AD082; Thu, 5 Mar 2015 04:08:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305120853.10068.20391.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 04:08:53 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:08:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Threats Analysis Authors : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-12.txt Pages : 20 Date : 2015-03-05 Abstract: This document proposes a threat analysis of the Locator/Identifier Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-threats-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-threats-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 04:10:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8B1A1B6A for ; Thu, 5 Mar 2015 04:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOnP_T5vxGBD for ; Thu, 5 Mar 2015 04:10:53 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342FE1A1B4C for ; Thu, 5 Mar 2015 04:10:53 -0800 (PST) Received: by wggx13 with SMTP id x13so12782867wgg.4 for ; Thu, 05 Mar 2015 04:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=LGHzMWN9onengjamgqV9sLdw2Ibg+Ax0JHLdkVOfCMw=; b=bKNCKKW5dqMp6qIPb5yI2txamGQspfbsuaKyjtKlPcZ2nvVtylsB8LqofsZatxgChY pBaQg5Dt+o7HASw/POixgDyuTTp+1C53o2X0yKqznC4SFxjFlX1pi75i9GkGrBGN4eWG VQHF17Vk+hkftIHaO1gK91GMNRNEH2UmFoWVBF1hG7DnRPb8YCKFL3ILA8Ywysl05W8g 5kwo3nmMsMdn6kafr3V5VGWS3NXHkZhWkgCEKaTAuG65Iu9I2PU/2f7nt6GGzOfw08q0 N5ukD/U4f3vIIeVseQ7c+3dYf+XQSmrnaFaYrsP6Xy5xgg+lPoTmQDSHyYmhxQPdx5sW MLHg== X-Received: by 10.194.48.12 with SMTP id h12mr18444048wjn.74.1425557451852; Thu, 05 Mar 2015 04:10:51 -0800 (PST) Received: from [10.122.247.218] (nat-eduroam-agro.univ-avignon.fr. [194.57.216.13]) by mx.google.com with ESMTPSA id t9sm29457377wia.15.2015.03.05.04.10.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 04:10:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: <20150305120853.10068.20391.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 13:10:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150305120853.10068.20391.idtracker@ietfa.amsl.com> To: LISP mailing list list X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-threats-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:10:54 -0000 Hello, Please find vers -12 taking into account comments given on the mailing = list and proposing a new mitigation section. Damien Saucez=20 On 05 Mar 2015, at 13:08, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP Threats Analysis > Authors : Damien Saucez > Luigi Iannone > Olivier Bonaventure > Filename : draft-ietf-lisp-threats-12.txt > Pages : 20 > Date : 2015-03-05 >=20 > Abstract: > This document proposes a threat analysis of the Locator/Identifier > Separation Protocol (LISP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-threats-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-threats-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Mar 5 05:13:13 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417F21A1A6C for ; Thu, 5 Mar 2015 05:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WGjC6qS3vy4 for ; Thu, 5 Mar 2015 05:13:10 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1A71A8748 for ; Thu, 5 Mar 2015 05:13:09 -0800 (PST) Received: by wesq59 with SMTP id q59so15868601wes.3 for ; Thu, 05 Mar 2015 05:13:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ZzimNhPpFy5by0F7lOfU3N4SvDF/MTnaxyMd18kKWLg=; b=JBScPP9v7gBJXpVCk2WxSUyHyPVLyD8fxMYeDJ9lTXeEDLylvzfhnHNEeDiJYHTv/P IT0vujdLMHVFB8bAdt29RjwC4JyCr7Ja3zaGbe11d/6DKmNMsFTrN0EISbP95qBkHJ9r sISA/XZFGUUDoywP3ecj4OenAe0aRqwhcXpgaip2oHOoTIodbGP4yBtcKnI7hMlVVJU2 VzQyA8YFlAbGDNUP9glRhWSuEwkGqXE9bwhwJ2ldrXGMzD5aDYNFxipexSFO+hXcpuRb XpZTyt1sCxzbFkNOuVyWb7bALB1NtZIPD7ZfWRk2ar25cDaFbA0wEa43I2jPUy5NLxIY k3tw== X-Gm-Message-State: ALoCoQnSMqBfIWOuBdnWaJyEMqfXgzhO2wbw37+DtKCYNn1wCuZu/DNSmaUhx81twKfmPu4ZIdIg X-Received: by 10.180.211.172 with SMTP id nd12mr65192341wic.88.1425561188488; Thu, 05 Mar 2015 05:13:08 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:58d4:15f4:1ef8:fe6c? ([2001:660:330f:a4:58d4:15f4:1ef8:fe6c]) by mx.google.com with ESMTPSA id fo9sm29687932wib.16.2015.03.05.05.13.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 05:13:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Thu, 5 Mar 2015 14:13:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28CD0A74-C890-48F2-8FFC-B1A25688EC49@gigix.net> References: To: LISP mailing list list X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Damien Saucez , Olivier Bonaventure Subject: [lisp] Progress on threats document [Follow-Up] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:13:12 -0000 Hi All, The threats document has been updated with all the received comments. = This sets the threats analysis as _done_. Is time to focus on mitigations. The updated document has a new section = named =E2=80=9Cthreats mitigation=E2=80=9D. Please review this part so to finalise the document during the next = meeting in Dallas. ciao L. > On 12 Jan 2015, at 15:47, Luigi Iannone wrote: >=20 > Hi All, >=20 > back in Toronto the WG agreed to organise the threats document in two = main parts:=20 >=20 > 1- threat analysis=20 > 2- threats mitigation >=20 > there was also agreement to try to finalise the first part before = tackling the second one. >=20 > To this end, this would be the right time to review the current = document and send any comment/feedback to the authors. >=20 > Having such review by the end of February at latest would give = sufficient time to have a new document with the first part done and a = newly proposed second part before the meeting in Dallas. >=20 > Please speak up before the end of February if you have any comment, = otherwise authors will consider the first part as done. >=20 > ciao >=20 > Luigi From nobody Thu Mar 5 05:15:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC591A01AE; Thu, 5 Mar 2015 05:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IREFEzehwHKd; Thu, 5 Mar 2015 05:15:28 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30C21A01BA; Thu, 5 Mar 2015 05:15:27 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D26008812D; Thu, 5 Mar 2015 05:15:27 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6004F1368260; Thu, 5 Mar 2015 05:15:22 -0800 (PST) Message-ID: <54F856FD.8020004@innovationslab.net> Date: Thu, 05 Mar 2015 08:15:41 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Kathleen Moriarty , The IESG References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> <54F83200.7020107@joelhalpern.com> In-Reply-To: <54F83200.7020107@joelhalpern.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk" Archived-At: Cc: draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, Radia Perlman Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:15:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joel, On 3/5/15 5:37 AM, Joel M. Halpern wrote: > I am not sure what would go in the introduction document that would > address Radia's concern. >=20 > Each mapping system document includes security considerations that are > specific to that mapping system. The Original BGP based system has one= > set of properties, the DDT one (which we will be advancing after the > blocking documents are cleared) as a different set. The introduction > document is not a requirements document driving that work, but rather a= n > explanation. Agreed. > I suppose we could add a short paragraph that notes that individual > mapping systems need to address traffic misdirection threats, and that > the mapping system interfaces (Map Servers and Map Resolvers, and the > protocol between ITRs/ETRs and those components) need to address a > multitude of security issues. But would that kind of text really help > the introduction? >=20 I think it would help by letting readers know that there are different security considerations for the different types of mapping systems. > I very much don't want to see this document getting into the question o= f > why not to use DNS as the mapping system, or a DNS clone, or ... One o= f > the keys to the LISP design is that different mapping system designs ca= n > be and are being tried. One of the challenges in writing this > introduction is to reflect the existing RFCs while allowing for the new= > work such as DDT that we know the working group plans so as not to > obsolete this introduction. I agree that this is not the document to get into the "use vs. not use" the DNS for mapping. Regards, Brian --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU+FcCAAoJEBOZRqCi7goq1QUH/RcU9LfY7MT89koDPGWZ1srK pRLBsyOa04ePjZC5c5LF08dW9KMKEc9LlgiM9vrVzFeRf2kKfi6qNpVEZrvNvNmQ m9Ds/RBc6YfsnsdcEMEKq+HP0i9uPtIIY+Vu8+CmWbYro4LOwy2vndG0OvmKiLe7 QIBHzhcfvJ1u6pUychlkedJoSp27ATGWDD1xTNAYuU7qOf7T/Lnr0KIHLyTLmdgm xiat0mZCXTlztc89sdn1q14K3m4kIjW+rLt496ePDo4x8Ra3ViMqLKdm2nQ1cOsU smcA/SjrXn5gvnKeB2VfUyBWrMsATJMVhLQHIktsr/snZOkIHX+ptbv76+ZKgd4= =WSln -----END PGP SIGNATURE----- --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk-- From nobody Thu Mar 5 05:15:38 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DC74C1A1A38; Thu, 5 Mar 2015 05:15:32 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC591A01AE; Thu, 5 Mar 2015 05:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IREFEzehwHKd; Thu, 5 Mar 2015 05:15:28 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30C21A01BA; Thu, 5 Mar 2015 05:15:27 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D26008812D; Thu, 5 Mar 2015 05:15:27 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6004F1368260; Thu, 5 Mar 2015 05:15:22 -0800 (PST) Message-ID: <54F856FD.8020004@innovationslab.net> Date: Thu, 05 Mar 2015 08:15:41 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Joel M. Halpern" , Kathleen Moriarty , The IESG References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> <54F83200.7020107@joelhalpern.com> In-Reply-To: <54F83200.7020107@joelhalpern.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk" Archived-At: Cc: draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, Radia Perlman Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:15:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joel, On 3/5/15 5:37 AM, Joel M. Halpern wrote: > I am not sure what would go in the introduction document that would > address Radia's concern. >=20 > Each mapping system document includes security considerations that are > specific to that mapping system. The Original BGP based system has one= > set of properties, the DDT one (which we will be advancing after the > blocking documents are cleared) as a different set. The introduction > document is not a requirements document driving that work, but rather a= n > explanation. Agreed. > I suppose we could add a short paragraph that notes that individual > mapping systems need to address traffic misdirection threats, and that > the mapping system interfaces (Map Servers and Map Resolvers, and the > protocol between ITRs/ETRs and those components) need to address a > multitude of security issues. But would that kind of text really help > the introduction? >=20 I think it would help by letting readers know that there are different security considerations for the different types of mapping systems. > I very much don't want to see this document getting into the question o= f > why not to use DNS as the mapping system, or a DNS clone, or ... One o= f > the keys to the LISP design is that different mapping system designs ca= n > be and are being tried. One of the challenges in writing this > introduction is to reflect the existing RFCs while allowing for the new= > work such as DDT that we know the working group plans so as not to > obsolete this introduction. I agree that this is not the document to get into the "use vs. not use" the DNS for mapping. Regards, Brian --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU+FcCAAoJEBOZRqCi7goq1QUH/RcU9LfY7MT89koDPGWZ1srK pRLBsyOa04ePjZC5c5LF08dW9KMKEc9LlgiM9vrVzFeRf2kKfi6qNpVEZrvNvNmQ m9Ds/RBc6YfsnsdcEMEKq+HP0i9uPtIIY+Vu8+CmWbYro4LOwy2vndG0OvmKiLe7 QIBHzhcfvJ1u6pUychlkedJoSp27ATGWDD1xTNAYuU7qOf7T/Lnr0KIHLyTLmdgm xiat0mZCXTlztc89sdn1q14K3m4kIjW+rLt496ePDo4x8Ra3ViMqLKdm2nQ1cOsU smcA/SjrXn5gvnKeB2VfUyBWrMsATJMVhLQHIktsr/snZOkIHX+ptbv76+ZKgd4= =WSln -----END PGP SIGNATURE----- --DwOa5pFRk1FvIHspC96XiUe8TA0V9lvOk-- From nobody Thu Mar 5 06:32:43 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5D1A002C; Thu, 5 Mar 2015 06:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXLVupgchRbV; Thu, 5 Mar 2015 06:32:34 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9565A1A000A; Thu, 5 Mar 2015 06:29:34 -0800 (PST) Received: by igbhl2 with SMTP id hl2so46050178igb.3; Thu, 05 Mar 2015 06:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8/VetyPx8rqkd7jNmIcv067QLuRBEsWdam4Q0ZM5TMs=; b=m1nkgUfSR1BvaoEK6Ky+KBZY4VJD1r4QST6nvbacWh9DX3E7rwTTuOcF3Hj9uNCCji LRtctukc55Q3UQsEsY+Zj0HI4WBuMp2D5ZOuP94hax0TzyBMFlQ/WyAm8ouLIwuYM7HJ SY4EQRjuxQdBMch/7SuA9Qm5GsNqzOEOznQwoAd/OpSBgAopccJDR2vVKvnjZpzCIPzE EYCB9NJWEQSCnog/+8JtkwGwqGGRGS99oJhuNz/vZ05Y2oDSj4ZDYalMDnUKg3F+s9Bt vQVMP8y/X6jcd9lSWPVUbMmA8TCpA6ewpjwxsBPVU/RC+vuNLLm5K9M6KYKXEb9FXFpU suoQ== MIME-Version: 1.0 X-Received: by 10.107.132.220 with SMTP id o89mr21151215ioi.9.1425565774072; Thu, 05 Mar 2015 06:29:34 -0800 (PST) Received: by 10.107.18.67 with HTTP; Thu, 5 Mar 2015 06:29:33 -0800 (PST) In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 15:29:33 +0100 Message-ID: From: Albert Cabellos To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113ff96491526905108b651e Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:32:39 -0000 --001a113ff96491526905108b651e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thank you very much for your very valuable comments, you can find below how we plan to address them. Please let me know if the suggested text clarifies them or not. Albert On Tue, Mar 3, 2015 at 11:09 PM, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this document. It is really helpful to have a clear > introduction to LISP, and I appreciate the hard work that has gone into > producing this text. > > I have a small Discuss that is easily fixed. The essence is that you > should limit this document to a description of LISP and not try to use > it to bash other solutions. > > In Section 4.2 > > On the contrary BGP is a > push architecture, where the required network state is pushed by > means of BGP UPDATE messages to BGP speakers. > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode > protocol. > > (I won't say to you that LISP is push mode because a Map-Reply pushes > the mapping information from the map server to the client :-) > > So, my advice is to describe LISP in this document and to not make > comments about other systems. It isn't a beauty contest and it isn't > wise to try to say "my system is better/different from yours". > > The solution is to just remove this sentence. > > Agreed, I=C2=B4ll remove the first sentence. > Similarly in 7.1 > > BGP is the standard protocol to implement inter-domain routing. With > BGP, routing information are propagated along the network and each > autonomous system can implement its own routing policy that will > influence the way routing information are propagated. The direct > consequence is that an autonomous system cannot precisely control the > way the traffic will enter the network. > > As opposed to BGP, a LISP site can strictly impose via which ETRs the > traffic must enter the the LISP site network even though the path > followed to reach the ETR is not under the control of the LISP site. > > Let's not get into the "BGP this, BGP that" debate. Just remove the > first paragraph and the first four words of the second paragraph. That > way you avoid all contention and write a document about LISP. > > > Agreed, I=C2=B4ll remove the first paragraph and first four words of the se= cond paragraph. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a few questions and editorial nits I hope you will pick up as > additional polish. Some of the nits come from Deborah's review as AD > in-training > > --- > > Section 1 > > I'm really not comfortable with your text... "Indeed and as pointed out > by the unpublished Internet Draft by Noel Chiappa [Chiappa]" > > This isn't a stable reference and I don't think you need it. You could > either rely on the later reference to RFC 4984, reference RFC 6830 > itself, or take out the aside "and as... ... [Chiappa]" > > The same reference is cited in RFC4984 and RFC4423, it is preferable to cite it as it is or cite RFC4984? > --- > > Section 1 has > > LISP creates two separate namespaces, EIDs (End-host IDentifiers) and > RLOCs (Routing LOCators), both are typically syntactically identical > to the current IPv4 and IPv6 addresses. > > The "typically" here opens a bit of door. > > RFC 6830 explains this in the definitions of EID, but seems to be clear > that an RLOC is an IP address. > > If you are opening up the RLOC to be something other than an IP address > (a MAC address or even something else?) then how do you deal with: > - lack of ICMP > - non-uniqueness > > Possibly you can say that this is "not my problem" since the problem > would already exist in the routing system that handles the non-IP > addresses. But maybe, for an introduction to the topic this is over- > reaching towards the many potential applications rather than the basic > explanation of the architecture? > > But in your own definitions in Section 2, you have > > Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to > uniquely identify nodes irrespective of their topological location > and are typically routed intra-domain. > > Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned > topologically to network attachment points and typically routed > inter-domain. > > Neither of which offers any possiblitity to vary "always" into > "typically". > > The again, 3.2 has... > > EIDs are typically -but > not limited to- IPv4 or IPv6 addresses > > ...and... > > With LISP, the core uses RLOCs, an RLOC is typically -but not limited > to- an IPv4 or IPv6 address > > Some concistency is needed! > > In 3.4.1 you finally get there... > > Typical mappings in LISP bind EIDs in the form of IP prefixes with a > set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are > encoded using the appropriate Address Family Identifier (AFI) > [RFC3232]. However LISP can also support more general address > encoding by means of the ongoing effort around the LISP Canonical > Address Format (LCAF) [I-D.ietf-lisp-lcaf]. > > Why don't you talk about everything in terms of IP adresses and then add > a section somewhere near the end to talk about LCAF? > > Agreed, as you suggest I will state that EIDs and RLOCs are IP addresses, which basically means removing the word "typically". I also think that the text that you highlighted is sufficient to explain that LCAF supports more general address encoding. Please let me know if this addresses your comment. --- > > Section 1 introduces "overlay" and "underlay". I think that a certain > class of network engineer understands these concepts really well. And, > in my experience, another class has no idea what you are talking about! > > This would probably show very easily on a simple diagram showing the > overlay and underlay networks. > > But perhaps the summary in the Introduction is launching in a bit deep > nd fast? This is probably the hardest part of the document to write: > how do you summarise what you haven't yet talked about? There are some > bits, however, that really need work. For example... > > o EIDs have meaning only in the overlay network unless they are > leaked into the underlay network. The overlay is the > encapsulation relationship between LISP-capable routers. > Furthermore EIDs are not assigned from the reserved address > blocks. > > So they have meaning only in one place, unless they have meaning in more > than one place? :-) And what is a "resrved address block"? > > Thanks for your comment, I suggest rephrasing the bullet point in the following way: EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers. Then Section 3.2 mentions the EID leakage as well as its assignment. --- > > Section 3.2 > > With LISP, LISP sites (edge) and the core of the Internet are > interconnected by means of LISP-capable routers (e.g., border > routers) using tunnels. > > I don't think this is right. > > It is true that > LISP sites and the core of the Internet are interconnected by means > of LISP-capable routers > > But the tunnels connect those border routers. So you probably need... > > > LISP sites (at the edge of the Internet) are connected to the core > of the Internet by means of LISP-capable routers (e.g., border > routers). LISP sites are connected across the core of the Internet > using tunnels between the LISP-capable routers. > > Agreed. > --- > > Section 3.2 > > OLD > > A typically distributed database, called the Mapping System, stores > mappings between EIDs and RLOCs. > > NEW > > A database which is typically distributed, called the Mapping System, > stores mappings between EIDs and RLOCs. > > Agreed. --- > > 3.2 > > Such LISP capable routers, in most cases, only require a software > upgrade. > > That's a little disconcerting. Can you add to "in most cases"? > > What about? Adding LISP capabilities to routers does not mandate hardware changes and can be done via a software upgrade. --- > > 4.1 > > Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon > expiration of the TTL the ITR has to refresh the mapping by > sending a new Map-Request. Typical values for TTL defined by LISP > are 24 hours. > > Presumably it doesn't *have to*. It can choose to delete it and not > refresh it. Maybe this should be worded as MUST NOT use after the > expiration of the TTL. > > I would prefer to avoid using the word MUST since this document does not specify LISP. I suggest rephrasing the bullet point in the following way: Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR can't use the mapping until it is refreshed by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. --- > > > Section 5 says > > The separation between locators and identifiers in LISP was initially > proposed for traffic engineering purpose where LISP sites can change > their attachment points to the Internet (i.e., RLOCs) without > impacting endpoints or the Internet core. > > RFC 6830 says > > Creation of LISP was initially motivated by discussions during the > IAB-sponsored Routing and Addressing Workshop held in Amsterdam in > October 2006 (see [RFC4984]). > > RFC 4984 says > > The primary goal of > the workshop was to develop a shared understanding of the problems > that the large backbone operators are facing regarding the > scalability of today's Internet routing system. > > I conclude that Section 5 here is somewhat wrong. > > I suggest the following sentence: The separation between locators and identifiers in LISP was initially motivated by discussions during the IAB-sponsored Workshop, the outcomes are described in RFC4984. --- > > Section 7.1 > > "the possibility for a site to issue a different mapping for each > remote site, implementing so precise routing policies." > > Suggest "the possibility for a site to support a different mapping > policy for each remote site." > > Agreed. > --- > > I think some examination of the classification of normative and > informative references would be useful. > > For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think > that is fine because it is where to go for a definition of LISP+ALT. But > 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] > which turns out to be Informative. > > Agreed, I=C2=B4ll move the following references from Informative to Normati= ve. [I-D.ietf-lisp-ddt] [I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-sec] [I-D.ietf-lisp-threats] --- > > Appendix A > "The LISP system.." > Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." > > Agreed. > --- > > Appendix A > > "A small group of like-minded personnel from various scattered locations > within Cisco, spontaneously formed immediately after that workshop, to > work on an idea that came out of informal discussions at the workshop > and on various mailing lists." > > Suggest deleting this sentence (unless you want this to look like a > Cisco-only initiative). > > Agreed, thanks! > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a113ff96491526905108b651e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thank you very much for your very va= luable comments, you can find below how we plan to address them. Please let= me know if the suggested text clarifies them or not.

<= div>Albert

O= n Tue, Mar 3, 2015 at 11:09 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Adrian Farrel has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. It is really helpful to have a clear
introduction to LISP, and I appreciate the hard work that has gone into
producing this text.

I have a small Discuss that is easily fixed. The essence is that you
should limit this document to a description of LISP and not try to use
it to bash other solutions.

In Section 4.2

=C2=A0 =C2=A0On the contrary BGP is a
=C2=A0 =C2=A0push architecture, where the required network state is pushed = by
=C2=A0 =C2=A0means of BGP UPDATE messages to BGP speakers.

You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol.

(I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-)

So, my advice is to describe LISP in this document and to not make
comments about other systems. It isn't a beauty contest and it isn'= t
wise to try to say "my system is better/different from yours".
The solution is to just remove this sentence.


Agreed, I=C2=B4ll remove the first sen= tence.
=C2=A0
Similarly in 7.1

=C2=A0 =C2=A0BGP is the standard protocol to implement inter-domain routing= .=C2=A0 With
=C2=A0 =C2=A0BGP, routing information are propagated along the network and = each
=C2=A0 =C2=A0autonomous system can implement its own routing policy that wi= ll
=C2=A0 =C2=A0influence the way routing information are propagated.=C2=A0 Th= e direct
=C2=A0 =C2=A0consequence is that an autonomous system cannot precisely cont= rol the
=C2=A0 =C2=A0way the traffic will enter the network.

=C2=A0 =C2=A0As opposed to BGP, a LISP site can strictly impose via which E= TRs the
=C2=A0 =C2=A0traffic must enter the the LISP site network even though the p= ath
=C2=A0 =C2=A0followed to reach the ETR is not under the control of the LISP= site.

Let's not get into the "BGP this, BGP that" debate. Just remo= ve the
first paragraph and the first four words of the second paragraph. That
way you avoid all contention and write a document about LISP.



Agreed, I=C2=B4ll remove the first par= agraph and first four words of the second paragraph.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few questions and editorial nits I hope you will pick up as
additional polish. Some of the nits come from Deborah's review as AD in-training

---

Section 1

I'm really not comfortable with your text... "Indeed and as pointe= d out
by the unpublished Internet Draft by Noel Chiappa [Chiappa]"

This isn't a stable reference and I don't think you need it. You co= uld
either rely on the later reference to RFC 4984, reference RFC 6830
itself, or take out the aside "and as... ... [Chiappa]"


The same reference is cited in RFC4984= and RFC4423, it is preferable to cite it as it is or cite RFC4984?
=C2=A0
---

Section 1 has

=C2=A0 =C2=A0LISP creates two separate namespaces, EIDs (End-host IDentifie= rs) and
=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically ide= ntical
=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses.

The "typically" here opens a bit of door.

RFC 6830 explains this in the definitions of EID, but seems to be clear
that an RLOC is an IP address.

If you are opening up the RLOC to be something other than an IP address
(a MAC address or even something else?) then how do you deal with:
- lack of ICMP
- non-uniqueness

Possibly you can say that this is "not my problem" since the prob= lem
would already exist in the routing system that handles the non-IP
addresses. But maybe, for an introduction to the topic this is over-
reaching towards the many potential applications rather than the basic
explanation of the architecture?

But in your own definitions in Section 2, you have

=C2=A0 =C2=A0Endpoint IDentifier (EID):=C2=A0 EIDs are IPv4 or IPv6 address= es used to
=C2=A0 =C2=A0 =C2=A0 uniquely identify nodes irrespective of their topologi= cal location
=C2=A0 =C2=A0 =C2=A0 and are typically routed intra-domain.

=C2=A0 =C2=A0Routing LOcator (RLOC):=C2=A0 RLOCs are IPv4 or IPv6 addresses= assigned
=C2=A0 =C2=A0 =C2=A0 topologically to network attachment points and typical= ly routed
=C2=A0 =C2=A0 =C2=A0 inter-domain.

Neither of which offers any possiblitity to vary "always" into "typically".

The again, 3.2 has...

=C2=A0 =C2=A0EIDs are typically -but
=C2=A0 =C2=A0not limited to- IPv4 or IPv6 addresses

...and...

=C2=A0 =C2=A0With LISP, the core uses RLOCs, an RLOC is typically -but not = limited
=C2=A0 =C2=A0to- an IPv4 or IPv6 address

Some concistency is needed!

In 3.4.1 you finally get there...

=C2=A0 =C2=A0Typical mappings in LISP bind EIDs in the form of IP prefixes = with a
=C2=A0 =C2=A0set of RLOCs, also in the form of IPs.=C2=A0 IPv4 and IPv6 add= resses are
=C2=A0 =C2=A0encoded using the appropriate Address Family Identifier (AFI)<= br> =C2=A0 =C2=A0[RFC3232].=C2=A0 However LISP can also support more general ad= dress
=C2=A0 =C2=A0encoding by means of the ongoing effort around the LISP Canoni= cal
=C2=A0 =C2=A0Address Format (LCAF) [I-D.ietf-lisp-lcaf].

Why don't you talk about everything in terms of IP adresses and then ad= d
a section somewhere near the end to talk about LCAF?


Agreed, as you suggest I will state th= at EIDs = and RLOCs are IP= addresses, which basically means removing the word "typically".= =C2=A0

I also think that the text that you highlig= hted is sufficient to explain that LCAF supports more general address encoding. Ple= ase let me know if this addresses your comment.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> ---

Section 1 introduces "overlay" and "underlay". I think = that a certain
class of network engineer understands these concepts really well. And,
in my experience, another class has no idea what you are talking about!

This would probably show very easily on a simple diagram showing the
overlay and underlay networks.

But perhaps the summary in the Introduction is launching in a bit deep
nd fast? This is probably the hardest part of the document to write:
how do you summarise what you haven't yet talked about? There are some<= br> bits, however, that really need work. For example...

=C2=A0 =C2=A0o=C2=A0 EIDs have meaning only in the overlay network unless t= hey are
=C2=A0 =C2=A0 =C2=A0 leaked into the underlay network.=C2=A0 The overlay is= the
=C2=A0 =C2=A0 =C2=A0 encapsulation relationship between LISP-capable router= s.
=C2=A0 =C2=A0 =C2=A0 Furthermore EIDs are not assigned from the reserved ad= dress
=C2=A0 =C2=A0 =C2=A0 blocks.

So they have meaning only in one place, unless they have meaning in more than one place? :-)=C2=A0 =C2=A0And what is a "resrved address block&q= uot;?


Thanks for your comment, I suggest rep= hrasing the bullet point in the following way:

EIDs have m= eaning only in the overlay network, which is the encapsulation relationship= between LISP-capable routers.

Then Section 3.2 me= ntions the EID<= /span> leakage as well as its assignment.=C2=A0

---

Section 3.2

=C2=A0 =C2=A0With LISP, LISP sites (edge) and the core of the Internet are<= br> =C2=A0 =C2=A0interconnected by means of LISP-capable routers (e.g., border<= br> =C2=A0 =C2=A0routers) using tunnels.

I don't think this is right.

It is true that
=C2=A0 LISP sites and the core of the Internet are interconnected by means<= br> =C2=A0 of LISP-capable routers

But the tunnels connect those border routers. So you probably need...


=C2=A0 =C2=A0LISP sites (at the edge of the Internet) are connected to the = core
=C2=A0 =C2=A0of the Internet by means of LISP-capable routers (e.g., border=
=C2=A0 =C2=A0routers).=C2=A0 LISP sites are connected across the core of th= e Internet
=C2=A0 =C2=A0using tunnels between the LISP-capable routers.


Agreed.
=C2=A0
---

Section 3.2

OLD

=C2=A0 =C2=A0A typically distributed database, called the Mapping System, s= tores
=C2=A0 =C2=A0mappings between EIDs and RLOCs.

NEW

=C2=A0 =C2=A0A database which is typically distributed, called the Mapping = System,
=C2=A0 =C2=A0stores mappings between EIDs and RLOCs.

=C2=A0
Agreed.

---

3.2

=C2=A0 =C2=A0Such LISP capable routers, in most cases, only require a softw= are
=C2=A0 =C2=A0upgrade.

That's a little disconcerting. Can you add to "in most cases"= ?


What about?

A= dding LISP capabilities to routers does not mandate hardware changes and ca= n be done via a software upgrade.=C2=A0

---

4.1

=C2=A0 =C2=A0Time-To-Live (TTL):=C2=A0 Each mapping contains a TTL set by t= he ETR, upon
=C2=A0 =C2=A0 =C2=A0 expiration of the TTL the ITR has to refresh the mappi= ng by
=C2=A0 =C2=A0 =C2=A0 sending a new Map-Request.=C2=A0 Typical values for TT= L defined by LISP
=C2=A0 =C2=A0 =C2=A0 are 24 hours.

Presumably it doesn't *have to*. It can choose to delete it and not
refresh it. Maybe this should be worded as MUST NOT use after the
expiration of the TTL.


I would prefer to avoid using the word= MUST since this document does not specify LISP. I suggest rephrasing the b= ullet point in the following way:

Time-To-Live (TTL): =C2= =A0Each mapping contains a TTL set by the ETR, upon
=C2=A0 =C2=A0 =C2=A0 expi= ration of the TTL the ITR can't use the mapping until it is refreshed by=C2=A0
<= div>=C2=A0 =C2=A0 =C2=A0 sending a new Map-Request.=C2=A0 Typical values fo= r TTL d= efined by LISP
=C2=A0 =C2=A0 =C2=A0 are 24 hours.=C2=A0

---


Section 5 says

=C2=A0 =C2=A0The separation between locators and identifiers in LISP was in= itially
=C2=A0 =C2=A0proposed for traffic engineering purpose where LISP sites can = change
=C2=A0 =C2=A0their attachment points to the Internet (i.e., RLOCs) without<= br> =C2=A0 =C2=A0impacting endpoints or the Internet core.

RFC 6830 says

=C2=A0 =C2=A0Creation of LISP was initially motivated by discussions during= the
=C2=A0 =C2=A0IAB-sponsored Routing and Addressing Workshop held in Amsterda= m in
=C2=A0 =C2=A0October 2006 (see [RFC4984]).

RFC 4984 says

=C2=A0 =C2=A0The primary goal of
=C2=A0 =C2=A0the workshop was to develop a shared understanding of the prob= lems
=C2=A0 =C2=A0that the large backbone operators are facing regarding the
=C2=A0 =C2=A0scalability of today's Internet routing system.

I conclude that Section 5 here is somewhat wrong.


I suggest the following sentence:

The separation between locators and identifiers in LISP was i= nitially
motivated by discussions during the IAB-sponsored Workshop, the= outcomes are=C2=A0
described in RFC4984.=C2=A0

---

Section 7.1

"the possibility for a site to issue a different mapping for each
=C2=A0 =C2=A0remote site, implementing so precise routing policies."
Suggest "the possibility for a site to support a different mapping
policy for each remote site."


Agreed.
=C2=A0
---

I think some examination of the classification of normative and
informative references would be useful.

For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think
that is fine because it is where to go for a definition of LISP+ALT. But 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt]
which turns out to be Informative.


Agreed, I=C2=B4ll move the following r= eferences from Informative to Normative.
[I-D.ietf-lisp-ddt]
[I-D.<= span>ietf-lis= p-lcaf]=
[I-D.ietf<= /span>-lisp-sec]
[I-D.ietf-lisp-threats]=C2=A0

---

Appendix A
"The LISP system.."
Haven't seen a "LISP system" defined. Suggest "The LISP = architecture.."


Agreed.
=C2=A0
---

Appendix A

"A small group of like-minded personnel from various scattered locatio= ns
within Cisco, spontaneously formed immediately after that workshop, to
work on an idea that came out of informal discussions at the workshop
and on various mailing lists."

Suggest deleting this sentence (unless you want this to look like a
Cisco-only initiative).


Agreed, thanks!
=C2=A0
=

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

--001a113ff96491526905108b651e-- From nobody Thu Mar 5 06:32:44 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2983E1A0039; Thu, 5 Mar 2015 06:32:39 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5D1A002C; Thu, 5 Mar 2015 06:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXLVupgchRbV; Thu, 5 Mar 2015 06:32:34 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9565A1A000A; Thu, 5 Mar 2015 06:29:34 -0800 (PST) Received: by igbhl2 with SMTP id hl2so46050178igb.3; Thu, 05 Mar 2015 06:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8/VetyPx8rqkd7jNmIcv067QLuRBEsWdam4Q0ZM5TMs=; b=m1nkgUfSR1BvaoEK6Ky+KBZY4VJD1r4QST6nvbacWh9DX3E7rwTTuOcF3Hj9uNCCji LRtctukc55Q3UQsEsY+Zj0HI4WBuMp2D5ZOuP94hax0TzyBMFlQ/WyAm8ouLIwuYM7HJ SY4EQRjuxQdBMch/7SuA9Qm5GsNqzOEOznQwoAd/OpSBgAopccJDR2vVKvnjZpzCIPzE EYCB9NJWEQSCnog/+8JtkwGwqGGRGS99oJhuNz/vZ05Y2oDSj4ZDYalMDnUKg3F+s9Bt vQVMP8y/X6jcd9lSWPVUbMmA8TCpA6ewpjwxsBPVU/RC+vuNLLm5K9M6KYKXEb9FXFpU suoQ== MIME-Version: 1.0 X-Received: by 10.107.132.220 with SMTP id o89mr21151215ioi.9.1425565774072; Thu, 05 Mar 2015 06:29:34 -0800 (PST) Received: by 10.107.18.67 with HTTP; Thu, 5 Mar 2015 06:29:33 -0800 (PST) In-Reply-To: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 15:29:33 +0100 Message-ID: From: Albert Cabellos To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113ff96491526905108b651e Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:32:39 -0000 --001a113ff96491526905108b651e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thank you very much for your very valuable comments, you can find below how we plan to address them. Please let me know if the suggested text clarifies them or not. Albert On Tue, Mar 3, 2015 at 11:09 PM, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this document. It is really helpful to have a clear > introduction to LISP, and I appreciate the hard work that has gone into > producing this text. > > I have a small Discuss that is easily fixed. The essence is that you > should limit this document to a description of LISP and not try to use > it to bash other solutions. > > In Section 4.2 > > On the contrary BGP is a > push architecture, where the required network state is pushed by > means of BGP UPDATE messages to BGP speakers. > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode > protocol. > > (I won't say to you that LISP is push mode because a Map-Reply pushes > the mapping information from the map server to the client :-) > > So, my advice is to describe LISP in this document and to not make > comments about other systems. It isn't a beauty contest and it isn't > wise to try to say "my system is better/different from yours". > > The solution is to just remove this sentence. > > Agreed, I=C2=B4ll remove the first sentence. > Similarly in 7.1 > > BGP is the standard protocol to implement inter-domain routing. With > BGP, routing information are propagated along the network and each > autonomous system can implement its own routing policy that will > influence the way routing information are propagated. The direct > consequence is that an autonomous system cannot precisely control the > way the traffic will enter the network. > > As opposed to BGP, a LISP site can strictly impose via which ETRs the > traffic must enter the the LISP site network even though the path > followed to reach the ETR is not under the control of the LISP site. > > Let's not get into the "BGP this, BGP that" debate. Just remove the > first paragraph and the first four words of the second paragraph. That > way you avoid all contention and write a document about LISP. > > > Agreed, I=C2=B4ll remove the first paragraph and first four words of the se= cond paragraph. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a few questions and editorial nits I hope you will pick up as > additional polish. Some of the nits come from Deborah's review as AD > in-training > > --- > > Section 1 > > I'm really not comfortable with your text... "Indeed and as pointed out > by the unpublished Internet Draft by Noel Chiappa [Chiappa]" > > This isn't a stable reference and I don't think you need it. You could > either rely on the later reference to RFC 4984, reference RFC 6830 > itself, or take out the aside "and as... ... [Chiappa]" > > The same reference is cited in RFC4984 and RFC4423, it is preferable to cite it as it is or cite RFC4984? > --- > > Section 1 has > > LISP creates two separate namespaces, EIDs (End-host IDentifiers) and > RLOCs (Routing LOCators), both are typically syntactically identical > to the current IPv4 and IPv6 addresses. > > The "typically" here opens a bit of door. > > RFC 6830 explains this in the definitions of EID, but seems to be clear > that an RLOC is an IP address. > > If you are opening up the RLOC to be something other than an IP address > (a MAC address or even something else?) then how do you deal with: > - lack of ICMP > - non-uniqueness > > Possibly you can say that this is "not my problem" since the problem > would already exist in the routing system that handles the non-IP > addresses. But maybe, for an introduction to the topic this is over- > reaching towards the many potential applications rather than the basic > explanation of the architecture? > > But in your own definitions in Section 2, you have > > Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to > uniquely identify nodes irrespective of their topological location > and are typically routed intra-domain. > > Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned > topologically to network attachment points and typically routed > inter-domain. > > Neither of which offers any possiblitity to vary "always" into > "typically". > > The again, 3.2 has... > > EIDs are typically -but > not limited to- IPv4 or IPv6 addresses > > ...and... > > With LISP, the core uses RLOCs, an RLOC is typically -but not limited > to- an IPv4 or IPv6 address > > Some concistency is needed! > > In 3.4.1 you finally get there... > > Typical mappings in LISP bind EIDs in the form of IP prefixes with a > set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are > encoded using the appropriate Address Family Identifier (AFI) > [RFC3232]. However LISP can also support more general address > encoding by means of the ongoing effort around the LISP Canonical > Address Format (LCAF) [I-D.ietf-lisp-lcaf]. > > Why don't you talk about everything in terms of IP adresses and then add > a section somewhere near the end to talk about LCAF? > > Agreed, as you suggest I will state that EIDs and RLOCs are IP addresses, which basically means removing the word "typically". I also think that the text that you highlighted is sufficient to explain that LCAF supports more general address encoding. Please let me know if this addresses your comment. --- > > Section 1 introduces "overlay" and "underlay". I think that a certain > class of network engineer understands these concepts really well. And, > in my experience, another class has no idea what you are talking about! > > This would probably show very easily on a simple diagram showing the > overlay and underlay networks. > > But perhaps the summary in the Introduction is launching in a bit deep > nd fast? This is probably the hardest part of the document to write: > how do you summarise what you haven't yet talked about? There are some > bits, however, that really need work. For example... > > o EIDs have meaning only in the overlay network unless they are > leaked into the underlay network. The overlay is the > encapsulation relationship between LISP-capable routers. > Furthermore EIDs are not assigned from the reserved address > blocks. > > So they have meaning only in one place, unless they have meaning in more > than one place? :-) And what is a "resrved address block"? > > Thanks for your comment, I suggest rephrasing the bullet point in the following way: EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers. Then Section 3.2 mentions the EID leakage as well as its assignment. --- > > Section 3.2 > > With LISP, LISP sites (edge) and the core of the Internet are > interconnected by means of LISP-capable routers (e.g., border > routers) using tunnels. > > I don't think this is right. > > It is true that > LISP sites and the core of the Internet are interconnected by means > of LISP-capable routers > > But the tunnels connect those border routers. So you probably need... > > > LISP sites (at the edge of the Internet) are connected to the core > of the Internet by means of LISP-capable routers (e.g., border > routers). LISP sites are connected across the core of the Internet > using tunnels between the LISP-capable routers. > > Agreed. > --- > > Section 3.2 > > OLD > > A typically distributed database, called the Mapping System, stores > mappings between EIDs and RLOCs. > > NEW > > A database which is typically distributed, called the Mapping System, > stores mappings between EIDs and RLOCs. > > Agreed. --- > > 3.2 > > Such LISP capable routers, in most cases, only require a software > upgrade. > > That's a little disconcerting. Can you add to "in most cases"? > > What about? Adding LISP capabilities to routers does not mandate hardware changes and can be done via a software upgrade. --- > > 4.1 > > Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon > expiration of the TTL the ITR has to refresh the mapping by > sending a new Map-Request. Typical values for TTL defined by LISP > are 24 hours. > > Presumably it doesn't *have to*. It can choose to delete it and not > refresh it. Maybe this should be worded as MUST NOT use after the > expiration of the TTL. > > I would prefer to avoid using the word MUST since this document does not specify LISP. I suggest rephrasing the bullet point in the following way: Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR can't use the mapping until it is refreshed by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. --- > > > Section 5 says > > The separation between locators and identifiers in LISP was initially > proposed for traffic engineering purpose where LISP sites can change > their attachment points to the Internet (i.e., RLOCs) without > impacting endpoints or the Internet core. > > RFC 6830 says > > Creation of LISP was initially motivated by discussions during the > IAB-sponsored Routing and Addressing Workshop held in Amsterdam in > October 2006 (see [RFC4984]). > > RFC 4984 says > > The primary goal of > the workshop was to develop a shared understanding of the problems > that the large backbone operators are facing regarding the > scalability of today's Internet routing system. > > I conclude that Section 5 here is somewhat wrong. > > I suggest the following sentence: The separation between locators and identifiers in LISP was initially motivated by discussions during the IAB-sponsored Workshop, the outcomes are described in RFC4984. --- > > Section 7.1 > > "the possibility for a site to issue a different mapping for each > remote site, implementing so precise routing policies." > > Suggest "the possibility for a site to support a different mapping > policy for each remote site." > > Agreed. > --- > > I think some examination of the classification of normative and > informative references would be useful. > > For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think > that is fine because it is where to go for a definition of LISP+ALT. But > 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] > which turns out to be Informative. > > Agreed, I=C2=B4ll move the following references from Informative to Normati= ve. [I-D.ietf-lisp-ddt] [I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-sec] [I-D.ietf-lisp-threats] --- > > Appendix A > "The LISP system.." > Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." > > Agreed. > --- > > Appendix A > > "A small group of like-minded personnel from various scattered locations > within Cisco, spontaneously formed immediately after that workshop, to > work on an idea that came out of informal discussions at the workshop > and on various mailing lists." > > Suggest deleting this sentence (unless you want this to look like a > Cisco-only initiative). > > Agreed, thanks! > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --001a113ff96491526905108b651e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thank you very much for your very va= luable comments, you can find below how we plan to address them. Please let= me know if the suggested text clarifies them or not.

<= div>Albert

O= n Tue, Mar 3, 2015 at 11:09 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Adrian Farrel has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. It is really helpful to have a clear
introduction to LISP, and I appreciate the hard work that has gone into
producing this text.

I have a small Discuss that is easily fixed. The essence is that you
should limit this document to a description of LISP and not try to use
it to bash other solutions.

In Section 4.2

=C2=A0 =C2=A0On the contrary BGP is a
=C2=A0 =C2=A0push architecture, where the required network state is pushed = by
=C2=A0 =C2=A0means of BGP UPDATE messages to BGP speakers.

You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol.

(I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-)

So, my advice is to describe LISP in this document and to not make
comments about other systems. It isn't a beauty contest and it isn'= t
wise to try to say "my system is better/different from yours".
The solution is to just remove this sentence.


Agreed, I=C2=B4ll remove the first sen= tence.
=C2=A0
Similarly in 7.1

=C2=A0 =C2=A0BGP is the standard protocol to implement inter-domain routing= .=C2=A0 With
=C2=A0 =C2=A0BGP, routing information are propagated along the network and = each
=C2=A0 =C2=A0autonomous system can implement its own routing policy that wi= ll
=C2=A0 =C2=A0influence the way routing information are propagated.=C2=A0 Th= e direct
=C2=A0 =C2=A0consequence is that an autonomous system cannot precisely cont= rol the
=C2=A0 =C2=A0way the traffic will enter the network.

=C2=A0 =C2=A0As opposed to BGP, a LISP site can strictly impose via which E= TRs the
=C2=A0 =C2=A0traffic must enter the the LISP site network even though the p= ath
=C2=A0 =C2=A0followed to reach the ETR is not under the control of the LISP= site.

Let's not get into the "BGP this, BGP that" debate. Just remo= ve the
first paragraph and the first four words of the second paragraph. That
way you avoid all contention and write a document about LISP.



Agreed, I=C2=B4ll remove the first par= agraph and first four words of the second paragraph.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few questions and editorial nits I hope you will pick up as
additional polish. Some of the nits come from Deborah's review as AD in-training

---

Section 1

I'm really not comfortable with your text... "Indeed and as pointe= d out
by the unpublished Internet Draft by Noel Chiappa [Chiappa]"

This isn't a stable reference and I don't think you need it. You co= uld
either rely on the later reference to RFC 4984, reference RFC 6830
itself, or take out the aside "and as... ... [Chiappa]"


The same reference is cited in RFC4984= and RFC4423, it is preferable to cite it as it is or cite RFC4984?
=C2=A0
---

Section 1 has

=C2=A0 =C2=A0LISP creates two separate namespaces, EIDs (End-host IDentifie= rs) and
=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically ide= ntical
=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses.

The "typically" here opens a bit of door.

RFC 6830 explains this in the definitions of EID, but seems to be clear
that an RLOC is an IP address.

If you are opening up the RLOC to be something other than an IP address
(a MAC address or even something else?) then how do you deal with:
- lack of ICMP
- non-uniqueness

Possibly you can say that this is "not my problem" since the prob= lem
would already exist in the routing system that handles the non-IP
addresses. But maybe, for an introduction to the topic this is over-
reaching towards the many potential applications rather than the basic
explanation of the architecture?

But in your own definitions in Section 2, you have

=C2=A0 =C2=A0Endpoint IDentifier (EID):=C2=A0 EIDs are IPv4 or IPv6 address= es used to
=C2=A0 =C2=A0 =C2=A0 uniquely identify nodes irrespective of their topologi= cal location
=C2=A0 =C2=A0 =C2=A0 and are typically routed intra-domain.

=C2=A0 =C2=A0Routing LOcator (RLOC):=C2=A0 RLOCs are IPv4 or IPv6 addresses= assigned
=C2=A0 =C2=A0 =C2=A0 topologically to network attachment points and typical= ly routed
=C2=A0 =C2=A0 =C2=A0 inter-domain.

Neither of which offers any possiblitity to vary "always" into "typically".

The again, 3.2 has...

=C2=A0 =C2=A0EIDs are typically -but
=C2=A0 =C2=A0not limited to- IPv4 or IPv6 addresses

...and...

=C2=A0 =C2=A0With LISP, the core uses RLOCs, an RLOC is typically -but not = limited
=C2=A0 =C2=A0to- an IPv4 or IPv6 address

Some concistency is needed!

In 3.4.1 you finally get there...

=C2=A0 =C2=A0Typical mappings in LISP bind EIDs in the form of IP prefixes = with a
=C2=A0 =C2=A0set of RLOCs, also in the form of IPs.=C2=A0 IPv4 and IPv6 add= resses are
=C2=A0 =C2=A0encoded using the appropriate Address Family Identifier (AFI)<= br> =C2=A0 =C2=A0[RFC3232].=C2=A0 However LISP can also support more general ad= dress
=C2=A0 =C2=A0encoding by means of the ongoing effort around the LISP Canoni= cal
=C2=A0 =C2=A0Address Format (LCAF) [I-D.ietf-lisp-lcaf].

Why don't you talk about everything in terms of IP adresses and then ad= d
a section somewhere near the end to talk about LCAF?


Agreed, as you suggest I will state th= at EIDs = and RLOCs are IP= addresses, which basically means removing the word "typically".= =C2=A0

I also think that the text that you highlig= hted is sufficient to explain that LCAF supports more general address encoding. Ple= ase let me know if this addresses your comment.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> ---

Section 1 introduces "overlay" and "underlay". I think = that a certain
class of network engineer understands these concepts really well. And,
in my experience, another class has no idea what you are talking about!

This would probably show very easily on a simple diagram showing the
overlay and underlay networks.

But perhaps the summary in the Introduction is launching in a bit deep
nd fast? This is probably the hardest part of the document to write:
how do you summarise what you haven't yet talked about? There are some<= br> bits, however, that really need work. For example...

=C2=A0 =C2=A0o=C2=A0 EIDs have meaning only in the overlay network unless t= hey are
=C2=A0 =C2=A0 =C2=A0 leaked into the underlay network.=C2=A0 The overlay is= the
=C2=A0 =C2=A0 =C2=A0 encapsulation relationship between LISP-capable router= s.
=C2=A0 =C2=A0 =C2=A0 Furthermore EIDs are not assigned from the reserved ad= dress
=C2=A0 =C2=A0 =C2=A0 blocks.

So they have meaning only in one place, unless they have meaning in more than one place? :-)=C2=A0 =C2=A0And what is a "resrved address block&q= uot;?


Thanks for your comment, I suggest rep= hrasing the bullet point in the following way:

EIDs have m= eaning only in the overlay network, which is the encapsulation relationship= between LISP-capable routers.

Then Section 3.2 me= ntions the EID<= /span> leakage as well as its assignment.=C2=A0

---

Section 3.2

=C2=A0 =C2=A0With LISP, LISP sites (edge) and the core of the Internet are<= br> =C2=A0 =C2=A0interconnected by means of LISP-capable routers (e.g., border<= br> =C2=A0 =C2=A0routers) using tunnels.

I don't think this is right.

It is true that
=C2=A0 LISP sites and the core of the Internet are interconnected by means<= br> =C2=A0 of LISP-capable routers

But the tunnels connect those border routers. So you probably need...


=C2=A0 =C2=A0LISP sites (at the edge of the Internet) are connected to the = core
=C2=A0 =C2=A0of the Internet by means of LISP-capable routers (e.g., border=
=C2=A0 =C2=A0routers).=C2=A0 LISP sites are connected across the core of th= e Internet
=C2=A0 =C2=A0using tunnels between the LISP-capable routers.


Agreed.
=C2=A0
---

Section 3.2

OLD

=C2=A0 =C2=A0A typically distributed database, called the Mapping System, s= tores
=C2=A0 =C2=A0mappings between EIDs and RLOCs.

NEW

=C2=A0 =C2=A0A database which is typically distributed, called the Mapping = System,
=C2=A0 =C2=A0stores mappings between EIDs and RLOCs.

=C2=A0
Agreed.

---

3.2

=C2=A0 =C2=A0Such LISP capable routers, in most cases, only require a softw= are
=C2=A0 =C2=A0upgrade.

That's a little disconcerting. Can you add to "in most cases"= ?


What about?

A= dding LISP capabilities to routers does not mandate hardware changes and ca= n be done via a software upgrade.=C2=A0

---

4.1

=C2=A0 =C2=A0Time-To-Live (TTL):=C2=A0 Each mapping contains a TTL set by t= he ETR, upon
=C2=A0 =C2=A0 =C2=A0 expiration of the TTL the ITR has to refresh the mappi= ng by
=C2=A0 =C2=A0 =C2=A0 sending a new Map-Request.=C2=A0 Typical values for TT= L defined by LISP
=C2=A0 =C2=A0 =C2=A0 are 24 hours.

Presumably it doesn't *have to*. It can choose to delete it and not
refresh it. Maybe this should be worded as MUST NOT use after the
expiration of the TTL.


I would prefer to avoid using the word= MUST since this document does not specify LISP. I suggest rephrasing the b= ullet point in the following way:

Time-To-Live (TTL): =C2= =A0Each mapping contains a TTL set by the ETR, upon
=C2=A0 =C2=A0 =C2=A0 expi= ration of the TTL the ITR can't use the mapping until it is refreshed by=C2=A0
<= div>=C2=A0 =C2=A0 =C2=A0 sending a new Map-Request.=C2=A0 Typical values fo= r TTL d= efined by LISP
=C2=A0 =C2=A0 =C2=A0 are 24 hours.=C2=A0

---


Section 5 says

=C2=A0 =C2=A0The separation between locators and identifiers in LISP was in= itially
=C2=A0 =C2=A0proposed for traffic engineering purpose where LISP sites can = change
=C2=A0 =C2=A0their attachment points to the Internet (i.e., RLOCs) without<= br> =C2=A0 =C2=A0impacting endpoints or the Internet core.

RFC 6830 says

=C2=A0 =C2=A0Creation of LISP was initially motivated by discussions during= the
=C2=A0 =C2=A0IAB-sponsored Routing and Addressing Workshop held in Amsterda= m in
=C2=A0 =C2=A0October 2006 (see [RFC4984]).

RFC 4984 says

=C2=A0 =C2=A0The primary goal of
=C2=A0 =C2=A0the workshop was to develop a shared understanding of the prob= lems
=C2=A0 =C2=A0that the large backbone operators are facing regarding the
=C2=A0 =C2=A0scalability of today's Internet routing system.

I conclude that Section 5 here is somewhat wrong.


I suggest the following sentence:

The separation between locators and identifiers in LISP was i= nitially
motivated by discussions during the IAB-sponsored Workshop, the= outcomes are=C2=A0
described in RFC4984.=C2=A0

---

Section 7.1

"the possibility for a site to issue a different mapping for each
=C2=A0 =C2=A0remote site, implementing so precise routing policies."
Suggest "the possibility for a site to support a different mapping
policy for each remote site."


Agreed.
=C2=A0
---

I think some examination of the classification of normative and
informative references would be useful.

For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think
that is fine because it is where to go for a definition of LISP+ALT. But 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt]
which turns out to be Informative.


Agreed, I=C2=B4ll move the following r= eferences from Informative to Normative.
[I-D.ietf-lisp-ddt]
[I-D.<= span>ietf-lis= p-lcaf]=
[I-D.ietf<= /span>-lisp-sec]
[I-D.ietf-lisp-threats]=C2=A0

---

Appendix A
"The LISP system.."
Haven't seen a "LISP system" defined. Suggest "The LISP = architecture.."


Agreed.
=C2=A0
---

Appendix A

"A small group of like-minded personnel from various scattered locatio= ns
within Cisco, spontaneously formed immediately after that workshop, to
work on an idea that came out of informal discussions at the workshop
and on various mailing lists."

Suggest deleting this sentence (unless you want this to look like a
Cisco-only initiative).


Agreed, thanks!
=C2=A0
=

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

--001a113ff96491526905108b651e-- From nobody Thu Mar 5 06:41:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE41A000B; Thu, 5 Mar 2015 06:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-N5dgWpdo_m; Thu, 5 Mar 2015 06:41:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F26E1A0069; Thu, 5 Mar 2015 06:38:38 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 398D28813F; Thu, 5 Mar 2015 06:38:38 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5374E136825A; Thu, 5 Mar 2015 06:38:37 -0800 (PST) Message-ID: <54F86A66.7010709@innovationslab.net> Date: Thu, 05 Mar 2015 09:38:30 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Albert Cabellos , Adrian Farrel References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:41:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert, On 3/5/15 9:29 AM, Albert Cabellos wrote: >> Section 1 >> >> I'm really not comfortable with your text... "Indeed and as pointed ou= t >> by the unpublished Internet Draft by Noel Chiappa [Chiappa]" >> >> This isn't a stable reference and I don't think you need it. You could= >> either rely on the later reference to RFC 4984, reference RFC 6830 >> itself, or take out the aside "and as... ... [Chiappa]" >> >> > The same reference is cited in RFC4984 and RFC4423, it is preferable to= > cite it as it is or cite RFC4984? >=20 My personal opinion is that RFC 4984 would be a perfectly reasonable reference for this. Regards, Brian --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU+GpsAAoJEBOZRqCi7goqimcH/3lFn+JTHjzXU7oLLqZnDD2K 2/xjJQxnWARJSQTUlAhPxoj+2I3NiCN/XM0Qg5FOeyfjVtk5VW3cl+tMc+QxjHaL v/UTtDOhPvZ65TePfeQGAFEPddGccqg95vRAsFvnwDJm7pCJrH5PQ1bi7jrERA3c dmPIUGkCbyvhsK9WkTey9MVH8+gWrRBzhgO/k+PIdQNtauwj1F8B543ciBn27aHf CqkM5GSEFFZOp7y6m409LHMQ+RBQNkQffsygagtsGeRvA++0Q+duGdcGZFdZ4x9P KcApbEt8RmojmWV0EAV8LMdirZn7zk6/FfUk+8ZgYdqxPTbO7QIowKB14h2mjk8= =SmM6 -----END PGP SIGNATURE----- --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2-- From nobody Thu Mar 5 06:41:57 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8269A1A0015; Thu, 5 Mar 2015 06:41:50 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE41A000B; Thu, 5 Mar 2015 06:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-N5dgWpdo_m; Thu, 5 Mar 2015 06:41:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F26E1A0069; Thu, 5 Mar 2015 06:38:38 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 398D28813F; Thu, 5 Mar 2015 06:38:38 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5374E136825A; Thu, 5 Mar 2015 06:38:37 -0800 (PST) Message-ID: <54F86A66.7010709@innovationslab.net> Date: Thu, 05 Mar 2015 09:38:30 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Albert Cabellos , Adrian Farrel References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:41:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert, On 3/5/15 9:29 AM, Albert Cabellos wrote: >> Section 1 >> >> I'm really not comfortable with your text... "Indeed and as pointed ou= t >> by the unpublished Internet Draft by Noel Chiappa [Chiappa]" >> >> This isn't a stable reference and I don't think you need it. You could= >> either rely on the later reference to RFC 4984, reference RFC 6830 >> itself, or take out the aside "and as... ... [Chiappa]" >> >> > The same reference is cited in RFC4984 and RFC4423, it is preferable to= > cite it as it is or cite RFC4984? >=20 My personal opinion is that RFC 4984 would be a perfectly reasonable reference for this. Regards, Brian --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU+GpsAAoJEBOZRqCi7goqimcH/3lFn+JTHjzXU7oLLqZnDD2K 2/xjJQxnWARJSQTUlAhPxoj+2I3NiCN/XM0Qg5FOeyfjVtk5VW3cl+tMc+QxjHaL v/UTtDOhPvZ65TePfeQGAFEPddGccqg95vRAsFvnwDJm7pCJrH5PQ1bi7jrERA3c dmPIUGkCbyvhsK9WkTey9MVH8+gWrRBzhgO/k+PIdQNtauwj1F8B543ciBn27aHf CqkM5GSEFFZOp7y6m409LHMQ+RBQNkQffsygagtsGeRvA++0Q+duGdcGZFdZ4x9P KcApbEt8RmojmWV0EAV8LMdirZn7zk6/FfUk+8ZgYdqxPTbO7QIowKB14h2mjk8= =SmM6 -----END PGP SIGNATURE----- --bnLlqa1JoLJJCnH0wP1RjvlWdSRl09Ai2-- From nobody Thu Mar 5 07:15:51 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ACF1A0334; Thu, 5 Mar 2015 07:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5TPYrq_EQbx; Thu, 5 Mar 2015 07:15:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5C1A0430; Thu, 5 Mar 2015 07:14:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:14:07 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:15:50 -0000 Alia Atlas has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most cases, only require a software upgrade." or explain how you can justify the need to add and remove new encapsulations and handle the various flag triggers and caching at line rate. There is no need for such marketing in this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses." What does "typically" mean? As far as I'm aware, they are syntactically identical. This is reiterated in Sec 3.2; are you just trying to preserve the point of architectural freedom? I've found the third instance of insisting that the EID or RLOC now is only "typically" an IPv4 or IPv6 address. Please lose "typically". Minorly, the , before both should be a ;. 2) top paragraph of p.4: "The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP is completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System." Instead of "LISP is completely deployed" to "LISP were to be completely deployed" - making it subjunctive. 3) Last paragraph in Sec 1: "This document describes the LISP architecture, its main operational mechanisms as its design rationale." I think you mean "This document describes the LISP architecture and its main operational mechanisms as well as its design rationale." 4) In Sec 3.1, second paragraph: "Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale." I assume that you mean "topologically meaningful addresses" instead of "identity meaningful addresses". From nobody Thu Mar 5 07:15:54 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 495531A0389; Thu, 5 Mar 2015 07:15:50 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ACF1A0334; Thu, 5 Mar 2015 07:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5TPYrq_EQbx; Thu, 5 Mar 2015 07:15:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5C1A0430; Thu, 5 Mar 2015 07:14:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:14:07 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:15:50 -0000 Alia Atlas has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most cases, only require a software upgrade." or explain how you can justify the need to add and remove new encapsulations and handle the various flag triggers and caching at line rate. There is no need for such marketing in this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses." What does "typically" mean? As far as I'm aware, they are syntactically identical. This is reiterated in Sec 3.2; are you just trying to preserve the point of architectural freedom? I've found the third instance of insisting that the EID or RLOC now is only "typically" an IPv4 or IPv6 address. Please lose "typically". Minorly, the , before both should be a ;. 2) top paragraph of p.4: "The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP is completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System." Instead of "LISP is completely deployed" to "LISP were to be completely deployed" - making it subjunctive. 3) Last paragraph in Sec 1: "This document describes the LISP architecture, its main operational mechanisms as its design rationale." I think you mean "This document describes the LISP architecture and its main operational mechanisms as well as its design rationale." 4) In Sec 3.1, second paragraph: "Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale." I assume that you mean "topologically meaningful addresses" instead of "identity meaningful addresses". From nobody Thu Mar 5 08:06:09 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247961A8A48; Wed, 4 Mar 2015 18:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoL279swgokz; Wed, 4 Mar 2015 18:11:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F91A8A44; Wed, 4 Mar 2015 18:11:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 18:11:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:05:56 -0800 Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 02:11:05 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It appears the SecDir review didn't make it to LISP list for some reason. There is one important security request from Radia's review and many other good suggestions. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html Expanding the Security Considerations section would be helpful, here is the background on the request: There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary. Why not use DNS? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html From nobody Thu Mar 5 08:06:11 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4A44E1A8A47; Wed, 4 Mar 2015 18:11:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247961A8A48; Wed, 4 Mar 2015 18:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoL279swgokz; Wed, 4 Mar 2015 18:11:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F91A8A44; Wed, 4 Mar 2015 18:11:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 18:11:02 -0800 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 08:05:58 -0800 Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org Subject: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 02:11:05 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-lisp-introduction-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It appears the SecDir review didn't make it to LISP list for some reason. There is one important security request from Radia's review and many other good suggestions. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html Expanding the Security Considerations section would be helpful, here is the background on the request: There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary. Why not use DNS? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html From nobody Thu Mar 5 08:33:16 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2871A1AF0; Thu, 5 Mar 2015 08:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc_6_-Qhke58; Thu, 5 Mar 2015 08:33:09 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98CF1A03A3; Thu, 5 Mar 2015 08:27:59 -0800 (PST) Received: by pablj1 with SMTP id lj1so34600872pab.10; Thu, 05 Mar 2015 08:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pVlyDH4r/5dWJDQK1TeswRUqTHBLd8Baq3A05FFFedI=; b=EnQ4dax8KfBBpfXC/ePGxxCK0vvY3ZsMcU9Q0+JO4oVn8fEeBXep65OCbEQy6wbm09 3mUjHA7W/zQPsNXzVLxSDNCG1rC0SEnKI+xwn0I1rEkT9xin8EWY6GlCu26t6PXH0zo/ Gc8tKhH9PGW13HaZ9ltA10DCB9oVGrifeZSHetEStYGj1c5airvaDK51Qi5bWyk1KD+W 9IdSXof801oLYK/saP6U7LB1q4vUVhAZdE1KecalhUgB7vUGO7CEKKf5T9TqoU3ECFAO HLrrRTZyOl2Z7mOdl05JG9e70ItB58fojQ5aUESJ6PZOlfkWrP/JM4UuAJa60L530SjB NdEw== X-Received: by 10.67.6.193 with SMTP id cw1mr17077507pad.61.1425572879393; Thu, 05 Mar 2015 08:27:59 -0800 (PST) Received: from [10.164.54.68] ([166.177.249.132]) by mx.google.com with ESMTPSA id c8sm7430577pds.5.2015.03.05.08.27.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 08:27:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 08:27:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> To: Kathleen Moriarty Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-introduction.all@ietf.org" , The IESG , "lisp@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:33:12 -0000 > On Mar 4, 2015, at 6:11 PM, Kathleen Moriarty wrote: >=20 > Much of the routing information > is > maintained in a database "like DNS". If it *were* DNS, DNSSEC could be > used > to address the integrity issues. If it is home grown, some equivalent > mechanism will be necessary. Why not use DNS? Because you create a circular dependency. Routing should not depend on direc= tory at the same time directory depends on routing.=20 See LISP-DDT-SEC for mapping database security.=20 Dino= From nobody Thu Mar 5 08:33:26 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E97E81A1B2A; Thu, 5 Mar 2015 08:33:11 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2871A1AF0; Thu, 5 Mar 2015 08:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc_6_-Qhke58; Thu, 5 Mar 2015 08:33:09 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98CF1A03A3; Thu, 5 Mar 2015 08:27:59 -0800 (PST) Received: by pablj1 with SMTP id lj1so34600872pab.10; Thu, 05 Mar 2015 08:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pVlyDH4r/5dWJDQK1TeswRUqTHBLd8Baq3A05FFFedI=; b=EnQ4dax8KfBBpfXC/ePGxxCK0vvY3ZsMcU9Q0+JO4oVn8fEeBXep65OCbEQy6wbm09 3mUjHA7W/zQPsNXzVLxSDNCG1rC0SEnKI+xwn0I1rEkT9xin8EWY6GlCu26t6PXH0zo/ Gc8tKhH9PGW13HaZ9ltA10DCB9oVGrifeZSHetEStYGj1c5airvaDK51Qi5bWyk1KD+W 9IdSXof801oLYK/saP6U7LB1q4vUVhAZdE1KecalhUgB7vUGO7CEKKf5T9TqoU3ECFAO HLrrRTZyOl2Z7mOdl05JG9e70ItB58fojQ5aUESJ6PZOlfkWrP/JM4UuAJa60L530SjB NdEw== X-Received: by 10.67.6.193 with SMTP id cw1mr17077507pad.61.1425572879393; Thu, 05 Mar 2015 08:27:59 -0800 (PST) Received: from [10.164.54.68] ([166.177.249.132]) by mx.google.com with ESMTPSA id c8sm7430577pds.5.2015.03.05.08.27.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 08:27:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 08:27:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> To: Kathleen Moriarty Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-introduction.all@ietf.org" , The IESG , "lisp@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:33:12 -0000 > On Mar 4, 2015, at 6:11 PM, Kathleen Moriarty wrote: >=20 > Much of the routing information > is > maintained in a database "like DNS". If it *were* DNS, DNSSEC could be > used > to address the integrity issues. If it is home grown, some equivalent > mechanism will be necessary. Why not use DNS? Because you create a circular dependency. Routing should not depend on direc= tory at the same time directory depends on routing.=20 See LISP-DDT-SEC for mapping database security.=20 Dino= From nobody Thu Mar 5 10:08:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E01A6ED9; Thu, 5 Mar 2015 10:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeLtDV5Mb0d4; Thu, 5 Mar 2015 10:08:45 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079571A3BA4; Thu, 5 Mar 2015 10:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1760; q=dns/txt; s=iport; t=1425578923; x=1426788523; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3UfvnKrD+hvmkfYUQk8fhgqv1k+K6ev09z2eTy2c7a0=; b=AUXmrqOh4E2CwfQkZbQ9fz7qhFvR//02MPYYPyu5bBI/m4vkdRONON4k 3GZvmmtaxyKYt4ZDsH/gZV/BrVX7O3i5gRIpkPF+sUEdfzHMbAfe63lGk BRkSZOjtsjxZ3thALugeSnG7nAXq1JrDXMjqTuw4j33FjW0s8oiEE+iWC w=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRCQDhmvhU/xbLJq1ahDKDCrgyi24CggcBAQEBAQF8hBABAQQjVhALGAkaBwICDwIQNgYBDAEFAgEBiBcDEb1jlSYNhTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeCRIIqB4JogUMBBJFrgS6Ec4FIhnOGaoYSI4IygT09MQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="asc'?scan'208";a="373406325" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Mar 2015 18:08:41 +0000 Received: from [10.61.171.130] ([10.61.171.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t25I8e5b008206; Thu, 5 Mar 2015 18:08:40 GMT Message-ID: <54F89BAA.200@cisco.com> Date: Thu, 05 Mar 2015 19:08:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dino Farinacci , Kathleen Moriarty References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1tETcGQ5x40mPHnewWlTVg2RaOo05RBml" Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-introduction.all@ietf.org" , The IESG , "lisp@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:08:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dino, On 3/5/15 5:27 PM, Dino Farinacci wrote: >> On Mar 4, 2015, at 6:11 PM, Kathleen Moriarty wrote: >> >> Much of the routing information >> is >> maintained in a database "like DNS". If it *were* DNS, DNSSEC could be= >> used >> to address the integrity issues. If it is home grown, some equivalent >> mechanism will be necessary. Why not use DNS? > Because you create a circular dependency. Routing should not depend on = directory at the same time directory depends on routing.=20 I mostly agree with this point. It is possible to engineer a network such that this doesn't happen, but that increases the effort/planning/management required to successfully manage the system as a whole. > > See LISP-DDT-SEC for mapping database security.=20 Yes. --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU+JuqAAoJEIe2a0bZ0nozdHUIAJ6JmWIubVo0jIDgmLckpOnr ikHl2WaduV3XMgQuomOtfJSl1D2VERZGf1Jz2mZqOXI41R0OR+5RbV2xqrDLh3mm UQbELE8SA0Dxgoyvaot1gUF3wdvvZIXR87RD9SH/PIjIQhEWHFgdmHumhENv00+t LiTX9RJxMq/6w/8Ucz8+r+2l2IiCedUI3q0xWwvT0g0675B11wDJMynkzPL3TKa+ tYZr6LRs5JK5V+zMg9Y4fJICjs5SQj0vQU6PN/e7xZmJQpE6uZoi/ZYpqT88hdfY Om+fTNuPb+hlKowfxf033v+3IwPLKZ3dcteWtNZ2v1zsB5C5vDFAMg3gA3BKE9g= =9iTD -----END PGP SIGNATURE----- --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml-- From nobody Thu Mar 5 10:08:52 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B483C1A6EDE; Thu, 5 Mar 2015 10:08:46 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E01A6ED9; Thu, 5 Mar 2015 10:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeLtDV5Mb0d4; Thu, 5 Mar 2015 10:08:45 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079571A3BA4; Thu, 5 Mar 2015 10:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1760; q=dns/txt; s=iport; t=1425578923; x=1426788523; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3UfvnKrD+hvmkfYUQk8fhgqv1k+K6ev09z2eTy2c7a0=; b=AUXmrqOh4E2CwfQkZbQ9fz7qhFvR//02MPYYPyu5bBI/m4vkdRONON4k 3GZvmmtaxyKYt4ZDsH/gZV/BrVX7O3i5gRIpkPF+sUEdfzHMbAfe63lGk BRkSZOjtsjxZ3thALugeSnG7nAXq1JrDXMjqTuw4j33FjW0s8oiEE+iWC w=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRCQDhmvhU/xbLJq1ahDKDCrgyi24CggcBAQEBAQF8hBABAQQjVhALGAkaBwICDwIQNgYBDAEFAgEBiBcDEb1jlSYNhTIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeCRIIqB4JogUMBBJFrgS6Ec4FIhnOGaoYSI4IygT09MQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="asc'?scan'208";a="373406325" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Mar 2015 18:08:41 +0000 Received: from [10.61.171.130] ([10.61.171.130]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t25I8e5b008206; Thu, 5 Mar 2015 18:08:40 GMT Message-ID: <54F89BAA.200@cisco.com> Date: Thu, 05 Mar 2015 19:08:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dino Farinacci , Kathleen Moriarty References: <20150305021102.12577.68131.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1tETcGQ5x40mPHnewWlTVg2RaOo05RBml" Archived-At: Cc: "lisp-chairs@ietf.org" , "draft-ietf-lisp-introduction.all@ietf.org" , The IESG , "lisp@ietf.org" Subject: Re: [lisp] Kathleen Moriarty's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:08:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dino, On 3/5/15 5:27 PM, Dino Farinacci wrote: >> On Mar 4, 2015, at 6:11 PM, Kathleen Moriarty wrote: >> >> Much of the routing information >> is >> maintained in a database "like DNS". If it *were* DNS, DNSSEC could be= >> used >> to address the integrity issues. If it is home grown, some equivalent >> mechanism will be necessary. Why not use DNS? > Because you create a circular dependency. Routing should not depend on = directory at the same time directory depends on routing.=20 I mostly agree with this point. It is possible to engineer a network such that this doesn't happen, but that increases the effort/planning/management required to successfully manage the system as a whole. > > See LISP-DDT-SEC for mapping database security.=20 Yes. --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU+JuqAAoJEIe2a0bZ0nozdHUIAJ6JmWIubVo0jIDgmLckpOnr ikHl2WaduV3XMgQuomOtfJSl1D2VERZGf1Jz2mZqOXI41R0OR+5RbV2xqrDLh3mm UQbELE8SA0Dxgoyvaot1gUF3wdvvZIXR87RD9SH/PIjIQhEWHFgdmHumhENv00+t LiTX9RJxMq/6w/8Ucz8+r+2l2IiCedUI3q0xWwvT0g0675B11wDJMynkzPL3TKa+ tYZr6LRs5JK5V+zMg9Y4fJICjs5SQj0vQU6PN/e7xZmJQpE6uZoi/ZYpqT88hdfY Om+fTNuPb+hlKowfxf033v+3IwPLKZ3dcteWtNZ2v1zsB5C5vDFAMg3gA3BKE9g= =9iTD -----END PGP SIGNATURE----- --1tETcGQ5x40mPHnewWlTVg2RaOo05RBml-- From nobody Thu Mar 5 10:28:14 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096ED1A6EE1; Thu, 5 Mar 2015 10:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbs_XjMxAmKm; Thu, 5 Mar 2015 10:28:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5281A1ADF; Thu, 5 Mar 2015 10:28:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305182809.5045.27139.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 10:28:09 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:28:12 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Thu Mar 5 10:28:16 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2C2D21A6EE7; Thu, 5 Mar 2015 10:28:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096ED1A6EE1; Thu, 5 Mar 2015 10:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbs_XjMxAmKm; Thu, 5 Mar 2015 10:28:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5281A1ADF; Thu, 5 Mar 2015 10:28:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305182809.5045.27139.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 10:28:09 -0800 From: IETF Secretariat Archived-At: Subject: [lisp] ID Tracker State Update Notice: X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:28:12 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ From nobody Thu Mar 5 13:32:53 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7B1A900A for ; Thu, 5 Mar 2015 13:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Ia0wIJvpdr for ; Thu, 5 Mar 2015 13:32:48 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7991A8F45 for ; Thu, 5 Mar 2015 13:32:46 -0800 (PST) Received: by wghb13 with SMTP id b13so56222854wgh.0 for ; Thu, 05 Mar 2015 13:32:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Sa6fy4ymUipe2u3XwLuzQ1eP6tvzikjRW6EHaSG+Y5I=; b=BFYQfKufuTgOo6NQBD29vmfbrH02nsHaCoigho+KHJY0XghFXbwaECf7JabdxwkOeS OmQ8dMFtruFYWJz9FkXknvV3xM1SlcS81LwAN+c3+vgdbFHsfvM+pG8mX+zWkiB91Vr6 3A0sRcWddH/5RUTWSX7nLDpKHI6wxLv9yl0O5+KbOyCzXdR2C/cmdsPfbxcW/0pCNNal 0mUwEqZa5oJbv0x5Yy6uh5X7H8Dryj4oF7vigfZW+U34UPREsLXgxMfvWVMlc/4JeVLt ivKwWUp7XSSMy+5yOfHPvuNbqrjRcrBN1ln69lGUp30HPq4hPy1ub/OOcfmKVPM5LHNY CB4w== X-Gm-Message-State: ALoCoQmGBOIqb1FMbqN4pZrdaDJSN7a9gaa6Jgp5nXZ4cUFn++r5ldtqMrOeeDY6kYO2C4At1S6y X-Received: by 10.180.79.1 with SMTP id f1mr71240128wix.24.1425591165074; Thu, 05 Mar 2015 13:32:45 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:8152:ab0b:5fb0:383e? ([2a01:e35:1381:3430:8152:ab0b:5fb0:383e]) by mx.google.com with ESMTPSA id y14sm12174052wjr.39.2015.03.05.13.32.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 13:32:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 22:32:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 21:32:50 -0000 Hi Alia=20 thanks for the review.=20 I have just one comment right in the middle of your review. > On 05 Mar 2015, at 16:14, Alia Atlas wrote: >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Adrian's discuss. In a similar vein: >=20 > In Sec 3.2: Please either remove the claim of "Such LISP capable > routers, in most cases, only require a software upgrade." or explain > how you can justify the need to add and remove new encapsulations and > handle the various flag triggers and caching at line rate. There is > no need for such marketing in this document. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) Sec 1, second paragraph: > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > and > RLOCs (Routing LOCators), both are typically syntactically identical > to the current IPv4 and IPv6 addresses." >=20 > What does "typically" mean? As far as I'm aware, they are > syntactically identical. This is reiterated in Sec 3.2; are you = just > trying to preserve the point of architectural freedom? I've found > the > third instance of insisting that the EID or RLOC now is only > "typically"=20 > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > before both should be a ;. >=20 I think that the changes the authors already proposed to Adrian fix the = above Discuss and comments. Can you check if I am correct? =46rom this point down is just typos/grammar, so authors will easily fix = your helpful comments thanks again ciao L. =20 > 2) top paragraph of p.4: > "The initial motivation in the LISP effort is to be found in the > routing scalability problem [RFC4984], where, if LISP is completely > deployed, the Internet core is populated with RLOCs while Traffic > Engineering mechanisms are pushed to the Mapping System." >=20 > Instead of "LISP is completely deployed" to "LISP were to be > completely deployed" - making it subjunctive. =20 >=20 > 3) Last paragraph in Sec 1: > "This document describes the LISP architecture, its main > operational mechanisms as its design rationale." >=20 > I think you mean=20 >=20 > "This document describes the LISP architecture and its main > operational mechanisms as well as its design rationale." >=20 > 4) In Sec 3.1, second paragraph: > "Locator/Identifier split: By decoupling the overloaded semantics > of the current IP addresses the Internet core can be assigned > identity meaningful addresses and hence, can use aggregation to > scale." > I assume that you mean "topologically meaningful addresses" instead > of "identity meaningful addresses". >=20 >=20 From nobody Thu Mar 5 13:32:54 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3D12F1A9004; Thu, 5 Mar 2015 13:32:50 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF201A8EA9 for ; Thu, 5 Mar 2015 13:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5hcuYkHznD4 for ; Thu, 5 Mar 2015 13:32:48 -0800 (PST) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C69B1A9004 for ; Thu, 5 Mar 2015 13:32:46 -0800 (PST) Received: by wesx3 with SMTP id x3so9055032wes.4 for ; Thu, 05 Mar 2015 13:32:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Sa6fy4ymUipe2u3XwLuzQ1eP6tvzikjRW6EHaSG+Y5I=; b=dd0QEJJS2twM+UyHaCk76crO8C4Kwk1uJG8lf11bcUmnPeUBfSYFGKamZtYrStPvZh Yd48d9QlqWoze7uIZobQ9Txh/LGflwcg57ReJHOy7RmPY0OQeKhpM0i4TCb9FjYKmAsy b84Bo2DXH24McNlDtQXQ5D3CjTEpQM3a1M6At3T8w8ZSmqaWuOMW8NRBBIh3yI//2Xe5 HG2t8QQyK8TMGyvU7h65aIc9E5gsGFsppwD8DTXdYJWTjCmS1/NrXmzXZmALilLIVIyE MZxa6uMW19P7BtXenBnzeWzrdYrCB+iENxZwfBSSawNsTKJTGiZTAYvxZ+Xwq/jcRYi0 tokw== X-Gm-Message-State: ALoCoQntVF52UB8aPmJ74VYFMGnodTx59ggRvHqxTG6EhAyrjE8QirOBYY5i+l1wzAQ4Sxz2UhVU X-Received: by 10.180.79.1 with SMTP id f1mr71240128wix.24.1425591165074; Thu, 05 Mar 2015 13:32:45 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:8152:ab0b:5fb0:383e? ([2a01:e35:1381:3430:8152:ab0b:5fb0:383e]) by mx.google.com with ESMTPSA id y14sm12174052wjr.39.2015.03.05.13.32.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 13:32:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 22:32:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 21:32:50 -0000 Hi Alia=20 thanks for the review.=20 I have just one comment right in the middle of your review. > On 05 Mar 2015, at 16:14, Alia Atlas wrote: >=20 > Alia Atlas has entered the following ballot position for > draft-ietf-lisp-introduction-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I support Adrian's discuss. In a similar vein: >=20 > In Sec 3.2: Please either remove the claim of "Such LISP capable > routers, in most cases, only require a software upgrade." or explain > how you can justify the need to add and remove new encapsulations and > handle the various flag triggers and caching at line rate. There is > no need for such marketing in this document. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) Sec 1, second paragraph: > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > and > RLOCs (Routing LOCators), both are typically syntactically identical > to the current IPv4 and IPv6 addresses." >=20 > What does "typically" mean? As far as I'm aware, they are > syntactically identical. This is reiterated in Sec 3.2; are you = just > trying to preserve the point of architectural freedom? I've found > the > third instance of insisting that the EID or RLOC now is only > "typically"=20 > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > before both should be a ;. >=20 I think that the changes the authors already proposed to Adrian fix the = above Discuss and comments. Can you check if I am correct? =46rom this point down is just typos/grammar, so authors will easily fix = your helpful comments thanks again ciao L. =20 > 2) top paragraph of p.4: > "The initial motivation in the LISP effort is to be found in the > routing scalability problem [RFC4984], where, if LISP is completely > deployed, the Internet core is populated with RLOCs while Traffic > Engineering mechanisms are pushed to the Mapping System." >=20 > Instead of "LISP is completely deployed" to "LISP were to be > completely deployed" - making it subjunctive. =20 >=20 > 3) Last paragraph in Sec 1: > "This document describes the LISP architecture, its main > operational mechanisms as its design rationale." >=20 > I think you mean=20 >=20 > "This document describes the LISP architecture and its main > operational mechanisms as well as its design rationale." >=20 > 4) In Sec 3.1, second paragraph: > "Locator/Identifier split: By decoupling the overloaded semantics > of the current IP addresses the Internet core can be assigned > identity meaningful addresses and hence, can use aggregation to > scale." > I assume that you mean "topologically meaningful addresses" instead > of "identity meaningful addresses". >=20 >=20 From nobody Thu Mar 5 14:13:17 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2031A9080; Thu, 5 Mar 2015 14:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzLrp2s5HhXa; Thu, 5 Mar 2015 14:13:11 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019AC1A897A; Thu, 5 Mar 2015 14:13:11 -0800 (PST) Received: by obbnt9 with SMTP id nt9so17090454obb.13; Thu, 05 Mar 2015 14:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8WY/U4A43AIc7FvsUTyrGDSJOIkJu/UamVHU/CNXtNY=; b=Jf+las8JuGH9tV4XcC+6oxavdA6pl+yO3IkD+oLb2XwLebOIIQ9BRehYJSzkgka0uN t9+OGujbO5tI0ND5ZsiC9N3eptbgzhGmFo+M1mY3rIdXItP2Vw7quMgaXf1DphEh/8Zr 2a0FFMW3x/SY4RGeB24gzVm6qLA3RtdTWecuPhfSj/gwrpiw09u9stI/yur5GKKpr5fB KLu5L00w7PVit0tdJohSg53FFuBtwyO7WhyE1U25LtfNh+yjwO3eI1btOpQlpsU3qFVe s5gR+Ai5aN5h1ZsWp7n8ffVrwqAVl374A8YM5jkuvfdg7+GWdqHxrXw3DEDLvdHgTbJq 2cEA== MIME-Version: 1.0 X-Received: by 10.182.165.70 with SMTP id yw6mr8665212obb.13.1425593590417; Thu, 05 Mar 2015 14:13:10 -0800 (PST) Received: by 10.60.97.135 with HTTP; Thu, 5 Mar 2015 14:13:10 -0800 (PST) In-Reply-To: References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 17:13:10 -0500 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a11c30c628d0e0e051091df7f Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:13:13 -0000 --001a11c30c628d0e0e051091df7f Content-Type: text/plain; charset=UTF-8 Hi Luigi, Yes, Adrian also picked up on the "typically" for EID and RLOC and the proposed response fixes that as well as the BGP issues. I don't recall seeing the "oh, routers can just do with with a software upgrade" claim fixed. Regards, Alia On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone wrote: > Hi Alia > > thanks for the review. > > I have just one comment right in the middle of your review. > > > On 05 Mar 2015, at 16:14, Alia Atlas wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-lisp-introduction-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Adrian's discuss. In a similar vein: > > > > In Sec 3.2: Please either remove the claim of "Such LISP capable > > routers, in most cases, only require a software upgrade." or explain > > how you can justify the need to add and remove new encapsulations and > > handle the various flag triggers and caching at line rate. There is > > no need for such marketing in this document. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 1) Sec 1, second paragraph: > > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > > and > > RLOCs (Routing LOCators), both are typically syntactically identical > > to the current IPv4 and IPv6 addresses." > > > > What does "typically" mean? As far as I'm aware, they are > > syntactically identical. This is reiterated in Sec 3.2; are you just > > trying to preserve the point of architectural freedom? I've found > > the > > third instance of insisting that the EID or RLOC now is only > > "typically" > > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > > before both should be a ;. > > > > I think that the changes the authors already proposed to Adrian fix the > above Discuss and comments. > Can you check if I am correct? > > From this point down is just typos/grammar, so authors will easily fix > your helpful comments > > thanks again > > ciao > > L. > > > > > > > 2) top paragraph of p.4: > > "The initial motivation in the LISP effort is to be found in the > > routing scalability problem [RFC4984], where, if LISP is completely > > deployed, the Internet core is populated with RLOCs while Traffic > > Engineering mechanisms are pushed to the Mapping System." > > > > Instead of "LISP is completely deployed" to "LISP were to be > > completely deployed" - making it subjunctive. > > > > 3) Last paragraph in Sec 1: > > "This document describes the LISP architecture, its main > > operational mechanisms as its design rationale." > > > > I think you mean > > > > "This document describes the LISP architecture and its main > > operational mechanisms as well as its design rationale." > > > > 4) In Sec 3.1, second paragraph: > > "Locator/Identifier split: By decoupling the overloaded semantics > > of the current IP addresses the Internet core can be assigned > > identity meaningful addresses and hence, can use aggregation to > > scale." > > I assume that you mean "topologically meaningful addresses" instead > > of "identity meaningful addresses". > > > > > > --001a11c30c628d0e0e051091df7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Luigi,

Yes, Adrian also picked up on= the "typically" for EID and RLOC and the proposed response fixes= that as well as the BGP issues.

I don't recal= l seeing the "oh, routers can just do with with a software upgrade&quo= t; claim fixed.

Regards,
Alia
=

O= n Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wr= ote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-intro= duction/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I support Adrian's discuss.=C2=A0 In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable<= br> > routers, in most cases, only require a software upgrade." or expl= ain
> how you can justify the need to add and remove new encapsulations and<= br> > handle the various flag triggers and caching at line rate.=C2=A0 There= is
> no need for such marketing in this document.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) Sec 1, second paragraph:
>=C2=A0 =C2=A0"LISP creates two separate namespaces, EIDs (End-host= IDentifiers)
> and
>=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically= identical
>=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses."
>
>=C2=A0 =C2=A0What does "typically" mean?=C2=A0 As far as I= 9;m aware, they are
>=C2=A0 =C2=A0syntactically identical.=C2=A0 This is reiterated in Sec 3= .2; are you just
>=C2=A0 =C2=A0trying to preserve the point of architectural freedom?=C2= =A0 I've found
> the
>=C2=A0 =C2=A0third instance of insisting that the EID or RLOC now is on= ly
> "typically"
>=C2=A0 =C2=A0an IPv4 or IPv6 address. Please lose "typically"= .=C2=A0 Minorly, the ,
>=C2=A0 =C2=A0before both should be a ;.
>

I think that the changes the authors already proposed to Adrian= fix the above Discuss and comments.
Can you check if I am correct?

>From this point down is just typos/grammar, so authors will easily fix your= helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>=C2=A0 "The initial motivation in the LISP effort is to be found i= n the
>=C2=A0 =C2=A0routing scalability problem [RFC4984], where, if LISP is c= ompletely
>=C2=A0 =C2=A0deployed, the Internet core is populated with RLOCs while = Traffic
>=C2=A0 =C2=A0Engineering mechanisms are pushed to the Mapping System.&q= uot;
>
>=C2=A0 =C2=A0Instead of "LISP is completely deployed" to &quo= t;LISP were to be
>=C2=A0 =C2=A0completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>=C2=A0 =C2=A0"This document describes the LISP architecture, its m= ain
>=C2=A0 =C2=A0operational mechanisms as its design rationale."
>
>=C2=A0 =C2=A0I think you mean
>
>=C2=A0 =C2=A0"This document describes the LISP architecture and it= s main
>=C2=A0 =C2=A0operational mechanisms as well as its design rationale.&qu= ot;
>
> 4) In Sec 3.1, second paragraph:
>=C2=A0 =C2=A0"Locator/Identifier split: By decoupling the overload= ed semantics
>=C2=A0 =C2=A0 =C2=A0 of the current IP addresses the Internet core can = be assigned
>=C2=A0 =C2=A0 =C2=A0 identity meaningful addresses and hence, can use a= ggregation to
>=C2=A0 =C2=A0 =C2=A0 scale."
>=C2=A0 =C2=A0I assume that you mean "topologically meaningful addr= esses" instead
>=C2=A0 =C2=A0of "identity meaningful addresses".
>
>


--001a11c30c628d0e0e051091df7f-- From nobody Thu Mar 5 14:13:18 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AC65B1A9086; Thu, 5 Mar 2015 14:13:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2031A9080; Thu, 5 Mar 2015 14:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzLrp2s5HhXa; Thu, 5 Mar 2015 14:13:11 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019AC1A897A; Thu, 5 Mar 2015 14:13:11 -0800 (PST) Received: by obbnt9 with SMTP id nt9so17090454obb.13; Thu, 05 Mar 2015 14:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8WY/U4A43AIc7FvsUTyrGDSJOIkJu/UamVHU/CNXtNY=; b=Jf+las8JuGH9tV4XcC+6oxavdA6pl+yO3IkD+oLb2XwLebOIIQ9BRehYJSzkgka0uN t9+OGujbO5tI0ND5ZsiC9N3eptbgzhGmFo+M1mY3rIdXItP2Vw7quMgaXf1DphEh/8Zr 2a0FFMW3x/SY4RGeB24gzVm6qLA3RtdTWecuPhfSj/gwrpiw09u9stI/yur5GKKpr5fB KLu5L00w7PVit0tdJohSg53FFuBtwyO7WhyE1U25LtfNh+yjwO3eI1btOpQlpsU3qFVe s5gR+Ai5aN5h1ZsWp7n8ffVrwqAVl374A8YM5jkuvfdg7+GWdqHxrXw3DEDLvdHgTbJq 2cEA== MIME-Version: 1.0 X-Received: by 10.182.165.70 with SMTP id yw6mr8665212obb.13.1425593590417; Thu, 05 Mar 2015 14:13:10 -0800 (PST) Received: by 10.60.97.135 with HTTP; Thu, 5 Mar 2015 14:13:10 -0800 (PST) In-Reply-To: References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 17:13:10 -0500 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a11c30c628d0e0e051091df7f Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:13:13 -0000 --001a11c30c628d0e0e051091df7f Content-Type: text/plain; charset=UTF-8 Hi Luigi, Yes, Adrian also picked up on the "typically" for EID and RLOC and the proposed response fixes that as well as the BGP issues. I don't recall seeing the "oh, routers can just do with with a software upgrade" claim fixed. Regards, Alia On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone wrote: > Hi Alia > > thanks for the review. > > I have just one comment right in the middle of your review. > > > On 05 Mar 2015, at 16:14, Alia Atlas wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-lisp-introduction-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Adrian's discuss. In a similar vein: > > > > In Sec 3.2: Please either remove the claim of "Such LISP capable > > routers, in most cases, only require a software upgrade." or explain > > how you can justify the need to add and remove new encapsulations and > > handle the various flag triggers and caching at line rate. There is > > no need for such marketing in this document. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 1) Sec 1, second paragraph: > > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > > and > > RLOCs (Routing LOCators), both are typically syntactically identical > > to the current IPv4 and IPv6 addresses." > > > > What does "typically" mean? As far as I'm aware, they are > > syntactically identical. This is reiterated in Sec 3.2; are you just > > trying to preserve the point of architectural freedom? I've found > > the > > third instance of insisting that the EID or RLOC now is only > > "typically" > > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > > before both should be a ;. > > > > I think that the changes the authors already proposed to Adrian fix the > above Discuss and comments. > Can you check if I am correct? > > From this point down is just typos/grammar, so authors will easily fix > your helpful comments > > thanks again > > ciao > > L. > > > > > > > 2) top paragraph of p.4: > > "The initial motivation in the LISP effort is to be found in the > > routing scalability problem [RFC4984], where, if LISP is completely > > deployed, the Internet core is populated with RLOCs while Traffic > > Engineering mechanisms are pushed to the Mapping System." > > > > Instead of "LISP is completely deployed" to "LISP were to be > > completely deployed" - making it subjunctive. > > > > 3) Last paragraph in Sec 1: > > "This document describes the LISP architecture, its main > > operational mechanisms as its design rationale." > > > > I think you mean > > > > "This document describes the LISP architecture and its main > > operational mechanisms as well as its design rationale." > > > > 4) In Sec 3.1, second paragraph: > > "Locator/Identifier split: By decoupling the overloaded semantics > > of the current IP addresses the Internet core can be assigned > > identity meaningful addresses and hence, can use aggregation to > > scale." > > I assume that you mean "topologically meaningful addresses" instead > > of "identity meaningful addresses". > > > > > > --001a11c30c628d0e0e051091df7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Luigi,

Yes, Adrian also picked up on= the "typically" for EID and RLOC and the proposed response fixes= that as well as the BGP issues.

I don't recal= l seeing the "oh, routers can just do with with a software upgrade&quo= t; claim fixed.

Regards,
Alia
=

O= n Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wr= ote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-intro= duction/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I support Adrian's discuss.=C2=A0 In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable<= br> > routers, in most cases, only require a software upgrade." or expl= ain
> how you can justify the need to add and remove new encapsulations and<= br> > handle the various flag triggers and caching at line rate.=C2=A0 There= is
> no need for such marketing in this document.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) Sec 1, second paragraph:
>=C2=A0 =C2=A0"LISP creates two separate namespaces, EIDs (End-host= IDentifiers)
> and
>=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically= identical
>=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses."
>
>=C2=A0 =C2=A0What does "typically" mean?=C2=A0 As far as I= 9;m aware, they are
>=C2=A0 =C2=A0syntactically identical.=C2=A0 This is reiterated in Sec 3= .2; are you just
>=C2=A0 =C2=A0trying to preserve the point of architectural freedom?=C2= =A0 I've found
> the
>=C2=A0 =C2=A0third instance of insisting that the EID or RLOC now is on= ly
> "typically"
>=C2=A0 =C2=A0an IPv4 or IPv6 address. Please lose "typically"= .=C2=A0 Minorly, the ,
>=C2=A0 =C2=A0before both should be a ;.
>

I think that the changes the authors already proposed to Adrian= fix the above Discuss and comments.
Can you check if I am correct?

>From this point down is just typos/grammar, so authors will easily fix your= helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>=C2=A0 "The initial motivation in the LISP effort is to be found i= n the
>=C2=A0 =C2=A0routing scalability problem [RFC4984], where, if LISP is c= ompletely
>=C2=A0 =C2=A0deployed, the Internet core is populated with RLOCs while = Traffic
>=C2=A0 =C2=A0Engineering mechanisms are pushed to the Mapping System.&q= uot;
>
>=C2=A0 =C2=A0Instead of "LISP is completely deployed" to &quo= t;LISP were to be
>=C2=A0 =C2=A0completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>=C2=A0 =C2=A0"This document describes the LISP architecture, its m= ain
>=C2=A0 =C2=A0operational mechanisms as its design rationale."
>
>=C2=A0 =C2=A0I think you mean
>
>=C2=A0 =C2=A0"This document describes the LISP architecture and it= s main
>=C2=A0 =C2=A0operational mechanisms as well as its design rationale.&qu= ot;
>
> 4) In Sec 3.1, second paragraph:
>=C2=A0 =C2=A0"Locator/Identifier split: By decoupling the overload= ed semantics
>=C2=A0 =C2=A0 =C2=A0 of the current IP addresses the Internet core can = be assigned
>=C2=A0 =C2=A0 =C2=A0 identity meaningful addresses and hence, can use a= ggregation to
>=C2=A0 =C2=A0 =C2=A0 scale."
>=C2=A0 =C2=A0I assume that you mean "topologically meaningful addr= esses" instead
>=C2=A0 =C2=A0of "identity meaningful addresses".
>
>


--001a11c30c628d0e0e051091df7f-- From nobody Fri Mar 6 02:11:52 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E831A0398 for ; Fri, 6 Mar 2015 02:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8hOIqj_l51x for ; Fri, 6 Mar 2015 02:11:48 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E3A1A1A0F for ; Fri, 6 Mar 2015 02:11:46 -0800 (PST) Received: by widem10 with SMTP id em10so2328528wid.0 for ; Fri, 06 Mar 2015 02:11:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vc8YNFS0wbuG3P+kokVGiah75DpeUudMLf0UQuOgONs=; b=hjwvp/iGsGxBf2p5NngAvrmYa6pcZiGLPZ4EuHLn9wZcvUp7uvUw9xqhiuDks7ULGT bEdBw1tuxVNjghaECSISpB2UCVFmTARcrNf85TAC/4J0CWN0CBFzr2K8guMmqWZXtJIz YS9BH873tPvkrLD05H4Ka4U71/rPmjVQBfAMsAFqz7AfGw17DUFhHI8PvB7DTG/xnHaj HfvH8qkzQOQV3dz1n1dnZJ6JDtYbgZ+LWYrKM2C8cBbegWHUQUpNZd+6xivfXTL5/kk8 uarlbIYgdEo9t+mlGC+evwz/LvbRywEY19fNuC3GglVHnhLAw4FfQ6iZ/QjNm1hoGpmR wnBw== X-Gm-Message-State: ALoCoQlzz6uYstHPyLUaPgCah6vHwJ5wvL+ZZkkqh7I6/EmwvLTzKMYdy4Vpd739Rp8bzw/KWzQ3 X-Received: by 10.180.19.9 with SMTP id a9mr31519546wie.85.1425636704838; Fri, 06 Mar 2015 02:11:44 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:cdf2:2315:ca0b:e2fa? ([2001:660:330f:a4:cdf2:2315:ca0b:e2fa]) by mx.google.com with ESMTPSA id b4sm1568952wic.2.2015.03.06.02.11.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 02:11:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Fri, 6 Mar 2015 11:11:42 +0100 Message-Id: <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:11:51 -0000 --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alia, > On 05 Mar 2015, at 23:13, Alia Atlas wrote: >=20 > Hi Luigi, >=20 > Yes, Adrian also picked up on the "typically" for EID and RLOC and the = proposed response fixes that as well as the BGP issues. >=20 > I don't recall seeing the "oh, routers can just do with with a = software upgrade" claim fixed. because it is lost in a lot of other fixes ;-) The authors propose to change the wording in the following way: "Adding LISP capabilities to routers does not mandate hardware changes = and can be done via a software upgrade." The point authors are trying to make is not about how to install LISP in = your boxes, is more about the fact that the protocol=20 does not need new hardware. Obviously you there can be hardware = implementations, but as you rightfully point out, this is=20 not the place to mention them. So, the above sentence looks appropriate, = unless we want to simplify even more and just state: "Adding LISP capabilities to routers does not mandate hardware changes." =20 What do you think? ciao Luigi >=20 > Regards, > Alia >=20 >=20 > On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone > wrote: > Hi Alia >=20 > thanks for the review. >=20 > I have just one comment right in the middle of your review. >=20 > > On 05 Mar 2015, at 16:14, Alia Atlas > wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-lisp-introduction-12: Discuss > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html = > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ = > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > I support Adrian's discuss. In a similar vein: > > > > In Sec 3.2: Please either remove the claim of "Such LISP capable > > routers, in most cases, only require a software upgrade." or explain > > how you can justify the need to add and remove new encapsulations = and > > handle the various flag triggers and caching at line rate. There is > > no need for such marketing in this document. > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > 1) Sec 1, second paragraph: > > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > > and > > RLOCs (Routing LOCators), both are typically syntactically = identical > > to the current IPv4 and IPv6 addresses." > > > > What does "typically" mean? As far as I'm aware, they are > > syntactically identical. This is reiterated in Sec 3.2; are you = just > > trying to preserve the point of architectural freedom? I've found > > the > > third instance of insisting that the EID or RLOC now is only > > "typically" > > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > > before both should be a ;. > > >=20 > I think that the changes the authors already proposed to Adrian fix = the above Discuss and comments. > Can you check if I am correct? >=20 > =46rom this point down is just typos/grammar, so authors will easily = fix your helpful comments >=20 > thanks again >=20 > ciao >=20 > L. >=20 >=20 >=20 >=20 >=20 > > 2) top paragraph of p.4: > > "The initial motivation in the LISP effort is to be found in the > > routing scalability problem [RFC4984], where, if LISP is = completely > > deployed, the Internet core is populated with RLOCs while Traffic > > Engineering mechanisms are pushed to the Mapping System." > > > > Instead of "LISP is completely deployed" to "LISP were to be > > completely deployed" - making it subjunctive. > > > > 3) Last paragraph in Sec 1: > > "This document describes the LISP architecture, its main > > operational mechanisms as its design rationale." > > > > I think you mean > > > > "This document describes the LISP architecture and its main > > operational mechanisms as well as its design rationale." > > > > 4) In Sec 3.1, second paragraph: > > "Locator/Identifier split: By decoupling the overloaded semantics > > of the current IP addresses the Internet core can be assigned > > identity meaningful addresses and hence, can use aggregation to > > scale." > > I assume that you mean "topologically meaningful addresses" = instead > > of "identity meaningful addresses". > > > > >=20 >=20 --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Alia,

On 05 Mar 2015, at 23:13, Alia = Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the "typically" for EID and = RLOC and the proposed response fixes that as well as the BGP = issues.

I = don't recall seeing the "oh, routers can just do with with a software = upgrade" claim fixed.

because it is lost in a lot of other fixes = ;-)

The authors propose to change = the wording in the following way:

"Adding LISP capabilities to routers does not = mandate hardware changes and can be done via a software = upgrade."

The point authors are = trying to make is not about how to install LISP in your boxes,  is = more about the fact that the protocol 
does not need new = hardware. Obviously you there can be hardware implementations, but as = you rightfully point out, this is 
not the place to = mention them. So, the above sentence looks appropriate, unless we want = to simplify even more and just state:

"Adding LISP capabilities to routers does not = mandate hardware changes."
  
What do you = think?

ciao

Luigi

Regards,
Alia


On Thu, = Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.
=

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> = wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found = here:
> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> I support Adrian's discuss.  In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable
> routers, in most cases, only require a software upgrade." or = explain
> how you can justify the need to add and remove new encapsulations = and
> handle the various flag triggers and caching at line rate.  = There is
> no need for such marketing in this document.
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) Sec 1, second paragraph:
>   "LISP creates two separate namespaces, EIDs (End-host = IDentifiers)
> and
>   RLOCs (Routing LOCators), both are typically = syntactically identical
>   to the current IPv4 and IPv6 addresses."
>
>   What does "typically" mean?  As far as I'm aware, = they are
>   syntactically identical.  This is reiterated in = Sec 3.2; are you just
>   trying to preserve the point of architectural = freedom?  I've found
> the
>   third instance of insisting that the EID or RLOC now is = only
> "typically"
>   an IPv4 or IPv6 address. Please lose "typically".  = Minorly, the ,
>   before both should be a ;.
>

I think that the changes the authors already proposed to = Adrian fix the above Discuss and comments.
Can you check if I am correct?

=46rom this point down is just typos/grammar, so authors will easily fix = your helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>  "The initial motivation in the LISP effort is to be found in = the
>   routing scalability problem [RFC4984], where, if LISP = is completely
>   deployed, the Internet core is populated with RLOCs = while Traffic
>   Engineering mechanisms are pushed to the Mapping = System."
>
>   Instead of "LISP is completely deployed" to "LISP were = to be
>   completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>   "This document describes the LISP architecture, its = main
>   operational mechanisms as its design rationale."
>
>   I think you mean
>
>   "This document describes the LISP architecture and its = main
>   operational mechanisms as well as its design = rationale."
>
> 4) In Sec 3.1, second paragraph:
>   "Locator/Identifier split: By decoupling the overloaded = semantics
>      of the current IP addresses the Internet core = can be assigned
>      identity meaningful addresses and hence, can = use aggregation to
>      scale."
>   I assume that you mean "topologically meaningful = addresses" instead
>   of "identity meaningful addresses".
>
>



= --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B-- From nobody Fri Mar 6 02:11:55 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C19231A1A62; Fri, 6 Mar 2015 02:11:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EA31A0398 for ; Fri, 6 Mar 2015 02:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-EvKt83T1yT for ; Fri, 6 Mar 2015 02:11:49 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402D21A1A62 for ; Fri, 6 Mar 2015 02:11:46 -0800 (PST) Received: by wesw55 with SMTP id w55so5090866wes.3 for ; Fri, 06 Mar 2015 02:11:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=vc8YNFS0wbuG3P+kokVGiah75DpeUudMLf0UQuOgONs=; b=DsiH0210iOQ1ZVtZ1CBKZ+v3IfSCsR6kXeJ6/wHVyn/v5/Q7MnPjbRRQ6PeunsI/Kk epVD8949RzfT+x2cH84oHNgI7MH2JpiUWAt/EKew6FfIdt1t8GUxavM2mvxRDIAq6cyj RZUicmZGbYJQVhYrBe5YbGyY64v/7B8uudrtLJASWaJN7gsTor5/pSV8cyamqhmVfqVm 1D+g50dy5Q5T5LWd1fvkvZX7UVAs9m4iaC9XCMEIns27bjN64919cWiPMP3zDk8qUsX5 zu5ol/omXc6iuvhbL4eR4RTRlPPCSg+RQ8jutEHeKfuafU7v8UjVJZCx4YH6OjE4VL4V j07A== X-Gm-Message-State: ALoCoQlIwLrIFzKuG7ApdQ9PR9J1MDvdZ2EG3eanTxnmob7YjEltUbdbGgQp04YaWaPEs+I5sCE5 X-Received: by 10.180.19.9 with SMTP id a9mr31519546wie.85.1425636704838; Fri, 06 Mar 2015 02:11:44 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:cdf2:2315:ca0b:e2fa? ([2001:660:330f:a4:cdf2:2315:ca0b:e2fa]) by mx.google.com with ESMTPSA id b4sm1568952wic.2.2015.03.06.02.11.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 02:11:42 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Fri, 6 Mar 2015 11:11:42 +0100 Message-Id: <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:11:51 -0000 --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alia, > On 05 Mar 2015, at 23:13, Alia Atlas wrote: >=20 > Hi Luigi, >=20 > Yes, Adrian also picked up on the "typically" for EID and RLOC and the = proposed response fixes that as well as the BGP issues. >=20 > I don't recall seeing the "oh, routers can just do with with a = software upgrade" claim fixed. because it is lost in a lot of other fixes ;-) The authors propose to change the wording in the following way: "Adding LISP capabilities to routers does not mandate hardware changes = and can be done via a software upgrade." The point authors are trying to make is not about how to install LISP in = your boxes, is more about the fact that the protocol=20 does not need new hardware. Obviously you there can be hardware = implementations, but as you rightfully point out, this is=20 not the place to mention them. So, the above sentence looks appropriate, = unless we want to simplify even more and just state: "Adding LISP capabilities to routers does not mandate hardware changes." =20 What do you think? ciao Luigi >=20 > Regards, > Alia >=20 >=20 > On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone > wrote: > Hi Alia >=20 > thanks for the review. >=20 > I have just one comment right in the middle of your review. >=20 > > On 05 Mar 2015, at 16:14, Alia Atlas > wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-lisp-introduction-12: Discuss > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html = > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ = > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > I support Adrian's discuss. In a similar vein: > > > > In Sec 3.2: Please either remove the claim of "Such LISP capable > > routers, in most cases, only require a software upgrade." or explain > > how you can justify the need to add and remove new encapsulations = and > > handle the various flag triggers and caching at line rate. There is > > no need for such marketing in this document. > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > 1) Sec 1, second paragraph: > > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > > and > > RLOCs (Routing LOCators), both are typically syntactically = identical > > to the current IPv4 and IPv6 addresses." > > > > What does "typically" mean? As far as I'm aware, they are > > syntactically identical. This is reiterated in Sec 3.2; are you = just > > trying to preserve the point of architectural freedom? I've found > > the > > third instance of insisting that the EID or RLOC now is only > > "typically" > > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > > before both should be a ;. > > >=20 > I think that the changes the authors already proposed to Adrian fix = the above Discuss and comments. > Can you check if I am correct? >=20 > =46rom this point down is just typos/grammar, so authors will easily = fix your helpful comments >=20 > thanks again >=20 > ciao >=20 > L. >=20 >=20 >=20 >=20 >=20 > > 2) top paragraph of p.4: > > "The initial motivation in the LISP effort is to be found in the > > routing scalability problem [RFC4984], where, if LISP is = completely > > deployed, the Internet core is populated with RLOCs while Traffic > > Engineering mechanisms are pushed to the Mapping System." > > > > Instead of "LISP is completely deployed" to "LISP were to be > > completely deployed" - making it subjunctive. > > > > 3) Last paragraph in Sec 1: > > "This document describes the LISP architecture, its main > > operational mechanisms as its design rationale." > > > > I think you mean > > > > "This document describes the LISP architecture and its main > > operational mechanisms as well as its design rationale." > > > > 4) In Sec 3.1, second paragraph: > > "Locator/Identifier split: By decoupling the overloaded semantics > > of the current IP addresses the Internet core can be assigned > > identity meaningful addresses and hence, can use aggregation to > > scale." > > I assume that you mean "topologically meaningful addresses" = instead > > of "identity meaningful addresses". > > > > >=20 >=20 --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Alia,

On 05 Mar 2015, at 23:13, Alia = Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the "typically" for EID and = RLOC and the proposed response fixes that as well as the BGP = issues.

I = don't recall seeing the "oh, routers can just do with with a software = upgrade" claim fixed.

because it is lost in a lot of other fixes = ;-)

The authors propose to change = the wording in the following way:

"Adding LISP capabilities to routers does not = mandate hardware changes and can be done via a software = upgrade."

The point authors are = trying to make is not about how to install LISP in your boxes,  is = more about the fact that the protocol 
does not need new = hardware. Obviously you there can be hardware implementations, but as = you rightfully point out, this is 
not the place to = mention them. So, the above sentence looks appropriate, unless we want = to simplify even more and just state:

"Adding LISP capabilities to routers does not = mandate hardware changes."
  
What do you = think?

ciao

Luigi

Regards,
Alia


On Thu, = Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.
=

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> = wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut = this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found = here:
> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> I support Adrian's discuss.  In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable
> routers, in most cases, only require a software upgrade." or = explain
> how you can justify the need to add and remove new encapsulations = and
> handle the various flag triggers and caching at line rate.  = There is
> no need for such marketing in this document.
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) Sec 1, second paragraph:
>   "LISP creates two separate namespaces, EIDs (End-host = IDentifiers)
> and
>   RLOCs (Routing LOCators), both are typically = syntactically identical
>   to the current IPv4 and IPv6 addresses."
>
>   What does "typically" mean?  As far as I'm aware, = they are
>   syntactically identical.  This is reiterated in = Sec 3.2; are you just
>   trying to preserve the point of architectural = freedom?  I've found
> the
>   third instance of insisting that the EID or RLOC now is = only
> "typically"
>   an IPv4 or IPv6 address. Please lose "typically".  = Minorly, the ,
>   before both should be a ;.
>

I think that the changes the authors already proposed to = Adrian fix the above Discuss and comments.
Can you check if I am correct?

=46rom this point down is just typos/grammar, so authors will easily fix = your helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>  "The initial motivation in the LISP effort is to be found in = the
>   routing scalability problem [RFC4984], where, if LISP = is completely
>   deployed, the Internet core is populated with RLOCs = while Traffic
>   Engineering mechanisms are pushed to the Mapping = System."
>
>   Instead of "LISP is completely deployed" to "LISP were = to be
>   completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>   "This document describes the LISP architecture, its = main
>   operational mechanisms as its design rationale."
>
>   I think you mean
>
>   "This document describes the LISP architecture and its = main
>   operational mechanisms as well as its design = rationale."
>
> 4) In Sec 3.1, second paragraph:
>   "Locator/Identifier split: By decoupling the overloaded = semantics
>      of the current IP addresses the Internet core = can be assigned
>      identity meaningful addresses and hence, can = use aggregation to
>      scale."
>   I assume that you mean "topologically meaningful = addresses" instead
>   of "identity meaningful addresses".
>
>



= --Apple-Mail=_74A9DCD6-244C-49B3-BEB0-8187C581856B-- From nobody Fri Mar 6 02:57:39 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF36A1A004A for ; Fri, 6 Mar 2015 02:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IicHL3AFRom for ; Fri, 6 Mar 2015 02:57:36 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DC71A036E for ; Fri, 6 Mar 2015 02:57:35 -0800 (PST) Received: by wghl2 with SMTP id l2so15467796wgh.8 for ; Fri, 06 Mar 2015 02:57:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=iDe3b1xzcLdLDAi5cPfkd9LAArE5CHdZpK9M9OFnsrE=; b=TSdKdxzpu87q/5tx91iWhyjApyX5zLc4kn8SFDtxAk2kvHTPZaovA6GwpPcyCXYl48 5SucNPxpH/56W/aIao6v1gUpxCKCKpiidcnPgX8Cky0vBt6nXKlURSjCl6uMkHMgdTQA Y4TnIDtpuJOchQviKtu6nHyy8PWm4j2waRixZKxARTpI7fB2VbpaWLPgFF/6Xu4U84sx znDuKOSljeVAVyhjx+DJJE/aGf8iaXbNl/hfpaVQltjxVroqUuapLiJ8dDX63kqr/cTr 2vT9XKRAuCpOeDlPCVSa8j5XJOvTT2NcZv9ip+3V8U5MwA/Y93haOq8wzPA4xKM585OL Z6VQ== X-Gm-Message-State: ALoCoQlde/rEWeVbc2Blx95z/qkw3Rdnuo58KroK/0mXRu+6HeNdk+0h1rsnI7Uv/kWOETn7Rhlp X-Received: by 10.180.80.9 with SMTP id n9mr31739679wix.34.1425639454699; Fri, 06 Mar 2015 02:57:34 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:cdf2:2315:ca0b:e2fa? ([2001:660:330f:a4:cdf2:2315:ca0b:e2fa]) by mx.google.com with ESMTPSA id 17sm14399460wjt.45.2015.03.06.02.57.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 02:57:32 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_78AF41E1-1DC8-4ED8-80D6-CBA5190BABD2" Date: Fri, 6 Mar 2015 11:57:33 +0100 References: <4BC9B4D4-175E-4347-887A-8BD0B956C523@gigix.net> To: LISP mailing list list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [lisp] Fwd: LISP WG - Call for Agenda Items X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:57:37 -0000 --Apple-Mail=_78AF41E1-1DC8-4ED8-80D6-CBA5190BABD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, just a reminder in case you want to present or discuss something during = the next LISP WG meeting. ciao L. > Begin forwarded message: >=20 > From: Luigi Iannone > Subject: LISP WG - Call for Agenda Items > Date: 2 Mar 2015 10:48:12 CET > Cc: "Joel M. Halpern" , Damien Saucez = , Wassim Haddad > To: LISP mailing list list >=20 >=20 > Hi All, >=20 > The final agenda for the IETF 92 @ Dallas has been published = (https://datatracker.ietf.org/meeting/92/agenda.html = ) >=20 > The LISP WG is scheduled to meet on Monday, March 23th, 2015, from = 1300 to 1500 (two hours) >=20 > Please send your requests for agenda items (Presenter=E2=80=99s name, = ppt title, slot duration)=20 > to lisp-chairs@tools.ietf.org by = Sunday, March 8th, 2015. >=20 > Chairs are going to prioritize requests based on the charter and = milestones. >=20 > ciao >=20 > Luigi >=20 >=20 --Apple-Mail=_78AF41E1-1DC8-4ED8-80D6-CBA5190BABD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

just = a reminder in case you want to present or discuss something during the = next LISP WG meeting.

ciao

L.


Begin = forwarded message:

From: = Luigi Iannone <ggx@gigix.net>
Subject: = LISP WG - Call = for Agenda Items
Date: 2 = Mar 2015 10:48:12 CET
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Damien Saucez <damien.saucez@gmail.com>, Wassim Haddad <wassim.haddad@ericsson.com>
To: = LISP mailing list list <lisp@ietf.org>


Hi All,

The final agenda for the IETF 92 @ = Dallas has been published (https://datatracker.ietf.org/meeting/92/agenda.html)
<= div class=3D"">
The LISP WG  is = scheduled to meet on Monday, March 23th, 2015, from 1300 to 1500 (two = hours)

Please send your requests for agenda items = (Presenter=E2=80=99s name, ppt title, slot duration) 
to lisp-chairs@tools.ietf.org by Sunday, March 8th, = 2015.

Chairs are going to prioritize requests = based on the charter and = milestones.

ciao

Luigi



= --Apple-Mail=_78AF41E1-1DC8-4ED8-80D6-CBA5190BABD2-- From nobody Fri Mar 6 06:26:05 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3181ACDF2; Fri, 6 Mar 2015 06:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aODbPGqfePdt; Fri, 6 Mar 2015 06:25:59 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F981A1DBE; Fri, 6 Mar 2015 06:25:59 -0800 (PST) Received: by obcwo20 with SMTP id wo20so20849248obc.5; Fri, 06 Mar 2015 06:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kXoPM/aVeRN9Sd1EQ0fMaYmTDFtWsCZWvdb94ZAnzSE=; b=VEAsDWmcpVus3FnLZzU8owUaUg+xIaCmHsOQ9soZ3c34rync8ziSDjc79jfE6dHSTl +7/MkNEDTVYNvdyRPARRszL8ILNDjXvQqljuV/QErPeJKd9mvrnfn+cjZmR7s3eze+dP W/hJCofwQ5UhmPov+dm3eauQENrhNdUGiF1en+pawNRArNjuTvJQKFkGAHn+f68wkS9H FQYYo34ntkLMe4FHbw5Jd1l4DA9fIYVt4V0+mM/n47eD0nKw63IT1NoMsDF9aiD/hxwT bobLVtPSdJf0ngPGLZIIt/RB9RBinv1kVx17lPf7tCEAGuxwqovSDycXqFmUyewZB7hA 8EVQ== MIME-Version: 1.0 X-Received: by 10.60.115.99 with SMTP id jn3mr11216811oeb.68.1425651959181; Fri, 06 Mar 2015 06:25:59 -0800 (PST) Received: by 10.60.97.135 with HTTP; Fri, 6 Mar 2015 06:25:59 -0800 (PST) In-Reply-To: <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> Date: Fri, 6 Mar 2015 09:25:59 -0500 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=089e0116126e99b81d05109f76e6 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:26:03 -0000 --089e0116126e99b81d05109f76e6 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 6, 2015 at 5:11 AM, Luigi Iannone wrote: > Hi Alia, > > On 05 Mar 2015, at 23:13, Alia Atlas wrote: > > Hi Luigi, > > Yes, Adrian also picked up on the "typically" for EID and RLOC and the > proposed response fixes that as well as the BGP issues. > > I don't recall seeing the "oh, routers can just do with with a software > upgrade" claim fixed. > > > because it is lost in a lot of other fixes ;-) > > The authors propose to change the wording in the following way: > > "Adding LISP capabilities to routers does not mandate hardware changes and > can be done via a software upgrade." > > The point authors are trying to make is not about how to install LISP in > your boxes, is more about the fact that the protocol > does not need new hardware. Obviously you there can be hardware > implementations, but as you rightfully point out, this is > not the place to mention them. So, the above sentence looks appropriate, > unless we want to simplify even more and just state: > > "Adding LISP capabilities to routers does not mandate hardware changes." > > What do you think? > Just take out the whole sentence. It adds nothing except inaccuracy and marketing. Alia > ciao > > Luigi > > > Regards, > Alia > > > On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone wrote: > >> Hi Alia >> >> thanks for the review. >> >> I have just one comment right in the middle of your review. >> >> > On 05 Mar 2015, at 16:14, Alia Atlas wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-lisp-introduction-12: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > I support Adrian's discuss. In a similar vein: >> > >> > In Sec 3.2: Please either remove the claim of "Such LISP capable >> > routers, in most cases, only require a software upgrade." or explain >> > how you can justify the need to add and remove new encapsulations and >> > handle the various flag triggers and caching at line rate. There is >> > no need for such marketing in this document. >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > 1) Sec 1, second paragraph: >> > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) >> > and >> > RLOCs (Routing LOCators), both are typically syntactically identical >> > to the current IPv4 and IPv6 addresses." >> > >> > What does "typically" mean? As far as I'm aware, they are >> > syntactically identical. This is reiterated in Sec 3.2; are you just >> > trying to preserve the point of architectural freedom? I've found >> > the >> > third instance of insisting that the EID or RLOC now is only >> > "typically" >> > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , >> > before both should be a ;. >> > >> >> I think that the changes the authors already proposed to Adrian fix the >> above Discuss and comments. >> Can you check if I am correct? >> >> From this point down is just typos/grammar, so authors will easily fix >> your helpful comments >> >> thanks again >> >> ciao >> >> L. >> >> >> >> >> >> > 2) top paragraph of p.4: >> > "The initial motivation in the LISP effort is to be found in the >> > routing scalability problem [RFC4984], where, if LISP is completely >> > deployed, the Internet core is populated with RLOCs while Traffic >> > Engineering mechanisms are pushed to the Mapping System." >> > >> > Instead of "LISP is completely deployed" to "LISP were to be >> > completely deployed" - making it subjunctive. >> > >> > 3) Last paragraph in Sec 1: >> > "This document describes the LISP architecture, its main >> > operational mechanisms as its design rationale." >> > >> > I think you mean >> > >> > "This document describes the LISP architecture and its main >> > operational mechanisms as well as its design rationale." >> > >> > 4) In Sec 3.1, second paragraph: >> > "Locator/Identifier split: By decoupling the overloaded semantics >> > of the current IP addresses the Internet core can be assigned >> > identity meaningful addresses and hence, can use aggregation to >> > scale." >> > I assume that you mean "topologically meaningful addresses" instead >> > of "identity meaningful addresses". >> > >> > >> >> > > --089e0116126e99b81d05109f76e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 6, 2015 at 5:11 AM, Luigi Iannone <ggx@gigix.net> wrote:=
Hi A= lia,

On 05 Mar= 2015, at 23:13, Alia Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the "typic= ally" for EID and RLOC and the proposed response fixes that as well as= the BGP issues.

I don't recall seeing the &qu= ot;oh, routers can just do with with a software upgrade" claim fixed.<= /div>

because it is lost= in a lot of other fixes ;-)

The authors propose t= o change the wording in the following way:

"A= dding LISP capabilities to routers does not mandate hardware changes and ca= n be done via a software upgrade."

The point = authors are trying to make is not about how to install LISP in your boxes, = =C2=A0is more about the fact that the protocol=C2=A0
does not nee= d new hardware. Obviously you there can be hardware implementations, but as= you rightfully point out, this is=C2=A0
not the place to mention= them. So, the above sentence looks appropriate, unless we want to simplify= even more and just state:

"Adding LISP capab= ilities to routers does not mandate hardware changes."
=C2= =A0=C2=A0
What do you think?
=

Just take out the whole sentence.=C2=A0 It adds nothing= except inaccuracy and marketing.

Alia=C2=A0
=

=C2=A0
ciao

Luigi
<= /span>


Regards,
Alia


On Thu, Mar 5, 2= 015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-intro= duction/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I support Adrian's discuss.=C2=A0 In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable<= br> > routers, in most cases, only require a software upgrade." or expl= ain
> how you can justify the need to add and remove new encapsulations and<= br> > handle the various flag triggers and caching at line rate.=C2=A0 There= is
> no need for such marketing in this document.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) Sec 1, second paragraph:
>=C2=A0 =C2=A0"LISP creates two separate namespaces, EIDs (End-host= IDentifiers)
> and
>=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically= identical
>=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses."
>
>=C2=A0 =C2=A0What does "typically" mean?=C2=A0 As far as I= 9;m aware, they are
>=C2=A0 =C2=A0syntactically identical.=C2=A0 This is reiterated in Sec 3= .2; are you just
>=C2=A0 =C2=A0trying to preserve the point of architectural freedom?=C2= =A0 I've found
> the
>=C2=A0 =C2=A0third instance of insisting that the EID or RLOC now is on= ly
> "typically"
>=C2=A0 =C2=A0an IPv4 or IPv6 address. Please lose "typically"= .=C2=A0 Minorly, the ,
>=C2=A0 =C2=A0before both should be a ;.
>

I think that the changes the authors already proposed to Adrian= fix the above Discuss and comments.
Can you check if I am correct?

>From this point down is just typos/grammar, so authors will easily fix your= helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>=C2=A0 "The initial motivation in the LISP effort is to be found i= n the
>=C2=A0 =C2=A0routing scalability problem [RFC4984], where, if LISP is c= ompletely
>=C2=A0 =C2=A0deployed, the Internet core is populated with RLOCs while = Traffic
>=C2=A0 =C2=A0Engineering mechanisms are pushed to the Mapping System.&q= uot;
>
>=C2=A0 =C2=A0Instead of "LISP is completely deployed" to &quo= t;LISP were to be
>=C2=A0 =C2=A0completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>=C2=A0 =C2=A0"This document describes the LISP architecture, its m= ain
>=C2=A0 =C2=A0operational mechanisms as its design rationale."
>
>=C2=A0 =C2=A0I think you mean
>
>=C2=A0 =C2=A0"This document describes the LISP architecture and it= s main
>=C2=A0 =C2=A0operational mechanisms as well as its design rationale.&qu= ot;
>
> 4) In Sec 3.1, second paragraph:
>=C2=A0 =C2=A0"Locator/Identifier split: By decoupling the overload= ed semantics
>=C2=A0 =C2=A0 =C2=A0 of the current IP addresses the Internet core can = be assigned
>=C2=A0 =C2=A0 =C2=A0 identity meaningful addresses and hence, can use a= ggregation to
>=C2=A0 =C2=A0 =C2=A0 scale."
>=C2=A0 =C2=A0I assume that you mean "topologically meaningful addr= esses" instead
>=C2=A0 =C2=A0of "identity meaningful addresses".
>
>



--089e0116126e99b81d05109f76e6-- From nobody Fri Mar 6 06:26:14 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8CDF41ACE16; Fri, 6 Mar 2015 06:26:03 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3181ACDF2; Fri, 6 Mar 2015 06:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aODbPGqfePdt; Fri, 6 Mar 2015 06:25:59 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F981A1DBE; Fri, 6 Mar 2015 06:25:59 -0800 (PST) Received: by obcwo20 with SMTP id wo20so20849248obc.5; Fri, 06 Mar 2015 06:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kXoPM/aVeRN9Sd1EQ0fMaYmTDFtWsCZWvdb94ZAnzSE=; b=VEAsDWmcpVus3FnLZzU8owUaUg+xIaCmHsOQ9soZ3c34rync8ziSDjc79jfE6dHSTl +7/MkNEDTVYNvdyRPARRszL8ILNDjXvQqljuV/QErPeJKd9mvrnfn+cjZmR7s3eze+dP W/hJCofwQ5UhmPov+dm3eauQENrhNdUGiF1en+pawNRArNjuTvJQKFkGAHn+f68wkS9H FQYYo34ntkLMe4FHbw5Jd1l4DA9fIYVt4V0+mM/n47eD0nKw63IT1NoMsDF9aiD/hxwT bobLVtPSdJf0ngPGLZIIt/RB9RBinv1kVx17lPf7tCEAGuxwqovSDycXqFmUyewZB7hA 8EVQ== MIME-Version: 1.0 X-Received: by 10.60.115.99 with SMTP id jn3mr11216811oeb.68.1425651959181; Fri, 06 Mar 2015 06:25:59 -0800 (PST) Received: by 10.60.97.135 with HTTP; Fri, 6 Mar 2015 06:25:59 -0800 (PST) In-Reply-To: <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> Date: Fri, 6 Mar 2015 09:25:59 -0500 Message-ID: From: Alia Atlas To: Luigi Iannone Content-Type: multipart/alternative; boundary=089e0116126e99b81d05109f76e6 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:26:03 -0000 --089e0116126e99b81d05109f76e6 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 6, 2015 at 5:11 AM, Luigi Iannone wrote: > Hi Alia, > > On 05 Mar 2015, at 23:13, Alia Atlas wrote: > > Hi Luigi, > > Yes, Adrian also picked up on the "typically" for EID and RLOC and the > proposed response fixes that as well as the BGP issues. > > I don't recall seeing the "oh, routers can just do with with a software > upgrade" claim fixed. > > > because it is lost in a lot of other fixes ;-) > > The authors propose to change the wording in the following way: > > "Adding LISP capabilities to routers does not mandate hardware changes and > can be done via a software upgrade." > > The point authors are trying to make is not about how to install LISP in > your boxes, is more about the fact that the protocol > does not need new hardware. Obviously you there can be hardware > implementations, but as you rightfully point out, this is > not the place to mention them. So, the above sentence looks appropriate, > unless we want to simplify even more and just state: > > "Adding LISP capabilities to routers does not mandate hardware changes." > > What do you think? > Just take out the whole sentence. It adds nothing except inaccuracy and marketing. Alia > ciao > > Luigi > > > Regards, > Alia > > > On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone wrote: > >> Hi Alia >> >> thanks for the review. >> >> I have just one comment right in the middle of your review. >> >> > On 05 Mar 2015, at 16:14, Alia Atlas wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-lisp-introduction-12: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > I support Adrian's discuss. In a similar vein: >> > >> > In Sec 3.2: Please either remove the claim of "Such LISP capable >> > routers, in most cases, only require a software upgrade." or explain >> > how you can justify the need to add and remove new encapsulations and >> > handle the various flag triggers and caching at line rate. There is >> > no need for such marketing in this document. >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > 1) Sec 1, second paragraph: >> > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) >> > and >> > RLOCs (Routing LOCators), both are typically syntactically identical >> > to the current IPv4 and IPv6 addresses." >> > >> > What does "typically" mean? As far as I'm aware, they are >> > syntactically identical. This is reiterated in Sec 3.2; are you just >> > trying to preserve the point of architectural freedom? I've found >> > the >> > third instance of insisting that the EID or RLOC now is only >> > "typically" >> > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , >> > before both should be a ;. >> > >> >> I think that the changes the authors already proposed to Adrian fix the >> above Discuss and comments. >> Can you check if I am correct? >> >> From this point down is just typos/grammar, so authors will easily fix >> your helpful comments >> >> thanks again >> >> ciao >> >> L. >> >> >> >> >> >> > 2) top paragraph of p.4: >> > "The initial motivation in the LISP effort is to be found in the >> > routing scalability problem [RFC4984], where, if LISP is completely >> > deployed, the Internet core is populated with RLOCs while Traffic >> > Engineering mechanisms are pushed to the Mapping System." >> > >> > Instead of "LISP is completely deployed" to "LISP were to be >> > completely deployed" - making it subjunctive. >> > >> > 3) Last paragraph in Sec 1: >> > "This document describes the LISP architecture, its main >> > operational mechanisms as its design rationale." >> > >> > I think you mean >> > >> > "This document describes the LISP architecture and its main >> > operational mechanisms as well as its design rationale." >> > >> > 4) In Sec 3.1, second paragraph: >> > "Locator/Identifier split: By decoupling the overloaded semantics >> > of the current IP addresses the Internet core can be assigned >> > identity meaningful addresses and hence, can use aggregation to >> > scale." >> > I assume that you mean "topologically meaningful addresses" instead >> > of "identity meaningful addresses". >> > >> > >> >> > > --089e0116126e99b81d05109f76e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 6, 2015 at 5:11 AM, Luigi Iannone <ggx@gigix.net> wrote:=
Hi A= lia,

On 05 Mar= 2015, at 23:13, Alia Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the "typic= ally" for EID and RLOC and the proposed response fixes that as well as= the BGP issues.

I don't recall seeing the &qu= ot;oh, routers can just do with with a software upgrade" claim fixed.<= /div>

because it is lost= in a lot of other fixes ;-)

The authors propose t= o change the wording in the following way:

"A= dding LISP capabilities to routers does not mandate hardware changes and ca= n be done via a software upgrade."

The point = authors are trying to make is not about how to install LISP in your boxes, = =C2=A0is more about the fact that the protocol=C2=A0
does not nee= d new hardware. Obviously you there can be hardware implementations, but as= you rightfully point out, this is=C2=A0
not the place to mention= them. So, the above sentence looks appropriate, unless we want to simplify= even more and just state:

"Adding LISP capab= ilities to routers does not mandate hardware changes."
=C2= =A0=C2=A0
What do you think?
=

Just take out the whole sentence.=C2=A0 It adds nothing= except inaccuracy and marketing.

Alia=C2=A0
=

=C2=A0
ciao

Luigi
<= /span>


Regards,
Alia


On Thu, Mar 5, 2= 015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your review.

> On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-intro= duction/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I support Adrian's discuss.=C2=A0 In a similar vein:
>
> In Sec 3.2: Please either remove the claim of "Such LISP capable<= br> > routers, in most cases, only require a software upgrade." or expl= ain
> how you can justify the need to add and remove new encapsulations and<= br> > handle the various flag triggers and caching at line rate.=C2=A0 There= is
> no need for such marketing in this document.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> 1) Sec 1, second paragraph:
>=C2=A0 =C2=A0"LISP creates two separate namespaces, EIDs (End-host= IDentifiers)
> and
>=C2=A0 =C2=A0RLOCs (Routing LOCators), both are typically syntactically= identical
>=C2=A0 =C2=A0to the current IPv4 and IPv6 addresses."
>
>=C2=A0 =C2=A0What does "typically" mean?=C2=A0 As far as I= 9;m aware, they are
>=C2=A0 =C2=A0syntactically identical.=C2=A0 This is reiterated in Sec 3= .2; are you just
>=C2=A0 =C2=A0trying to preserve the point of architectural freedom?=C2= =A0 I've found
> the
>=C2=A0 =C2=A0third instance of insisting that the EID or RLOC now is on= ly
> "typically"
>=C2=A0 =C2=A0an IPv4 or IPv6 address. Please lose "typically"= .=C2=A0 Minorly, the ,
>=C2=A0 =C2=A0before both should be a ;.
>

I think that the changes the authors already proposed to Adrian= fix the above Discuss and comments.
Can you check if I am correct?

>From this point down is just typos/grammar, so authors will easily fix your= helpful comments

thanks again

ciao

L.





> 2) top paragraph of p.4:
>=C2=A0 "The initial motivation in the LISP effort is to be found i= n the
>=C2=A0 =C2=A0routing scalability problem [RFC4984], where, if LISP is c= ompletely
>=C2=A0 =C2=A0deployed, the Internet core is populated with RLOCs while = Traffic
>=C2=A0 =C2=A0Engineering mechanisms are pushed to the Mapping System.&q= uot;
>
>=C2=A0 =C2=A0Instead of "LISP is completely deployed" to &quo= t;LISP were to be
>=C2=A0 =C2=A0completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>=C2=A0 =C2=A0"This document describes the LISP architecture, its m= ain
>=C2=A0 =C2=A0operational mechanisms as its design rationale."
>
>=C2=A0 =C2=A0I think you mean
>
>=C2=A0 =C2=A0"This document describes the LISP architecture and it= s main
>=C2=A0 =C2=A0operational mechanisms as well as its design rationale.&qu= ot;
>
> 4) In Sec 3.1, second paragraph:
>=C2=A0 =C2=A0"Locator/Identifier split: By decoupling the overload= ed semantics
>=C2=A0 =C2=A0 =C2=A0 of the current IP addresses the Internet core can = be assigned
>=C2=A0 =C2=A0 =C2=A0 identity meaningful addresses and hence, can use a= ggregation to
>=C2=A0 =C2=A0 =C2=A0 scale."
>=C2=A0 =C2=A0I assume that you mean "topologically meaningful addr= esses" instead
>=C2=A0 =C2=A0of "identity meaningful addresses".
>
>



--089e0116126e99b81d05109f76e6-- From nobody Fri Mar 6 08:14:34 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0E9EC1A909A; Thu, 5 Mar 2015 16:31:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E5D1A9084 for ; Thu, 5 Mar 2015 16:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0yRZnt2hS7I for ; Thu, 5 Mar 2015 16:31:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30931A6FFA for ; Thu, 5 Mar 2015 16:31:11 -0800 (PST) Received: from p130.piuha.net ([2a00:1d50:2::130]:51905) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YTgAZ-0007B4-4z for draft-ietf-lisp-introduction.all@tools.ietf.org; Thu, 05 Mar 2015 16:31:11 -0800 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E338C2CEDA; Thu, 5 Mar 2015 15:53:10 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNFXdD9bTQxb; Thu, 5 Mar 2015 15:53:10 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 0B1FA2CED4; Thu, 5 Mar 2015 15:53:10 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_1681798D-A322-492D-8D7D-36D35B567BCB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <54DB432C.5090607@isode.com> Date: Thu, 5 Mar 2015 15:53:10 +0200 Message-Id: <82500183-B207-47B5-939B-E5F0AD3B9CD4@piuha.net> References: <54DB432C.5090607@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 2a00:1d50:2::130 X-SA-Exim-Rcpt-To: draft-ietf-lisp-introduction.all@tools.ietf.org X-SA-Exim-Mail-From: jari.arkko@piuha.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-lisp-introduction.all@ietf.org Resent-Message-Id: <20150306003111.F30931A6FFA@ietfa.amsl.com> Resent-Date: Thu, 5 Mar 2015 16:31:11 -0800 (PST) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 08:14:33 -0800 Cc: gen-art@ietf.org, draft-ietf-lisp-introduction.all@tools.ietf.org Subject: Re: [lisp] [Gen-art] Gen-ART LC review of draft-ietf-lisp-introduction-11 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 00:31:13 -0000 --Apple-Mail=_1681798D-A322-492D-8D7D-36D35B567BCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your review, Alexey! On 11 Feb 2015, at 13:55, Alexey Melnikov = wrote: > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . >=20 > Please resolve these comments along with any other Last Call comments = you may receive. >=20 > Document: draft-ietf-lisp-introduction-11 > Reviewer: Alexey Melnikov > Review Date: 2015-02-11 > IETF LC End Date: 2015-02-04 > IESG Telechat date: 2015-03-05 >=20 > Summary: This draft is ready for publication as an Informational RFC. >=20 > Thank you for writing this document, I quite enjoyed reading it. >=20 > Major issues: > Minor issues: > Nits/editorial comments: >=20 > In A.1: >=20 > >LISP, as initially conceived, had a number of potential operating = modes, named =92models=92. Although they are note > Typo: not > >used anymore, one occasionally sees mention of them, so they are = briefly described here. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_1681798D-A322-492D-8D7D-36D35B567BCB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU+F/HAAoJEM80gCTQU46q5BgP/jvxV4zSoFw37l6+Xf/TudYz UW8EKiyfzzUjBGd2Y7vpEJJmozyqHyGpqGwDGanu2utgfvoD7X3fFo/r0EvvM8ZP ARlggf2nIe1072NV8+q7/WNc4KvxeNIIjDXAUFl4aJjWsaW3cZC8y/gmS0ohYuSB 4L10VCUwhXE2Iqkj/1Csnn1KFOs9daAn4poaq0/+9AgLc89jJUzOreco3WsZjiHg 7QyQFCM5wvS5hKZXHTHuPuQydOZAWnAbdYTyNjxBUqLuELuZIOsCi7Cl36Z1PWWW H98jslN2Zl7Eph+unbcb8eBToWJjuHa1p3+ZWE5mATtGJ0iO81QA4URdLYNHFWhy NKoCwD0Y7eQd17oQPAc3axZ8v73Sx13+qaV8NCs8ptPFe4COdijfdp5yKO6sMEgY odE7CPsokshENujfs+4A0fy1ABN89+UrcInvA+vGljxpWwuZ42vjEGafOFqATjTH wkcOjmmaTo18RAgDAHxKoD8QyLhCtGrlxvQrNVAjTqZeoj5qmnYtUhRZ7pP2H1/3 GrvvSCosCgglGn3uazYPWIUUBxxkcETwcpfBnoIthMf5NSBLBINnr9+X47zzx4YU YxDfkg4Rswx9fh4wwuP8u91kCiqfXD+4KHGygxwbqg8N/Up+eErE9BOGNt6jmr7H e4Vz2wGiY9qKFzE3sLVm =1A+P -----END PGP SIGNATURE----- --Apple-Mail=_1681798D-A322-492D-8D7D-36D35B567BCB-- From nobody Fri Mar 6 08:54:39 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DD94D1ACF1B; Fri, 6 Mar 2015 08:54:29 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0BB1ACF16 for ; Fri, 6 Mar 2015 08:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvW9_fG-5353 for ; Fri, 6 Mar 2015 08:54:27 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47CE1ACEEC for ; Fri, 6 Mar 2015 08:54:19 -0800 (PST) Received: by wibbs8 with SMTP id bs8so5010199wib.4 for ; Fri, 06 Mar 2015 08:54:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nyccvC6k0wAUiAsLCz1kKmkz7DH+eoRTJCqZdhtywmQ=; b=JuVy5id+DnAuF6RTuG6f/2LmUGWBllwywVRgBd/6c5JziNNN0s+l1nNWqNEMtnboTS 5lOpb3UUFcQ4UZS7rDMSqPrwTifVtosWDFgwei40JSCGQUyJGDTlDb8FedT9YMY3wKSY Jm8pEx0eKvBugjoPKvJDgqZmUShB9U4AVw7Z/+0Awp19ZxcYoXDSOVYVpM2PmZwjwdH4 TN4Fu86mJiQuCjyc9IYqxV/t0BxwIA0Ig869Y/5yCcy+Z+AEyIrO3s2O/DUvQ1A3HFH1 w9/PtN+U6/QrF1zXgmAVtNpv0tqccj93v2bwwXCH4i03rxTRs9mHYh0oqDsfvfDmL7dW GVrQ== X-Gm-Message-State: ALoCoQk678WupHfx9j4ZRbW1IpEdIp3Ds1cCzWbLwtmM9j/GsLXLbDhhTzY9KamvPq9XXUFztDwW X-Received: by 10.194.94.1 with SMTP id cy1mr30436737wjb.127.1425660858567; Fri, 06 Mar 2015 08:54:18 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:5180:10da:abb3:f88a? ([2001:660:330f:a4:5180:10da:abb3:f88a]) by mx.google.com with ESMTPSA id ch6sm15712139wjc.3.2015.03.06.08.54.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 08:54:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Fri, 6 Mar 2015 17:54:18 +0100 Message-Id: <0D06CF17-34C8-47C8-9E70-6A265E22FA7E@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 16:54:30 -0000 --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 06 Mar 2015, at 15:25, Alia Atlas wrote: >=20 > On Fri, Mar 6, 2015 at 5:11 AM, Luigi Iannone > wrote: > Hi Alia, >=20 >> On 05 Mar 2015, at 23:13, Alia Atlas > wrote: >>=20 >> Hi Luigi, >>=20 >> Yes, Adrian also picked up on the "typically" for EID and RLOC and = the proposed response fixes that as well as the BGP issues. >>=20 >> I don't recall seeing the "oh, routers can just do with with a = software upgrade" claim fixed. >=20 > because it is lost in a lot of other fixes ;-) >=20 > The authors propose to change the wording in the following way: >=20 > "Adding LISP capabilities to routers does not mandate hardware changes = and can be done via a software upgrade." >=20 > The point authors are trying to make is not about how to install LISP = in your boxes, is more about the fact that the protocol=20 > does not need new hardware. Obviously you there can be hardware = implementations, but as you rightfully point out, this is=20 > not the place to mention them. So, the above sentence looks = appropriate, unless we want to simplify even more and just state: >=20 > "Adding LISP capabilities to routers does not mandate hardware = changes." > =20 > What do you think? >=20 > Just take out the whole sentence. It adds nothing except inaccuracy = and marketing. I can live with that.=20 If the authors agree, than let=E2=80=99s delete the sentence. ciao Luigi >=20 > Alia=20 >=20 > =20 > ciao >=20 > Luigi >=20 >>=20 >> Regards, >> Alia >>=20 >>=20 >> On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone > wrote: >> Hi Alia >>=20 >> thanks for the review. >>=20 >> I have just one comment right in the middle of your review. >>=20 >> > On 05 Mar 2015, at 16:14, Alia Atlas > wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-lisp-introduction-12: Discuss >> > >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> > >> > >> > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html = >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ = >> > >> > >> > >> > = ---------------------------------------------------------------------- >> > DISCUSS: >> > = ---------------------------------------------------------------------- >> > >> > I support Adrian's discuss. In a similar vein: >> > >> > In Sec 3.2: Please either remove the claim of "Such LISP capable >> > routers, in most cases, only require a software upgrade." or = explain >> > how you can justify the need to add and remove new encapsulations = and >> > handle the various flag triggers and caching at line rate. There = is >> > no need for such marketing in this document. >> > >> > >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > >> > 1) Sec 1, second paragraph: >> > "LISP creates two separate namespaces, EIDs (End-host = IDentifiers) >> > and >> > RLOCs (Routing LOCators), both are typically syntactically = identical >> > to the current IPv4 and IPv6 addresses." >> > >> > What does "typically" mean? As far as I'm aware, they are >> > syntactically identical. This is reiterated in Sec 3.2; are you = just >> > trying to preserve the point of architectural freedom? I've = found >> > the >> > third instance of insisting that the EID or RLOC now is only >> > "typically" >> > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , >> > before both should be a ;. >> > >>=20 >> I think that the changes the authors already proposed to Adrian fix = the above Discuss and comments. >> Can you check if I am correct? >>=20 >> =46rom this point down is just typos/grammar, so authors will easily = fix your helpful comments >>=20 >> thanks again >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>=20 >>=20 >>=20 >> > 2) top paragraph of p.4: >> > "The initial motivation in the LISP effort is to be found in the >> > routing scalability problem [RFC4984], where, if LISP is = completely >> > deployed, the Internet core is populated with RLOCs while Traffic >> > Engineering mechanisms are pushed to the Mapping System." >> > >> > Instead of "LISP is completely deployed" to "LISP were to be >> > completely deployed" - making it subjunctive. >> > >> > 3) Last paragraph in Sec 1: >> > "This document describes the LISP architecture, its main >> > operational mechanisms as its design rationale." >> > >> > I think you mean >> > >> > "This document describes the LISP architecture and its main >> > operational mechanisms as well as its design rationale." >> > >> > 4) In Sec 3.1, second paragraph: >> > "Locator/Identifier split: By decoupling the overloaded semantics >> > of the current IP addresses the Internet core can be assigned >> > identity meaningful addresses and hence, can use aggregation = to >> > scale." >> > I assume that you mean "topologically meaningful addresses" = instead >> > of "identity meaningful addresses". >> > >> > --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 06 Mar 2015, at 15:25, Alia Atlas <akatlas@gmail.com> = wrote:

On Fri, = Mar 6, 2015 at 5:11 AM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia,

On 05 Mar 2015, at 23:13, Alia Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the = "typically" for EID and RLOC and the proposed response fixes that as = well as the BGP issues.

I don't recall seeing the "oh, routers can just do with with = a software upgrade" claim fixed.

because it is = lost in a lot of other fixes ;-)

The authors propose to change the = wording in the following way:

"Adding LISP capabilities to routers = does not mandate hardware changes and can be done via a software = upgrade."

The = point authors are trying to make is not about how to install LISP in = your boxes,  is more about the fact that the = protocol 
does not need new hardware. = Obviously you there can be hardware implementations, but as you = rightfully point out, this is 
not the place = to mention them. So, the above sentence looks appropriate, unless we = want to simplify even more and just state:

"Adding LISP capabilities to routers = does not mandate hardware changes."
  
What do you = think?

Just take out the whole sentence.  = It adds nothing except inaccuracy and = marketing.

I can live with that. 

If the authors agree, than let=E2=80=99s delete = the sentence.

ciao

Luigi






Alia 

 
ciao

Luigi


Regards,
Alia


On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your = review.

> = On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position = for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the = subject line intact and reply to all
> email addresses = included in the To and CC lines. (Feel free to cut this
>= introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The = document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> I support Adrian's discuss.  In = a similar vein:
>
> In Sec 3.2: Please = either remove the claim of "Such LISP capable
> = routers, in most cases, only require a software upgrade." or explain
> how you can justify the need to add and remove new = encapsulations and
> handle the various flag triggers = and caching at line rate.  There is
> no need for = such marketing in this document.
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) Sec 1, second paragraph:
>   "LISP creates two separate namespaces, EIDs = (End-host IDentifiers)
> and
>  =  RLOCs (Routing LOCators), both are typically syntactically = identical
>   to the current IPv4 and IPv6 = addresses."
>
>   What does = "typically" mean?  As far as I'm aware, they are
>   syntactically identical.  This is = reiterated in Sec 3.2; are you just
>  =  trying to preserve the point of architectural freedom?  I've = found
> the
>   third = instance of insisting that the EID or RLOC now is only
> = "typically"
>   an IPv4 or IPv6 address. = Please lose "typically".  Minorly, the ,
>  =  before both should be a ;.
>

I think that the changes the authors already = proposed to Adrian fix the above Discuss and comments.
Can = you check if I am correct?

=46rom this = point down is just typos/grammar, so authors will easily fix your = helpful comments

thanks again

ciao

L.





> 2) top = paragraph of p.4:
>  "The initial motivation in = the LISP effort is to be found in the
>  =  routing scalability problem [RFC4984], where, if LISP is = completely
>   deployed, the Internet core is = populated with RLOCs while Traffic
>  =  Engineering mechanisms are pushed to the Mapping System."
>
>   Instead of "LISP is = completely deployed" to "LISP were to be
>  =  completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>  =  "This document describes the LISP architecture, its main
>   operational mechanisms as its design = rationale."
>
>   I think = you mean
>
>   "This = document describes the LISP architecture and its main
>   operational mechanisms as well as its design = rationale."
>
> 4) In Sec 3.1, second = paragraph:
>   "Locator/Identifier split: By = decoupling the overloaded semantics
>    =   of the current IP addresses the Internet core can be assigned
>      identity meaningful addresses and = hence, can use aggregation to
>      = scale."
>   I assume that you mean = "topologically meaningful addresses" instead
>  =  of "identity meaningful addresses".
>
>

= --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08-- From nobody Fri Mar 6 08:54:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4558E1ACEEC for ; Fri, 6 Mar 2015 08:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSVdWmFs0lXi for ; Fri, 6 Mar 2015 08:54:28 -0800 (PST) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73AB1ACEF4 for ; Fri, 6 Mar 2015 08:54:19 -0800 (PST) Received: by wesu56 with SMTP id u56so60639045wes.10 for ; Fri, 06 Mar 2015 08:54:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nyccvC6k0wAUiAsLCz1kKmkz7DH+eoRTJCqZdhtywmQ=; b=LyQbfaW1gTBcrPAs9s7b5XZXj4SKmbnj0h/h/3oajJKhkquYGVlpghlGf/Wmo4ZGuj fzFuEOcV7ejLCtKFzlSipExbkDaowvMmy6KD0/LpFT7+NELMDKV4wGrAzAaDQIdbkuPY lUCsNuGKspfczv5Sio4nqrg2jLkT9Gx/y5PRvXPcipzHuNwBOVxW1Pwd5SlxzddhK8Y1 Eu1pbiGpn1Jr5WhlTrlDuQBYYgozmW1nJhadKWmI5JuQAOhjk//KvuwhaNiKbL5jlinZ dZwyWFUA7XayWk8qT7NBe4VwhzKR9zjyZLm+xejEckl7UfXqcyo/BXvI20/YvYD5uHHf 1AOQ== X-Gm-Message-State: ALoCoQl6OAqWU12aFkMgenvoycHkYE0TyGinYotTVV+9eJAdPPAcBYZms+FLHzlYebkPVq77EWih X-Received: by 10.194.94.1 with SMTP id cy1mr30436737wjb.127.1425660858567; Fri, 06 Mar 2015 08:54:18 -0800 (PST) Received: from ?IPv6:2001:660:330f:a4:5180:10da:abb3:f88a? ([2001:660:330f:a4:5180:10da:abb3:f88a]) by mx.google.com with ESMTPSA id ch6sm15712139wjc.3.2015.03.06.08.54.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 08:54:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Fri, 6 Mar 2015 17:54:18 +0100 Message-Id: <0D06CF17-34C8-47C8-9E70-6A265E22FA7E@gigix.net> References: <20150305151407.1551.26393.idtracker@ietfa.amsl.com> <55FBB71E-E4FB-4F19-9E41-47AF279AA7EB@gigix.net> To: Alia Atlas X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp Subject: Re: [lisp] Alia Atlas' Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 16:54:30 -0000 --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 06 Mar 2015, at 15:25, Alia Atlas wrote: >=20 > On Fri, Mar 6, 2015 at 5:11 AM, Luigi Iannone > wrote: > Hi Alia, >=20 >> On 05 Mar 2015, at 23:13, Alia Atlas > wrote: >>=20 >> Hi Luigi, >>=20 >> Yes, Adrian also picked up on the "typically" for EID and RLOC and = the proposed response fixes that as well as the BGP issues. >>=20 >> I don't recall seeing the "oh, routers can just do with with a = software upgrade" claim fixed. >=20 > because it is lost in a lot of other fixes ;-) >=20 > The authors propose to change the wording in the following way: >=20 > "Adding LISP capabilities to routers does not mandate hardware changes = and can be done via a software upgrade." >=20 > The point authors are trying to make is not about how to install LISP = in your boxes, is more about the fact that the protocol=20 > does not need new hardware. Obviously you there can be hardware = implementations, but as you rightfully point out, this is=20 > not the place to mention them. So, the above sentence looks = appropriate, unless we want to simplify even more and just state: >=20 > "Adding LISP capabilities to routers does not mandate hardware = changes." > =20 > What do you think? >=20 > Just take out the whole sentence. It adds nothing except inaccuracy = and marketing. I can live with that.=20 If the authors agree, than let=E2=80=99s delete the sentence. ciao Luigi >=20 > Alia=20 >=20 > =20 > ciao >=20 > Luigi >=20 >>=20 >> Regards, >> Alia >>=20 >>=20 >> On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone > wrote: >> Hi Alia >>=20 >> thanks for the review. >>=20 >> I have just one comment right in the middle of your review. >>=20 >> > On 05 Mar 2015, at 16:14, Alia Atlas > wrote: >> > >> > Alia Atlas has entered the following ballot position for >> > draft-ietf-lisp-introduction-12: Discuss >> > >> > When responding, please keep the subject line intact and reply to = all >> > email addresses included in the To and CC lines. (Feel free to cut = this >> > introductory paragraph, however.) >> > >> > >> > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html = >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ = >> > >> > >> > >> > = ---------------------------------------------------------------------- >> > DISCUSS: >> > = ---------------------------------------------------------------------- >> > >> > I support Adrian's discuss. In a similar vein: >> > >> > In Sec 3.2: Please either remove the claim of "Such LISP capable >> > routers, in most cases, only require a software upgrade." or = explain >> > how you can justify the need to add and remove new encapsulations = and >> > handle the various flag triggers and caching at line rate. There = is >> > no need for such marketing in this document. >> > >> > >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > >> > 1) Sec 1, second paragraph: >> > "LISP creates two separate namespaces, EIDs (End-host = IDentifiers) >> > and >> > RLOCs (Routing LOCators), both are typically syntactically = identical >> > to the current IPv4 and IPv6 addresses." >> > >> > What does "typically" mean? As far as I'm aware, they are >> > syntactically identical. This is reiterated in Sec 3.2; are you = just >> > trying to preserve the point of architectural freedom? I've = found >> > the >> > third instance of insisting that the EID or RLOC now is only >> > "typically" >> > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , >> > before both should be a ;. >> > >>=20 >> I think that the changes the authors already proposed to Adrian fix = the above Discuss and comments. >> Can you check if I am correct? >>=20 >> =46rom this point down is just typos/grammar, so authors will easily = fix your helpful comments >>=20 >> thanks again >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>=20 >>=20 >>=20 >> > 2) top paragraph of p.4: >> > "The initial motivation in the LISP effort is to be found in the >> > routing scalability problem [RFC4984], where, if LISP is = completely >> > deployed, the Internet core is populated with RLOCs while Traffic >> > Engineering mechanisms are pushed to the Mapping System." >> > >> > Instead of "LISP is completely deployed" to "LISP were to be >> > completely deployed" - making it subjunctive. >> > >> > 3) Last paragraph in Sec 1: >> > "This document describes the LISP architecture, its main >> > operational mechanisms as its design rationale." >> > >> > I think you mean >> > >> > "This document describes the LISP architecture and its main >> > operational mechanisms as well as its design rationale." >> > >> > 4) In Sec 3.1, second paragraph: >> > "Locator/Identifier split: By decoupling the overloaded semantics >> > of the current IP addresses the Internet core can be assigned >> > identity meaningful addresses and hence, can use aggregation = to >> > scale." >> > I assume that you mean "topologically meaningful addresses" = instead >> > of "identity meaningful addresses". >> > >> > --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 06 Mar 2015, at 15:25, Alia Atlas <akatlas@gmail.com> = wrote:

On Fri, = Mar 6, 2015 at 5:11 AM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia,

On 05 Mar 2015, at 23:13, Alia Atlas <akatlas@gmail.com> wrote:

Hi Luigi,

Yes, Adrian also picked up on the = "typically" for EID and RLOC and the proposed response fixes that as = well as the BGP issues.

I don't recall seeing the "oh, routers can just do with with = a software upgrade" claim fixed.

because it is = lost in a lot of other fixes ;-)

The authors propose to change the = wording in the following way:

"Adding LISP capabilities to routers = does not mandate hardware changes and can be done via a software = upgrade."

The = point authors are trying to make is not about how to install LISP in = your boxes,  is more about the fact that the = protocol 
does not need new hardware. = Obviously you there can be hardware implementations, but as you = rightfully point out, this is 
not the place = to mention them. So, the above sentence looks appropriate, unless we = want to simplify even more and just state:

"Adding LISP capabilities to routers = does not mandate hardware changes."
  
What do you = think?

Just take out the whole sentence.  = It adds nothing except inaccuracy and = marketing.

I can live with that. 

If the authors agree, than let=E2=80=99s delete = the sentence.

ciao

Luigi






Alia 

 
ciao

Luigi


Regards,
Alia


On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone <ggx@gigix.net> wrote:
Hi Alia

thanks for the review.

I have just one comment right in the middle of your = review.

> = On 05 Mar 2015, at 16:14, Alia Atlas <akatlas@gmail.com> wrote:
>
> Alia Atlas has entered the following ballot position = for
> draft-ietf-lisp-introduction-12: Discuss
>
> When responding, please keep the = subject line intact and reply to all
> email addresses = included in the To and CC lines. (Feel free to cut this
>= introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The = document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
>
>
>
> = ----------------------------------------------------------------------
> DISCUSS:
> = ----------------------------------------------------------------------
>
> I support Adrian's discuss.  In = a similar vein:
>
> In Sec 3.2: Please = either remove the claim of "Such LISP capable
> = routers, in most cases, only require a software upgrade." or explain
> how you can justify the need to add and remove new = encapsulations and
> handle the various flag triggers = and caching at line rate.  There is
> no need for = such marketing in this document.
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> = ----------------------------------------------------------------------
>
> 1) Sec 1, second paragraph:
>   "LISP creates two separate namespaces, EIDs = (End-host IDentifiers)
> and
>  =  RLOCs (Routing LOCators), both are typically syntactically = identical
>   to the current IPv4 and IPv6 = addresses."
>
>   What does = "typically" mean?  As far as I'm aware, they are
>   syntactically identical.  This is = reiterated in Sec 3.2; are you just
>  =  trying to preserve the point of architectural freedom?  I've = found
> the
>   third = instance of insisting that the EID or RLOC now is only
> = "typically"
>   an IPv4 or IPv6 address. = Please lose "typically".  Minorly, the ,
>  =  before both should be a ;.
>

I think that the changes the authors already = proposed to Adrian fix the above Discuss and comments.
Can = you check if I am correct?

=46rom this = point down is just typos/grammar, so authors will easily fix your = helpful comments

thanks again

ciao

L.





> 2) top = paragraph of p.4:
>  "The initial motivation in = the LISP effort is to be found in the
>  =  routing scalability problem [RFC4984], where, if LISP is = completely
>   deployed, the Internet core is = populated with RLOCs while Traffic
>  =  Engineering mechanisms are pushed to the Mapping System."
>
>   Instead of "LISP is = completely deployed" to "LISP were to be
>  =  completely deployed" - making it subjunctive.
>
> 3) Last paragraph in Sec 1:
>  =  "This document describes the LISP architecture, its main
>   operational mechanisms as its design = rationale."
>
>   I think = you mean
>
>   "This = document describes the LISP architecture and its main
>   operational mechanisms as well as its design = rationale."
>
> 4) In Sec 3.1, second = paragraph:
>   "Locator/Identifier split: By = decoupling the overloaded semantics
>    =   of the current IP addresses the Internet core can be assigned
>      identity meaningful addresses and = hence, can use aggregation to
>      = scale."
>   I assume that you mean = "topologically meaningful addresses" instead
>  =  of "identity meaningful addresses".
>
>

= --Apple-Mail=_24F5C29B-4472-456C-A3B7-C4B96F5EAE08-- From nobody Fri Mar 6 11:12:40 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524CC1A1BE4; Fri, 6 Mar 2015 11:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TUYXuLT_wfe; Fri, 6 Mar 2015 11:12:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4461A6EEC; Fri, 6 Mar 2015 11:12:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306191221.14726.77369.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 11:12:21 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-impact-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:12:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Impact Authors : Damien Saucez Luigi Iannone Albert Cabellos Florin Coras Filename : draft-ietf-lisp-impact-01.txt Pages : 16 Date : 2015-03-06 Abstract: The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the Internet in general and the end-user in particular. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-impact-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-impact-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 12:03:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204491A7023; Fri, 6 Mar 2015 12:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSCyh5BH6O1a; Fri, 6 Mar 2015 12:03:13 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3003A1A700F; Fri, 6 Mar 2015 12:03:13 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K39qX004229; Fri, 6 Mar 2015 20:03:09 GMT Received: from 950129200 (089144213255.atnat0022.highway.a1.net [89.144.213.255]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K24e4003548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2015 20:03:07 GMT From: "Adrian Farrel" To: References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 6 Mar 2015 20:02:05 -0000 Message-ID: <02f201d05848$92394220$b6abc660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIdNdBVPp7LPbNGZv+qHmP8KDM0ewIn3SzznGS9cSA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21382.002 X-TM-AS-Result: No--33.752-10.0-31-10 X-imss-scan-details: No--33.752-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wpmug812qIbzKqaitAbDW1qqvcIF1TcLYDlM ngboKBfFEqKQnEa9DF6T65CxuwIJtxtlRBeFg9jM2Ud/1nepkpNU3K6aV1ad7bP7qOmy9QBUUoJ JXv0NurDmP0EDE8v6ojNXervDb6hc8qconkGQR4gSEYfcJF0pRZlhiS3ydre3WP9qYuzytBL9ph oXIzcVvFJvQPep6+JXibWqJyoFwCeQ7kS+FkQAzpF+9R8v7nzmpKs40Iv4zXcoDMZ3xV44iNRBu 2IPUoRpYx1Ye0eO/X/jCJhKsmTnQVHZxHZPJAqeb0rZzyQrEg1MkOX0UoduuSWrO+SgZCHmiHXG zNYvf0ERkcfW2QvH7qfVr83RVWIvy5j7H7ClYgeWLCkl1lq7B7pZtsuh6XaldROyZB3lVupbXVr r4MMb9UqLuIc287W8QN70OjoNAZ5PDPfmo+ftx0bKkLkJUU4fYtmTggNRdce5IifwYL1+qyXdaT B+fIOxqTQaUessnJwycPsDdl2dA7Wd3Qhj3xBViUPZPmKZOQlAq6/y5AEOOhRZ/9wBMhGs28vyR IpB9YRJ3fwJ/s4z7WQp/kaJaaDjJkzXbc0wOa5Ak58YKWonGWXaGha4V72KIFBEE5CFomLzE7iK wulloVFZ9B5e/g6wDyhvPYLQ4DMH+DiyPUjnmZRrnSy7UTtbXEjKf9fhKaeX1RWcrwojHNmJ86n vpEHqbxCMLwmIJD7Nf0peb0lymHZ+VA6xnTKuffXtKyM+c+sYZdGd023v1ZgWnaLDiGghArfwhX ClRwmSbSv1sT4BsiKAZd9zQifKCJci3xZfAmeeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, 'The IESG' Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:03:16 -0000 Hello Albert, Thanks for your speedy turn-around. >> DISCUSS: >> = ---------------------------------------------------------------------- >> >> In Section 4.2 >> >> On the contrary BGP is a >> push architecture, where the required network state is pushed by >> means of BGP UPDATE messages to BGP speakers. >> >> You will be aware of RFC 5291 and the use of ORF to make BGP a pull- >> mode protocol. >> >> (I won't say to you that LISP is push mode because a Map-Reply >> pushes the mapping information from the map server to the client :-) >> >> So, my advice is to describe LISP in this document and to not make >> comments about other systems. It isn't a beauty contest and it isn't >> wise to try to say "my system is better/different from yours". >> >> The solution is to just remove this sentence. > > Agreed, I=C2=B4ll remove the first sentence. Perfect =20 >> Similarly in 7.1 >> >> BGP is the standard protocol to implement inter-domain routing. = With >> BGP, routing information are propagated along the network and each >> autonomous system can implement its own routing policy that will >> influence the way routing information are propagated. The direct >> consequence is that an autonomous system cannot precisely control = the >> way the traffic will enter the network. >> >> As opposed to BGP, a LISP site can strictly impose via which ETRs = the >> traffic must enter the the LISP site network even though the path >> followed to reach the ETR is not under the control of the LISP = site. >> >> Let's not get into the "BGP this, BGP that" debate. Just remove the >> first paragraph and the first four words of the second paragraph. = That >> way you avoid all contention and write a document about LISP. > > Agreed, I=C2=B4ll remove the first paragraph and first four words of = the=20 > second paragraph. Also perfect. =20 >> COMMENT: >> = ---------------------------------------------------------------------- Please note that Comments are just my observations. You are not obliged = to make changes or pay attention. You just need to reach equilibrium = with your AD. >> Section 1 >> >> I'm really not comfortable with your text... "Indeed and as pointed = out >>by the unpublished Internet Draft by Noel Chiappa [Chiappa]" >> >> This isn't a stable reference and I don't think you need it. You = could >> either rely on the later reference to RFC 4984, reference RFC 6830 >> itself, or take out the aside "and as... ... [Chiappa]" >> > The same reference is cited in RFC4984 and RFC4423, it is preferable > to cite it as it is or cite RFC4984? Per Brian, 4984 would be fine. =20 >> Section 1 has >> >> LISP creates two separate namespaces, EIDs (End-host IDentifiers) = and >> RLOCs (Routing LOCators), both are typically syntactically = identical >> to the current IPv4 and IPv6 addresses. >> >> The "typically" here opens a bit of door. >> >> RFC 6830 explains this in the definitions of EID, but seems to be = clear >> that an RLOC is an IP address. >> >> If you are opening up the RLOC to be something other than an IP = address >> (a MAC address or even something else?) then how do you deal with: >> - lack of ICMP >> - non-uniqueness >> >> Possibly you can say that this is "not my problem" since the problem >> would already exist in the routing system that handles the non-IP >> addresses. But maybe, for an introduction to the topic this is over- >> reaching towards the many potential applications rather than the = basic >> explanation of the architecture? >> >> But in your own definitions in Section 2, you have >> >> Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used = to >> uniquely identify nodes irrespective of their topological = location >> and are typically routed intra-domain. >> >> Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned >> topologically to network attachment points and typically routed >> inter-domain. >> >> Neither of which offers any possibility to vary "always" into >> "typically". >> >> The again, 3.2 has... >> >> EIDs are typically -but >> not limited to- IPv4 or IPv6 addresses >> >> ...and... >> >> With LISP, the core uses RLOCs, an RLOC is typically -but not = limited >> to- an IPv4 or IPv6 address >> >> Some consistency is needed! >> >> In 3.4.1 you finally get there... >> >> Typical mappings in LISP bind EIDs in the form of IP prefixes with = a >> set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses = are >> encoded using the appropriate Address Family Identifier (AFI) >> [RFC3232]. However LISP can also support more general address >> encoding by means of the ongoing effort around the LISP Canonical >> Address Format (LCAF) [I-D.ietf-lisp-lcaf]. >> >> Why don't you talk about everything in terms of IP adresses and then = add >> a section somewhere near the end to talk about LCAF? > > Agreed, as you suggest I will state that EIDs and RLOCs are IP = addresses, which > basically means removing the word "typically".=20 Why don't you say "addresses" instead of "typically IP addresses"? That = is then open to the flexibility of LCAF while still embracing IP = addresses. > I also think that the text that you highlighted is sufficient to = explain that > LCAF supports more general address encoding. Please let me know if = this > addresses your comment.=20 I think it would *if* you make the change to "addresses".=20 >> Section 1 introduces "overlay" and "underlay". I think that a certain >> class of network engineer understands these concepts really well. = And, >> in my experience, another class has no idea what you are talking = about! >> >> This would probably show very easily on a simple diagram showing the >> overlay and underlay networks. >> >> But perhaps the summary in the Introduction is launching in a bit = deep >> and fast? This is probably the hardest part of the document to write: >> how do you summarise what you haven't yet talked about? There are = some >> bits, however, that really need work. For example... >> >> o EIDs have meaning only in the overlay network unless they are >> leaked into the underlay network. The overlay is the >> encapsulation relationship between LISP-capable routers. >> Furthermore EIDs are not assigned from the reserved address >> blocks. >> >> So they have meaning only in one place, unless they have meaning in = more >> than one place? :-) And what is a "reserved address block"? > > Thanks for your comment, I suggest rephrasing the bullet point in the = following way: > > EIDs have meaning only in the overlay network, which is the = encapsulation=20 > relationship between LISP-capable routers. > > Then Section 3.2 mentions the EID leakage as well as its assignment.=20 A fine change. Note that you are addressing my specific example, giving a little bit = more of a clue about what an overlay is, but not handling the general = problem that the Introduction may be going to deep, or fully explaining = overlay/underlay. [snipped agreement] >> 3.2 >> >> Such LISP capable routers, in most cases, only require a software >> upgrade. >> >> That's a little disconcerting. Can you add to "in most cases"? > > What about? > > Adding LISP capabilities to routers does not mandate hardware changes > and can be done via a software upgrade. =20 If that's true (and I have no reason to doubt you), then that works. >> 4.1 >> >> Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, = upon >> expiration of the TTL the ITR has to refresh the mapping by >> sending a new Map-Request. Typical values for TTL defined by = LISP >> are 24 hours. >> >> Presumably it doesn't *have to*. It can choose to delete it and not >> refresh it. Maybe this should be worded as MUST NOT use after the >> expiration of the TTL. > > I would prefer to avoid using the word MUST since this document > does not specify LISP. Agreed. My bad choice of emphasis marker! > I suggest rephrasing the bullet point in the=20 > following way: > > Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon > expiration of the TTL the ITR can't use the mapping until it is = refreshed by=20 > sending a new Map-Request. Typical values for TTL defined by = LISP > are 24 hours.=20 That works. >> Section 5 says [snip] > I suggest the following sentence: > > The separation between locators and identifiers in LISP was initially > motivated by discussions during the IAB-sponsored Workshop, the = outcomes are=20 > described in RFC4984.=20 Great. s/are/of which/ [snipped agreement] Many thanks again for the work. Adrian From nobody Fri Mar 6 12:03:30 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3D67C1A702D; Fri, 6 Mar 2015 12:03:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204491A7023; Fri, 6 Mar 2015 12:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSCyh5BH6O1a; Fri, 6 Mar 2015 12:03:13 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3003A1A700F; Fri, 6 Mar 2015 12:03:13 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K39qX004229; Fri, 6 Mar 2015 20:03:09 GMT Received: from 950129200 (089144213255.atnat0022.highway.a1.net [89.144.213.255]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t26K24e4003548 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 Mar 2015 20:03:07 GMT From: "Adrian Farrel" To: References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 6 Mar 2015 20:02:05 -0000 Message-ID: <02f201d05848$92394220$b6abc660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIdNdBVPp7LPbNGZv+qHmP8KDM0ewIn3SzznGS9cSA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21382.002 X-TM-AS-Result: No--33.752-10.0-31-10 X-imss-scan-details: No--33.752-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wpmug812qIbzKqaitAbDW1qqvcIF1TcLYDlM ngboKBfFEqKQnEa9DF6T65CxuwIJtxtlRBeFg9jM2Ud/1nepkpNU3K6aV1ad7bP7qOmy9QBUUoJ JXv0NurDmP0EDE8v6ojNXervDb6hc8qconkGQR4gSEYfcJF0pRZlhiS3ydre3WP9qYuzytBL9ph oXIzcVvFJvQPep6+JXibWqJyoFwCeQ7kS+FkQAzpF+9R8v7nzmpKs40Iv4zXcoDMZ3xV44iNRBu 2IPUoRpYx1Ye0eO/X/jCJhKsmTnQVHZxHZPJAqeb0rZzyQrEg1MkOX0UoduuSWrO+SgZCHmiHXG zNYvf0ERkcfW2QvH7qfVr83RVWIvy5j7H7ClYgeWLCkl1lq7B7pZtsuh6XaldROyZB3lVupbXVr r4MMb9UqLuIc287W8QN70OjoNAZ5PDPfmo+ftx0bKkLkJUU4fYtmTggNRdce5IifwYL1+qyXdaT B+fIOxqTQaUessnJwycPsDdl2dA7Wd3Qhj3xBViUPZPmKZOQlAq6/y5AEOOhRZ/9wBMhGs28vyR IpB9YRJ3fwJ/s4z7WQp/kaJaaDjJkzXbc0wOa5Ak58YKWonGWXaGha4V72KIFBEE5CFomLzE7iK wulloVFZ9B5e/g6wDyhvPYLQ4DMH+DiyPUjnmZRrnSy7UTtbXEjKf9fhKaeX1RWcrwojHNmJ86n vpEHqbxCMLwmIJD7Nf0peb0lymHZ+VA6xnTKuffXtKyM+c+sYZdGd023v1ZgWnaLDiGghArfwhX ClRwmSbSv1sT4BsiKAZd9zQifKCJci3xZfAmeeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, 'The IESG' Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:03:16 -0000 Hello Albert, Thanks for your speedy turn-around. >> DISCUSS: >> = ---------------------------------------------------------------------- >> >> In Section 4.2 >> >> On the contrary BGP is a >> push architecture, where the required network state is pushed by >> means of BGP UPDATE messages to BGP speakers. >> >> You will be aware of RFC 5291 and the use of ORF to make BGP a pull- >> mode protocol. >> >> (I won't say to you that LISP is push mode because a Map-Reply >> pushes the mapping information from the map server to the client :-) >> >> So, my advice is to describe LISP in this document and to not make >> comments about other systems. It isn't a beauty contest and it isn't >> wise to try to say "my system is better/different from yours". >> >> The solution is to just remove this sentence. > > Agreed, I=C2=B4ll remove the first sentence. Perfect =20 >> Similarly in 7.1 >> >> BGP is the standard protocol to implement inter-domain routing. = With >> BGP, routing information are propagated along the network and each >> autonomous system can implement its own routing policy that will >> influence the way routing information are propagated. The direct >> consequence is that an autonomous system cannot precisely control = the >> way the traffic will enter the network. >> >> As opposed to BGP, a LISP site can strictly impose via which ETRs = the >> traffic must enter the the LISP site network even though the path >> followed to reach the ETR is not under the control of the LISP = site. >> >> Let's not get into the "BGP this, BGP that" debate. Just remove the >> first paragraph and the first four words of the second paragraph. = That >> way you avoid all contention and write a document about LISP. > > Agreed, I=C2=B4ll remove the first paragraph and first four words of = the=20 > second paragraph. Also perfect. =20 >> COMMENT: >> = ---------------------------------------------------------------------- Please note that Comments are just my observations. You are not obliged = to make changes or pay attention. You just need to reach equilibrium = with your AD. >> Section 1 >> >> I'm really not comfortable with your text... "Indeed and as pointed = out >>by the unpublished Internet Draft by Noel Chiappa [Chiappa]" >> >> This isn't a stable reference and I don't think you need it. You = could >> either rely on the later reference to RFC 4984, reference RFC 6830 >> itself, or take out the aside "and as... ... [Chiappa]" >> > The same reference is cited in RFC4984 and RFC4423, it is preferable > to cite it as it is or cite RFC4984? Per Brian, 4984 would be fine. =20 >> Section 1 has >> >> LISP creates two separate namespaces, EIDs (End-host IDentifiers) = and >> RLOCs (Routing LOCators), both are typically syntactically = identical >> to the current IPv4 and IPv6 addresses. >> >> The "typically" here opens a bit of door. >> >> RFC 6830 explains this in the definitions of EID, but seems to be = clear >> that an RLOC is an IP address. >> >> If you are opening up the RLOC to be something other than an IP = address >> (a MAC address or even something else?) then how do you deal with: >> - lack of ICMP >> - non-uniqueness >> >> Possibly you can say that this is "not my problem" since the problem >> would already exist in the routing system that handles the non-IP >> addresses. But maybe, for an introduction to the topic this is over- >> reaching towards the many potential applications rather than the = basic >> explanation of the architecture? >> >> But in your own definitions in Section 2, you have >> >> Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used = to >> uniquely identify nodes irrespective of their topological = location >> and are typically routed intra-domain. >> >> Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned >> topologically to network attachment points and typically routed >> inter-domain. >> >> Neither of which offers any possibility to vary "always" into >> "typically". >> >> The again, 3.2 has... >> >> EIDs are typically -but >> not limited to- IPv4 or IPv6 addresses >> >> ...and... >> >> With LISP, the core uses RLOCs, an RLOC is typically -but not = limited >> to- an IPv4 or IPv6 address >> >> Some consistency is needed! >> >> In 3.4.1 you finally get there... >> >> Typical mappings in LISP bind EIDs in the form of IP prefixes with = a >> set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses = are >> encoded using the appropriate Address Family Identifier (AFI) >> [RFC3232]. However LISP can also support more general address >> encoding by means of the ongoing effort around the LISP Canonical >> Address Format (LCAF) [I-D.ietf-lisp-lcaf]. >> >> Why don't you talk about everything in terms of IP adresses and then = add >> a section somewhere near the end to talk about LCAF? > > Agreed, as you suggest I will state that EIDs and RLOCs are IP = addresses, which > basically means removing the word "typically".=20 Why don't you say "addresses" instead of "typically IP addresses"? That = is then open to the flexibility of LCAF while still embracing IP = addresses. > I also think that the text that you highlighted is sufficient to = explain that > LCAF supports more general address encoding. Please let me know if = this > addresses your comment.=20 I think it would *if* you make the change to "addresses".=20 >> Section 1 introduces "overlay" and "underlay". I think that a certain >> class of network engineer understands these concepts really well. = And, >> in my experience, another class has no idea what you are talking = about! >> >> This would probably show very easily on a simple diagram showing the >> overlay and underlay networks. >> >> But perhaps the summary in the Introduction is launching in a bit = deep >> and fast? This is probably the hardest part of the document to write: >> how do you summarise what you haven't yet talked about? There are = some >> bits, however, that really need work. For example... >> >> o EIDs have meaning only in the overlay network unless they are >> leaked into the underlay network. The overlay is the >> encapsulation relationship between LISP-capable routers. >> Furthermore EIDs are not assigned from the reserved address >> blocks. >> >> So they have meaning only in one place, unless they have meaning in = more >> than one place? :-) And what is a "reserved address block"? > > Thanks for your comment, I suggest rephrasing the bullet point in the = following way: > > EIDs have meaning only in the overlay network, which is the = encapsulation=20 > relationship between LISP-capable routers. > > Then Section 3.2 mentions the EID leakage as well as its assignment.=20 A fine change. Note that you are addressing my specific example, giving a little bit = more of a clue about what an overlay is, but not handling the general = problem that the Introduction may be going to deep, or fully explaining = overlay/underlay. [snipped agreement] >> 3.2 >> >> Such LISP capable routers, in most cases, only require a software >> upgrade. >> >> That's a little disconcerting. Can you add to "in most cases"? > > What about? > > Adding LISP capabilities to routers does not mandate hardware changes > and can be done via a software upgrade. =20 If that's true (and I have no reason to doubt you), then that works. >> 4.1 >> >> Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, = upon >> expiration of the TTL the ITR has to refresh the mapping by >> sending a new Map-Request. Typical values for TTL defined by = LISP >> are 24 hours. >> >> Presumably it doesn't *have to*. It can choose to delete it and not >> refresh it. Maybe this should be worded as MUST NOT use after the >> expiration of the TTL. > > I would prefer to avoid using the word MUST since this document > does not specify LISP. Agreed. My bad choice of emphasis marker! > I suggest rephrasing the bullet point in the=20 > following way: > > Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon > expiration of the TTL the ITR can't use the mapping until it is = refreshed by=20 > sending a new Map-Request. Typical values for TTL defined by = LISP > are 24 hours.=20 That works. >> Section 5 says [snip] > I suggest the following sentence: > > The separation between locators and identifiers in LISP was initially > motivated by discussions during the IAB-sponsored Workshop, the = outcomes are=20 > described in RFC4984.=20 Great. s/are/of which/ [snipped agreement] Many thanks again for the work. Adrian From nobody Fri Mar 6 12:18:55 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8A1A6FFC; Fri, 6 Mar 2015 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18MslKBpGx9I; Fri, 6 Mar 2015 12:18:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE0F1A1AF0; Fri, 6 Mar 2015 12:18:49 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EB1F788135; Fri, 6 Mar 2015 12:18:48 -0800 (PST) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1CD9913681EB; Fri, 6 Mar 2015 12:18:48 -0800 (PST) Message-ID: <54FA0BA6.1040900@innovationslab.net> Date: Fri, 06 Mar 2015 15:18:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Farrel , acabello@ac.upc.edu References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <02f201d05848$92394220$b6abc660$@olddog.co.uk> In-Reply-To: <02f201d05848$92394220$b6abc660$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, 'The IESG' Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:18:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, On 3/6/15 3:02 PM, Adrian Farrel wrote: >>> Section 1 >>> >>> I'm really not comfortable with your text... "Indeed and as >>> pointed out by the unpublished Internet Draft by Noel Chiappa >>> [Chiappa]" >>> >>> This isn't a stable reference and I don't think you need it. >>> You could either rely on the later reference to RFC 4984, >>> reference RFC 6830 itself, or take out the aside "and as... ... >>> [Chiappa]" >>> >> The same reference is cited in RFC4984 and RFC4423, it is >> preferable to cite it as it is or cite RFC4984? > > Per Brian, 4984 would be fine. Good. > >>> Section 1 has >>> >>> LISP creates two separate namespaces, EIDs (End-host >>> IDentifiers) and RLOCs (Routing LOCators), both are typically >>> syntactically identical to the current IPv4 and IPv6 >>> addresses. >>> >>> The "typically" here opens a bit of door. >>> >>> RFC 6830 explains this in the definitions of EID, but seems to >>> be clear that an RLOC is an IP address. >>> >>> If you are opening up the RLOC to be something other than an IP >>> address (a MAC address or even something else?) then how do you >>> deal with: - lack of ICMP - non-uniqueness >>> >>> Possibly you can say that this is "not my problem" since the >>> problem would already exist in the routing system that handles >>> the non-IP addresses. But maybe, for an introduction to the >>> topic this is over- reaching towards the many potential >>> applications rather than the basic explanation of the >>> architecture? >>> >>> But in your own definitions in Section 2, you have >>> >>> Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses >>> used to uniquely identify nodes irrespective of their >>> topological location and are typically routed intra-domain. >>> >>> Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses >>> assigned topologically to network attachment points and >>> typically routed inter-domain. >>> >>> Neither of which offers any possibility to vary "always" into >>> "typically". >>> >>> The again, 3.2 has... >>> >>> EIDs are typically -but not limited to- IPv4 or IPv6 addresses >>> >>> ...and... >>> >>> With LISP, the core uses RLOCs, an RLOC is typically -but not >>> limited to- an IPv4 or IPv6 address >>> >>> Some consistency is needed! >>> >>> In 3.4.1 you finally get there... >>> >>> Typical mappings in LISP bind EIDs in the form of IP prefixes >>> with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 >>> addresses are encoded using the appropriate Address Family >>> Identifier (AFI) [RFC3232]. However LISP can also support more >>> general address encoding by means of the ongoing effort around >>> the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. >>> >>> Why don't you talk about everything in terms of IP adresses and >>> then add a section somewhere near the end to talk about LCAF? >> >> Agreed, as you suggest I will state that EIDs and RLOCs are IP >> addresses, which basically means removing the word "typically". > > Why don't you say "addresses" instead of "typically IP addresses"? > That is then open to the flexibility of LCAF while still embracing > IP addresses. This makes sense to me. > >> I also think that the text that you highlighted is sufficient to >> explain that LCAF supports more general address encoding. Please >> let me know if this addresses your comment. > > I think it would *if* you make the change to "addresses". Agreed. > >>> Section 1 introduces "overlay" and "underlay". I think that a >>> certain class of network engineer understands these concepts >>> really well. And, in my experience, another class has no idea >>> what you are talking about! >>> >>> This would probably show very easily on a simple diagram >>> showing the overlay and underlay networks. >>> >>> But perhaps the summary in the Introduction is launching in a >>> bit deep and fast? This is probably the hardest part of the >>> document to write: how do you summarise what you haven't yet >>> talked about? There are some bits, however, that really need >>> work. For example... >>> >>> o EIDs have meaning only in the overlay network unless they >>> are leaked into the underlay network. The overlay is the >>> encapsulation relationship between LISP-capable routers. >>> Furthermore EIDs are not assigned from the reserved address >>> blocks. >>> >>> So they have meaning only in one place, unless they have >>> meaning in more than one place? :-) And what is a "reserved >>> address block"? >> >> Thanks for your comment, I suggest rephrasing the bullet point in >> the following way: >> >> EIDs have meaning only in the overlay network, which is the >> encapsulation relationship between LISP-capable routers. >> >> Then Section 3.2 mentions the EID leakage as well as its >> assignment. > > A fine change. Note that you are addressing my specific example, > giving a little bit more of a clue about what an overlay is, but > not handling the general problem that the Introduction may be going > to deep, or fully explaining overlay/underlay. > > [snipped agreement] > >>> 3.2 >>> >>> Such LISP capable routers, in most cases, only require a >>> software upgrade. >>> >>> That's a little disconcerting. Can you add to "in most cases"? >> >> What about? >> >> Adding LISP capabilities to routers does not mandate hardware >> changes and can be done via a software upgrade. > > If that's true (and I have no reason to doubt you), then that > works. Based on Alia's review, this whole sentence will be gone. > >>> 4.1 >>> >>> Time-To-Live (TTL): Each mapping contains a TTL set by the >>> ETR, upon expiration of the TTL the ITR has to refresh the >>> mapping by sending a new Map-Request. Typical values for TTL >>> defined by LISP are 24 hours. >>> >>> Presumably it doesn't *have to*. It can choose to delete it and >>> not refresh it. Maybe this should be worded as MUST NOT use >>> after the expiration of the TTL. >> >> I would prefer to avoid using the word MUST since this document >> does not specify LISP. > > Agreed. My bad choice of emphasis marker! > >> I suggest rephrasing the bullet point in the following way: >> >> Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, >> upon expiration of the TTL the ITR can't use the mapping until it >> is refreshed by sending a new Map-Request. Typical values for >> TTL defined by LISP are 24 hours. > > That works. Agreed. > >>> Section 5 says > [snip] >> I suggest the following sentence: >> >> The separation between locators and identifiers in LISP was >> initially motivated by discussions during the IAB-sponsored >> Workshop, the outcomes are described in RFC4984. > > Great. s/are/of which/ > Agreed. Regards, Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+gumAAoJEBOZRqCi7goqXjoH/iuhyBIs9i6kq4fdz9Mqj2w7 fbxgwn54ElBNg2SXmS5XPmVwUIKQMy3ufWDvXp/tgUbTtuRZ6Yj6q4Km5EOh6RY1 fZ32l69hvpCxX34MBKnv8xK8CO3y+tuXTzh7Et4CBN13Gh3jUGFJhwTcan1IX7K7 2eii+TUYweRFH33yrXPe7SuoMrWh6c38gXySq6BDXala/KRFy+27WXOwYn/X7nq3 GnS+avh6moaUmQJSY1+Rsr8+NKqHCQq30ucLAqVBryzGPSBIwEL1Qfht0MTyd9gI 3A/IGz8Wvq5pHdNRkgK4ViBBnZl7xC77UfdUmYq5KPXTGLTPSP75WGQPG25Qzxw= =Fg7y -----END PGP SIGNATURE----- From nobody Fri Mar 6 12:18:56 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 633881A7000; Fri, 6 Mar 2015 12:18:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8A1A6FFC; Fri, 6 Mar 2015 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18MslKBpGx9I; Fri, 6 Mar 2015 12:18:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE0F1A1AF0; Fri, 6 Mar 2015 12:18:49 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EB1F788135; Fri, 6 Mar 2015 12:18:48 -0800 (PST) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1CD9913681EB; Fri, 6 Mar 2015 12:18:48 -0800 (PST) Message-ID: <54FA0BA6.1040900@innovationslab.net> Date: Fri, 06 Mar 2015 15:18:46 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adrian Farrel , acabello@ac.upc.edu References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <02f201d05848$92394220$b6abc660$@olddog.co.uk> In-Reply-To: <02f201d05848$92394220$b6abc660$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, lisp@ietf.org, 'The IESG' Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:18:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, On 3/6/15 3:02 PM, Adrian Farrel wrote: >>> Section 1 >>> >>> I'm really not comfortable with your text... "Indeed and as >>> pointed out by the unpublished Internet Draft by Noel Chiappa >>> [Chiappa]" >>> >>> This isn't a stable reference and I don't think you need it. >>> You could either rely on the later reference to RFC 4984, >>> reference RFC 6830 itself, or take out the aside "and as... ... >>> [Chiappa]" >>> >> The same reference is cited in RFC4984 and RFC4423, it is >> preferable to cite it as it is or cite RFC4984? > > Per Brian, 4984 would be fine. Good. > >>> Section 1 has >>> >>> LISP creates two separate namespaces, EIDs (End-host >>> IDentifiers) and RLOCs (Routing LOCators), both are typically >>> syntactically identical to the current IPv4 and IPv6 >>> addresses. >>> >>> The "typically" here opens a bit of door. >>> >>> RFC 6830 explains this in the definitions of EID, but seems to >>> be clear that an RLOC is an IP address. >>> >>> If you are opening up the RLOC to be something other than an IP >>> address (a MAC address or even something else?) then how do you >>> deal with: - lack of ICMP - non-uniqueness >>> >>> Possibly you can say that this is "not my problem" since the >>> problem would already exist in the routing system that handles >>> the non-IP addresses. But maybe, for an introduction to the >>> topic this is over- reaching towards the many potential >>> applications rather than the basic explanation of the >>> architecture? >>> >>> But in your own definitions in Section 2, you have >>> >>> Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses >>> used to uniquely identify nodes irrespective of their >>> topological location and are typically routed intra-domain. >>> >>> Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses >>> assigned topologically to network attachment points and >>> typically routed inter-domain. >>> >>> Neither of which offers any possibility to vary "always" into >>> "typically". >>> >>> The again, 3.2 has... >>> >>> EIDs are typically -but not limited to- IPv4 or IPv6 addresses >>> >>> ...and... >>> >>> With LISP, the core uses RLOCs, an RLOC is typically -but not >>> limited to- an IPv4 or IPv6 address >>> >>> Some consistency is needed! >>> >>> In 3.4.1 you finally get there... >>> >>> Typical mappings in LISP bind EIDs in the form of IP prefixes >>> with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 >>> addresses are encoded using the appropriate Address Family >>> Identifier (AFI) [RFC3232]. However LISP can also support more >>> general address encoding by means of the ongoing effort around >>> the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. >>> >>> Why don't you talk about everything in terms of IP adresses and >>> then add a section somewhere near the end to talk about LCAF? >> >> Agreed, as you suggest I will state that EIDs and RLOCs are IP >> addresses, which basically means removing the word "typically". > > Why don't you say "addresses" instead of "typically IP addresses"? > That is then open to the flexibility of LCAF while still embracing > IP addresses. This makes sense to me. > >> I also think that the text that you highlighted is sufficient to >> explain that LCAF supports more general address encoding. Please >> let me know if this addresses your comment. > > I think it would *if* you make the change to "addresses". Agreed. > >>> Section 1 introduces "overlay" and "underlay". I think that a >>> certain class of network engineer understands these concepts >>> really well. And, in my experience, another class has no idea >>> what you are talking about! >>> >>> This would probably show very easily on a simple diagram >>> showing the overlay and underlay networks. >>> >>> But perhaps the summary in the Introduction is launching in a >>> bit deep and fast? This is probably the hardest part of the >>> document to write: how do you summarise what you haven't yet >>> talked about? There are some bits, however, that really need >>> work. For example... >>> >>> o EIDs have meaning only in the overlay network unless they >>> are leaked into the underlay network. The overlay is the >>> encapsulation relationship between LISP-capable routers. >>> Furthermore EIDs are not assigned from the reserved address >>> blocks. >>> >>> So they have meaning only in one place, unless they have >>> meaning in more than one place? :-) And what is a "reserved >>> address block"? >> >> Thanks for your comment, I suggest rephrasing the bullet point in >> the following way: >> >> EIDs have meaning only in the overlay network, which is the >> encapsulation relationship between LISP-capable routers. >> >> Then Section 3.2 mentions the EID leakage as well as its >> assignment. > > A fine change. Note that you are addressing my specific example, > giving a little bit more of a clue about what an overlay is, but > not handling the general problem that the Introduction may be going > to deep, or fully explaining overlay/underlay. > > [snipped agreement] > >>> 3.2 >>> >>> Such LISP capable routers, in most cases, only require a >>> software upgrade. >>> >>> That's a little disconcerting. Can you add to "in most cases"? >> >> What about? >> >> Adding LISP capabilities to routers does not mandate hardware >> changes and can be done via a software upgrade. > > If that's true (and I have no reason to doubt you), then that > works. Based on Alia's review, this whole sentence will be gone. > >>> 4.1 >>> >>> Time-To-Live (TTL): Each mapping contains a TTL set by the >>> ETR, upon expiration of the TTL the ITR has to refresh the >>> mapping by sending a new Map-Request. Typical values for TTL >>> defined by LISP are 24 hours. >>> >>> Presumably it doesn't *have to*. It can choose to delete it and >>> not refresh it. Maybe this should be worded as MUST NOT use >>> after the expiration of the TTL. >> >> I would prefer to avoid using the word MUST since this document >> does not specify LISP. > > Agreed. My bad choice of emphasis marker! > >> I suggest rephrasing the bullet point in the following way: >> >> Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, >> upon expiration of the TTL the ITR can't use the mapping until it >> is refreshed by sending a new Map-Request. Typical values for >> TTL defined by LISP are 24 hours. > > That works. Agreed. > >>> Section 5 says > [snip] >> I suggest the following sentence: >> >> The separation between locators and identifiers in LISP was >> initially motivated by discussions during the IAB-sponsored >> Workshop, the outcomes are described in RFC4984. > > Great. s/are/of which/ > Agreed. Regards, Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+gumAAoJEBOZRqCi7goqXjoH/iuhyBIs9i6kq4fdz9Mqj2w7 fbxgwn54ElBNg2SXmS5XPmVwUIKQMy3ufWDvXp/tgUbTtuRZ6Yj6q4Km5EOh6RY1 fZ32l69hvpCxX34MBKnv8xK8CO3y+tuXTzh7Et4CBN13Gh3jUGFJhwTcan1IX7K7 2eii+TUYweRFH33yrXPe7SuoMrWh6c38gXySq6BDXala/KRFy+27WXOwYn/X7nq3 GnS+avh6moaUmQJSY1+Rsr8+NKqHCQq30ucLAqVBryzGPSBIwEL1Qfht0MTyd9gI 3A/IGz8Wvq5pHdNRkgK4ViBBnZl7xC77UfdUmYq5KPXTGLTPSP75WGQPG25Qzxw= =Fg7y -----END PGP SIGNATURE----- From nobody Mon Mar 9 05:15:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F931A885A; Mon, 9 Mar 2015 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIhq7-pAi2Xj; Mon, 9 Mar 2015 05:15:36 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEDD1A8836; Mon, 9 Mar 2015 05:15:36 -0700 (PDT) Received: by igbhn18 with SMTP id hn18so20085034igb.2; Mon, 09 Mar 2015 05:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4f68xY6J4E0wndeaUcXg/bkobH5n8K9yiWaRDjuMlXA=; b=W4qp1YIYSLHLCbHvDsojHYqrnSjxqNv+L2NaYWnSGy2mJA6V4jjzed2VsOdGn/eVzn pkaAeoCrfP6cMz2KEjOuXR8Mm41gyS6LpYIAFjZGq6mHYU41XK8NDkrgXkMieD1OTMg/ ypsVc6+NaxlwzSVMZngpSMioFtzgFs+z3c58IvMKH5o9LXlq82sDRxXQUl9f+lA5hcry LcryMIoQvGciKLNrK1e7cvHAYG+ujsm80sKufNZRuTLDAQ9q7RBFnwq/jht/sOvNLVaB //8E9+nULVAMrmXN0tBKJce+Dq4ca9cqjxaocY3GZ/cphc/tZaYIyNBDqI+UpKJI27iM hgEA== MIME-Version: 1.0 X-Received: by 10.42.203.147 with SMTP id fi19mr25941395icb.12.1425903335866; Mon, 09 Mar 2015 05:15:35 -0700 (PDT) Received: by 10.107.18.67 with HTTP; Mon, 9 Mar 2015 05:15:35 -0700 (PDT) In-Reply-To: <20150304062237.2720.128.idtracker@ietfa.amsl.com> References: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 13:15:35 +0100 Message-ID: From: Albert Cabellos To: Spencer Dawkins Content-Type: multipart/alternative; boundary=485b397dd12bd187cf0510d9fd75 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: 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, 09 Mar 2015 12:15:39 -0000 --485b397dd12bd187cf0510d9fd75 Content-Type: text/plain; charset=UTF-8 Hi Thank you very much for your comments, please find below how we plan to address them: On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-lisp-introduction-12: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a Yes because this draft is helpful to the largely uninitiated (that > would include me), but I was consistently encountering questions that > Adrian's Discuss and Comments answered, so I'd encourage you to work > through his Comments, as well as his Discuss. > > Beyond that: > > In this text: > > 3.3.1. LISP Encapsulation > > ITRs encapsulate data packets towards ETRs. LISP data packets are > encapsulated using UDP (port 4341), the source port is usually > selected by the ITR using a 5-tuple hash of the inner header (so to > be consistent in case of multi-path solutions such as ECMP [RFC2992]) > and ignored on reception. > > would you ever use "virtual xTRs" with the same outermost IP addresses? > If not, fine, but if so, would you need to use different destination > ports to disambiguate them? Or does the Instance ID provide enough > isolation to meet this need? > > I ask because adding virtual hosts to HTTP was a drag, so best for me to > ask early! > > Indeed and as you point out InstanceID should provide enough isolation. Please let me know if the following sentence (section 4.1) clarifies your point: The Map-Cache is indexed by (Instance ID, EID-prefix) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights). Further in the same paragraph, in this text: > > A particularity of LISP is that UDP > packets should include a zero checksum [RFC6935] [RFC6936] that it is > not verified in reception, LISP also supports non-zero checksums that > may be verified. This decision was made because the typical > transport protocols used by the applications already include a > checksum, by neglecting the additional UDP encapsulation checksum > xTRs can forward packets more efficiently. > > I'm wobbling between "should include a zero checksum" and "also supports > non-zero checksums". Is that text saying something like this? > > LISP data packets are often encapsulated in UDP packets that > include a zero checksum [RFC6935] [RFC6936] that is not verified > when it is received, because LISP data packets typically include > an inner transport protocol header with a non-zero checksum. By > omitting the additional outer UDP encapsulation checksum, xTRs > can forward packets more efficiently. If LISP data packets are > encapsulated in UDP packets with non-zero checksums, the outer > UDP checksums are verified when the UDP packets are received, as > part of normal UDP processing. > > This is correct, I'll update the paragraph as you suggest, thanks! Albert > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --485b397dd12bd187cf0510d9fd75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thank you very much for your comment= s, please find below how we plan to address them:

On Wed, Mar 4, 2015 at 7:22 AM, Spenc= er Dawkins <spencerdawkins.ietf@gmail.com> wrote= :
Spencer Dawkins has entered the following ballot posi= tion for
draft-ietf-lisp-introduction-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes because this draft is helpful to the largely uninitiated (tha= t
would include me), but I was consistently encountering questions that
Adrian's Discuss and Comments answered, so I'd encourage you to wor= k
through his Comments, as well as his Discuss.

Beyond that:

In this text:

3.3.1.=C2=A0 LISP Encapsulation

=C2=A0 =C2=A0ITRs encapsulate data packets towards ETRs.=C2=A0 LISP data pa= ckets are
=C2=A0 =C2=A0encapsulated using UDP (port 4341), the source port is usually=
=C2=A0 =C2=A0selected by the ITR using a 5-tuple hash of the inner header (= so to
=C2=A0 =C2=A0be consistent in case of multi-path solutions such as ECMP [RF= C2992])
=C2=A0 =C2=A0and ignored on reception.

would you ever use "virtual xTRs" with the same outermost IP addr= esses?
If not, fine, but if so, would you need to use different destination
ports to disambiguate them? Or does the Instance ID provide enough
isolation to meet this need?

I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early!


Indeed and as you point out InstanceID= should provide enough isolation. Please let me know if the following sente= nce (section 4.1) clarifies your point:

The Map-Ca= che is indexed by (Instance ID, EID-prefix) and
=C2=A0 =C2=A0cont= ains basically the set of RLOCs with the associated traffic
=C2= =A0 =C2=A0engineering policies (priorities and weights).
=C2=A0 = =C2=A0=C2=A0

Further in the same paragraph, in this text:

=C2=A0 =C2=A0A particularity of LISP is that UDP
=C2=A0 =C2=A0packets should include a zero checksum [RFC6935] [RFC6936] tha= t it is
=C2=A0 =C2=A0not verified in reception, LISP also supports non-zero checksu= ms that
=C2=A0 =C2=A0may be verified.=C2=A0 This decision was made because the typi= cal
=C2=A0 =C2=A0transport protocols used by the applications already include a=
=C2=A0 =C2=A0checksum, by neglecting the additional UDP encapsulation check= sum
=C2=A0 =C2=A0xTRs can forward packets more efficiently.

I'm wobbling between "should include a zero checksum" and &qu= ot;also supports
non-zero checksums". Is that text saying something like this?

=C2=A0 =C2=A0LISP data packets are often encapsulated in UDP packets that =C2=A0 =C2=A0include a zero checksum [RFC6935] [RFC6936] that is not verifi= ed
=C2=A0 =C2=A0when it is received, because LISP data packets typically inclu= de
=C2=A0 =C2=A0an inner transport protocol header with a non-zero checksum. B= y
=C2=A0 =C2=A0omitting the additional outer UDP encapsulation checksum, xTRs=
=C2=A0 =C2=A0can forward packets more efficiently. If LISP data packets are=
=C2=A0 =C2=A0encapsulated in UDP packets with non-zero checksums, the outer=
=C2=A0 =C2=A0UDP checksums are verified when the UDP packets are received, = as
=C2=A0 =C2=A0part of normal UDP processing.


This is correct, I'll update the p= aragraph as you suggest, thanks! =C2=A0 =C2=A0

Alb= ert=C2=A0

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

--485b397dd12bd187cf0510d9fd75-- From nobody Mon Mar 9 05:15:46 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2B9081A885D; Mon, 9 Mar 2015 05:15:39 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F931A885A; Mon, 9 Mar 2015 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIhq7-pAi2Xj; Mon, 9 Mar 2015 05:15:36 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEDD1A8836; Mon, 9 Mar 2015 05:15:36 -0700 (PDT) Received: by igbhn18 with SMTP id hn18so20085034igb.2; Mon, 09 Mar 2015 05:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4f68xY6J4E0wndeaUcXg/bkobH5n8K9yiWaRDjuMlXA=; b=W4qp1YIYSLHLCbHvDsojHYqrnSjxqNv+L2NaYWnSGy2mJA6V4jjzed2VsOdGn/eVzn pkaAeoCrfP6cMz2KEjOuXR8Mm41gyS6LpYIAFjZGq6mHYU41XK8NDkrgXkMieD1OTMg/ ypsVc6+NaxlwzSVMZngpSMioFtzgFs+z3c58IvMKH5o9LXlq82sDRxXQUl9f+lA5hcry LcryMIoQvGciKLNrK1e7cvHAYG+ujsm80sKufNZRuTLDAQ9q7RBFnwq/jht/sOvNLVaB //8E9+nULVAMrmXN0tBKJce+Dq4ca9cqjxaocY3GZ/cphc/tZaYIyNBDqI+UpKJI27iM hgEA== MIME-Version: 1.0 X-Received: by 10.42.203.147 with SMTP id fi19mr25941395icb.12.1425903335866; Mon, 09 Mar 2015 05:15:35 -0700 (PDT) Received: by 10.107.18.67 with HTTP; Mon, 9 Mar 2015 05:15:35 -0700 (PDT) In-Reply-To: <20150304062237.2720.128.idtracker@ietfa.amsl.com> References: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 13:15:35 +0100 Message-ID: From: Albert Cabellos To: Spencer Dawkins Content-Type: multipart/alternative; boundary=485b397dd12bd187cf0510d9fd75 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: 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, 09 Mar 2015 12:15:39 -0000 --485b397dd12bd187cf0510d9fd75 Content-Type: text/plain; charset=UTF-8 Hi Thank you very much for your comments, please find below how we plan to address them: On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-lisp-introduction-12: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a Yes because this draft is helpful to the largely uninitiated (that > would include me), but I was consistently encountering questions that > Adrian's Discuss and Comments answered, so I'd encourage you to work > through his Comments, as well as his Discuss. > > Beyond that: > > In this text: > > 3.3.1. LISP Encapsulation > > ITRs encapsulate data packets towards ETRs. LISP data packets are > encapsulated using UDP (port 4341), the source port is usually > selected by the ITR using a 5-tuple hash of the inner header (so to > be consistent in case of multi-path solutions such as ECMP [RFC2992]) > and ignored on reception. > > would you ever use "virtual xTRs" with the same outermost IP addresses? > If not, fine, but if so, would you need to use different destination > ports to disambiguate them? Or does the Instance ID provide enough > isolation to meet this need? > > I ask because adding virtual hosts to HTTP was a drag, so best for me to > ask early! > > Indeed and as you point out InstanceID should provide enough isolation. Please let me know if the following sentence (section 4.1) clarifies your point: The Map-Cache is indexed by (Instance ID, EID-prefix) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights). Further in the same paragraph, in this text: > > A particularity of LISP is that UDP > packets should include a zero checksum [RFC6935] [RFC6936] that it is > not verified in reception, LISP also supports non-zero checksums that > may be verified. This decision was made because the typical > transport protocols used by the applications already include a > checksum, by neglecting the additional UDP encapsulation checksum > xTRs can forward packets more efficiently. > > I'm wobbling between "should include a zero checksum" and "also supports > non-zero checksums". Is that text saying something like this? > > LISP data packets are often encapsulated in UDP packets that > include a zero checksum [RFC6935] [RFC6936] that is not verified > when it is received, because LISP data packets typically include > an inner transport protocol header with a non-zero checksum. By > omitting the additional outer UDP encapsulation checksum, xTRs > can forward packets more efficiently. If LISP data packets are > encapsulated in UDP packets with non-zero checksums, the outer > UDP checksums are verified when the UDP packets are received, as > part of normal UDP processing. > > This is correct, I'll update the paragraph as you suggest, thanks! Albert > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --485b397dd12bd187cf0510d9fd75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thank you very much for your comment= s, please find below how we plan to address them:

On Wed, Mar 4, 2015 at 7:22 AM, Spenc= er Dawkins <spencerdawkins.ietf@gmail.com> wrote= :
Spencer Dawkins has entered the following ballot posi= tion for
draft-ietf-lisp-introduction-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes because this draft is helpful to the largely uninitiated (tha= t
would include me), but I was consistently encountering questions that
Adrian's Discuss and Comments answered, so I'd encourage you to wor= k
through his Comments, as well as his Discuss.

Beyond that:

In this text:

3.3.1.=C2=A0 LISP Encapsulation

=C2=A0 =C2=A0ITRs encapsulate data packets towards ETRs.=C2=A0 LISP data pa= ckets are
=C2=A0 =C2=A0encapsulated using UDP (port 4341), the source port is usually=
=C2=A0 =C2=A0selected by the ITR using a 5-tuple hash of the inner header (= so to
=C2=A0 =C2=A0be consistent in case of multi-path solutions such as ECMP [RF= C2992])
=C2=A0 =C2=A0and ignored on reception.

would you ever use "virtual xTRs" with the same outermost IP addr= esses?
If not, fine, but if so, would you need to use different destination
ports to disambiguate them? Or does the Instance ID provide enough
isolation to meet this need?

I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early!


Indeed and as you point out InstanceID= should provide enough isolation. Please let me know if the following sente= nce (section 4.1) clarifies your point:

The Map-Ca= che is indexed by (Instance ID, EID-prefix) and
=C2=A0 =C2=A0cont= ains basically the set of RLOCs with the associated traffic
=C2= =A0 =C2=A0engineering policies (priorities and weights).
=C2=A0 = =C2=A0=C2=A0

Further in the same paragraph, in this text:

=C2=A0 =C2=A0A particularity of LISP is that UDP
=C2=A0 =C2=A0packets should include a zero checksum [RFC6935] [RFC6936] tha= t it is
=C2=A0 =C2=A0not verified in reception, LISP also supports non-zero checksu= ms that
=C2=A0 =C2=A0may be verified.=C2=A0 This decision was made because the typi= cal
=C2=A0 =C2=A0transport protocols used by the applications already include a=
=C2=A0 =C2=A0checksum, by neglecting the additional UDP encapsulation check= sum
=C2=A0 =C2=A0xTRs can forward packets more efficiently.

I'm wobbling between "should include a zero checksum" and &qu= ot;also supports
non-zero checksums". Is that text saying something like this?

=C2=A0 =C2=A0LISP data packets are often encapsulated in UDP packets that =C2=A0 =C2=A0include a zero checksum [RFC6935] [RFC6936] that is not verifi= ed
=C2=A0 =C2=A0when it is received, because LISP data packets typically inclu= de
=C2=A0 =C2=A0an inner transport protocol header with a non-zero checksum. B= y
=C2=A0 =C2=A0omitting the additional outer UDP encapsulation checksum, xTRs=
=C2=A0 =C2=A0can forward packets more efficiently. If LISP data packets are=
=C2=A0 =C2=A0encapsulated in UDP packets with non-zero checksums, the outer=
=C2=A0 =C2=A0UDP checksums are verified when the UDP packets are received, = as
=C2=A0 =C2=A0part of normal UDP processing.


This is correct, I'll update the p= aragraph as you suggest, thanks! =C2=A0 =C2=A0

Alb= ert=C2=A0

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

--485b397dd12bd187cf0510d9fd75-- From nobody Mon Mar 9 05:24:08 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69EC1A8876; Mon, 9 Mar 2015 05:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rBbdbiYzlIw; Mon, 9 Mar 2015 05:24:00 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B591A8869; Mon, 9 Mar 2015 05:24:00 -0700 (PDT) Received: by iecrl12 with SMTP id rl12so19649124iec.5; Mon, 09 Mar 2015 05:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SKSOLghOxCn2KXwfTdAypMX7IGduhvr6fUyIBibgSNk=; b=SHKUmbqbOGYsiW0Y5ssRsU8eAh+7b76YJ0XwGhcSzpgefupMAvM1WDdxaotH/BchXs EeDH9gR2Js0JPtKQJTRZXQXhxmcuG0cx0rUz7OR11yMbujPfw5jgPqfhl1CSm4E5O+UU GJyMNX0/an6BcjkFb9khFiBO+gFFf4DUWrU1guSjAW8K1CxnN7PsdnEXioBi+yDvIRG5 BJPfZec7FUFbnMlnaGfLe5aU692Cia5J34Pwgb7VZyLrWPoXUk+nWZJx9tO8hrgtRJsA JkQYvz7knyFUoJ/1uUnPVE8b38Sb5YE93/s7bLLXmueQPN10jeYJglYIRPdlsJG/gpT9 013g== MIME-Version: 1.0 X-Received: by 10.107.156.19 with SMTP id f19mr47406463ioe.45.1425903839821; Mon, 09 Mar 2015 05:23:59 -0700 (PDT) Received: by 10.107.18.67 with HTTP; Mon, 9 Mar 2015 05:23:59 -0700 (PDT) In-Reply-To: <54F6FC7E.9000400@cisco.com> References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <54F6FC7E.9000400@cisco.com> Date: Mon, 9 Mar 2015 13:23:59 +0100 Message-ID: From: Albert Cabellos To: Eliot Lear Content-Type: multipart/alternative; boundary=001a1141b9acdb803d0510da1ba6 Archived-At: Cc: "lisp@ietf.org" , draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: 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, 09 Mar 2015 12:24:02 -0000 --001a1141b9acdb803d0510da1ba6 Content-Type: text/plain; charset=UTF-8 Hi Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP can operate as a push architecture. We used the term pull arcihtecture to introduce the use of RLOC probing, please let me know if the following paragraph clarifies the point that you rised: In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand. This has consequences concerning the propagation of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information. As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs: Albert On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear wrote: > Hi, > > I'm sorry I didn't catch this earlier (attention elsewhere). > > On 3/3/15 11:09 PM, Adrian Farrel wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thank you for this document. It is really helpful to have a clear > > introduction to LISP, and I appreciate the hard work that has gone into > > producing this text. > > > > I have a small Discuss that is easily fixed. The essence is that you > > should limit this document to a description of LISP and not try to use > > it to bash other solutions. > > > > In Section 4.2 > > > > On the contrary BGP is a > > push architecture, where the required network state is pushed by > > means of BGP UPDATE messages to BGP speakers. > > > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode > > protocol. > > > > (I won't say to you that LISP is push mode because a Map-Reply pushes > > the mapping information from the map server to the client :-) > > > > So, my advice is to describe LISP in this document and to not make > > comments about other systems. It isn't a beauty contest and it isn't > > wise to try to say "my system is better/different from yours". > > > > The solution is to just remove this sentence. > > > > Similarly in 7.1 > > > > BGP is the standard protocol to implement inter-domain routing. With > > BGP, routing information are propagated along the network and each > > autonomous system can implement its own routing policy that will > > influence the way routing information are propagated. The direct > > consequence is that an autonomous system cannot precisely control the > > way the traffic will enter the network. > > > > As opposed to BGP, a LISP site can strictly impose via which ETRs the > > traffic must enter the the LISP site network even though the path > > followed to reach the ETR is not under the control of the LISP site. > > > > Let's not get into the "BGP this, BGP that" debate. Just remove the > > first paragraph and the first four words of the second paragraph. That > > way you avoid all contention and write a document about LISP. > > > I would go further. Whether LISP is a pull- or a push architecture (or > something else) is entirely a characteristic of the mapping system > used. The one in common use today is indeed a pull architecture. The > text discussing push/pull, therefore, should be addressed to the mapping > system. > > Eliot > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a1141b9acdb803d0510da1ba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thanks for your comment, I agree wit= h you, in some cases (e.g., NERD) LISP can operate as a push architecture. = We used the term pull arcihtecture to introduce the use of RLOC probing, pl= ease let me know if the following paragraph clarifies the point that you ri= sed:

In most cases LISP operates with a pull-= based Mapping System (e.g., DDT), this results in an edge to edge pull arch= itecture. In such scenario the network state is stored in the control-plane= while the data-plane pulls it on demand.=C2=A0 This has consequences conce= rning the propagation of xTRs reachability/liveness information since pull = architectures require explicit mechanisms to propagate this information.=C2= =A0 As a result LISP defines a set of mechanisms to inform ITRs and PITRS a= bout the reachability of the cached RLOCs:

A= lbert


On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear <lear@cisco.com> wrote:
Hi,

I'm sorry I didn't catch this earlier (attention elsewhere).

On 3/3/15 11:09 PM, Adrian Farrel wrote:
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thank you for this document. It is really helpful to have a clear
> introduction to LISP, and I appreciate the hard work that has gone int= o
> producing this text.
>
> I have a small Discuss that is easily fixed. The essence is that you > should limit this document to a description of LISP and not try to use=
> it to bash other solutions.
>
> In Section 4.2
>
>=C2=A0 =C2=A0 On the contrary BGP is a
>=C2=A0 =C2=A0 push architecture, where the required network state is pu= shed by
>=C2=A0 =C2=A0 means of BGP UPDATE messages to BGP speakers.
>
> You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mo= de
> protocol.
>
> (I won't say to you that LISP is push mode because a Map-Reply pus= hes
> the mapping information from the map server to the client :-)
>
> So, my advice is to describe LISP in this document and to not make
> comments about other systems. It isn't a beauty contest and it isn= 't
> wise to try to say "my system is better/different from yours"= ;.
>
> The solution is to just remove this sentence.
>
> Similarly in 7.1
>
>=C2=A0 =C2=A0 BGP is the standard protocol to implement inter-domain ro= uting.=C2=A0 With
>=C2=A0 =C2=A0 BGP, routing information are propagated along the network= and each
>=C2=A0 =C2=A0 autonomous system can implement its own routing policy th= at will
>=C2=A0 =C2=A0 influence the way routing information are propagated.=C2= =A0 The direct
>=C2=A0 =C2=A0 consequence is that an autonomous system cannot precisely= control the
>=C2=A0 =C2=A0 way the traffic will enter the network.
>
>=C2=A0 =C2=A0 As opposed to BGP, a LISP site can strictly impose via wh= ich ETRs the
>=C2=A0 =C2=A0 traffic must enter the the LISP site network even though = the path
>=C2=A0 =C2=A0 followed to reach the ETR is not under the control of the= LISP site.
>
> Let's not get into the "BGP this, BGP that" debate. Just= remove the
> first paragraph and the first four words of the second paragraph. That=
> way you avoid all contention and write a document about LISP.


I would go further.=C2=A0 Whether LISP is a pull- or a push arc= hitecture (or
something else) is entirely a characteristic of the mapping system
used.=C2=A0 The one in common use today is indeed a pull architecture.=C2= =A0 The
text discussing push/pull, therefore, should be addressed to the mapping system.

Eliot



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


--001a1141b9acdb803d0510da1ba6-- From nobody Mon Mar 9 05:24:09 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E4A781A887A; Mon, 9 Mar 2015 05:24:02 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69EC1A8876; Mon, 9 Mar 2015 05:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rBbdbiYzlIw; Mon, 9 Mar 2015 05:24:00 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B591A8869; Mon, 9 Mar 2015 05:24:00 -0700 (PDT) Received: by iecrl12 with SMTP id rl12so19649124iec.5; Mon, 09 Mar 2015 05:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SKSOLghOxCn2KXwfTdAypMX7IGduhvr6fUyIBibgSNk=; b=SHKUmbqbOGYsiW0Y5ssRsU8eAh+7b76YJ0XwGhcSzpgefupMAvM1WDdxaotH/BchXs EeDH9gR2Js0JPtKQJTRZXQXhxmcuG0cx0rUz7OR11yMbujPfw5jgPqfhl1CSm4E5O+UU GJyMNX0/an6BcjkFb9khFiBO+gFFf4DUWrU1guSjAW8K1CxnN7PsdnEXioBi+yDvIRG5 BJPfZec7FUFbnMlnaGfLe5aU692Cia5J34Pwgb7VZyLrWPoXUk+nWZJx9tO8hrgtRJsA JkQYvz7knyFUoJ/1uUnPVE8b38Sb5YE93/s7bLLXmueQPN10jeYJglYIRPdlsJG/gpT9 013g== MIME-Version: 1.0 X-Received: by 10.107.156.19 with SMTP id f19mr47406463ioe.45.1425903839821; Mon, 09 Mar 2015 05:23:59 -0700 (PDT) Received: by 10.107.18.67 with HTTP; Mon, 9 Mar 2015 05:23:59 -0700 (PDT) In-Reply-To: <54F6FC7E.9000400@cisco.com> References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <54F6FC7E.9000400@cisco.com> Date: Mon, 9 Mar 2015 13:23:59 +0100 Message-ID: From: Albert Cabellos To: Eliot Lear Content-Type: multipart/alternative; boundary=001a1141b9acdb803d0510da1ba6 Archived-At: Cc: "lisp@ietf.org" , draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: acabello@ac.upc.edu List-Id: 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, 09 Mar 2015 12:24:03 -0000 --001a1141b9acdb803d0510da1ba6 Content-Type: text/plain; charset=UTF-8 Hi Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP can operate as a push architecture. We used the term pull arcihtecture to introduce the use of RLOC probing, please let me know if the following paragraph clarifies the point that you rised: In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand. This has consequences concerning the propagation of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information. As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs: Albert On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear wrote: > Hi, > > I'm sorry I didn't catch this earlier (attention elsewhere). > > On 3/3/15 11:09 PM, Adrian Farrel wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thank you for this document. It is really helpful to have a clear > > introduction to LISP, and I appreciate the hard work that has gone into > > producing this text. > > > > I have a small Discuss that is easily fixed. The essence is that you > > should limit this document to a description of LISP and not try to use > > it to bash other solutions. > > > > In Section 4.2 > > > > On the contrary BGP is a > > push architecture, where the required network state is pushed by > > means of BGP UPDATE messages to BGP speakers. > > > > You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode > > protocol. > > > > (I won't say to you that LISP is push mode because a Map-Reply pushes > > the mapping information from the map server to the client :-) > > > > So, my advice is to describe LISP in this document and to not make > > comments about other systems. It isn't a beauty contest and it isn't > > wise to try to say "my system is better/different from yours". > > > > The solution is to just remove this sentence. > > > > Similarly in 7.1 > > > > BGP is the standard protocol to implement inter-domain routing. With > > BGP, routing information are propagated along the network and each > > autonomous system can implement its own routing policy that will > > influence the way routing information are propagated. The direct > > consequence is that an autonomous system cannot precisely control the > > way the traffic will enter the network. > > > > As opposed to BGP, a LISP site can strictly impose via which ETRs the > > traffic must enter the the LISP site network even though the path > > followed to reach the ETR is not under the control of the LISP site. > > > > Let's not get into the "BGP this, BGP that" debate. Just remove the > > first paragraph and the first four words of the second paragraph. That > > way you avoid all contention and write a document about LISP. > > > I would go further. Whether LISP is a pull- or a push architecture (or > something else) is entirely a characteristic of the mapping system > used. The one in common use today is indeed a pull architecture. The > text discussing push/pull, therefore, should be addressed to the mapping > system. > > Eliot > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a1141b9acdb803d0510da1ba6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Thanks for your comment, I agree wit= h you, in some cases (e.g., NERD) LISP can operate as a push architecture. = We used the term pull arcihtecture to introduce the use of RLOC probing, pl= ease let me know if the following paragraph clarifies the point that you ri= sed:

In most cases LISP operates with a pull-= based Mapping System (e.g., DDT), this results in an edge to edge pull arch= itecture. In such scenario the network state is stored in the control-plane= while the data-plane pulls it on demand.=C2=A0 This has consequences conce= rning the propagation of xTRs reachability/liveness information since pull = architectures require explicit mechanisms to propagate this information.=C2= =A0 As a result LISP defines a set of mechanisms to inform ITRs and PITRS a= bout the reachability of the cached RLOCs:

A= lbert


On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear <lear@cisco.com> wrote:
Hi,

I'm sorry I didn't catch this earlier (attention elsewhere).

On 3/3/15 11:09 PM, Adrian Farrel wrote:
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thank you for this document. It is really helpful to have a clear
> introduction to LISP, and I appreciate the hard work that has gone int= o
> producing this text.
>
> I have a small Discuss that is easily fixed. The essence is that you > should limit this document to a description of LISP and not try to use=
> it to bash other solutions.
>
> In Section 4.2
>
>=C2=A0 =C2=A0 On the contrary BGP is a
>=C2=A0 =C2=A0 push architecture, where the required network state is pu= shed by
>=C2=A0 =C2=A0 means of BGP UPDATE messages to BGP speakers.
>
> You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mo= de
> protocol.
>
> (I won't say to you that LISP is push mode because a Map-Reply pus= hes
> the mapping information from the map server to the client :-)
>
> So, my advice is to describe LISP in this document and to not make
> comments about other systems. It isn't a beauty contest and it isn= 't
> wise to try to say "my system is better/different from yours"= ;.
>
> The solution is to just remove this sentence.
>
> Similarly in 7.1
>
>=C2=A0 =C2=A0 BGP is the standard protocol to implement inter-domain ro= uting.=C2=A0 With
>=C2=A0 =C2=A0 BGP, routing information are propagated along the network= and each
>=C2=A0 =C2=A0 autonomous system can implement its own routing policy th= at will
>=C2=A0 =C2=A0 influence the way routing information are propagated.=C2= =A0 The direct
>=C2=A0 =C2=A0 consequence is that an autonomous system cannot precisely= control the
>=C2=A0 =C2=A0 way the traffic will enter the network.
>
>=C2=A0 =C2=A0 As opposed to BGP, a LISP site can strictly impose via wh= ich ETRs the
>=C2=A0 =C2=A0 traffic must enter the the LISP site network even though = the path
>=C2=A0 =C2=A0 followed to reach the ETR is not under the control of the= LISP site.
>
> Let's not get into the "BGP this, BGP that" debate. Just= remove the
> first paragraph and the first four words of the second paragraph. That=
> way you avoid all contention and write a document about LISP.


I would go further.=C2=A0 Whether LISP is a pull- or a push arc= hitecture (or
something else) is entirely a characteristic of the mapping system
used.=C2=A0 The one in common use today is indeed a pull architecture.=C2= =A0 The
text discussing push/pull, therefore, should be addressed to the mapping system.

Eliot



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


--001a1141b9acdb803d0510da1ba6-- From nobody Mon Mar 9 05:25:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085981A887E; Mon, 9 Mar 2015 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htWnyk72eRV3; Mon, 9 Mar 2015 05:24:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B051A8876; Mon, 9 Mar 2015 05:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13024; q=dns/txt; s=iport; t=1425903900; x=1427113500; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5vEgkCwQhi9FIX7vz+jhbxvE5KoHNPxoeBO83YqGpd0=; b=WHwYgisqN6GDPhvNM+rzQ9DMtBb2cq76HSI7TxF4hU2xhv1357rfenl1 If/NJp94g3PLeUuZBsBBPuYkl6WllJl0LhQlAUBmN+wjh44FbvwOfri9O xHkgd1RjQ0SJ1dMK7g3yBs1UM+tzp63awWbheYdoIzUlJRFftHlX5h8pX o=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBAAKkP1U/xbLJq1aDoNKWoMKv0wBCYVwAoF1AQEBAQEBfIQQAQEEAQEBIEsKARALEgYJFggDAgIJAwIBAgEVHwMOEwEFAgEBF4gUDaghmx0BAQEBAQUBAQEBAQEBFwSLF4QXVweCaIFFBYQ7gT6IFINngS6BHIMpgXuBGoMogjOGIIMdg0IjgjJ/Pj0xgQOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.11,367,1422921600"; d="asc'?scan'208,217";a="384757686" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Mar 2015 12:24:57 +0000 Received: from [10.61.85.25] (ams3-vpn-dhcp5402.cisco.com [10.61.85.25]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t29COt8s005595; Mon, 9 Mar 2015 12:24:56 GMT Message-ID: <54FD9117.2080504@cisco.com> Date: Mon, 09 Mar 2015 13:24:55 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: acabello@ac.upc.edu References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <54F6FC7E.9000400@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HmCqHxVFBguB0d3GDD20PewUtuUGRV5We" Archived-At: Cc: "lisp@ietf.org" , draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:25:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We Content-Type: multipart/alternative; boundary="------------030002050402080002000102" This is a multi-part message in MIME format. --------------030002050402080002000102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert, While that text works, the key point to make is that it is a matter for the mapping system. Eliot On 3/9/15 1:23 PM, Albert Cabellos wrote: > Hi > > Thanks for your comment, I agree with you, in some cases (e.g., NERD) > LISP can operate as a push architecture. We used the term pull > arcihtecture to introduce the use of RLOC probing, please let me know > if the following paragraph clarifies the point that you rised: > > In most cases LISP operates with a pull-based Mapping System (e.g., > DDT), this results in an edge to edge pull architecture. In such > scenario the network state is stored in the control-plane while the > data-plane pulls it on demand. This has consequences concerning the > propagation of xTRs reachability/liveness information since pull > architectures require explicit mechanisms to propagate this > information. As a result LISP defines a set of mechanisms to inform > ITRs and PITRS about the reachability of the cached RLOCs: > > Albert > > > On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear > wrote: > > Hi, > > I'm sorry I didn't catch this earlier (attention elsewhere). > > On 3/3/15 11:09 PM, Adrian Farrel wrote: > > > -------------------------------------------------------------------= --- > > DISCUSS: > > > -------------------------------------------------------------------= --- > > > > Thank you for this document. It is really helpful to have a clear= > > introduction to LISP, and I appreciate the hard work that has > gone into > > producing this text. > > > > I have a small Discuss that is easily fixed. The essence is that = you > > should limit this document to a description of LISP and not try > to use > > it to bash other solutions. > > > > In Section 4.2 > > > > On the contrary BGP is a > > push architecture, where the required network state is pushed = by > > means of BGP UPDATE messages to BGP speakers. > > > > You will be aware of RFC 5291 and the use of ORF to make BGP a > pull-mode > > protocol. > > > > (I won't say to you that LISP is push mode because a Map-Reply > pushes > > the mapping information from the map server to the client :-) > > > > So, my advice is to describe LISP in this document and to not mak= e > > comments about other systems. It isn't a beauty contest and it is= n't > > wise to try to say "my system is better/different from yours". > > > > The solution is to just remove this sentence. > > > > Similarly in 7.1 > > > > BGP is the standard protocol to implement inter-domain > routing. With > > BGP, routing information are propagated along the network and > each > > autonomous system can implement its own routing policy that wi= ll > > influence the way routing information are propagated. The dir= ect > > consequence is that an autonomous system cannot precisely > control the > > way the traffic will enter the network. > > > > As opposed to BGP, a LISP site can strictly impose via which > ETRs the > > traffic must enter the the LISP site network even though the p= ath > > followed to reach the ETR is not under the control of the > LISP site. > > > > Let's not get into the "BGP this, BGP that" debate. Just remove t= he > > first paragraph and the first four words of the second > paragraph. That > > way you avoid all contention and write a document about LISP. > > > I would go further. Whether LISP is a pull- or a push > architecture (or > something else) is entirely a characteristic of the mapping system > used. The one in common use today is indeed a pull architecture. = The > text discussing push/pull, therefore, should be addressed to the > mapping > system. > > Eliot > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --------------030002050402080002000102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert,

While that text works, the key point to make is that it is a matter for the mapping system.

Eliot


On 3/9/15 1:23 PM, Albert Cabellos wrote:
Hi

Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP can operate as a push architecture. We used the term pull arcihtecture to introduce the use of RLOC probing, please let me know if the following paragraph clarifies the point that you rised:

In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand.=C2=A0 This has consequences concerning the propagatio= n of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information.=C2=A0 As a result LISP defines a set of mechanis= ms to inform ITRs and PITRS about the reachability of the cached RLOCs:

Albert


On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear <lear@cisco= =2Ecom> wrote:
Hi,

I'm sorry I didn't catch this earlier (attention elsewhere).<= br>

On 3/3/15 11:09 PM, Adrian Farrel wrote:
> ---------------------------------------------------------= -------------
> DISCUSS:
> ---------------------------------------------------------= -------------
>
> Thank you for this document. It is really helpful to have a clear
> introduction to LISP, and I appreciate the hard work that has gone into
> producing this text.
>
> I have a small Discuss that is easily fixed. The essence is that you
> should limit this document to a description of LISP and not try to use
> it to bash other solutions.
>
> In Section 4.2
>
>=C2=A0 =C2=A0 On the contrary BGP is a
>=C2=A0 =C2=A0 push architecture, where the required n= etwork state is pushed by
>=C2=A0 =C2=A0 means of BGP UPDATE messages to BGP spe= akers.
>
> You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode
> protocol.
>
> (I won't say to you that LISP is push mode because a Map-Reply pushes
> the mapping information from the map server to the client :-)
>
> So, my advice is to describe LISP in this document and to not make
> comments about other systems. It isn't a beauty contest and it isn't
> wise to try to say "my system is better/different from yours".
>
> The solution is to just remove this sentence.
>
> Similarly in 7.1
>
>=C2=A0 =C2=A0 BGP is the standard protocol to impleme= nt inter-domain routing.=C2=A0 With
>=C2=A0 =C2=A0 BGP, routing information are propagated= along the network and each
>=C2=A0 =C2=A0 autonomous system can implement its own= routing policy that will
>=C2=A0 =C2=A0 influence the way routing information a= re propagated.=C2=A0 The direct
>=C2=A0 =C2=A0 consequence is that an autonomous syste= m cannot precisely control the
>=C2=A0 =C2=A0 way the traffic will enter the network.=
>
>=C2=A0 =C2=A0 As opposed to BGP, a LISP site can stri= ctly impose via which ETRs the
>=C2=A0 =C2=A0 traffic must enter the the LISP site ne= twork even though the path
>=C2=A0 =C2=A0 followed to reach the ETR is not under = the control of the LISP site.
>
> Let's not get into the "BGP this, BGP that" debate. Just remove the
> first paragraph and the first four words of the second paragraph. That
> way you avoid all contention and write a document about LISP.


I would go further.=C2=A0 Whether LISP is a pull- or a push architecture (or
something else) is entirely a characteristic of the mapping system
used.=C2=A0 The one in common use today is indeed a pull architecture.=C2=A0 The
text discussing push/pull, therefore, should be addressed to the mapping
system.

Eliot



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



--------------030002050402080002000102-- --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU/ZEXAAoJEIe2a0bZ0nozUqEH/1YM1P2M6RhJzYgRNm4Hbdl7 8k2WREWN/+sPo0GPWNmZ2dcsUfXdzmsxml663DnfEQoRoYY6wIgSTrL5I5gdqFX5 BkTkUs7IwvYrFvtjdwKnm+NP8AKFY6KwxtNTuEnCcacBNWZxoGmyTh1g2/AlhTM3 8bPDlkdB+PP97qt/a4s9ms6BqLUBAMKPxbWXd6HitLBh3aRSEoFiUGxgK2ws5G77 +VV2ce4+DAOau6NkguwL9N43Dbu7sKhszERhNXDNooIphiJho41etGKgRg4X0X0Q FcVqeXuO161JwmTyZwpoA5lTdDgxbti6lN2cs0J0bXod4y8oYJq3VHXUjg8S3N4= =OsyF -----END PGP SIGNATURE----- --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We-- From nobody Mon Mar 9 05:25:08 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2FC481A887F; Mon, 9 Mar 2015 05:25:03 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085981A887E; Mon, 9 Mar 2015 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htWnyk72eRV3; Mon, 9 Mar 2015 05:24:59 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B051A8876; Mon, 9 Mar 2015 05:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13024; q=dns/txt; s=iport; t=1425903900; x=1427113500; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5vEgkCwQhi9FIX7vz+jhbxvE5KoHNPxoeBO83YqGpd0=; b=WHwYgisqN6GDPhvNM+rzQ9DMtBb2cq76HSI7TxF4hU2xhv1357rfenl1 If/NJp94g3PLeUuZBsBBPuYkl6WllJl0LhQlAUBmN+wjh44FbvwOfri9O xHkgd1RjQ0SJ1dMK7g3yBs1UM+tzp63awWbheYdoIzUlJRFftHlX5h8pX o=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBAAKkP1U/xbLJq1aDoNKWoMKv0wBCYVwAoF1AQEBAQEBfIQQAQEEAQEBIEsKARALEgYJFggDAgIJAwIBAgEVHwMOEwEFAgEBF4gUDaghmx0BAQEBAQUBAQEBAQEBFwSLF4QXVweCaIFFBYQ7gT6IFINngS6BHIMpgXuBGoMogjOGIIMdg0IjgjJ/Pj0xgQOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.11,367,1422921600"; d="asc'?scan'208,217";a="384757686" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Mar 2015 12:24:57 +0000 Received: from [10.61.85.25] (ams3-vpn-dhcp5402.cisco.com [10.61.85.25]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t29COt8s005595; Mon, 9 Mar 2015 12:24:56 GMT Message-ID: <54FD9117.2080504@cisco.com> Date: Mon, 09 Mar 2015 13:24:55 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: acabello@ac.upc.edu References: <20150303220919.5152.47932.idtracker@ietfa.amsl.com> <54F6FC7E.9000400@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HmCqHxVFBguB0d3GDD20PewUtuUGRV5We" Archived-At: Cc: "lisp@ietf.org" , draft-ietf-lisp-introduction.all@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:25:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We Content-Type: multipart/alternative; boundary="------------030002050402080002000102" This is a multi-part message in MIME format. --------------030002050402080002000102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert, While that text works, the key point to make is that it is a matter for the mapping system. Eliot On 3/9/15 1:23 PM, Albert Cabellos wrote: > Hi > > Thanks for your comment, I agree with you, in some cases (e.g., NERD) > LISP can operate as a push architecture. We used the term pull > arcihtecture to introduce the use of RLOC probing, please let me know > if the following paragraph clarifies the point that you rised: > > In most cases LISP operates with a pull-based Mapping System (e.g., > DDT), this results in an edge to edge pull architecture. In such > scenario the network state is stored in the control-plane while the > data-plane pulls it on demand. This has consequences concerning the > propagation of xTRs reachability/liveness information since pull > architectures require explicit mechanisms to propagate this > information. As a result LISP defines a set of mechanisms to inform > ITRs and PITRS about the reachability of the cached RLOCs: > > Albert > > > On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear > wrote: > > Hi, > > I'm sorry I didn't catch this earlier (attention elsewhere). > > On 3/3/15 11:09 PM, Adrian Farrel wrote: > > > -------------------------------------------------------------------= --- > > DISCUSS: > > > -------------------------------------------------------------------= --- > > > > Thank you for this document. It is really helpful to have a clear= > > introduction to LISP, and I appreciate the hard work that has > gone into > > producing this text. > > > > I have a small Discuss that is easily fixed. The essence is that = you > > should limit this document to a description of LISP and not try > to use > > it to bash other solutions. > > > > In Section 4.2 > > > > On the contrary BGP is a > > push architecture, where the required network state is pushed = by > > means of BGP UPDATE messages to BGP speakers. > > > > You will be aware of RFC 5291 and the use of ORF to make BGP a > pull-mode > > protocol. > > > > (I won't say to you that LISP is push mode because a Map-Reply > pushes > > the mapping information from the map server to the client :-) > > > > So, my advice is to describe LISP in this document and to not mak= e > > comments about other systems. It isn't a beauty contest and it is= n't > > wise to try to say "my system is better/different from yours". > > > > The solution is to just remove this sentence. > > > > Similarly in 7.1 > > > > BGP is the standard protocol to implement inter-domain > routing. With > > BGP, routing information are propagated along the network and > each > > autonomous system can implement its own routing policy that wi= ll > > influence the way routing information are propagated. The dir= ect > > consequence is that an autonomous system cannot precisely > control the > > way the traffic will enter the network. > > > > As opposed to BGP, a LISP site can strictly impose via which > ETRs the > > traffic must enter the the LISP site network even though the p= ath > > followed to reach the ETR is not under the control of the > LISP site. > > > > Let's not get into the "BGP this, BGP that" debate. Just remove t= he > > first paragraph and the first four words of the second > paragraph. That > > way you avoid all contention and write a document about LISP. > > > I would go further. Whether LISP is a pull- or a push > architecture (or > something else) is entirely a characteristic of the mapping system > used. The one in common use today is indeed a pull architecture. = The > text discussing push/pull, therefore, should be addressed to the > mapping > system. > > Eliot > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --------------030002050402080002000102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Albert,

While that text works, the key point to make is that it is a matter for the mapping system.

Eliot


On 3/9/15 1:23 PM, Albert Cabellos wrote:
Hi

Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP can operate as a push architecture. We used the term pull arcihtecture to introduce the use of RLOC probing, please let me know if the following paragraph clarifies the point that you rised:

In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand.=C2=A0 This has consequences concerning the propagatio= n of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information.=C2=A0 As a result LISP defines a set of mechanis= ms to inform ITRs and PITRS about the reachability of the cached RLOCs:

Albert


On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear <lear@cisco= =2Ecom> wrote:
Hi,

I'm sorry I didn't catch this earlier (attention elsewhere).<= br>

On 3/3/15 11:09 PM, Adrian Farrel wrote:
> ---------------------------------------------------------= -------------
> DISCUSS:
> ---------------------------------------------------------= -------------
>
> Thank you for this document. It is really helpful to have a clear
> introduction to LISP, and I appreciate the hard work that has gone into
> producing this text.
>
> I have a small Discuss that is easily fixed. The essence is that you
> should limit this document to a description of LISP and not try to use
> it to bash other solutions.
>
> In Section 4.2
>
>=C2=A0 =C2=A0 On the contrary BGP is a
>=C2=A0 =C2=A0 push architecture, where the required n= etwork state is pushed by
>=C2=A0 =C2=A0 means of BGP UPDATE messages to BGP spe= akers.
>
> You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode
> protocol.
>
> (I won't say to you that LISP is push mode because a Map-Reply pushes
> the mapping information from the map server to the client :-)
>
> So, my advice is to describe LISP in this document and to not make
> comments about other systems. It isn't a beauty contest and it isn't
> wise to try to say "my system is better/different from yours".
>
> The solution is to just remove this sentence.
>
> Similarly in 7.1
>
>=C2=A0 =C2=A0 BGP is the standard protocol to impleme= nt inter-domain routing.=C2=A0 With
>=C2=A0 =C2=A0 BGP, routing information are propagated= along the network and each
>=C2=A0 =C2=A0 autonomous system can implement its own= routing policy that will
>=C2=A0 =C2=A0 influence the way routing information a= re propagated.=C2=A0 The direct
>=C2=A0 =C2=A0 consequence is that an autonomous syste= m cannot precisely control the
>=C2=A0 =C2=A0 way the traffic will enter the network.=
>
>=C2=A0 =C2=A0 As opposed to BGP, a LISP site can stri= ctly impose via which ETRs the
>=C2=A0 =C2=A0 traffic must enter the the LISP site ne= twork even though the path
>=C2=A0 =C2=A0 followed to reach the ETR is not under = the control of the LISP site.
>
> Let's not get into the "BGP this, BGP that" debate. Just remove the
> first paragraph and the first four words of the second paragraph. That
> way you avoid all contention and write a document about LISP.


I would go further.=C2=A0 Whether LISP is a pull- or a push architecture (or
something else) is entirely a characteristic of the mapping system
used.=C2=A0 The one in common use today is indeed a pull architecture.=C2=A0 The
text discussing push/pull, therefore, should be addressed to the mapping
system.

Eliot



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



--------------030002050402080002000102-- --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJU/ZEXAAoJEIe2a0bZ0nozUqEH/1YM1P2M6RhJzYgRNm4Hbdl7 8k2WREWN/+sPo0GPWNmZ2dcsUfXdzmsxml663DnfEQoRoYY6wIgSTrL5I5gdqFX5 BkTkUs7IwvYrFvtjdwKnm+NP8AKFY6KwxtNTuEnCcacBNWZxoGmyTh1g2/AlhTM3 8bPDlkdB+PP97qt/a4s9ms6BqLUBAMKPxbWXd6HitLBh3aRSEoFiUGxgK2ws5G77 +VV2ce4+DAOau6NkguwL9N43Dbu7sKhszERhNXDNooIphiJho41etGKgRg4X0X0Q FcVqeXuO161JwmTyZwpoA5lTdDgxbti6lN2cs0J0bXod4y8oYJq3VHXUjg8S3N4= =OsyF -----END PGP SIGNATURE----- --HmCqHxVFBguB0d3GDD20PewUtuUGRV5We-- From nobody Mon Mar 9 07:08:11 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084F91A893A for ; Mon, 9 Mar 2015 07:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4a02nUK1lg9 for ; Mon, 9 Mar 2015 07:08:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666021A894C for ; Mon, 9 Mar 2015 07:07:43 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2E82888158; Mon, 9 Mar 2015 07:07:43 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5ADBF1368279; Mon, 9 Mar 2015 07:07:42 -0700 (PDT) Message-ID: <54FDA92F.9060902@innovationslab.net> Date: Mon, 09 Mar 2015 10:07:43 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Gregg Schudel (gschudel)" References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> In-Reply-To: <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fpcSBBKSXT7ojAa5kpVPFOucxlJU4kkOD" Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 14:08:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fpcSBBKSXT7ojAa5kpVPFOucxlJU4kkOD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/6/15 12:58 PM, Gregg Schudel (gschudel) wrote: >=20 > On Feb 6, 2015, at 7:44 AM, Brian Haberman w= rote: >=20 >> It turns out that the discussion during review was with the upper limi= t. >> I can't find any reference to discussions on the lower limit. Authors= ? >=20 > going back to check Brian - it was a while ago. Have we gotten anywhere with this check? The erratum is sitting in a less-than-useful state at this point. Regards, Brian --fpcSBBKSXT7ojAa5kpVPFOucxlJU4kkOD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/akvAAoJEBOZRqCi7goqmg4IAL6PZmtwVhrwCndbzBrccUIK rb+4BSj5N8Orr4bai4lGGIoNzI9bOly3lyXWmLmXjOSzPVp20Zr1W661BsSYTaxG 7kSSHfpwmAuw29Vp7FlR51do3/2mQh3afNtP5Ekaitvub/WmzIDLcowtevh+qnIq 5ykf7iDfR66Hbk8YxEPjE+BUkI89EtHj4Isgx7zqz51bcPg850sQzHs1/HWC5lg7 oDy8rqF+XSTer8pS6GKjMVqGgWJU6FjRT3A5kFuDajuvUCOS9METjlYiI/pSUjNv Y6MSZk5Wredrlm1woyV6ay/aVnpvZlWU6xMDv6WlENUvYOd07BJuOAU2MQ9QKGQ= =W8J7 -----END PGP SIGNATURE----- --fpcSBBKSXT7ojAa5kpVPFOucxlJU4kkOD-- From nobody Mon Mar 9 07:22:38 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521301A897E for ; Mon, 9 Mar 2015 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eZeA83_Kzaa for ; Mon, 9 Mar 2015 07:22:34 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4621A896E for ; Mon, 9 Mar 2015 07:22:06 -0700 (PDT) Received: by wivr20 with SMTP id r20so21126583wiv.3 for ; Mon, 09 Mar 2015 07:22:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=TgLppx4YNrdESCXZEjoSKBW81Avqp1CGXlb5LpeZkE8=; b=lu92ZSqR4QuUJ5GL+02QQh+CzB2OZeWD0+MnErHOvWsS0OZ1Ms9Jgu/TwFN9MGoMnk +eUlk84Pfru0aT3Vodbnoejr9kce8FId5B1XG0KqUcJHYD53HEfqDhB7Sy1Gpbj/p12J j0I8JoVtgOUNQ7/01xrytlLCMoYW6MWyRCEdKCBm791zLf31T/Awy9fwJ5yuvfeLA8tx 5aNniRe+BYueyuFmBucB3Nx+33yBmYi8+C5iWXgfDGvVqPQj6Pwy5mqmGLVzc8wKXXVG KgDVMhZs0NLCtB6LbuGGmiIr94GBOW0vIIEkXwqZ6yd5H+yExriUxGLBjfq6SD1jFrw1 /+yQ== X-Gm-Message-State: ALoCoQmq5nZY0BqLkvhx6KRRlGA7rY1VwWQlvoNE64iNrakr1AciYWRDgsDzI2dlFF/eb1+q/Mo5 X-Received: by 10.180.78.202 with SMTP id d10mr103545216wix.25.1425910924772; Mon, 09 Mar 2015 07:22:04 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:307a:fa5f:f904:618a? ([2001:660:330f:a4:307a:fa5f:f904:618a]) by mx.google.com with ESMTPSA id dz6sm15747021wib.0.2015.03.09.07.22.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 07:22:03 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_6916DA15-C79E-4F27-B02D-FE2F6D4D8C53" Date: Mon, 9 Mar 2015 15:22:12 +0100 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-lisp-impact@tools.ietf.org Subject: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 14:22:36 -0000 --Apple-Mail=_6916DA15-C79E-4F27-B02D-FE2F6D4D8C53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, the authors of the LISP Impact document = [https://tools.ietf.org/html/draft-ietf-lisp-impact-01 = ] requested the = Work Group Last Call. This email starts a WG Last Call, to end March 30th, 2015. Because usually the pre-meeting period is already overloaded, the LC = duration is set to three weeks. Please review this updated WG document and let the WG know if you agree = that it is ready for handing to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. Any raised issue will be discussed during the WG meeting in Dallas. Thanks Luigi & Joel --Apple-Mail=_6916DA15-C79E-4F27-B02D-FE2F6D4D8C53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

the= authors of the LISP Impact document  [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] = requested the Work Group Last Call.

This email starts a WG Last Call, to end March 30th, = 2015.
Because usually the = pre-meeting period is already overloaded, the LC duration is set to = three weeks.

Please review this updated WG document and let the WG know if = you agree that it is ready for handing to the AD.
If you have objections, please state your reasons why, and = explain what it would take to address your concerns.

Any raised issue will be discussed during the WG meeting in = Dallas.

Thanks

Luigi & Joel

= --Apple-Mail=_6916DA15-C79E-4F27-B02D-FE2F6D4D8C53-- From nobody Mon Mar 9 08:39:42 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707B91A8AE7 for ; Mon, 9 Mar 2015 08:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Woq-xKBV5Akk for ; Mon, 9 Mar 2015 08:39:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C38A1A9032 for ; Mon, 9 Mar 2015 08:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1189; q=dns/txt; s=iport; t=1425915312; x=1427124912; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Vw+r0wJs3287i0fN7KLZmi59znXRJoKDX6vGS64iq2c=; b=UKOD5hDheMnu4PZP2hQ+O5SEshw1d+do5nrD+56NTwl8rbyqMq9DeMze QgbVjkWJBOnIc1U9XDCudDuKDYYHNEOs7CbY3HDfNNYAe/ippCXUL3puK 76gQ8fGLTTVrInYpLmnn5vqJGKBINyUFC/eaVFay8EQR4KfSgqbo1cdfC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbBQA8vf1U/5FdJa1ZA4MGUloEwmeFcAKBJU0BAQEBAQF8hA8BAQEDAW8KEAIBCBguMiUCBA4FiCcIDcALAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXgT2CTwsGAR0jEAIFEYMGgRYFhXmKFolTk3Qjgg+BX28BgQIIFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="130249206" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 09 Mar 2015 15:35:11 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t29FZBqP001061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 15:35:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 10:35:11 -0500 From: "Gregg Schudel (gschudel)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxls8Hl+pKXQkekcAzaN3dwL5zkBIuAgAAYB4CAAARNAIAAA3iAgAAG+wCAMDjR2YAAbDGA Date: Mon, 9 Mar 2015 15:35:10 +0000 Message-ID: <677F4128-C137-4181-B169-D42E1DFDDB6E@cisco.com> References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> <54FDA92F.9060902@innovationslab.net> In-Reply-To: <54FDA92F.9060902@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.184.106] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97AAB6C04EC55546A11E79B8513D3D96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:39:41 -0000 On Mar 9, 2015, at 7:07 AM, Brian Haberman wrote= : >=20 >=20 > On 2/6/15 12:58 PM, Gregg Schudel (gschudel) wrote: >>=20 >> On Feb 6, 2015, at 7:44 AM, Brian Haberman wr= ote: >>=20 >>> It turns out that the discussion during review was with the upper limit= . >>> I can't find any reference to discussions on the lower limit. Authors? >>=20 >> going back to check Brian - it was a while ago. >=20 > Have we gotten anywhere with this check? The erratum is sitting in a > less-than-useful state at this point. my apologies Brian - i=92d totally forgotten this one. thanks for the (gentle :) reminder ! >=20 > Regards, > Brian Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From nobody Mon Mar 9 10:09:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91C81A8F4B for ; Mon, 9 Mar 2015 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOl7dzOuFRAw for ; Mon, 9 Mar 2015 10:09:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E0D1A8ABE for ; Mon, 9 Mar 2015 10:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1638; q=dns/txt; s=iport; t=1425920981; x=1427130581; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3oxJEBSF4qHn43kqrk6ArUIVpL5f9xbUT76OVv59PwU=; b=kuYmALcJaTX9hEv5NSkNuavE5YP5157Thph4liMW7CmFMmAg+APYZkdj Faxmd+6yBNsMt80G3a8kdGhF4SJcb/7Lc7mpHFghjPDqUqmqWslBU2wKC a8Iz+vu5ouFMjC7DKXKZphX+vSJsQmduWja4fSczG9+/SFsy2lZhC5TH6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMBQDU0v1U/4cNJK1ZA4MGUloEwmeFcAKBKk0BAQEBAQF8hA8BAQEDAW8KEAIBCBguMiUCBA4FiCcIDcBtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXgT2CTwsGAR0jEAIFEYMGgRYFhXmIFIICiVOTdCOCD4FfbwGBAggXIn8BAQE X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="402079297" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2015 17:09:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t29H9eBV022633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 17:09:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 12:09:39 -0500 From: "Gregg Schudel (gschudel)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxls8Hl+pKXQkekcAzaN3dwL5zkBIuAgAAYB4CAAARNAIAAA3iAgAAG+wCAMDjR2YAAhpcA Date: Mon, 9 Mar 2015 17:09:39 +0000 Message-ID: <2F6DE777-4655-4F71-87CC-84ABA2EF3B5C@cisco.com> References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> <54FDA92F.9060902@innovationslab.net> In-Reply-To: <54FDA92F.9060902@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.184.106] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:09:42 -0000 On Mar 9, 2015, at 7:07 AM, Brian Haberman wrote= : >=20 >=20 > On 2/6/15 12:58 PM, Gregg Schudel (gschudel) wrote: >>=20 >> On Feb 6, 2015, at 7:44 AM, Brian Haberman wr= ote: >>=20 >>> It turns out that the discussion during review was with the upper limit= . >>> I can't find any reference to discussions on the lower limit. Authors? >>=20 >> going back to check Brian - it was a while ago. >=20 > Have we gotten anywhere with this check? The erratum is sitting in a > less-than-useful state at this point. >=20 > Regards, > Brian Hi Brian I=92m really sorry about droppng this.=20 I=92ve checked internal notes, authors, etc. I cannot find any record of (n= or do we recall) us discussing =93minimum length.=94 Looking at it now, the= value of =935=94 in RFC7052 does not match any =93real minimum length=94 t= hat we can see. Further, (in discussing with Isidor), the ability to return unspecified as = an empty address, hence =930=94 length, makes sense. So, again - the errate makes sense. No evidence is available to indicate ot= herwise. thanks! Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From nobody Mon Mar 9 10:14:10 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84771A8BBF; Mon, 9 Mar 2015 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs7nAN6JYq15; Mon, 9 Mar 2015 10:14:06 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C507A1A9054; Mon, 9 Mar 2015 10:14:06 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A9B01880E1; Mon, 9 Mar 2015 10:14:06 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2FA16136827E; Mon, 9 Mar 2015 10:14:06 -0700 (PDT) Message-ID: <54FDD4DE.6050201@innovationslab.net> Date: Mon, 09 Mar 2015 13:14:06 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ietf@ietf.org, "lisp@ietf.org" , l2tpext@ietf.org, trill@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q1HAX9xd3waUiA6o4I5VWcAB8VigNlgVf" Archived-At: Subject: [lisp] Announcement of the move of L2TPEXT, LISP, and TRILL X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:14:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q1HAX9xd3waUiA6o4I5VWcAB8VigNlgVf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, As a part of the IESG re-organization, the IESG discussed moving some Working Groups from the Internet Area to the Routing Area. Now that we know we will have three RTG ADs seated from the Dallas meeting onwards, we will go ahead with our plan to move L2TPEXT, LISP and TRILL from INT to RTG. This move will be effective immediately after IETF-92. Regards, Brian --Q1HAX9xd3waUiA6o4I5VWcAB8VigNlgVf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/dTeAAoJEBOZRqCi7goqyokIALajR0zVrZWEBShjewiyBmsN JoUsnxO9eXGOLn2asZI6MTIhqCG3WqFcG8b/68RVsr+Ymd7e4VrSZV/D+sWs8FbD 19JOifZCs2GcrQ+A1bdC55gIgu+dxSpgtjpYm2w5+HDkf/XNCvm1eEgJob306XdY BLFfHpYLXmKIGB4AA+GaSNfk+e60Z2YCZutHE6GILup1atYQvfKmM3DTuEFkE4kl 6Q4FAXI9QLNxeBmYw7RukgVYPXRYVTzvaMTQJJRRbUsV++pmB3qjbQHgu9FJon2D ouOxsJWC+XW8vHwjl7pJhZaiRIrM7mM8Lp3+WuTIl1JHJuHkaaNjwbgyuEdVpJQ= =Y2sB -----END PGP SIGNATURE----- --Q1HAX9xd3waUiA6o4I5VWcAB8VigNlgVf-- From nobody Mon Mar 9 10:19:09 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152361A9096 for ; Mon, 9 Mar 2015 10:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdYDzx4BKjqx for ; Mon, 9 Mar 2015 10:19:07 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295361A8908 for ; Mon, 9 Mar 2015 10:19:07 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 032F48813E; Mon, 9 Mar 2015 10:19:07 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 42EB171B0001; Mon, 9 Mar 2015 10:19:06 -0700 (PDT) Message-ID: <54FDD607.1090701@innovationslab.net> Date: Mon, 09 Mar 2015 13:19:03 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Gregg Schudel (gschudel)" References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> <54FDA92F.9060902@innovationslab.net> <2F6DE777-4655-4F71-87CC-84ABA2EF3B5C@cisco.com> In-Reply-To: <2F6DE777-4655-4F71-87CC-84ABA2EF3B5C@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="alipJwwpXBe2VEB6eC3htpijSVT8NuIi2" Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:19:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --alipJwwpXBe2VEB6eC3htpijSVT8NuIi2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Gregg, On 3/9/15 1:09 PM, Gregg Schudel (gschudel) wrote: >=20 > On Mar 9, 2015, at 7:07 AM, Brian Haberman > wrote: >=20 >>=20 >>=20 >> On 2/6/15 12:58 PM, Gregg Schudel (gschudel) wrote: >>>=20 >>> On Feb 6, 2015, at 7:44 AM, Brian Haberman >>> wrote: >>>=20 >>>> It turns out that the discussion during review was with the >>>> upper limit. I can't find any reference to discussions on the >>>> lower limit. Authors? >>>=20 >>> going back to check Brian - it was a while ago. >>=20 >> Have we gotten anywhere with this check? The erratum is sitting in >> a less-than-useful state at this point. >>=20 >> Regards, Brian >=20 >=20 > Hi Brian I=92m really sorry about droppng this. >=20 >=20 > I=92ve checked internal notes, authors, etc. I cannot find any record > of (nor do we recall) us discussing =93minimum length.=94 Looking at it= > now, the value of =935=94 in RFC7052 does not match any =93real minimum= > length=94 that we can see. >=20 > Further, (in discussing with Isidor), the ability to return > unspecified as an empty address, hence =930=94 length, makes sense. >=20 > So, again - the errate makes sense. No evidence is available to > indicate otherwise. >=20 Isidor and I discussed whether changing all the lower bounds of 5 to 0 made sense or if there was a smaller subset of variables that should be changed. Isidor insisted on lispEidRegistrationLastRegisterSenderLength being changed, but there are potentially others. I do not want to see a slew of errata roll in over the years changing one variable's lower limit at a time. Keeping in mind, a change for one variable actually requires a change to two variables (the affected variable and its corresponding Length variable). Can the WG identify all the MIB variables that it wants changed with this erratum? Regards, Brian --alipJwwpXBe2VEB6eC3htpijSVT8NuIi2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/dYHAAoJEBOZRqCi7goqUrUH/0BaM0kTCV7rDvhWnc2qV/Fr tQaVwtK9/ClWJNXc5wrCOFXubBmNa48TKOb4YAxNYjZwLj4f6cyhUNmRJtl8ErVG 3cS06cK6HUyo7952ZFN2/6659AE42cE5Q3F/+IvGgjTBMz0LpA6NhU7ez740qHOR zuJH1y2ltDchLEdJdrteZd+GGhsajKotfBC/p8DBXdgmcv3CKLBRAhmO9HPGi6eM CNyZeXeomEH6koXmoxk24RdezvidwRxq8XN/Of3VWDDO1pe37N5HFzqaIZvou3In PdkoabzFXPpdr0J2GYiizS++NOfJ2YZhDIlyVHNDmei/oggXI2KMR9GfMzctBRA= =E20N -----END PGP SIGNATURE----- --alipJwwpXBe2VEB6eC3htpijSVT8NuIi2-- From nobody Mon Mar 9 11:37:20 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D81A870E; Mon, 9 Mar 2015 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2IZo987Cg4t; Mon, 9 Mar 2015 11:37:13 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8081A891F; Mon, 9 Mar 2015 11:37:12 -0700 (PDT) Received: by labhs14 with SMTP id hs14so73050682lab.4; Mon, 09 Mar 2015 11:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bUOOX999wnA3ZgfOfHFEdr01ZFvOf7Ic8nfuypkmH3U=; b=pCoq2PmhRKXbONeYlLXrGLy34ys1EXyVe/AhgKtDf3+0Ceo20u8uvJ1+G1Z+EVZt8X Y8ENJKxinUFEet8W1mnLxncA33mdRwAJ54anscRPaLcUUsTssCr2XnhuRLrM42gcBbWu IJt2HfOFzoDo/h2Ze0gw7Krn3+/EMJxS4FG5bwNWO25D9G0lMBGYOF8nOk1xwU0nNVC1 nwliV3dOygpeaWW3fZXaUvY8O5FVwz2BWhYAVpl8PeCU6pfqwLklkW/Ezu6Wqb7A/Nps mXG/raAFxMG98+I79WoVrFOUbKOcN/fUipWVBhaMr/9BA1dsAjnnkCqa8RWrboDIZBMS +fmg== MIME-Version: 1.0 X-Received: by 10.112.235.10 with SMTP id ui10mr27635701lbc.77.1425926231197; Mon, 09 Mar 2015 11:37:11 -0700 (PDT) Received: by 10.152.129.193 with HTTP; Mon, 9 Mar 2015 11:37:11 -0700 (PDT) In-Reply-To: References: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 13:37:11 -0500 Message-ID: From: Spencer Dawkins at IETF To: acabello@ac.upc.edu Content-Type: multipart/alternative; boundary=001a11c3d8ca7c8b630510df5202 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:37:18 -0000 --001a11c3d8ca7c8b630510df5202 Content-Type: text/plain; charset=UTF-8 Hi, Albert, On Mon, Mar 9, 2015 at 7:15 AM, Albert Cabellos wrote: > Hi > > Thank you very much for your comments, please find below how we plan to > address them: > > On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-lisp-introduction-12: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm a Yes because this draft is helpful to the largely uninitiated (that >> would include me), but I was consistently encountering questions that >> Adrian's Discuss and Comments answered, so I'd encourage you to work >> through his Comments, as well as his Discuss. >> >> Beyond that: >> >> In this text: >> >> 3.3.1. LISP Encapsulation >> >> ITRs encapsulate data packets towards ETRs. LISP data packets are >> encapsulated using UDP (port 4341), the source port is usually >> selected by the ITR using a 5-tuple hash of the inner header (so to >> be consistent in case of multi-path solutions such as ECMP [RFC2992]) >> and ignored on reception. >> >> would you ever use "virtual xTRs" with the same outermost IP addresses? >> If not, fine, but if so, would you need to use different destination >> ports to disambiguate them? Or does the Instance ID provide enough >> isolation to meet this need? >> >> I ask because adding virtual hosts to HTTP was a drag, so best for me to >> ask early! >> >> > Indeed and as you point out InstanceID should provide enough isolation. > Please let me know if the following sentence (section 4.1) clarifies your > point: > > The Map-Cache is indexed by (Instance ID, EID-prefix) and > contains basically the set of RLOCs with the associated traffic > engineering policies (priorities and weights). > Thanks - if I'd seen Instance ID mentioned where this paragraph will appear, I'd have understood what was going on! Spencer > > > Further in the same paragraph, in this text: >> >> A particularity of LISP is that UDP >> packets should include a zero checksum [RFC6935] [RFC6936] that it is >> not verified in reception, LISP also supports non-zero checksums that >> may be verified. This decision was made because the typical >> transport protocols used by the applications already include a >> checksum, by neglecting the additional UDP encapsulation checksum >> xTRs can forward packets more efficiently. >> >> I'm wobbling between "should include a zero checksum" and "also supports >> non-zero checksums". Is that text saying something like this? >> >> LISP data packets are often encapsulated in UDP packets that >> include a zero checksum [RFC6935] [RFC6936] that is not verified >> when it is received, because LISP data packets typically include >> an inner transport protocol header with a non-zero checksum. By >> omitting the additional outer UDP encapsulation checksum, xTRs >> can forward packets more efficiently. If LISP data packets are >> encapsulated in UDP packets with non-zero checksums, the outer >> UDP checksums are verified when the UDP packets are received, as >> part of normal UDP processing. >> >> > This is correct, I'll update the paragraph as you suggest, thanks! > > Albert > >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > --001a11c3d8ca7c8b630510df5202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Albert,

On Mon, Mar 9, 2015 at 7:15 AM, Albert Cabellos <albert.cabellos@gmail.com> wrote:
Hi

Thank you very much for your= comments, please find below how we plan to address them:

On W= ed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins <spencerdawkins.= ietf@gmail.com> wrote:
Spencer Dawkins ha= s entered the following ballot position for
draft-ietf-lisp-introduction-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes because this draft is helpful to the largely uninitiated (tha= t
would include me), but I was consistently encountering questions that
Adrian's Discuss and Comments answered, so I'd encourage you to wor= k
through his Comments, as well as his Discuss.

Beyond that:

In this text:

3.3.1.=C2=A0 LISP Encapsulation

=C2=A0 =C2=A0ITRs encapsulate data packets towards ETRs.=C2=A0 LISP data pa= ckets are
=C2=A0 =C2=A0encapsulated using UDP (port 4341), the source port is usually=
=C2=A0 =C2=A0selected by the ITR using a 5-tuple hash of the inner header (= so to
=C2=A0 =C2=A0be consistent in case of multi-path solutions such as ECMP [RF= C2992])
=C2=A0 =C2=A0and ignored on reception.

would you ever use "virtual xTRs" with the same outermost IP addr= esses?
If not, fine, but if so, would you need to use different destination
ports to disambiguate them? Or does the Instance ID provide enough
isolation to meet this need?

I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early!


Indeed and as you point ou= t InstanceID should provide enough isolation. Please let me know if the fol= lowing sentence (section 4.1) clarifies your point:

The Map-Cache is indexed by (Instance ID, EID-prefix) and
=C2= =A0 =C2=A0contains basically the set of RLOCs with the associated traffic
=C2=A0 =C2=A0engineering policies (priorities and weights).
<= /div>


Thanks - i= f I'd seen Instance ID mentioned where this paragraph will appear, I= 9;d have understood what was going on!

Spencer
=C2=A0
=C2=A0<= /div>

Further in the same paragraph, in this text:

=C2=A0 =C2=A0A particularity of LISP is that UDP
=C2=A0 =C2=A0packets should include a zero checksum [RFC6935] [RFC6936] tha= t it is
=C2=A0 =C2=A0not verified in reception, LISP also supports non-zero checksu= ms that
=C2=A0 =C2=A0may be verified.=C2=A0 This decision was made because the typi= cal
=C2=A0 =C2=A0transport protocols used by the applications already include a=
=C2=A0 =C2=A0checksum, by neglecting the additional UDP encapsulation check= sum
=C2=A0 =C2=A0xTRs can forward packets more efficiently.

I'm wobbling between "should include a zero checksum" and &qu= ot;also supports
non-zero checksums". Is that text saying something like this?

=C2=A0 =C2=A0LISP data packets are often encapsulated in UDP packets that =C2=A0 =C2=A0include a zero checksum [RFC6935] [RFC6936] that is not verifi= ed
=C2=A0 =C2=A0when it is received, because LISP data packets typically inclu= de
=C2=A0 =C2=A0an inner transport protocol header with a non-zero checksum. B= y
=C2=A0 =C2=A0omitting the additional outer UDP encapsulation checksum, xTRs=
=C2=A0 =C2=A0can forward packets more efficiently. If LISP data packets are=
=C2=A0 =C2=A0encapsulated in UDP packets with non-zero checksums, the outer=
=C2=A0 =C2=A0UDP checksums are verified when the UDP packets are received, = as
=C2=A0 =C2=A0part of normal UDP processing.


This is correct, I'll updat= e the paragraph as you suggest, thanks! =C2=A0 =C2=A0

<= div>Albert=C2=A0

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


--001a11c3d8ca7c8b630510df5202-- From nobody Mon Mar 9 11:37:26 2015 Return-Path: X-Original-To: expand-draft-ietf-lisp-introduction.all@virtual.ietf.org Delivered-To: lisp@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E01C91A9218; Mon, 9 Mar 2015 11:37:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-lisp-introduction.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D81A870E; Mon, 9 Mar 2015 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2IZo987Cg4t; Mon, 9 Mar 2015 11:37:13 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8081A891F; Mon, 9 Mar 2015 11:37:12 -0700 (PDT) Received: by labhs14 with SMTP id hs14so73050682lab.4; Mon, 09 Mar 2015 11:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bUOOX999wnA3ZgfOfHFEdr01ZFvOf7Ic8nfuypkmH3U=; b=pCoq2PmhRKXbONeYlLXrGLy34ys1EXyVe/AhgKtDf3+0Ceo20u8uvJ1+G1Z+EVZt8X Y8ENJKxinUFEet8W1mnLxncA33mdRwAJ54anscRPaLcUUsTssCr2XnhuRLrM42gcBbWu IJt2HfOFzoDo/h2Ze0gw7Krn3+/EMJxS4FG5bwNWO25D9G0lMBGYOF8nOk1xwU0nNVC1 nwliV3dOygpeaWW3fZXaUvY8O5FVwz2BWhYAVpl8PeCU6pfqwLklkW/Ezu6Wqb7A/Nps mXG/raAFxMG98+I79WoVrFOUbKOcN/fUipWVBhaMr/9BA1dsAjnnkCqa8RWrboDIZBMS +fmg== MIME-Version: 1.0 X-Received: by 10.112.235.10 with SMTP id ui10mr27635701lbc.77.1425926231197; Mon, 09 Mar 2015 11:37:11 -0700 (PDT) Received: by 10.152.129.193 with HTTP; Mon, 9 Mar 2015 11:37:11 -0700 (PDT) In-Reply-To: References: <20150304062237.2720.128.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 13:37:11 -0500 Message-ID: From: Spencer Dawkins at IETF To: acabello@ac.upc.edu Content-Type: multipart/alternative; boundary=001a11c3d8ca7c8b630510df5202 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-introduction.all@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Spencer Dawkins' Yes on draft-ietf-lisp-introduction-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:37:19 -0000 --001a11c3d8ca7c8b630510df5202 Content-Type: text/plain; charset=UTF-8 Hi, Albert, On Mon, Mar 9, 2015 at 7:15 AM, Albert Cabellos wrote: > Hi > > Thank you very much for your comments, please find below how we plan to > address them: > > On Wed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-lisp-introduction-12: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm a Yes because this draft is helpful to the largely uninitiated (that >> would include me), but I was consistently encountering questions that >> Adrian's Discuss and Comments answered, so I'd encourage you to work >> through his Comments, as well as his Discuss. >> >> Beyond that: >> >> In this text: >> >> 3.3.1. LISP Encapsulation >> >> ITRs encapsulate data packets towards ETRs. LISP data packets are >> encapsulated using UDP (port 4341), the source port is usually >> selected by the ITR using a 5-tuple hash of the inner header (so to >> be consistent in case of multi-path solutions such as ECMP [RFC2992]) >> and ignored on reception. >> >> would you ever use "virtual xTRs" with the same outermost IP addresses? >> If not, fine, but if so, would you need to use different destination >> ports to disambiguate them? Or does the Instance ID provide enough >> isolation to meet this need? >> >> I ask because adding virtual hosts to HTTP was a drag, so best for me to >> ask early! >> >> > Indeed and as you point out InstanceID should provide enough isolation. > Please let me know if the following sentence (section 4.1) clarifies your > point: > > The Map-Cache is indexed by (Instance ID, EID-prefix) and > contains basically the set of RLOCs with the associated traffic > engineering policies (priorities and weights). > Thanks - if I'd seen Instance ID mentioned where this paragraph will appear, I'd have understood what was going on! Spencer > > > Further in the same paragraph, in this text: >> >> A particularity of LISP is that UDP >> packets should include a zero checksum [RFC6935] [RFC6936] that it is >> not verified in reception, LISP also supports non-zero checksums that >> may be verified. This decision was made because the typical >> transport protocols used by the applications already include a >> checksum, by neglecting the additional UDP encapsulation checksum >> xTRs can forward packets more efficiently. >> >> I'm wobbling between "should include a zero checksum" and "also supports >> non-zero checksums". Is that text saying something like this? >> >> LISP data packets are often encapsulated in UDP packets that >> include a zero checksum [RFC6935] [RFC6936] that is not verified >> when it is received, because LISP data packets typically include >> an inner transport protocol header with a non-zero checksum. By >> omitting the additional outer UDP encapsulation checksum, xTRs >> can forward packets more efficiently. If LISP data packets are >> encapsulated in UDP packets with non-zero checksums, the outer >> UDP checksums are verified when the UDP packets are received, as >> part of normal UDP processing. >> >> > This is correct, I'll update the paragraph as you suggest, thanks! > > Albert > >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > --001a11c3d8ca7c8b630510df5202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Albert,

On Mon, Mar 9, 2015 at 7:15 AM, Albert Cabellos <albert.cabellos@gmail.com> wrote:
Hi

Thank you very much for your= comments, please find below how we plan to address them:

On W= ed, Mar 4, 2015 at 7:22 AM, Spencer Dawkins <spencerdawkins.= ietf@gmail.com> wrote:
Spencer Dawkins ha= s entered the following ballot position for
draft-ietf-lisp-introduction-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introducti= on/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm a Yes because this draft is helpful to the largely uninitiated (tha= t
would include me), but I was consistently encountering questions that
Adrian's Discuss and Comments answered, so I'd encourage you to wor= k
through his Comments, as well as his Discuss.

Beyond that:

In this text:

3.3.1.=C2=A0 LISP Encapsulation

=C2=A0 =C2=A0ITRs encapsulate data packets towards ETRs.=C2=A0 LISP data pa= ckets are
=C2=A0 =C2=A0encapsulated using UDP (port 4341), the source port is usually=
=C2=A0 =C2=A0selected by the ITR using a 5-tuple hash of the inner header (= so to
=C2=A0 =C2=A0be consistent in case of multi-path solutions such as ECMP [RF= C2992])
=C2=A0 =C2=A0and ignored on reception.

would you ever use "virtual xTRs" with the same outermost IP addr= esses?
If not, fine, but if so, would you need to use different destination
ports to disambiguate them? Or does the Instance ID provide enough
isolation to meet this need?

I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early!


Indeed and as you point ou= t InstanceID should provide enough isolation. Please let me know if the fol= lowing sentence (section 4.1) clarifies your point:

The Map-Cache is indexed by (Instance ID, EID-prefix) and
=C2= =A0 =C2=A0contains basically the set of RLOCs with the associated traffic
=C2=A0 =C2=A0engineering policies (priorities and weights).
<= /div>


Thanks - i= f I'd seen Instance ID mentioned where this paragraph will appear, I= 9;d have understood what was going on!

Spencer
=C2=A0
=C2=A0<= /div>

Further in the same paragraph, in this text:

=C2=A0 =C2=A0A particularity of LISP is that UDP
=C2=A0 =C2=A0packets should include a zero checksum [RFC6935] [RFC6936] tha= t it is
=C2=A0 =C2=A0not verified in reception, LISP also supports non-zero checksu= ms that
=C2=A0 =C2=A0may be verified.=C2=A0 This decision was made because the typi= cal
=C2=A0 =C2=A0transport protocols used by the applications already include a=
=C2=A0 =C2=A0checksum, by neglecting the additional UDP encapsulation check= sum
=C2=A0 =C2=A0xTRs can forward packets more efficiently.

I'm wobbling between "should include a zero checksum" and &qu= ot;also supports
non-zero checksums". Is that text saying something like this?

=C2=A0 =C2=A0LISP data packets are often encapsulated in UDP packets that =C2=A0 =C2=A0include a zero checksum [RFC6935] [RFC6936] that is not verifi= ed
=C2=A0 =C2=A0when it is received, because LISP data packets typically inclu= de
=C2=A0 =C2=A0an inner transport protocol header with a non-zero checksum. B= y
=C2=A0 =C2=A0omitting the additional outer UDP encapsulation checksum, xTRs=
=C2=A0 =C2=A0can forward packets more efficiently. If LISP data packets are=
=C2=A0 =C2=A0encapsulated in UDP packets with non-zero checksums, the outer=
=C2=A0 =C2=A0UDP checksums are verified when the UDP packets are received, = as
=C2=A0 =C2=A0part of normal UDP processing.


This is correct, I'll updat= e the paragraph as you suggest, thanks! =C2=A0 =C2=A0

<= div>Albert=C2=A0

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


--001a11c3d8ca7c8b630510df5202-- From nobody Mon Mar 9 12:05:26 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9181A92E2 for ; Mon, 9 Mar 2015 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nNSuHY-82Lq for ; Mon, 9 Mar 2015 12:05:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F4E1A90D7 for ; Mon, 9 Mar 2015 12:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2305; q=dns/txt; s=iport; t=1425927895; x=1427137495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QDffjDQHBiHsSfV+ARBbAs8SGwiUJfdsuASfkvySb1I=; b=d/90pJcU6gM+56dk8EkBc72PACzFvmTAkFMaBU6GTXmmJEymAjS8jXcd ufP2AKi0IXJoM8bqd4G9QqTzLY1xFt4Ykwt6BE4U25XogSUblk1ZPlMLn K9G2RYCWmZBGoBbN5s6BZUNPkzSHdEw/1F26XkJQBb5kth1LH7or/uj9Z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AADQDI7f1U/4QNJK1SCoMGgSwEwDOIJgKBKk0BAQEBAQF8hA8BAQEDAXkFCwIBCBguMiUCBA4FiCcIwWkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeBPYJVBSQzB4MXgRYBBJAPiVOBGoV8jF4jgg+BX2+BA0F/AQEB X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="130325251" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 09 Mar 2015 19:04:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29J4scb019542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 19:04:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:04:54 -0500 From: "Isidoros Kouvelas (kouvelas)" To: Brian Haberman Thread-Topic: [Technical Errata Reported] RFC7052 (4256) Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoCAAARKAIAAA3qAgAAG+QCAACV6AIAwZx+AgAAy1ICAAAKhgIAAHZUA Date: Mon, 9 Mar 2015 19:04:54 +0000 Message-ID: <44F338B7-4A00-4B8B-A398-788110DE90CA@cisco.com> References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <54D4D87E.7060807@innovationslab.net> <54D4E142.6020409@innovationslab.net> <8A99A6AF-5E6D-458B-B7F8-8B4DE2FEA182@cisco.com> <54FDA92F.9060902@innovationslab.net> <2F6DE777-4655-4F71-87CC-84ABA2EF3B5C@cisco.com> <54FDD607.1090701@innovationslab.net> In-Reply-To: <54FDD607.1090701@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.197.103] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:05:24 -0000 On Mar 9, 2015, at 19:19, Brian Haberman wrote: > Hi Gregg, >=20 > On 3/9/15 1:09 PM, Gregg Schudel (gschudel) wrote: >>=20 >> On Mar 9, 2015, at 7:07 AM, Brian Haberman >> wrote: >>=20 >>>=20 >>> On 2/6/15 12:58 PM, Gregg Schudel (gschudel) wrote: >>>>=20 >>>> On Feb 6, 2015, at 7:44 AM, Brian Haberman >>>> wrote: >>>>=20 >>>>> It turns out that the discussion during review was with the >>>>> upper limit. I can't find any reference to discussions on the >>>>> lower limit. Authors? >>>>=20 >>>> going back to check Brian - it was a while ago. >>>=20 >>> Have we gotten anywhere with this check? The erratum is sitting in >>> a less-than-useful state at this point. >>>=20 >>> Regards, Brian >>=20 >> Hi Brian I=92m really sorry about droppng this. >>=20 >> I=92ve checked internal notes, authors, etc. I cannot find any record >> of (nor do we recall) us discussing =93minimum length.=94 Looking at it >> now, the value of =935=94 in RFC7052 does not match any =93real minimum >> length=94 that we can see. >>=20 >> Further, (in discussing with Isidor), the ability to return >> unspecified as an empty address, hence =930=94 length, makes sense. >>=20 >> So, again - the errate makes sense. No evidence is available to >> indicate otherwise. >>=20 >=20 > Isidor and I discussed whether changing all the lower bounds of 5 to 0 > made sense or if there was a smaller subset of variables that should be > changed. >=20 > Isidor insisted on lispEidRegistrationLastRegisterSenderLength being > changed, but there are potentially others. >=20 > I do not want to see a slew of errata roll in over the years changing > one variable's lower limit at a time. Keeping in mind, a change for one > variable actually requires a change to two variables (the affected > variable and its corresponding Length variable). >=20 > Can the WG identify all the MIB variables that it wants changed with > this erratum? The reason for which I think lispEidRegistrationLastRegisterSender is the o= nly use of LispAddressType that needs to be changed is that its access is "= read-only". All other uses are "not-accessible=94 and part of the index of = tables. thanks Isidor From nobody Mon Mar 9 15:05:58 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3141E1ACDBE for ; Mon, 9 Mar 2015 15:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpYJDnWnO-0N for ; Mon, 9 Mar 2015 15:05:53 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4D1ACDB8 for ; Mon, 9 Mar 2015 15:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 5CD03102DB9; Mon, 9 Mar 2015 23:05:50 +0100 (CET) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sm4qysaimxAc; Mon, 9 Mar 2015 23:05:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id A18BF102DD0; Mon, 9 Mar 2015 23:05:49 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YsLR2B5R5LF6; Mon, 9 Mar 2015 23:05:49 +0100 (CET) Received: from [192.168.0.42] (bny92-2-81-56-19-67.fbx.proxad.net [81.56.19.67]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 35C8A102DB9; Mon, 9 Mar 2015 23:05:49 +0100 (CET) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_96E0259F-3B16-4AAF-AD66-43C7B4A4861A" Date: Mon, 9 Mar 2015 23:05:48 +0100 Message-Id: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [lisp] Preliminary Agenda Available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:05:55 -0000 --Apple-Mail=_96E0259F-3B16-4AAF-AD66-43C7B4A4861A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, The preliminary agenda for our meeting in Dallas is now online: http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp = Please let the chair know any proposed change before next Monday March = 16th. ciao Luigi --Apple-Mail=_96E0259F-3B16-4AAF-AD66-43C7B4A4861A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi All,

The preliminary agenda for our meeting in Dallas is now online:


Please let the chair know any proposed change before next Monday March 16th.

ciao

Luigi


--Apple-Mail=_96E0259F-3B16-4AAF-AD66-43C7B4A4861A-- From nobody Wed Mar 11 08:04:07 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6A71A9133; Mon, 9 Mar 2015 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNmrP3VgK3GV; Mon, 9 Mar 2015 11:05:37 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EF44C1A9100; Mon, 9 Mar 2015 11:05:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Brian Haberman'" , , , , References: <54FDD4DE.6050201@innovationslab.net> In-Reply-To: <54FDD4DE.6050201@innovationslab.net> Date: Mon, 9 Mar 2015 14:05:34 -0400 Message-ID: <02ff01d05a93$a3feedf0$ebfcc9d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFVP25qrWHZBW7tmgXWuCwLom2rAp4Kp4Hw X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 08:04:06 -0700 Subject: Re: [lisp] [trill] Announcement of the move of L2TPEXT, LISP, and TRILL X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:05:38 -0000 As a TRILL co-chair - I wish to thank Brian and Ted for their years of guidance and support for TRILL. We happily look forward to Adrian and Alia's guidance in 2015 for TRILL in the Routing Area. Sue Hares -----Original Message----- From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Monday, March 09, 2015 1:14 PM To: ietf@ietf.org; lisp@ietf.org; l2tpext@ietf.org; trill@ietf.org Subject: [trill] Announcement of the move of L2TPEXT, LISP, and TRILL All, As a part of the IESG re-organization, the IESG discussed moving some Working Groups from the Internet Area to the Routing Area. Now that we know we will have three RTG ADs seated from the Dallas meeting onwards, we will go ahead with our plan to move L2TPEXT, LISP and TRILL from INT to RTG. This move will be effective immediately after IETF-92. Regards, Brian From nobody Tue Mar 17 00:59:24 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6D1A00EA for ; Tue, 17 Mar 2015 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLojPgfjspTn for ; Tue, 17 Mar 2015 00:59:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D4F4D1A00B5 for ; Tue, 17 Mar 2015 00:59:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 37183180092; Tue, 17 Mar 2015 00:58:16 -0700 (PDT) To: gschudel@cisco.com, atjain@juniper.net, vimoreno@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, jmh@joelhalpern.com, ggx@gigix.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150317075816.37183180092@rfc-editor.org> Date: Tue, 17 Mar 2015 00:58:16 -0700 (PDT) Archived-At: Cc: lisp@ietf.org, rfc-editor@rfc-editor.org Subject: [lisp] [Technical Errata Reported] RFC7052 (4304) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 07:59:23 -0000 The following errata report has been submitted for RFC7052, "Locator/ID Separation Protocol (LISP) MIB". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4304 -------------------------------------- Type: Technical Reported by: Isidor Kouvelas Section: 7 Original Text ------------- lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE SYNTAX Integer32 (5..39) MAX-ACCESS read-only Corrected Text -------------- lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE SYNTAX Integer32 (0..39) MAX-ACCESS read-only Notes ----- The lispEidRegistrationLastRegisterSender is the only use of the LispAddressType in a readable attribute. In order to be able to encode an unspecified address, the minimum length must be lowered to zero. For more information see errata 4256. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7052 (draft-ietf-lisp-mib-13) -------------------------------------- Title : Locator/ID Separation Protocol (LISP) MIB Publication Date : October 2013 Author(s) : G. Schudel, A. Jain, V. Moreno Category : EXPERIMENTAL Source : Locator/ID Separation Protocol Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Mar 17 05:35:21 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46B1A039C for ; Tue, 17 Mar 2015 05:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHn6AzCo36E8 for ; Tue, 17 Mar 2015 05:35:17 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016391A038D for ; Tue, 17 Mar 2015 05:35:16 -0700 (PDT) Received: by wetk59 with SMTP id k59so6484728wet.3 for ; Tue, 17 Mar 2015 05:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=Cimt+KXHoNWAdH2DRYRQyhlw4lNKciyLdZXQ0OhhgQw=; b=lu16sBOK0vjL2zD21T1so/C1+gHdG3l+eMHV+NlVDMIVHoXBrlMkpZYDh9uihNJHhw 9JlGvZUAqTgdai/+sGeBJCfXqVoVhniipaUEiXzhw4PdUWr+/pyVu03a7wai2S39OQW3 /VMqibttFyOZQgVpgT/CKQQNB0oPcEL3rRR6F8l0GelXgFBDGC3OElDpyAaPTXALasoQ U7NF+4aHLF+UQElYrTzt4qYkhF+LJEwV/WSi5HAPg3AmMbK638I2VrRJ/XgvQDBSqUUb 5lERch9COXlhneBL3Q2ZCO36Lu53wqybraC+tHtQIBsjXPleRWcw3rAtx/L+gKKJb3kh W1jw== X-Gm-Message-State: ALoCoQmOxlO/XCNlPaPBukZCbo9KBAl2btyMaOJAFrkGUqYLKrMLBxbZ+OSjGu5MWq+FanWdSEyl X-Received: by 10.194.94.164 with SMTP id dd4mr134795586wjb.56.1426595715638; Tue, 17 Mar 2015 05:35:15 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:1854:5f15:e6b5:cbd2? ([2001:660:330f:a4:1854:5f15:e6b5:cbd2]) by mx.google.com with ESMTPSA id fo8sm2515122wib.14.2015.03.17.05.35.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 05:35:13 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_F7BF4E8D-87DD-4267-AB38-98726A95C33D" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Tue, 17 Mar 2015 13:35:12 +0100 References: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> To: LISP mailing list list In-Reply-To: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [lisp] Preliminary Agenda Available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:35:19 -0000 --Apple-Mail=_F7BF4E8D-87DD-4267-AB38-98726A95C33D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, no changes on the agenda have been requested, which is now confirmed. All speakers are invited to send me their slides by Sunday morning at = latest. ciao L. > On 09 Mar 2015, at 23:05, Luigi Iannone = wrote: >=20 > Hi All, >=20 > The preliminary agenda for our meeting in Dallas is now online: >=20 > http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp = >=20 > Please let the chair know any proposed change before next Monday March = 16th. >=20 > ciao >=20 > Luigi >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_F7BF4E8D-87DD-4267-AB38-98726A95C33D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

no = changes on the agenda have been requested, which is now = confirmed.

All = speakers are invited to send me their slides by Sunday morning at = latest.

ciao

L.

On = 09 Mar 2015, at 23:05, Luigi Iannone <luigi.iannone@telecom-paristech.fr> wrote:

Hi All,

The preliminary agenda = for our meeting in Dallas is now online:

http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp

Please let the = chair know any proposed change before next Monday March 16th.

ciao

Luigi


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

= --Apple-Mail=_F7BF4E8D-87DD-4267-AB38-98726A95C33D-- From nobody Wed Mar 18 08:24:34 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B71A1AA6 for ; Wed, 18 Mar 2015 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Wpo0ed8ZHU for ; Wed, 18 Mar 2015 08:24:31 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A36F1A1A6F for ; Wed, 18 Mar 2015 08:24:31 -0700 (PDT) Received: by wibg7 with SMTP id g7so65754325wib.1 for ; Wed, 18 Mar 2015 08:24:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=DCn0tPPjyHS3+v/8PQsdLLB/c0UyySponRxYXPZuWUE=; b=F6q8xBuiI7T6QHdWKxu0yPO8L9DMzQqCleMDH00aQtINfG287cwUaMFQ7A/fW4DYIE 0Vs/+bUIWfI/WG6ry8tfbZyuseT/3Ef/stdxKg0ui+pB+slSoEVjVfgE67OrvREzljUT C3hq78D+J7Ke8SJvNT6rwJAMXIkJq20v/uIguO1eonrD9dfiaUKI36Pg46d5vgGzW1qh H6RzvVSWzjRGWkKQEdq6uBzgA3TCfkjroblx+A0JhoQc09tjKXeNOYXHQesjcbaOToN2 8BOplxWxGUJPNbQ5VEk8BG7g4m/TT3swIxvJ1xdyMp1jAFYP81KqzBlisXst5o5WHt02 nrMA== X-Gm-Message-State: ALoCoQnkQWIHEszYQngZtcsoohr7iPV9f/xTMGqM/69ly9/qrDJCrnNm2w83WwLZii7XICLshQCv X-Received: by 10.180.74.202 with SMTP id w10mr8130522wiv.0.1426692270025; Wed, 18 Mar 2015 08:24:30 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:354d:d83a:7ac0:cc00? ([2001:660:330f:a4:354d:d83a:7ac0:cc00]) by mx.google.com with ESMTPSA id cf12sm24935035wjb.10.2015.03.18.08.24.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 08:24:29 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_D0FE8077-6085-474B-B7FC-5577C4DF59A3" Message-Id: <9344FCAB-11D0-4797-9E51-A56253E4E37C@gigix.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Wed, 18 Mar 2015 16:24:29 +0100 References: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> To: LISP mailing list list In-Reply-To: X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [lisp] Errata - LISP Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:24:33 -0000 --Apple-Mail=_D0FE8077-6085-474B-B7FC-5577C4DF59A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, there was a mistake in the agenda that was uploaded last week. Sorry for = that. The agenda has been corrected and is now online. http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp = ciao Luigi > On 17 Mar 2015, at 13:35, Luigi Iannone wrote: >=20 > Hi All, >=20 > no changes on the agenda have been requested, which is now confirmed. >=20 > All speakers are invited to send me their slides by Sunday morning at = latest. >=20 > ciao >=20 > L. >=20 >> On 09 Mar 2015, at 23:05, Luigi Iannone = > wrote: >>=20 >> Hi All, >>=20 >> The preliminary agenda for our meeting in Dallas is now online: >>=20 >> http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp = >>=20 >> Please let the chair know any proposed change before next Monday = March 16th. >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 --Apple-Mail=_D0FE8077-6085-474B-B7FC-5577C4DF59A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

there was a mistake in the agenda that was uploaded last = week. Sorry for that.

The agenda has been corrected and is now online.

http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp

ciao

Luigi



On = 17 Mar 2015, at 13:35, Luigi Iannone <ggx@gigix.net> wrote:

Hi All,

no changes on the agenda = have been requested, which is now confirmed.

All speakers are invited to send me = their slides by Sunday morning at latest.

ciao

L.

On 09 Mar 2015, at 23:05, Luigi Iannone = <luigi.iannone@telecom-paristech.fr> wrote:

Hi All,

The preliminary agenda = for our meeting in Dallas is now online:

http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp

Please let the = chair know any proposed change before next Monday March 16th.

ciao

Luigi


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


= --Apple-Mail=_D0FE8077-6085-474B-B7FC-5577C4DF59A3-- From nobody Fri Mar 20 15:48:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071EB1A88B2 for ; Fri, 20 Mar 2015 15:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rji04q-04D5F for ; Fri, 20 Mar 2015 15:48:53 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEB41A88A4 for ; Fri, 20 Mar 2015 15:48:53 -0700 (PDT) Received: by wixw10 with SMTP id w10so326381wix.0 for ; Fri, 20 Mar 2015 15:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EEJhm1V5ads78ksfyccE+R36Lrba/VlMJpnktL2CooA=; b=y3nCj7JZKmgn32t1gRbiqGgDaS8TYCaWVa7ahcQjWBHIMOxHBryR6EtUCvxBVWkd3O bMdprF7KcbdL3SEuLGQLlPk9F2wxlfZVmjGnHyyzvkncRs9GkbCXDcOCY7oUVifCtP8v aWeMkGjtgWweekQVvfg/z8rTZ5Xj8XdSsrIjf9BkzewrbyhlDbGa2kdDw9IX7rowiJGS tAxpYO9ENpVx15pkwx2arjmvMjw7eZ6vJmn6sexjrm3D4F78w6sh3jVNe9AKkn5w07Kk HU4Y0xXuQKOTY2pn4PAkIs9VDtpdehcUwEyOxVA66ZP7rR1CJfrGDce58BBiHr7pWrIO ntgQ== X-Received: by 10.194.177.167 with SMTP id cr7mr122711303wjc.19.1426891731765; Fri, 20 Mar 2015 15:48:51 -0700 (PDT) Received: from [172.17.2.79] (ANice-652-1-10-242.w86-193.abo.wanadoo.fr. [86.193.241.242]) by mx.google.com with ESMTPSA id vq9sm8208692wjc.6.2015.03.20.15.48.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Mar 2015 15:48:50 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_699DC0CD-3D55-45E5-9160-2C9167C970A7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Fri, 20 Mar 2015 23:48:44 +0100 Message-Id: References: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> To: Luigi Iannone X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Preliminary Agenda Available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:48:55 -0000 --Apple-Mail=_699DC0CD-3D55-45E5-9160-2C9167C970A7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello, Please find attached the slides for the threats presentation. --Apple-Mail=_699DC0CD-3D55-45E5-9160-2C9167C970A7 Content-Disposition: inline; filename=20150323_IETF92_lisp_threats.pdf Content-Type: application/pdf; name="20150323_IETF92_lisp_threats.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFkU1PhDAURff8iruEBZ1+QKFLvxYaTSQ2ceG4IAgZDEyE svHfWwoOMHEiXZSQ987hvtchQ4fdjWEoDJg7pgC1h1EeIZEp+hKVKzv/+orjqZUSNT5SeiPEIcbe dsE00ytF4/ANDhY7IulY3tkuxwfjMVEcEWVEKJV4RYtrjXSqnC/dYqf1aNIV3uA/3r88Qx/6ACyF X+aDwdUxb75NbQK8Qz/gTiPzFglXkvBYQoiEiFgpTBbB3U/M17nlo8+rIazLoQqb2nyFgxV6v8KQ rUyrOP+aBLN5aQTqbXw+w96/LQuyDxBAf7oEG64iMQdX6mKALdCO6a8Ap4mFjF9KsDHNC1lGJYQg Ukk7uU0A67MJnnK7FLtO3+ZY47MfXYuQfQplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMjg5CmVu ZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAg UiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgMTAyNCA3NjhdCj4+CmVuZG9iago2IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg Pj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCAx MSAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMAB R4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDSh WBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0Mk BgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6M u1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8 cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVlt mWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl 4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kV M2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/ GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu 4UxBIlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASy QT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+Z QtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN 2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAER IWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKl YtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm 8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3Qi hhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+S P1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7 JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKB krcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIG wjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9Qw aiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJ muWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3 Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNa ozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyj eZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/ 7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnO Kc4NzqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sP kUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tP BDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5 uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsV eyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTX k7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1p hLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5n R2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I 2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJP JdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9p j2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh 3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOj ufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM 9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2eu OV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+ e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5 r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6o vjn61vZt52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVu ZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAx MCAwIFIgXQplbmRvYmoKMTMgMCBvYmoKPDwgL0xlbmd0aCAxNCAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBlZJLbsQgDIb3OcW/7CzKACEQth3NAUZC6jrKo8Moj+Yh9US9Vs9S IOkj02RRWBgh+7N/2z0u6HE8jQz5CBbumIO6yygXUDLFUKIKbve/z2i/QynR/kgZeUhA+NjmB1PP T4o64GtcHdYjqXfvXVTgQySCcEiWklhrFeUNngzS2XExpsHRGJ/IVHh4ZOwAc8PZhCq/OEojFooo qjUCJOIqpFjMGvK+hWBMOIYrR+l0ZiCWgTGbaM04F3bqBpvVeO1qO15t+/JvKk8loRz0Dk2wRXIS ueS/JGJTohuJ79OuRJ7oXYlYSzzV2WA/8myyXTsiK4qygG1RlW9Os22n8RD9nYRv426OJJaEidR1 dZ2JbJESKonQEkwR6baDL0NhPtxt7GzWHO4bF4XduHwCKhSnggplbmRzdHJlYW0KZW5kb2JqCjE0 IDAgb2JqCjMwNgplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv UmVzb3VyY2VzIDE1IDAgUiAvQ29udGVudHMgMTMgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzY4 XSA+PgplbmRvYmoKMTUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoxOCAw IG9iago8PCAvTGVuZ3RoIDE5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAF1 kstugzAQRfd8xV0mizq2eRgv2yqb7iJZ6qLqAhGSuOLRAL/U/+zYkAQQwYtB4Dlz78xcccAVu/dO IO8g/OlycDqCywgqSdEWOPlry6+fqO+pnGn3JEngIB7hcqsHphxeOUqPL3EhrENyd/1KWZ6PKI6Y RCJSFmqtgrzCm0E6XByDqbAzxhUyJ2xehNzC/GBvvMobR2mEmjPFtYaHBFL5EmOYQ/7WEEJECFPF pNLpwECYeMYQgjljf7R909qsxG9T2u5i6zPDGtdJ4/FEGmbSFtjn0rh8Kg2jNBoH9egLm9fjsd1C pNgUXYdzURctCc2bqirqvsNp/NlUqDJbknSQhd7p/4b5oOYGblMmzZVy2ty5g1v1cUITBwRgsUoF j2WwGLzrthTPuz2HDpaQob+028D7yshHZXt7znrb1OiK3MW7AdqOlXVbVA1o2R4zjrlmcRRR3nzS bG2qMU9YpBOQhYRWV46rS9L8Yg9hzgkfnMM/UEfOLAplbmRzdHJlYW0KZW5kb2JqCjE5IDAgb2Jq CjM3NgplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3Vy Y2VzIDIwIDAgUiAvQ29udGVudHMgMTggMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzY4XSA+Pgpl bmRvYmoKMjAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagoyMyAwIG9iago8 PCAvTGVuZ3RoIDI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdzj0PgjAQ BuDdX/GOupQWytGuGkcHkkucDRHFAAbL/4/9QIn2hmuae5/rhBoTsoNTaBxULNdA+lIy16jI4HVF G8f+X88Yv1EpbDhEm4BEImSHlenTVaKPfI+7ZwMpw/jkU9FHoYwgjaLUorC22jQD9gyTJpfGAzLm sIlbbE/d3N0uc/cc3Q78wJHjdz9gKUloS1CVIC/mi6hMWpjar6hXp34Dv5xAZgplbmRzdHJlYW0K ZW5kb2JqCjI0IDAgb2JqCjE2OQplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCAzIDAgUiAvUmVzb3VyY2VzIDI1IDAgUiAvQ29udGVudHMgMjMgMCBSIC9NZWRpYUJveApbMCAw IDEwMjQgNzY4XSA+PgplbmRvYmoKMjUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVu ZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAGlk09PgzAYh+98it8REsMosEKvGi8mHkxIPBgPjHVbDYOMFo0fyK+1z+LbAup0ziXC oS1pnz68f3a4ww6zK81QaTD36goRvSyKU2Q8Ryexctu+f71H83E0CoV9OPcsxCHs2e0nph6mEWqH r7EhrEVGdvuOTjk+koiDszxMhMi8aovLAvmwbRyKLWZFYa8pVniAfynRqXXbBWA5/LbXAR5R3OC6 cNYTNxNI52mYRUKM2DhzV47DAdZ/C1A8fUcwlhKDhXEmcjg1L+GOMQ4HDFK7bbWB2YxqsjQaVdlg IbFVRq1LI5d4UWYDUvZ+Ktv7Ei6c83AfznH2bE6n32apIAb/4kzLX539fW1kp1E2S3Skh1qRaWlU 2+gLBN7xmMT5ENf/OMb517iedKzaZr/uSc9a4Vl2al/9pcjE/8PIxLlhpNQvZVkZ9ey80K6wouz3 XeDZGpWaiqI0KKfCQNPSaqHbujeyfrXlcKSCbSrZPJlS6VFnnEglOUz4Xa+m6TI8zp5HPEwFB8tC Tp0Xjy1Ctq4rh+GgvP35Z4vcvQN1/wImCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKNDE3CmVu ZG9iagoyNyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzAg MCBSIC9Db250ZW50cyAyOCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3NjhdID4+CmVuZG9iagoz MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9MZW5n dGggMzQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AY1VwW6bQBC98xVzxFK9 2V2WBdRTmrRSq1ZqEqQcoh4Q3jhUgLGXtPUH5bfyLZ1dIBhsHMzBKxvem3lv5rGFG9jCxZVmkGpg 9tIpULwY5QICGcJOwaO9bfzrPZRvj1ISmY+UjgGxEObZoofJmyOF3MLn8ISwBpKa27f4lMUHxiSR Erml9Ijw/cBJC/gUgwwIt7e8HeICLuLY8MWP8ADu5XP9pMo6S5NaQbop690CWAjuJl9WeVIqWDi/ IP4Gn2PbTkfo+QGhHhbrhw0hzCF03EJpnayVXkD8e4wZRODziPDA5y0a9wlrGPtT2wBKhg24L6eA GGPE9xHMJwGlXgvmYaGhFaM/DcEu87/JXsOzVoCiQNJLk21KmMfkoOo9fnMSviA0jIwTY/kLlT4l ZaYLDVWn/J9spVaQIeNJ6dvuRChmdme9dlzTkq5Umr2i19iQnuhIgKAh4eycC86gjwkXhDQuCCqI FOdcGIE9bnbwI6mWt2r7rHR90ZyrfH/SgCFJO/ZHBnBBmB+aURoW3oKvM12rHWiF494NpnOwXQ2J h7t1vpMR+u2XKxl69AM0Bw+ScgXfv979XN6p9CPae7wDjAngYYDVnpN/xPNyEqkpmuN++uE5+Ydg D45rDOj2FNQ/M6BrO5Co0QKWJh3KJM/3ZkTNUBVJVWXlGqU7lRSsrUNwW8eEQybGBtZgNOk9ulJY V6xo19cxZhMGgksaKmcUSiOqib33PIby0uCQ0TFZ0nt/kKwYSkxKQqPZfjgT69CEEpOoA5/nh60q RoXfhvKgsDYG3sGTmKBIh7nXbhlvkt8dhdsqqRN4VflqBtWEhQKXzOO48SMn3TZ1mkxrd6JryTGv 0u6l0rXEMb5nStS+xSqcTMdOZpHVGuoNrFWpdkmeYZaPWsU/cXrfm9rGrZCaSricaPloaruZ7dYH B/V4x30qiYgksIBIL4p4C457ZV/mzddgGVzZ49z8B7YV+ocKZW5kc3RyZWFtCmVuZG9iagozNCAw IG9iago3MzUKZW5kb2JqCjMyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jl c291cmNlcyAzNSAwIFIgL0NvbnRlbnRzIDMzIDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc2OF0g Pj4KZW5kb2JqCjM1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgovVFQyIDM2IDAgUiA+PiA+Pgpl bmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBbZG/TsMwEMb3PMU3JkNdOwn+s4JY2AqWGBCDSd0ScBKaWFQ8EO9J7ARKq/iGs+y7 3313d8AGB6xvBoZqAIs2VKCjMZqXEFyit9jFsMvXR7R/qZSocDhPAiQiQm5zwrjpSuEi3uF1xAYk DeGHMSvywUpKJDiTpFBKJFWDaw05Bc5ON1hrHQrpHdIH1x1X2+7YwnhvqnfbDxn0G251VP3LFQpF zomgSs3QXMSSszuHfi8hGCtHRkFyoSSisKTgkTG7M8YT0nvjLVzd1B5V1/o+A5NIO7f6cKa1MJWv u3aA7+v93vZZEn7tFi9f2BpvVhmeoe8uGwkqckn/qcCiinETYTxTKftpWz+Qpa6uKCel4mCC8HHk +dRZUBoXEl1y1lkqTpzND67jh8QKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iagoyOTgKZW5kb2Jq CjM4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0MSAwIFIg L0NvbnRlbnRzIDM5IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc2OF0gPj4KZW5kb2JqCjQxIDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg Pj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0 NSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBjVK7TuQwFO3zFadMCoLtSZy4 BW1DsRKSxRbLFiF4Zozy0MQeJD6I/9xrJwyE125cXMuxz+veA65xwPml42gdeFyuBaPFmShQyRqT wTZee3/6C8PpKctV+KRMAkiECG/7V5hu3jJ0Eb7DnmADJAvXD/Qq4kOwIi8FJK/zjVJV0va40Kjn m0vRPc61Dkx6i99IbzKUJVIz2e0T7LAdpwxnvEbaN96OQ4Y/0FfJDx1tvBBVChvF8oophZlEVFHD UlYk6XMG/YAZgjzOWjkvsKmrXFSqXjA2Mv5bygqDhP40j2bCvSV9QZ5pffeEozMYxuHMjZ1trTf3 i4XkjQWH2cSi4JRWVFAU/1RAkimq9DY9Dp1xDs3R783gbdsQ321G6Cd3K2whxZcJJSt3q4ReMQoF Uar/1ReiIGE9Goe9HbyDH+Enu9tRbA3tjs43d535XG/g4jJyLWPzfTc+TgpeGkOc5rHpcko90Vfv Uy+ZzAslwatc0pCKpffU0jgXc1mnU4eE5xG8/guG19LeCmVuZHN0cmVhbQplbmRvYmoKNDUgMCBv YmoKMzk1CmVuZG9iago0MyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNv dXJjZXMgNDYgMCBSIC9Db250ZW50cyA0NCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3NjhdID4+ CmVuZG9iago0NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKPj4gPj4KZW5kb2JqCjUwIDAgb2Jq Cjw8IC9MZW5ndGggNTEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV3OPQvC MBAG4L2/4h11SS9NTJtJUNxcCgfOJVhEUqHG/4/5qBbNDRfCvc9lRo8Z9TFIuACZKzhQLEmNRms6 PK8Y89j/6wWPb5SETceYKiGZSNlpZXy5EnzmPW6RTSSl8Tmmsg+llSANtdNCWdtWbsKB0ZXJpfGE mjlt4hGb8xBecIP3+y34jhPn3368HRmhrYFshYlgs4CyK/tK+wXt6vRvOcA/agplbmRzdHJlYW0K ZW5kb2JqCjUxIDAgb2JqCjE2NwplbmRvYmoKNDggMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCA0OSAwIFIgL1Jlc291cmNlcyA1MiAwIFIgL0NvbnRlbnRzIDUwIDAgUiAvTWVkaWFCb3gKWzAg MCAxMDI0IDc2OF0gPj4KZW5kb2JqCjUyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBd IC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+Pgpl bmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA1NCAwIFIgL0NvdW50IDggL0tp ZHMgWyAyIDAgUiAxMiAwIFIgMTcgMCBSIDIyIDAgUgoyNyAwIFIgMzIgMCBSIDM4IDAgUiA0MyAw IFIgXSA+PgplbmRvYmoKNDkgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTQgMCBSIC9D b3VudCAxIC9LaWRzIFsgNDggMCBSIF0gPj4KZW5kb2JqCjU0IDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvTWVkaWFCb3ggWzAgMCAxMDI0IDc2OF0gL0NvdW50IDkgL0tpZHMgWyAzIDAgUiA0OSAwIFIg XSA+PgplbmRvYmoKNTUgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDU0IDAgUiA+Pgpl bmRvYmoKMjYgMCBvYmoKWyAyMiAwIFIgL1hZWiAwIDc2OCAwIF0KZW5kb2JqCjE2IDAgb2JqClsg MTIgMCBSIC9YWVogMCA3NjggMCBdCmVuZG9iago1MyAwIG9iagpbIDQ4IDAgUiAvWFlaIDAgNzY4 IDAgXQplbmRvYmoKNDIgMCBvYmoKWyAzOCAwIFIgL1hZWiAwIDc2OCAwIF0KZW5kb2JqCjM3IDAg b2JqClsgMzIgMCBSIC9YWVogMCA3NjggMCBdCmVuZG9iagozMSAwIG9iagpbIDI3IDAgUiAvWFla IDAgNzY4IDAgXQplbmRvYmoKNDcgMCBvYmoKWyA0MyAwIFIgL1hZWiAwIDc2OCAwIF0KZW5kb2Jq CjIxIDAgb2JqClsgMTcgMCBSIC9YWVogMCA3NjggMCBdCmVuZG9iago5IDAgb2JqClsgMiAwIFIg L1hZWiAwIDc2OCAwIF0KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1Ry dWVUeXBlIC9CYXNlRm9udCAvSEpOWkNKK0hlbHZldGljYS1MaWdodCAvRm9udERlc2NyaXB0b3IK NTYgMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hh ciAyMjIgL1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4 IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2CjU1NiA1NTYgMCAyNzggMCAwIDAg NTAwIDAgNjY3IDY2NyA3MjIgNzIyIDYxMSA1NTYgMCAwIDI3OCAwIDAgNTU2IDgzMyA3MjIKMCA2 MTEgMCA2NjcgNjExIDU1NiAwIDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA2MTEgNTU2IDYx MSA1NTYgMjc4IDYxMQo1NTYgMjIyIDAgNTAwIDIyMiA4MzMgNTU2IDU1NiA2MTEgNjExIDMzMyA1 MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCA1 MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDUwMCBdID4+CmVuZG9iago1NiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnRO YW1lIC9ISk5aQ0orSGVsdmV0aWNhLUxpZ2h0IC9GbGFncyAzMiAvRm9udEJCb3gKWy00NTMgLTM1 NSAxMzQ1IDEyMDZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0Nh cEhlaWdodAo3MTggL1N0ZW1WIDY4IC9YSGVpZ2h0IDUyNCAvU3RlbUggNTggL0F2Z1dpZHRoIDU5 NyAvTWF4V2lkdGggMTQ0NSAvRm9udEZpbGUyCjU3IDAgUiA+PgplbmRvYmoKNTcgMCBvYmoKPDwg L0xlbmd0aCA1OCAwIFIgL0xlbmd0aDEgMTMwODggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBxXsJcBzXeeZ7PYMZEAPMgbmAuTAzjbkHc98YDGaAAYiDxMETIClRPEWKosSVKFlS7ETx OrFD21lVOfGm1lZqkziOSrEV5pAMCU4kK64cW9mE5XJixZXDkbyJs7FdLq/iSqmEQb6/u+cgIcty lat2WA/v9evu9/776sfrDz1ygQ2yJ5mK1c9dPXONSb++v2CMf/Lco9e98jW/hd578dq9V5Xr7zEm /PO99z9+Ub7WfoOx6PsvXThzXr5mb6MvXMKEfM1z6McvXb3+mHytfg39m/c/eE65r6X33n/1zGPK /uzvcO194MzVC/Lzmf9AH7724MPXletT6D997aELyvN8A9ePyvd6/nKMp9hn2D72COtjdMXYACBn /GHgy6UZrr1a+5fdvzltqP47G1V9ix55UfzuH1P/v1986QutydbTfQ31C7jchxflH1ZSCbsOxvp+ E/df7Wsoayu30U1tsYHYFmMx9hLuCUyI8ZewpTR4GYNTbJGVWYRhDdYfe5mp2fptM+xlvPYAO8Hm WabzkMBO3/7QS8Cqj2lpI+/cBy6PNLGaBS9UWJXR2LybY/2ChumFl5hWuMXMzIJH48tbbN/axu9y /oubW3z357ZY0/0isFOdvntii/G41zt3uXmT34MLIY6JqA8jVdw7f1MVmD+0IW56b3hvLJ6/4Z33 Xjpz/qY6IPW4ceHGZtJ7kx3euIy/RzZ8N+ubzs7wwuZmBeuoaR28gsdvbGKF+5QV0EtTyR081Bdf 9t5UBdc21jduPtl03qw3N50+n3fu5itrGzdfaTp9m5t4StOBFBAT9jLMWsCsieJ+v7zK4Y2bdedN tnnjBq15eEP03Xzyxg3nDeChXG+xV+6Y4OzOiboyAUpgDVBibos/uYbF0Ik+J02IPtEHODeb2Htf fPnwxhwg9RGkA+9Ocl0HETw7CPB1EsmHfkIk178XkhveE8mNHUhvI7kJMBuJ5MP/H0lu7iE5rNeb aDa0g6yIVsL4Ivqw1Nt2d4Q4C6E9hpZC86ONo4loEbRJtDiNpeffxP1PMQPauvAVPP8V9OfQ4mwJ 9y+jX1c12ArmVzG/gufW0Mcwb0Q/jD6BfhV9En0J/QTesyjjBfYPbAXwNtHTOnXcX0ALSu/gecC9 jPsJ6R3cw9iEvQzoh5U2hH4eGi/bNAaLruEfwbVXMiQY9PwE2B/6qWE7NEzL+qH7A0yHd4aYnhmY kZlwd1h6BjYEvYVZmY3Z2QgblWbJajHmZC7mRu9BG8NOPvR+tL0/kY2zAAuyEAvD5kVhFWGF2ARL sCRLsTQsVpblWJ4VWJGVYBcre5f4icxUfyKr/DiLTCoPH2PH2IfY77Gvs+9zI4/zX+H/S6gKX1YN qh5SfVcdVL/SV+/7YN8PNCnNs1qN9iHtH2i/2z/cX+3/TP8P9h3a962BjYEbA1u6i7rvDc4PfmXo wNAX9ef1f2EwGo4YHjMOGq8bv2G6ZHpzuDD862ZmPmt+yvx1i81y0Wqx1sBj/PibwhfBdQ04PQgO n4G6JreYFs1ohEe4hUbXxhfhoVRv4gojA0YMw7kNuut8EcvoapvKhEATAuuTJvCwGlvAXWA0gFEq bfKZfNxnN5u05pA2VAzxN1uD/DOtzz37Z89+7NlnPc8+K3xxpync2G19lbfwZ3d3YneXpLe42+BW 4Q1IoGcbAKsBrjp2BxRDtc1Umuu51WKziwlVPlcTity6sH5kLhupx232+HREeOPSd37mA//33vKV Bx/fP/f4tSsFrF3C2rb22liX1u+srSGENExa217j+VwwlPWorBa9oC0pS8fs9ng9/PKelQnui7vv Y7/DNqBF49sglApq1V27n9buJ2IReQSQx27RaPM1PsXFfPZ3It5Bm3/RE88PBPpdHv8GrRdm/4cH uIiFrHIAoYoxWhihCxYG+lYxzwM7XKzViL2M4jDaX0X7E92g3h3cFO5J+yMYwf7ZfNZ6cXEDWzG+ u7P7We4FXVTMRTEKZ9jrdjbLVBHN2Xzp30onVFN4DZCEdr8vqIUvwUJE2F1bLAoJIimKQqICkKhA krBtS5OzR5osRA9LjzR5acIrS5MFMoRYDdLklYSQpInnEoLo1wtWi0fIZmqCKuNRE2tEf0Ig9vMv DwXnSvnZoMEUns2W58YHn8sdyPuGNZb8qcXFu/KW4ezd/GT56rFcfuNapfngSqy08QD/1FhhYf1Y ZP7Js5XKuf+6OPvkBZmWj4EoDwCvAVbeBtvIWHZpqSVQtT2w76OJfQT7tsQdhT9ivqYqZk0iT7wQ bqR9/dm6MBhVDbjyEzvTIHEKBFRhjwl2ehumVQ3Dqo5t41Lm3DY2VzMRcwgeQE876GlPtrnSR1v2 9cAwQhMjsoDZJNr1gXZhSRPNoE824wHt9GqtXqX1WX01Xqz15RWa2ue81aO5/HrRNZZtNGccJq/D yPkvtLLc4g+sHmjmPCPRkk8sR2wC/3ru6JRvLLcQTi6U4qFxy5DbHxktZA+FotVkKFGJ+gtBsztV Hyf54MwP+WDAcZJd2YapVxF2wBF2BS6GRpAJoEEjEvQCRm0MbYSQrQfDME2EZSrT2pN4eIvZFHuz xcIYpWV8IR9t3KxirlCscRl9jVbRZwhNKGuxkSCFEirt308s5T0jkaLHXwzb6ojhDsejiwVvOhtM uwY8laOFqRNVv6Z+ZiU4kxzlwvjUoQT/iG4sF/ElPXpbpOhLHfR5TNbYTLy4ZhsMJXMj8QMVkduy h2vrhx3xylis7NNR6A+yCP2IxAfgZyEsbclCoAoOq8Fhhn7wVpsGKkJZ1UODXkkbBA1ILPECXupT XtbeSqUDvjzPmrJW0SoGfCZ+sfVHfKFy9my9tcNVzxX5X7eihee+yR/F++Lu9/lbgCfKDm5D+1SA qMuBYdp9uGf3AE0EZA448faQtHsAdIfJgLYOY2SROFD0gOJtJmi0ITNETltTKUIoKW3o3MDpudB0 3D460QinDrjzZX5367W4VRwPjaQOVX2B2nosc3wmov7Cwn5XuhEMzaQcYlDLrxa+MzSsU3urxwul 49UxS3K5SLImsAhkTYCseRFL3LvFsrBDKbQsiDMC4ozAFoHeADMFMI09tshNaLl78DTThFnGcwh4 +iQ83R08zRjFJDx5gpNRklCzWS2atjXKZmx2bY+1gi/hz+tmyo3lsF5t8EVLoSuPPHp//sRM0FY+ t3Lk2sDXApMRmylUjU9MBU2rgqXQqJ2+lrGEx8yP33flCXHtZ++a/vC1hY2jT7lS0+OeqYx3LDvt PbQp6wHjb4OHerJV8Dm38XCP11aMV8drD0nOAPyBXRBhr3yT/EsH7mv6VPN92QP3ZFsfE16qHnv+ t38pd+C3n3kaxlHF4pJOvwoCBdh+0us+TM6BRNuwYCoQhkZ5jMh2bUNNVdD3rlSliLipHmrXaaIu U9vTkek6aExxhMwuWar4bRRNCKrbroMqORCwS5YOqo7ooO0fCtweqCUcJGpidWLUkagFPbmQbTRa cLsz49b5FxyBEZ23sBgNH6yOT2Qrs2LjVCm4Oh2e5pvDgXLIV4qM2KMVMVAMDPOM0Zsag+YbDP5c sDDZ+p7R7Y95x+tJB7dEGxPFlVHrqVpureBy5FZy0+faskm2PoAo98oWy0Eu+9FykE0TZNNE10CY PCSuMIr0yOceS9j1lduIobkUIMm+UtZDsonBXj0shvSQU9lR3qaDZimEklU1+KhudnJ6OWIQBO/p 6cxaecxVOlrZf7o8Epy7uxRZKPjVX1s/dHQFkmo98qlypXb31ZRQKHmrR7KZo9Ni6Z4PLp348KmE JVqP8e8J9xxeP0GyunKG8JdiI/5txEYGtkRBjBr+kkzXPlBABQpQP4ie7J++Y/+6UdM2jI2gIEqU 2htDqRDPKHHUYk8kxatSiIOXkZfw1xDjBEDcq9swbCqIMEloBNAEpZEbc2QBt1gQcLRj4iD2C/Tw Q3G1iIjwDIXGQZLgIEkwzAwehs0AG+m1kKRdxSBcEIJUOYKxi8GOOxa0YIAWkL/GTSFbKuy0hiuB QCVk4VNqz+ShdHa95AmVqjaTur74QvFExB6fSLmcSdHiSEyNZw5Nep3p+Wh8ulD0O6Y9LxCmAijM hI+i0qMFkeptT8IJRFjsDsyKYZDtACGh+BopiKEyF3llRIk8y8WQT2v2qQzceZBb5g+3to7ezx0f F27tpF5/nbv4EyDaOvY8iz0HYQKS7LLMYYdEUxhPhc5RjDQSdYnLQx0uOwk2Zw9sDppwyBZBD1B0 0ksO0BPbgLJOjEZkyra9TIznu0OVySdHO4LWqliBX/586XDB6SmtpJ7/XH4hbralDpaebnL19Imy w+KN2JYXxdrxbGVgrJycKHp0lWEx6/Mn3UM79wm3HKnZcLAYsKoF3T0LWMFK/gbx2+53hF+FPIXY LHlyNVxI18r5CQV/D07d+GyL+QE/ogFgIksLheOKJ2mHt8WsXtWrsXZhzfrQqcbdU+7RytmlxIFy aGD/YGL5ysLhR5f92RNPLBRPLyb38d1TK7mNh+vV6ydLnvxCLHfXfGTq0i8cvPepkxF35WiJ6Cfx 6mnwytaN2b2wPxSztyWewm5kRwCQskA7Ru9BjuhBwonjlbDEHcQg4INdibmAUCibaWtCKMFjfP0H nkopPzqecOr2WXyjo5ON+fHf+43EepRmBlypoHdj4jeEWyqdbdixfPjo+PjS/obT5TdrK5ipLa4F QuuLUxYT6rngB8lgBXjp2NFtsi6YbFsYdUfW3kUPtiGcgpS0yTjIHCICQB0oYTIhiFHaOv/H1gX+ cOvj/DeFW5XW25XW6yhYcLYEGByAYR9b/onB0LvzEr/Vus4vtX5F2fUZ7HkZiH4ee6pYcht/ZLzf A79o3azpcpMUuU0/O9bpY/kfax1ZluXVfNb1Jv8gVryP6jecrYAe/w9rGtgvyfUG8nq99Qay5YhZ IDYUAQ/cQsMTRHTEDJgdwsxQJ+vZwz0lDXoXs3ZbvEN2TkeaqSPjIoFszpqRoplEFf6ZVi59W/jW vU3h2/XvCEDi54Sf2kkJH9z5aWoSPqvAB+jh/YfhrwAp1U8o/CYfpkKEKchag6t2NQVZXEd71LS3 uscqKA6uC/9tRRUCd4BeGZDBNQNOEywy2Cb+stA8yP+n0FwVru98DLB+VHiE2AgAiOZ1wKiHLb6w xRyA0ILmAJRt/aYEW6Y6UVovwTzy3nTEgB2oICPrCGm8JJ+KvY1xk1mK+4MYrXDt/Mm8Nb1yLvM/ Pp06kHdvnrkp3PKWFsPVlYnh1qv8sUFfOdGcb70uwb0GuM8D7kEkib+1xRKAuQ8tAbgNoKcB1JUh 1eGKkluLBLcPVz56Fs+JGIsdaTES6Yw91NbThF7205Lj9tGEr2dCpAmRJrYBh6BkOEZsRgEHQhNs Yvg7WHBs5E/CaitJDrC1gje+DCUBSDJh8+xWFKaQXIr8UrCRcrnT0/7Xmtzxvp8u1rzjw32c92kH tMu6fX0qtcYZRFr5s0axEAznPIOtf6u0XhRubZ5vrrl00ULVFSn4zX3a4fr8jNUtDmugVzH4niJ8 T5ktbpPfQQGWIpk0RpC3Tg69J1LJEX45wo+qB20PJEpcLHqQn0k5m4YKKlKcKLZjFo+2nd1cVYvF hUhqPm4NTq0eXp0Kjk2dqk6drHoa7kzdn9sfNfZp4vWDa8sV8cYHSvfMh76Wmo2aRyIFTzTns5gd 8bl8YL7g9U+uxCPV4LA7UXKJUaeJbuTOP+CePD4J/IyQBRdkQcsa28CJytRdrJTQpas0iloBK9l0 oOQAXmnAI8qGkduQ3ohGYfCbzW/CcMKnfxJ7oLotrGMPDcoOeI+Ubc/KSlDU3UoxOJL1MGedPKsS h/f/7Wv731qGDj4pPKnoYAI5kk2wAI9Z9ml8XIN82tFI/5oQoQb6BuRZI8X7dohXVBltsTLulTsy rKTc+zpxW5I4mOwR2QxNZHomujxWsKrSE1WZ6TopNKWU3SElCKihUgiqFNXyIaoLUeVTymqRD0pS YLLYilbKICDO+XYmUeSfCq6E5g6axyLW8Wbee8GUNBi0k/NjudCoeko1Xl6Ohuay7tGg1jmkHzIg ZQ+eLfunU67nudE4oOrL5UdEu46SqweFfq3Wp09M6pwT/kQjYjYFahOtfxbN+qTQrxIM1lF9ND4c LAY/NAKWsVXQNga+mZFqfmKLxUFX8hlx0NUK2llBV4tETaK2BbNUORsAxqhvQCxoJoqZaIfGSn7V ZbISkHaJrlQrZQEjQelWQtqVSopJDRJJzW1iFuR4n2y2qV2BkhPSkPhRe3wmGqynnIIlPpeINCZG qlX3heLk8bLLUd6YHs2lI0MC70uuT/qdueV0+mg9IE6utv5KuNV6I5WeWD5fKJ9fjOodIfoOw1kS dZy3IW+iHIuqEE539UVJF7voKAhL6HgBdzdrpMzljli0cHsoarPzLxhXqomZqMUcnUnOruvq/WLx QLp2ouIaq25WTjyo5+cqjeD0ajiyUgssNWL7s67o4vly4dyBiWMnwb8S+GdR+PffZf61dYN4KNtw MrjELTtmLOAW6YitMzOKmdEO/xTudPmnVArfGWFJ0T2kEh5ZaahuKFebPR0etqvNdoWX5HHzYm9I Djq8NjLRiCSbcYvgTNWD0Zm4vVoVhiLp3Oj0RtnhKh+fLF5w87746qQYqB9Np5dzTv/kOn9rJ3US fNNLRDm/PJEmtw26TEh1FQsQD7Kf2WIhshdoIVDAA3w9kGudRIEBXFEGZUZvpqcAdlCWbcxYOnRR nFmXDKOE9ShhTcVljuXIj4sd/EcxMsoSoNh9WH0qt98pA1r+sjVSC4enYg61LTYTmzyin9WNF5Yk KfBNbZSuPMF5KDibdnsyM4FMdLnoq5UD00lHdPFcuXx+OfaJjxHOHIrKOBf+AdncJ+WMHPETQBoG dqTLAnp7Jy7pfp8BzqSFSjW0y3glPuxirJQwuxO9ok+JCvYnV4ERyqkYEV1J3mj3EXIe+Ww+V6By nlWyiW6Osio02nIwU9WPDFqMdseg6vz5Kv9q5lBtQRCKfSaXOFzPtOL8q5KsxyHrFtiqGvu1LTYN bsWIY1h9Gjtl0WfBV1nWY5ihvWOARpZ1mpnCzFSHp4qsdxEqEU9LrDuhGC9tx2Mk6ImELOslLC3L egIjsldyNi1Xi9pSb9UQ02sCpF6poNGHMJq5o45kz/LXegxZMykZMmvh7qXyoZyT17WeSMY5tRTU 8b22jd9h23i6Fc+dXoi543m7O2DtjzaPTfRauvAo5GUB/HoDtsPJHt9iLlBSj+YCleTItl1BE0Az PRAcgla0ffue3EERpy7l9pREhohyQzLlSESGJd2g8JvMuc2O2gJEQXGW8KKmher4wULqkMusrdYW XImAQ7tPDYv93WDKF3FNeluf54fm502ucctowtn6V8gHYnX2FPChj4Vn5eotoh1ogLqDE32ThSYA I6EjBXvk/F3zIIqV1VKIR6BTnWy9Oj0jaHbeEt63iRIy6NrEn38BHDr6KgErg0mCQift/EMpqMRd 70LBbvYl54fFrNYsqrTWZrV16NW/nX31LKhT/8F263nuu+vLgAM5PENlCQBIuezt3932cLDLMHn1 9SqCMFhTjroXloDepdnT8rdY+iS3jc8vKlTyaAT9oroGcCSNV3VsjJJ/dVFSMrTuhJJVdCe6UGAx Mku9NkaaGCc5GpfliHIJfDuB3kVgXrKIDaxZOTjAJ2c52pJFSoMvdW3xksbvh3exH8uOZ0R7v+N4 KT/t11WTdd+UfWCoX9UdCZqViaTROW7NpsXyUqj1Ir9Yqrs9Q2IwaGz9a88F0UnWJ0tXnwyKPnHI G4dlAh0BKmW3BgCu79GnPZRSeP0uhOnNv+iggVnWJ6LBOyvUh6rvpFCahXfSJ4AqsCB8qEaytyE6 4RAGNpT7hsFj+kBG+STlvnSuQc4hPT0YKan2OyNAASQsEF4jdytKkPfJHxwkrsFQmhWn2Y6muS1z vBH0VE9U8fnQ7Z/efMISnUklZ6MW2MwY9Xrub15sls8txWKIkGrnF0LclFib9AemVqOp9Yo3UCMD AbxWd3OIecmP/BgxL0W6cqQkx7/4wtqxhoqMdnFVIqLuhOJpun5EiaoQPbR9SDdease8IYUEFPNC rns++AVDH6VwKTH3I8Ilfke41FILXzk5Gr4tXKIYMqf41RhTYkjiM3kBiiG96L0dv0oct0ocb2cD e3OAPX51T+KlUKxLD8XRSlE0JVSyX+3mAW1v2htDmtrZk5xfk/98hyByr7PcE0SmdhJ87A73CH1e hlJnICd6dqhr9+60cXtM2h5V7jVpVKFTCqBtY2UN4hzGh2GORlcb2ZmQQdCcqaUb3F9ZxVdRhtyX /wlgmGBIx6mKQzW/3iqOS+IFrdsrkXtCtV55635fJh1Mpbvfl9VKeCYmkJ9qoHqdUyGhK/rFpi81 ZkwvHVtKnz5+5LJuqn+5XK5K197SwURif8Yl/Pps0ej0m4MBq8FTyjYOL29U0+mwGLAP+0qZQDlo RnAfIFtp2f0+a6FyMMqubeNwEh2lIv+hgbxRRG5C3/1yr4SmXXVSYonuRPd7CyqcoIVWMi79WImq XUY0FWbpKAfOCpHYBPPIQejUDkWgSlje0o3bJpKLi9UzZ4QBq3lwdFAQBiYq/KcyTz2VaT1tdg33 q0E7tgCevIFTwKPsEbkiyKAdOOUjmTPZvlN9UI9d9bgD7DqWQpGFLuAG8maGnohzT82ye0qhfR4A NUsxr6RPFFVKJy/y/Leq1UFPKOfPzcfM1dr+wGTYRmHJgt4zanLn5iL8aOtzs/vduQWSK5xIlHDY W6/pwqYQtTuhBEZQUsTycr3G1HjmmcafzwqaVpN/cect2FcOdJjwx6DPEM5PKV58T4y1h6WDRIjB HkL0slRy/L3hT8CMWpH0j8DgrY9MPVP/L8LDC79a/fnHZtf4Cztv8d9vHQRU8zgmTjChPsX/CTDp 8JVdgWlPwLXH5ypQS0ZJAqG3flzUiuZQ1i4FYW//2uKffmHpv33iwParC9/4Bh986y//8q0WHZhl w7s5/jr2tSEaU/b90agrRya61rHXXNJ5CfqaAkH2SOdCiiqJFSQQwVBzcHRo1GvV7/vz2c9+tvGl YV9gYszoHvy4oPZOpE3CQGuW/2GLp1eKbogy1hkCkL8v5YwulHT+vZs3diuhd2aQyJ4h3W1f6MbY CUl3duLpH51ZjhGvx3pqyXvEY4/9Ur5idmVxT1zYzcflajoQg0L+sGR0i42Bjm6Jjj8sLeVQLjOs xNBqT3p69myVj1RVMzPvlKS24koiIMncPPsD/pzgQpxhJiFEXkr/e8EA36aiE4ed8xSy++LPuZDe BxppFw7oBAIzGRe/t/cKdxG7SL/d51GjfKcfHSTECSfokXzqeBh79541diA2daFU40cA3T0/jFPU 0qnhrHJiuIwMZo7NQ1MW8N8jluAHDyC3WmVrkOFD7DA7wo7i9O1xaPcm/kPFSfzfi1fYh7EzaRmX wCJ5ZwtLKydml2ILF+5/9ML1y+fOTBy4fO+l6/8JhoqJwgplbmRzdHJlYW0KZW5kb2JqCjU4IDAg b2JqCjcxNTUKZW5kb2JqCjM2IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL1ZUVkVWSStIZWx2ZXRpY2EtTGlnaHRPYmxpcXVlCi9Gb250RGVzY3JpcHRv ciA1OSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RD aGFyCjIyMiAvV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2CjAgNTU2IDYxMSA1NTYgMCAw IDU1NiAyMjIgMCAwIDIyMiAwIDU1NiA1NTYgMCAwIDAgMCAyNzggNTU2IDAgMCAwIDAgMCAwIDAK MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgXSA+PgplbmRvYmoKNTkgMCBvYmoKPDwgL1R5cGUg L0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvVlRWRVZJK0hlbHZldGljYS1MaWdodE9ibGlxdWUg L0ZsYWdzIDk2Ci9Gb250QkJveCBbLTQ2OCAtMzgwIDE0OTMgMTIwNl0gL0l0YWxpY0FuZ2xlIDE1 IC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAKL0NhcEhlaWdodCA3MTggL1N0ZW1WIDY2IC9YSGVp Z2h0IDUyNCAvU3RlbUggNTggL0F2Z1dpZHRoIDY0OCAvTWF4V2lkdGggLTIzNgovRm9udEZpbGUy IDYwIDAgUiA+PgplbmRvYmoKNjAgMCBvYmoKPDwgL0xlbmd0aCA2MSAwIFIgL0xlbmd0aDEgNDIy OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHdWEtsG8cZ/meW3OVz+VhaD1Oil1qR lERSlEhVa0k0Tb0pU7EedhzSTuvQlGypsWTXUdwURQEfXMAhgiJAjaA+9BYUhZAALFC3kmzARk+5 FPDBBnoogp6C9tIWgXsJarL/7K5E2rWDHAoE6JK7M/PvvzPf//pmya1r766CA24AB9nyRukqaIfZ DUA+Kl/fkvUxeYStfPHqpQ1j/E8A+sWlyz+6qI/5zwCs82urpRV9DP/GdngNBYb+ELbdaxtb7+lj 05+wPXr5Stm4z/8ax4GN0nvG+vBnHMubpY1VXd99GtuBq1fe2TLGPmyzV6+tGvqkgOPr+r2mK8G+ CB+DFTZBADYCsCFyIO+ACcdMQoSNI6evmc670v+Cdu6vTGVX+cdt1v5xd+/3tVjtpvmJ6Xf4kBVP /cDnOFo/DFD34f13zU/wuSfGPb0Rd8AW3QGIwh6uQoFGyR66WOs8wM6bMAcj0As4B1iiDxDN0nMS eICPbcJZmIHkgRKF888r7YEZPwJbSJ7+yXrbFM7mwwdGIQ2sL9WHwEJ5EOkeCPQRSOBD1Vh+B6yL hd8Q8rPiDqn/dAemOnfROu789+I7QGKyPL0+VSVv4YDGUNAXxB4Xk2eqXGhmuaAU5YpcmVupyDPy WmmlagppLd5YrRQTchVOFdbxeroQrGaL/oPuarE4ivOY2Dz4CKpXijjD940ZsNVEiWeoZI7l5SoX XiwsFao3pvzV7FTRHwzK09WHi4Xqwyl/sFhELf4AKSJm1uuYBcTM9+F9iz7LqUI1669CsVJhc54q KMHqjUrFX0E7jPEOPHxBQOBFQdYQoCdwDvTE9A65sYiTYaME/UygBJUg4ixO4drWWP5UYRqRBhlS 29e73H5gCOo6EL5dc7nzf+Ry8Zu43PWNXO4+QPqcyz2I2c1c7v0WXS41uRxr/BbcJi3YxmASz7O0 DGVsC3jm4HOsNjxZH88F1FvBdpU8xbpERsAPOxzAk1vYyloxaqJv8cK4h0OeMGsYeOQzdljwtDJO Mw47ov5/O5yGQRMwAX8hQ2SbWuhb9Bf0PufjNrk/mHymX6GGGZCz6S16H73Eo08c4EKGRbqbLuAl 4d9FHXumaAgoE1AwawL3LtsNniLdYc+GvYFBKegJkmCr5BGkiBBRI7fJ05qDfFz7ZPuz7Q+2twPb 2/T+sylaqdcekxpe6vV4vY4TTta/pAnqAzeMw7V7SMUcqGCK7uMIsWVDYD3AkWCChIGDIU0yQbJJ MMQEQ02CUSYYZYJdsGuwQwi7Q4NNRCLglw/QVDJD1UiGqPgd7qdKFy8oGS6VDFCB41tU1FK6Iv1E ZW0/VYdV8qRvoWemaDc7/OFD3bPHYtaTnkGPx8mZ+fa4knmz5ZhzcGKhLzIedVvTlkO9NqHT6XR2 WsyJt0e6xnrcFv894nbbOPPQd9qUVrs3NBK5Qi2CEBRbwx3u5GT/eK/kCWXitS8USUxQC2eO+/ti 3rAavtnGAkzgLPpuGn2nNOImM1vlJn+1MEGL7g0ZzeY0B7Rgz6k7oB/tEanugWE1JXKaeczyFoFS LpvuP3G022rlOkcTk6W2rCc5sTyYWYryDvvQfHn07Hd5Uh4dDx9f6Ok9mQmdGI/Opjr65lZGhsvz 8TPnGE4KZcT5qbabRmH1Hm7xHCJqxNjHIPrAeRDjHiboeYURWnoGmEZAt6oHbTFrVgWw59Kt0iK4 b1aGSilOUZVm21qpyyrII72J+dGwxWbvHgv3zY1ELqfvpCXqTQ6r7ccXe8wOx8BcaUw95yXm2MKY Esq+PjiYH/J3jS2Rr54NnDscOSxqtq7k44MDuq0FtHUZY2KDMEzuZ7HC4CpNBrUzQTvDf4/VD6al Cd9JlANL2rHnfs4SF9Fy9MUIkZpFCBzt6Zkc7nHYrbw8Fh0rHZ6UBrOLepAcw6+Vjr597giJhCcH OwPJiVCyL68GMyOh44nDfXPlkZGVfPTnHzDsBHkeqIpx8iPbG2VPGFDSFBueCZAuDoJlMIVODKwg nUzDqceGRzu8mh0pDEGGYFK1tvACp0jDYS3tsPa43J30aOyN4YG85DQLuXTOlch1JKNddlHkx+ij 2t/DA8HejjG59ilZnpnxdHT72vv9tb9hXi0h6F7EyyG35/YQFRL+AXMYyBtAzQyXucmUZuRmBGoC ikTGgEpqSljaTG/OShMS5Z99RX9YLKIX2Hphbb34Hi7/ktUaOdyYXJ9y6U76Dn30DLNk38++Zj8b 9NpAKzC0wtf5WWQaou5nAeFLup8VKSW83NE305tp1yscTfncy9zM8oLCAub0HOa0BJEG09jY8rZX ALQhnnbEg1mEPUVDZu7nVINQRU56oUCJlFxIuUVHar6cPrYUszicR0+WfmulnWMDiTzyj42ldiKv douka+ri1Ej5RDSKLJNZyUWIp39xrCt0bKFvYGlUDmVOImYCK/UvyRr9CFEs7+eylSG2NiE2MrXh dI5pcLpLrQgcfwKhCa5H+LKGJ4eSFs2UVrYJhFVJUVOYKSlB4UQSwOQeVmv2SEs85Fics88dSR8p 2Ut5k0mQJEe7k1JbfJT8OPnhh8naL6UOr8XEMZyr6Nsl/MXRDq/t4zRSpwHLxWC5moA/txmzmjNM 07Y4nwaRMMYzCA8zmm/R9jd6iOWAqzuudg1lZZMVq01MzIbGUyEry/OcGGj3dA5N95LXa59MznYO 5aLsHQrf8eg8/RxaMWOPwN19nAYVNHLewnBamirMoOmGxn8VpYc94mkyzWDGhvGHmMYhPSYa97cx QZsuIBgS9CIGiTGNvrmDewckDJcPT7YjdGhljSWNO3sq2SpoxOMiLGqKn2KxYxSv2he8zvF0p8/h dbcGvDaTeMF+oZwu30USeH9CmiCPk8uZnEk1ezoUbzZZi5HHtZjBDHqNsCvU7+KbyMsOEYUc/sKc gVlk2TzMwwKyyTK8AQV4qD1AGE9qPR46Ac6cPjN9Zi6aW718fXVrvVyKz69fWttauHB5/Qf498N/ AM0qKpYKZW5kc3RyZWFtCmVuZG9iago2MSAwIG9iagoyMjUyCmVuZG9iago2MiAwIG9iagooMjAx NTAzMjNfSUVURjkyX2xpc3BfdGhyZWF0cy5rZXkpCmVuZG9iago2MyAwIG9iagooTWFjIE9TIFgg MTAuOS41IFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKNjQgMCBvYmoKKEtleW5vdGUpCmVuZG9i ago2NSAwIG9iagooRDoyMDE1MDMyMDIyNDcxM1owMCcwMCcpCmVuZG9iagoxIDAgb2JqCjw8IC9U aXRsZSA2MiAwIFIgL1Byb2R1Y2VyIDYzIDAgUiAvQ3JlYXRvciA2NCAwIFIgL0NyZWF0aW9uRGF0 ZSA2NSAwIFIgL01vZERhdGUKNjUgMCBSID4+CmVuZG9iagp4cmVmCjAgNjYKMDAwMDAwMDAwMCA2 NTUzNSBmIAowMDAwMDIwOTYzIDAwMDAwIG4gCjAwMDAwMDA0MDQgMDAwMDAgbiAKMDAwMDAwODY3 MCAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDAzODUgMDAwMDAgbiAKMDAwMDAw MDUwOSAwMDAwMCBuIAowMDAwMDAzMzQyIDAwMDAwIG4gCjAwMDAwMDkzNzAgMDAwMDAgbiAKMDAw MDAwOTMzMiAwMDAwMCBuIAowMDAwMDAwNjA2IDAwMDAwIG4gCjAwMDAwMDMzMjEgMDAwMDAgbiAK MDAwMDAwMzc4MCAwMDAwMCBuIAowMDAwMDAzMzc4IDAwMDAwIG4gCjAwMDAwMDM3NjAgMDAwMDAg biAKMDAwMDAwMzg4OCAwMDAwMCBuIAowMDAwMDA5MDUyIDAwMDAwIG4gCjAwMDAwMDQ0NTggMDAw MDAgbiAKMDAwMDAwMzk4NiAwMDAwMCBuIAowMDAwMDA0NDM4IDAwMDAwIG4gCjAwMDAwMDQ1NjYg MDAwMDAgbiAKMDAwMDAwOTI5MiAwMDAwMCBuIAowMDAwMDA0OTI5IDAwMDAwIG4gCjAwMDAwMDQ2 NjQgMDAwMDAgbiAKMDAwMDAwNDkwOSAwMDAwMCBuIAowMDAwMDA1MDM3IDAwMDAwIG4gCjAwMDAw MDkwMTIgMDAwMDAgbiAKMDAwMDAwNTY0OCAwMDAwMCBuIAowMDAwMDA1MTM1IDAwMDAwIG4gCjAw MDAwMDU2MjggMDAwMDAgbiAKMDAwMDAwNTc1NiAwMDAwMCBuIAowMDAwMDA5MjEyIDAwMDAwIG4g CjAwMDAwMDY2ODUgMDAwMDAgbiAKMDAwMDAwNTg1NCAwMDAwMCBuIAowMDAwMDA2NjY1IDAwMDAw IG4gCjAwMDAwMDY3OTMgMDAwMDAgbiAKMDAwMDAxNzU3MiAwMDAwMCBuIAowMDAwMDA5MTcyIDAw MDAwIG4gCjAwMDAwMDcyOTcgMDAwMDAgbiAKMDAwMDAwNjkwMyAwMDAwMCBuIAowMDAwMDA3Mjc3 IDAwMDAwIG4gCjAwMDAwMDc0MDUgMDAwMDAgbiAKMDAwMDAwOTEzMiAwMDAwMCBuIAowMDAwMDA3 OTk0IDAwMDAwIG4gCjAwMDAwMDc1MDMgMDAwMDAgbiAKMDAwMDAwNzk3NCAwMDAwMCBuIAowMDAw MDA4MTAyIDAwMDAwIG4gCjAwMDAwMDkyNTIgMDAwMDAgbiAKMDAwMDAwODQ2MyAwMDAwMCBuIAow MDAwMDA4NzkzIDAwMDAwIG4gCjAwMDAwMDgyMDAgMDAwMDAgbiAKMDAwMDAwODQ0MyAwMDAwMCBu IAowMDAwMDA4NTcyIDAwMDAwIG4gCjAwMDAwMDkwOTIgMDAwMDAgbiAKMDAwMDAwODg2OSAwMDAw MCBuIAowMDAwMDA4OTYxIDAwMDAwIG4gCjAwMDAwMTAwNDkgMDAwMDAgbiAKMDAwMDAxMDMwNSAw MDAwMCBuIAowMDAwMDE3NTUxIDAwMDAwIG4gCjAwMDAwMTgxNjUgMDAwMDAgbiAKMDAwMDAxODQy OSAwMDAwMCBuIAowMDAwMDIwNzcxIDAwMDAwIG4gCjAwMDAwMjA3OTIgMDAwMDAgbiAKMDAwMDAy MDg0MyAwMDAwMCBuIAowMDAwMDIwODk1IDAwMDAwIG4gCjAwMDAwMjA5MjEgMDAwMDAgbiAKdHJh aWxlcgo8PCAvU2l6ZSA2NiAvUm9vdCA1NSAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPGNjYzRkZTIy YWY2ODlhM2YzODQ5MzBiZmRkZGJiZjY4Pgo8Y2NjNGRlMjJhZjY4OWEzZjM4NDkzMGJmZGRkYmJm Njg+IF0gPj4Kc3RhcnR4cmVmCjIxMDY4CiUlRU9GCg== --Apple-Mail=_699DC0CD-3D55-45E5-9160-2C9167C970A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Damien Saucez=20 On 17 Mar 2015, at 13:35, Luigi Iannone wrote: > Hi All, >=20 > no changes on the agenda have been requested, which is now confirmed. >=20 > All speakers are invited to send me their slides by Sunday morning at = latest. >=20 > ciao >=20 > L. >=20 >> On 09 Mar 2015, at 23:05, Luigi Iannone = wrote: >>=20 >> Hi All, >>=20 >> The preliminary agenda for our meeting in Dallas is now online: >>=20 >> http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp >>=20 >> Please let the chair know any proposed change before next Monday = March 16th. >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_699DC0CD-3D55-45E5-9160-2C9167C970A7-- From nobody Sat Mar 21 14:43:33 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614811ACDB8 for ; Sat, 21 Mar 2015 14:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI_Avl98HU5W for ; Sat, 21 Mar 2015 14:43:30 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED981A8F43 for ; Sat, 21 Mar 2015 14:43:30 -0700 (PDT) Received: by weop45 with SMTP id p45so108086774weo.0 for ; Sat, 21 Mar 2015 14:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=i4/IVfFknROdxy1L+zZE7RjWTW2WVw21QK2bJpW4vp0=; b=qb7gYyw340HVu+aAiHa/SdyJks9/6demJ8sJlw9ODooX5Tu143ZuvMuokTVJmDEoA3 rKMt5BKSaGWBFc/Zr6F5E0BvOx/V2P7oZ/Xq0N6qLcfFMru2pum7n2whpxbXZyGiX4Ey 6tWV2faw578Zls91TaCkCS4aQDRKQOaTo5oJ4K5Lfui0Od6lX6oTqOB0LHR79m+Sm2F9 C0iXZkOf1zp6hf702twi/xAsAW7gXFX4pfYW2dko9+J7ji7Z8KHeb/UQcvLUEmlshavL Wn7n/nVyTCJcvlAmqgGBIpRqXP16V7256bwT0SY47xPICNwhFAT/+8jUaHxlSX2X2ZVh Zx5A== X-Received: by 10.194.88.131 with SMTP id bg3mr176250773wjb.119.1426974209029; Sat, 21 Mar 2015 14:43:29 -0700 (PDT) Received: from [172.17.2.79] (ANice-652-1-10-242.w86-193.abo.wanadoo.fr. [86.193.241.242]) by mx.google.com with ESMTPSA id u18sm4067648wib.1.2015.03.21.14.43.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Mar 2015 14:43:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_2654BE89-A60B-4307-A071-EEDA18894103" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Sat, 21 Mar 2015 22:43:18 +0100 Message-Id: <5C26F6A4-4188-4F9D-8864-EF306BA20399@gmail.com> References: <29A5BDA6-56CF-42C0-8B61-EAE054A39241@telecom-paristech.fr> To: Luigi Iannone X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Preliminary Agenda Available X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 21:43:32 -0000 --Apple-Mail=_2654BE89-A60B-4307-A071-EEDA18894103 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello, Please find attached the slides for the impact presentation. --Apple-Mail=_2654BE89-A60B-4307-A071-EEDA18894103 Content-Disposition: inline; filename=20150323_IETF92_lisp_impact.pdf Content-Type: application/pdf; name="20150323_IETF92_lisp_impact.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdkM1qwzAQhO95ijnaBysryZGja0MPCS00VNBDk4NxY+Ji h/jn/elKNg0uLZRoDyvE7jejabFHi+Wmlyh6yFB9AeKSpFJkZo3uhDKM/Xx9w+V7lYT1x5iFhwSE 321umHq8EuqAr3FmrEeSH295K/ChbCqkQUpSaGuzRdHgwWE9Tk7NNVg655Vciehp+/qCbXPNiyGG +8SjC3ZvQCtW2kDrTOiVtRNRqyA4tTnxo8vLIalOQ5nUVX9NqgBPiO7ia50KzpIwF8Eh2uUXcYjx O5XYreI47H9dA3/5lncpsLygkM/M+Dsitv6cdzGsQsQfiHGE2425778ApV+GpQplbmRzdHJlYW0K ZW5kb2JqCjUgMCBvYmoKMjUzCmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg MyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgMTAy NCA3NjhdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoK MTAgMCBvYmoKPDwgL0xlbmd0aCAxMSAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7SBUE UYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPemv3HWd/Z 57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC1Py9PZmZqEjG s/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUpMoYxMhahCaKsIuPE r2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1USZoA5fco09P4nEwAMBSZ X8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeYaeXoyGb68bNT+WIxK5TD TeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09yHr7VfEm7M+eQYyeWd9s 7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7 n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehV UeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQ MQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0c gDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AK hsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qa ughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyF X8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJW YdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIc cH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGW ICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0m vSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1aT71E fUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFahRuG0wj2F SUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdowHUc3pPvTk+nF 9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zavaV7/vCmV+SpuKnyV IpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80/+T8h+qwuol6uPpq9cPq PeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ7sxUZiWzizmhra7tpy3R PqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+tn6S/R79bf8rA0CDaYItB m8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+Zo JjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSa a11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3V Eevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr +sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+ dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYC QvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7 RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEq HhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJP QbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChz WWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msO rYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5bDmzF bBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNYmWJZXtnQ ruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ftndrH29e/321/ 0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUelx8KPddU71Nc3qDeU NsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarpJ/2f9rbQWopaodbc1om2 pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF8YuJF4c6V3Q+urTk0p2u sK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnpte9tvelws/2W462OvgV9 5/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX4 12apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3 ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+V n40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKMjYxMgplbmRvYmoK NyAwIG9iagpbIC9JQ0NCYXNlZCAxMCAwIFIgXQplbmRvYmoKMTMgMCBvYmoKPDwgL0xlbmd0aCAx NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZFLTsMwEIb3OcW/pAtS203t eAtCSGxQJUtdp65Di5K4rQ034kJwIfwI0EBXeBbjx8w3/4yPWOGI+a2j0A40mdMgwShhFQSvcTJo U9jv2zWG71RSyrg4LyIkIWJu/4Pp8pagS/gOu4CNSBLDjyEr8VEtq5KB07pcSCkK3eNGoc6Bo1M9 5krFQqrF1TUhM6hn3Kmk8osjJBaVKAWREglSMJFKjG4KebuEoLQKjCBHyDozsOCJkV0xZazv0Wzt we/tgKb15oQar+bkwtnB7Qdt8Ki93YQHRijDWckwtdx9UM04O1ONf6lmS5lUj+ObqMZU9cOL89C7 ZngysC38zmBoegNvsTEIPW2txru2/aHbN4P/mBV/Z70kvKwkBxUlD7/GxmHROneV3bQsi90X6c9W n1fslr8KZW5kc3RyZWFtCmVuZG9iagoxNCAwIG9iagozMTAKZW5kb2JqCjEyIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxNSAwIFIgL0NvbnRlbnRzIDEzIDAg UiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc2OF0gPj4KZW5kb2JqCjE1IDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RU MSA4IDAgUgo+PiA+PgplbmRvYmoKMTggMCBvYmoKPDwgL0xlbmd0aCAxOSAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZTBbpwwFEX3fMVdMgs8GIOBbdpUandpkbqIsiBgErfA zGCQ2g/qD7U/1GczyYQJadrCwsiyz7vv+poDrnDA9o3hqAy4e02FkF4eRjFSmWFQaNyy89nP6B+3 hiy3j5SehTiE3dudMO38GaJ1+Bb3hLXI0C4/0C7HR5zELILkGRN5nnpVh4sC2bzwOBQdtkVhCxUN /CDkGxRfcFk4lQ+cNHeoNMxzOIgXpa7EcVhCfqwhOI+JwVmU5tnMgJCOMQ/egnEN/7LW427QZYv9 rtXmXvd324+qUcMGPIOv+kph2tflqAzDBjcoPhxlk21z+yRbyJydZOO/ZAspneyjfwvZWMj235XV OJHkfupu1WBQ1rWqoXt8UhWDQElT5itN3X7HxntutHVJROJFl87KXZA/PXW/QqLeo5j/e+/eKT1W TCSyvxRjj+zbqHrb8E/dj3RQXpJQpOpdV5ID3dSOuirNuDirx6j+sVgiIsaTCOEyJf4v1NpUkzF6 Z21YSa7F8kS+6MMZcD26cU6M1w+Fckd3iHy4fh+8ZU056L6sKh1QeveB0Xd92QbNQ3xV8JohT6o+ S57kgsVhTDlf5u9mzYMklCzOJXjKJP0HoiONbpG7JvOw5IgT5+o3cmYgaQplbmRzdHJlYW0KZW5k b2JqCjE5IDAgb2JqCjQ3NwplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDIwIDAgUiAvQ29udGVudHMgMTggMCBSIC9NZWRpYUJveApbMCAwIDEw MjQgNzY4XSA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9i agoyMyAwIG9iago8PCAvTGVuZ3RoIDI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAFdzj0LwjAQBuC9v+IddUkvTUybSVDcXAoHziVYRFKhxv+P+agWzQ0Xwr3PZUaPGfUxSLgA mSs4UCxJjUZrOjyvGPPY/+sFj2+UhE3HmCohmUjZaWV8uRJ85j1ukU0kpfE5prIPpZUgDbXTQlnb Vm7CgdGVyaXxhJo5beIRm/MQXnCD9/st+I4T599+vB0Zoa2BbIWJYLOAsiv7SvsF9er0bzmEP2UK ZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iagoxNjcKZW5kb2JqCjIyIDAgb2JqCjw8IC9UeXBlIC9Q YWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyNSAwIFIgL0NvbnRlbnRzIDIzIDAgUiAvTWVk aWFCb3gKWzAgMCAxMDI0IDc2OF0gPj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAg Ugo+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgMTAy NCA3NjhdIC9Db3VudCA0IC9LaWRzIFsgMiAwIFIgMTIgMCBSIDE3IDAgUgoyMiAwIFIgXSA+Pgpl bmRvYmoKMjcgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSID4+CmVuZG9iagoy NiAwIG9iagpbIDIyIDAgUiAvWFlaIDAgNzY4IDAgXQplbmRvYmoKOSAwIG9iagpbIDIgMCBSIC9Y WVogMCA3NjggMCBdCmVuZG9iagoxNiAwIG9iagpbIDEyIDAgUiAvWFlaIDAgNzY4IDAgXQplbmRv YmoKMjEgMCBvYmoKWyAxNyAwIFIgL1hZWiAwIDc2OCAwIF0KZW5kb2JqCjggMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvR0RJVFBBK0hlbHZldGljYS1M aWdodCAvRm9udERlc2NyaXB0b3IKMjggMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAv Rmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMTEgL1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAwIDMz MyAzMzMgMCAwIDAgMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiAwIDAgMCA1NTYgMCAw CjAgMCAwIDAgNTAwIDAgMCA2NjcgMCA3MjIgNjExIDU1NiA3NzggMCAyNzggNTAwIDAgNTU2IDgz MyAwIDc3OCA2MTEgMCA2NjcKNjExIDAgMCAwIDg4OSAwIDAgMCAzMzMgMCAzMzMgMCAwIDAgNTU2 IDYxMSA1NTYgNjExIDU1NiAyNzggNjExIDU1NiAyMjIgMAo1MDAgMjIyIDgzMyA1NTYgNTU2IDYx MSAwIDMzMyA1MDAgMjc4IDU1NiA1MDAgMCA1MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgNTAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAzODkgMzg5IF0gPj4KZW5k b2JqCjI4IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0dESVRQQStI ZWx2ZXRpY2EtTGlnaHQgL0ZsYWdzIDMyIC9Gb250QkJveApbLTQ1MyAtMzU1IDEzNDUgMTIwNl0g L0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3NzAgL0Rlc2NlbnQgLTIzMCAvQ2FwSGVpZ2h0CjcxOCAv U3RlbVYgNjggL1hIZWlnaHQgNTI0IC9TdGVtSCA1OCAvQXZnV2lkdGggNTk3IC9NYXhXaWR0aCAx NDQ1IC9Gb250RmlsZTIKMjkgMCBSID4+CmVuZG9iagoyOSAwIG9iago8PCAvTGVuZ3RoIDMwIDAg UiAvTGVuZ3RoMSAxMTg2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWnlwY3d9 //2eZMm2bNmyLuuwLOlZt6z7sGRZlmzZ62PXx16xd0OSza73INlkJywhgRxbSEqzQJsZWmCapB1C IEwG0i2TwxtDAynTlk5Ld5i03TKUUkI5CqGZbeCPTFbu5/ve07FxmsJMZmrP0/u973vv9/ve1++d veP9G6yHnWMqVjl6+sgZJv11PMMYP3f0zrNu+Zpfwtl9/MyJ08r1a4wJPz5x693H5WvtE4z52cmN I8fka/YmzrmTACjPZ3AeOXn67F3ytfoyzt+79fajyn0t3T9z+shdyvrse7h233bk9Ib8fIzuB8/c /r6z8vUo1mMPn7ljQ3mer+H6ziPsNnaWDbnlZ/DLceTZE6yLvZ91SFeMdQNzxt8HerkE4drT5Z9s /9ONfaVfMZvqp/TuRfGXf0nnv7/4wvP18fpjHVX1c7jswovyH+ZVCdt2xjo+j/svdVSVuZXbOOU3 WXdkk7EIewH3BCZE+AtYUhq8iMH1bJ4VWIhhDtYZeZGp2eo1EPYiXruNHWKzLNV8SGA3XvvQC6Cq g2lpIffMvacGa5jNhBeKrMRobNzOsE5Bw/TCC0wrXGJGZsKj0cVN1rWy9uec//76Jt9+cJPVhi6C OtWNN4xuMh51u2dO1S7wm3AhRAEIezBSRd2zF1S+2b1r4rr7vPv8/LHz7ln3ySPHLqh90hk3Ns6v x90X2L61U/jdv+a5UFl3NIcb6+tFzKOmefAKHj+/jhneq8yAswSKX8VDHdFF9wWVf2Vtde3CuZrj QqW27vB43DMXvr6yduHrNYdnfR1PaZqYAmOiXsZZC5w1YdzvlGfZt3ah4rjA1s+fpzn3rYmeC+fO n3ecBx3K9Sb7+lsAnL0VUFEA4ATmACdmNvm5FUyGk+hxEED0iB7guV7D2l3RxX1rM8DUQ5h2vzPL dU1C8GwP0NdJLO99l1iu/01Y3vcbsby/iek1LDcA535i+cD/I8uNbSyH6b+Ow4JjD8vjGMMRxPVx btm+KkRZAMddOBI4vDhGcETxjld4hK0K38FxFEeULai6WRbvncI9C65XVVW2RDDcX8KzKzhHVHcz PeY/jCONZ2KALeMcx3kM51G8b1LGc+z7bAlz1XCmuSq4P4fDT+/g/UXci0nPA46xAceAdDzIDuI8 yx9ky7Bs2XcxeG4NvwPXbvYMYNf+CfAz8p8aXkLDtKwTVt7NdAq055rHe6UrPX77WD8zsAGM4C/w a2bgI7OyQfzaJGeEAXPQD/6cOIakEWMuNgxMPMzLRDbCfAgJjAVYEH4uDE8YxdUoi7E4S7AkximW Vt57t0/Zd3vC5nwZlpPGB9lB9gD7Cvtb9lOu5mf444JJeFT4keo+1RX1rerLHfaO/R3f7ahrZjVn NJe1U9o/6cx0PtH5Wpe9q9Z1pfue7u/obtBd7pnrea13rffR3h/o1frP9LG+W/te78/1P25ghpsN Dxv+bsA5cMfAo0aEGVqTvy58FRLVQIY9kNERmFx8k2lx9PfDq1/CQdf9FxFlVK/jCqM+jBiGM2t0 13ER0+jK6wpAIIDAOiQAHlZjCbh8jLoxSiQNHoOHe6xGg9YY0AbyAf56vYc/Uf/SU3/z1Mefesr1 1FPCV6/WhPPb9Zd5HT/b26Pb26SZ+e0qNwuvQIdcW0BYDXTVkbdg0VteTyS5nptNFqsYU2UzZSHP zXOr+2fSoUrUYo1OhoRXTr56/73/eaJwy+1375q5+8wtOcw9hrktjbkxL83fnFtDBGmYNLe1zLMZ fyDtUplNekE7pkwdsVqjleCLO2YmvIPsP7iPi5jSLAdtVYRtgWNIF7AI0DWLWe67ysVymcTBKPf5 M7aG50dkOlkbLgq3wdyLeFQAO9PZtPn4/Noavbt9dfsL3A06VMxJeQFnWOtaschUiMZ0duznY4dU E3gNmAS2rwhq4RuwzBB7zyYLQ+Ik9TA0wAcN8MVJeA3pO9qkbyLemNqk7yaAW5a+CTJHfgTpuyWl IenzTEwQvXrBbHIJ6VRZUKVcamKl6I0JJC7+zV7/zFh22t9nCE6nCzMjPU9ndmc9AxpT9vr5+fdk TQPpG/jhwumDmezamWLt9qXI2Npt/JHh3NzqwdDsuZuLxaMfmZ8+tyHz8i4w5TbQ1c0KW3BT5Lha ctUSqto23LsI0EW4b0nSUeQjZsuqfNog8thzwWrS05muCD1hVbczO3p1EixOgIEqrDHKbtyCS1PD makjW7hUS6ttYXE1HJca6VQ3+GkFP63xhlQ6aMmONhwGCTBIOFzEZMS7DvAuKFmOEfxJp1zgnV6t 1au0HrOnzPPljqzCU+uMu3Qgk13NO4fT1dqU3eC293P+UD3NTV7f8u5axjUYHvOIhZBF4N/NHJjw DGfmgvG5sWhgxNQ75A3Zcum9gXApHogVw96c3ziUqIyQfnDmhX4w0DjObtmCq1URdaARfgBOnUbQ CZBBI1L0HEYNCi1EkKWNwiABgjKXae5xPLzJLIp/2GRBjJIyvdCPBm1mMZPLl7lMvkar2B+UJpA2 WUiRAjGV9l9HF7KuwVDe5c0HLRXkTfui4fmcO5n2J53druKB3MShkldTObLkn4rbuDAysTfGf083 nAl54i69JZT3JPZ4XAZzZCqaX7H0BOKZwejuosgt6X3l1X32aHE4UvDoKN0GW4ROZL/drJdBWRqa heQQElZDwgznnksNHqiIZFUbD9o1rQc8ILXEC3ipQ3lZeymR9HmyPG1Im0Wz6PMY+PH6X/C54s03 V+pXuerpPP/Hejj39I/4nZg5KsnnJdivj+0iGXUAOCPJw4ZRRBplMSI93ALLVZBdS0YJwi/Rhl+F ABVZRq4mfpWmjBIYmSQZ8TZbJlmprrn2q2QnbJW0FmKDZ27Yeo5bfeWY3TZaDYqlUZs9Vva7MgGL LZwbGkqNmGefs/sGde7cfDi4pzQymi5Oi9Xrx/zLk8FJvj7gKwQ8Y6FBa7go+vK+AZ7qdyeGIcW+ Pm/Gnxuvv9Y/5I24RypxOzeFq6P5JZv5+nJmJee0Z5Yyk0fJ53mhfJfhK33weae3kJiowD7iTgj2 6pdGQ4B1YrTJ/BBNIxb6QbyvzQcqJgvPimcoJPqJe37i3iYbxMO9kh3TawHJZef9UGUEJ9kTWkV/ 06wFLWKXFh79MjcELImgwxws+nzFgIlPqF3je5Pp1TFXYKxkMagr88/lD4Ws0dGE0xEXTfbYxEhq 77jbkZwNRydzea990vUcBQUVKkAm3IwqrQeOKc5OUehRI90iSj0YyTSHMdJIlJLm9jY110GkOCj2 KbTZCWCXNUMPLuqkl+ygDcvAWzkwGpSpJKskIiM82xqqDB7Zgwlas6INf/TlsX05h2tsKfHsl7Jz UaMlsWfssRpXTx4q2E3ukGVxXixfly52Dxfio3mXrjggpj3e+FDv1fcKl+yJ6aA/7zOrBd1Nc5jB DDSAFdH8GGi2tOKZW4lnDSlSSEKkB8qU0VgxalgrJxJ5G83tQdcqUcnxSlCiEvYJeqyKP9KrxEA6 1ZBuIMYjfPXXruJY1jYSc+i6TB6bbbw6O/KVz8VWwwTpdib87rXRzwmXVDrLgH1x34GRkYVdVYfT a9QWASnPr/gCq/MTJgP6C8CJ6CqCLh07sIVIJUcYlIWQmbops3fAfwtCFhDzSKWJBvgyhQHoQlAy YUBMUY5V/m/1Df6++if454VLxfqbxfoPi4TDAnCwA4cutviu4dC+8gK/VD/LT9Y/o6z6RayZ3X5V eB62mmTnNlkKklQjI1FJGUkKtPddwgHIiCRPNSBJQJLNKKtkKS0tVhyyZKGSyXaTzLtltabGiuyQ KYEZlljUjVFIYhHPegxiFoJWEhZJ/Mg125MaBKo8/wjPFI3Jyv5s7ez+eHDfvQcKR5dzPbNdkdJC cNfxqWFx+kh5qFxMDRh6OS8W6x//kDvrMyVufPim5Yc2is7CgWKwErGmDt+/u3Tr3kSvKyF6F0Lg xSkg92XwX8XiO/PDd5A98ThtOFUTLl1FysKZZftV/qeYx8iWN5kJPO3EYQLvjOCdEdwED6AcnaAc Rt60DiV0tXipJ9bpiXWUyZAW5aXcLpfFciaNxKdDHbZsfLZQu/nUxEJI/yPvVNa9slvouvqrU7eH ZtaBDvAh3bYCnw6W/a3okrVYps5jXq3xD4PC90JVMecS5vxvzNnH/lCua4jG9rqGqIM5SHQiPwPl 3XiCPALiI6C9gPQ29WgHd5X0rcWMlqtQ/KWSZLY0TUfs0hG7JJSNaSNSS4Oowr9h6eQvhJ+eqAm/ qLwqgIgHhQ9dTQgfvnofHaBHkOzgZdiBEZEEeXoQuNpwBCG1hl+zAXdknMCdqEC8b0puB7J9hEqf LDmTpOaUa7okGbblmlJu3tGei0G+2cj+e1b3338gEtl/37599+0P85XZjeqwb/ZYeQbn4eoGP7F8 /kRp/MTHlpceOlEqnXjoSnbt7OTiB/ZHc+tnJytn16j5CppIRhXISI/4tLHJ7KCHtNHeRhPZoSwl okkvUTf4m/m7PqxAhaLs78h7S75GiUERbjBKhPkxWuLa2cNZc3LpaOqPH03szg6tH7kgXHKPzQdL S6MD9Zf4XT2eQqw2W/+hhPcK8D4GvHuQDD+5yWLAuQNHDHg3/JGMqQ46RIw1SXh7cOWhZ/GciLHY 1K5+Ekd/W9xpWZaiTB56wkMCUwAiAUQCbAEPAZkGUdqPxboleeqxSN/3NpkXC3njqL6aIdlghtZ5 UhaziZJpxC+rGU4MSbTIT/qrCedQctJ7ucbtH7gvX3aPDHRw3qHt1i7qujpUao3Dj/T5d/rFnD+Y cfXUf16sXxQurR+rrTh14VzJGcp5jR3agcrslHlIHNDADiPw33nobYHNb6Gto4aSUf6RxAi62qwV dmRSGaIvI2so+RY5nxIlKeZdKiWt0FDhKFUGYiOncmlBmOR6TqvF/FwoMRs1+yeW9y1P+Icnri9N HC65qkOpijezK9zfoYlW9qwsFsXz947dNBv458R02DgYyrnCGY/JaI/OZH2zObd3fCkaKvkHhmJj TjHsMNCNzLHbhsavGwd96G+pbpH8zFoji1DaIC3XoISYFkARbwugJmrRVGuKt5MAnQRAMQBHQU4C /xgZ08LvCo/Nfm3xSeHJxRdqjwhP7r5JOANvcc/VB+A5HhbOQEc5O4y+hh1817KUXBNQXGtg2PJm dK9RhMhpAZXqVio9cBx+8f57X1Q9nnrzpRTNmd6usiuNOSnBfPteCfnwxpwaKCS1gTCnmIW7y6av YM6vvZhSlTEl9DaG+sUimKD90+xRbBzAPqw4yKfVoMJVnKuISBop4lsxW1gZbbIC7hWaNuQjjvlY V5OFcQLE23iaIkCqDdDSMcWoSvREiZ4gR00luA8r2uVyR88pRVeaF9kA1d/UEaLorxXL0EiU5waT JW/Wc9ELc8rSmVobef6Ifykws8c4HDKP1LLuDUO8r087PjucCdjUE6qRwmI4MJMesvm1jl59b9+A Tu2/ueCdTDif5f393aqOTHZQtOqo8Lld6NRqPfrYuM4x6o1VQ0aDrzxa/7Fo1MeFTpXQZ7bpw9EB f97/wCDxdhm8jUA3jSgDP7nJouArxbgo+GoG78zgq0niJnGb4j91KCjfcUtQgoQBCTd5rFT0Lb1V ioQW05V8q6XIilgklsodIaoT+iSWGhvMzMn1EPxS2tCo9OViMSB+zBqdCvsrCYdgis7EQtXRwVJp aCM/fl3BaS+sTdoyyVCvwDviq+NeR2YxmTxQ8Ynjy/V/EC7VX0kkRxeP5QrH5sN6e4B2xjiLb1/h b0LfRDYtV++ONrtQWlgtchSCJXLcwBuKDaWgjgVVdvCqMci40dLK5dPtyaHFyp/vXyrFpsImY3gq Pr2qq3SK+d3J8qGic7i0Xjx0u54fLVb9k8vB0FLZt1CN7Eo7w/PHCrmju0cPHob8xiA/kyK/T8vy a9gGyVCOIY3+nBUQE6RFNmJp2ogNEFtTfjuyYaUj8/YES+mxi0zCJRsN9WdkGbowkmXY6OpZFVlC gmJWfAsfLg+OVkPxWtQkOBIVf3gqai2VhN5QMmObXCvYnYXrxvMbQ7wjujwu+ioHksnFjMM7vsrf uJo4DLnpJaYcWxxNUroIvoxKPQ8TAoif3b/JAuQvcATAARfodUGvdRIHKKujqlbOa2lM1Tl1M4lT piZflGDaYoONqLYR1dTE45QGI7qKTfop1eqXNUCJO4g61NZ8qw5o+YvmUDkYnIjY1ZbIVGR8v35a N5JbkLTAM7E2dssHOQ/4p5NDrtSULxVezHvKBd9k3B6eP1ooHFuMfPLjRDOHoTLOhe+jwv6U3LEQ JJQGQB3ZsoCztZkXtfrWoJn6EjtSdyUCtCgeIIoH2txnu+pTZMD64Bv5c7StMCK+Ehdp9UG0rIzZ dDaTS6csVrPkE4c4xRDRYNqTKukHe0z9VnuP6tixEn85tbc8Jwj5DoNTHKik6lH+sqTrUei6Cb6q zD67ySYhzwjJFbNPYqU0zmnIVe5FRwChtSPARtZ1gkwAMtGUqaLrLQrHiMKxNgoV56VtRowYPRGT dX0MU8u6HsOIdF3ucPivkbpZQ0IvC1TvKA4LGwQECTS8v5yfWNP8cpsjq8UlR2bO3bBQ2Jtx8IrW FUo5Jhb8Or7Tt/G3+DaerEczN85FhqJZ65DP3BmuHRxt93RBG/RlDvJ6Bb7Dwe7eZE5wUo/DCS7J 1QK1dsgOBPBMDwJ7cbUzO1C0R1GnFit31Dq9xLlemXOkIgMSl6jqJHdusaLfA1VQgiWiqGGuNLIn l9jrNGpL5TlnzGfXdqnhsX/pT3hCznF3/ct87+yswTlissUc9Z9BP1ArsIdBjwoZzc1bVBPQP4yS an6ZJtqrkikSmlqwQ893lELttFCurlYKhbRBhW7camlyStBcfUP4wPq6ZIc18PUnwENH3V94GQAJ C5208v/KQSW/ewcOtqpFuZ7Np7VGUaU110r1vS/9y/RL6OPVK7/eqj/LPe/5JuSLmpl9QuKH1Au4 dn+jld8pEmwRKc++Wmr0AiqUx8Hukuwx6g9S5kb5+QhGPmkE+6IeGWgki1c1fYyS5bZIUlLWFkCp alqAFhYKWu0+RvJTI6RHI7IeUS3jkOwuBPeSpnw0LScH2IqTsy1ZpTTYEWmolzS+B9HFejA9khKt nfbrxrKTXl0pXvFMWLt7O1WtkaBZGo33O0bM6aRYWAjUL/LjY5UhV6/o9/fXf9Z2AZEr9mRq2VOf Yk/8EgpMeCbwDvakwlUfENe32dMOTimyfgfGtNd/tAFrlO2JePD2BvVA6e0MSjP3dvYEVAXmRwzV SP42QDu/1E+g2pv6CbQRQfUs1d603yvXsK42ipSC5u0JoAQSHgivyW0IypM65M0ASWpwlEYlaDay aW5JXVf1u0qHStimGfJOrn/QFJ5KxKfDJvjMCJ313Fs7XiscXYhEkCGVj80FuCG2Mu71TSyHE6tF t69MDgJ0LW9nkPNSHPktcl7KdOVMSc5/sZPV9IaKjrZoVTKiFkCJNK040trnasSQVr7UyHkDCgso 54Vey+WDFEP8gY9RuhSb+T/SJf6WdKmuFr5z2Ba8Jl3ibBHKmwI/9Gxvy77fass7THeHyrabLnXO lKZxwyjNfiTBH4XZ2Zar6alAn6A5Uk5Wube4HIHtoMbjfwUcRhm6F9QtoV5ce7fEKWkZzdvO+R0p STtf5Ux8QNE1dB5d8AnSroNaSUNEys01ULHmLnPgFv18zZMY7k8uHFxI3njd/lO6ic7FQqEkXbvH 9sRiu1JO4fHpfL/Da/T7zH2usXR13+JaKZkMij7rgGcs5Sv4jUhifeQTTNtXWF34FLT9zBY+TqBP KchPaqBNlHkacG7tBCopWEttlJjZArS3pntBmFYyok7MRF2lfhwqQGlrGNU0pRf+LBXUiFKUaSnp Z103YhmNz8+XjhwRus3GHluPIHSPFvmHUg8/nKo/ZnQOdKrJyc9BJq/gSz4be7/ceWPwYfhqQDJb 2Y9RH06PVfW4A+qaFqHoQgtxpZvYAijq06oCW7uezd1DqhOUMoGyJ2knN8ufLJV6XIGMNzMbMZbK u3zjQQuF3zm9y2YYysyE+IH6l6Z3DWXmSK8MEALRoMG2sxJRduCmMLWFm5IAADfkrGkHR2vFUP3i F6vfmhY09Rr/6tU34Ec4fa3E/x1z67Crqsy9I4jv8ONK3G3R3dpcgIZqRWMgbZUC+5ufnf/r5xf+ 4JO7t16a+8EPeM8b3/72G3X6wIwNbGf4D7GuBRFeWXeH5vRQlOxpy2SNBDCylgdSnJYEMEJpaLcH SiPbSF4lkU3M9wdqPbZem9us7/rW9Be+UP3GgMc3Otw/1PMJQe0eTRqE7vo0/1qdJ5fyQ1Ab+NeD /L94Tsp/rOxGZP6wZNIcraQ5g9CYHmhMDyDGNo1RhNDqGygaAwBtJAlSK1DezKK0nj6WsFBJgY1/ dFOkSiLQNn415O6xeOc/LZ+EjWi229fpdHnX7myOJBnOsmf404ITqBhfAAC1A309i7Y3Bqjdm/vR corOn3aiBPNVk05nsurzTaWc/ET7Fe5SfAH9cYV+ZNZEvxbUytGf6G/sofS00b9Dc3akRjtahIoE JZZRRO2UeqBywUW4a7TZMp/gsH9t25jHr2XNoSZDrmEN6JD+tp9FP+zt/vIA4qsFKJn85R59t0df 7VmR/3iRGDa+wcO3iNLXd/TlXRZWWET1VsG3iDNsFnYzh4+LFxCBdiN7X2Yr0Oi9bB87gC/drsNX TuvsML5afoZ9lD2L1cjiqGnIYM34OnBXbX7/SjUyt3HrnRtnTx09Mrr71ImTZ/8HUAuR6QplbmRz dHJlYW0KZW5kb2JqCjMwIDAgb2JqCjY2MTYKZW5kb2JqCjMxIDAgb2JqCigyMDE1MDMyM19JRVRG OTJfbGlzcF9pbXBhY3Qua2V5KQplbmRvYmoKMzIgMCBvYmoKKE1hYyBPUyBYIDEwLjkuNSBRdWFy dHogUERGQ29udGV4dCkKZW5kb2JqCjMzIDAgb2JqCihLZXlub3RlKQplbmRvYmoKMzQgMCBvYmoK KEQ6MjAxNTAzMjEyMTQyMDNaMDAnMDAnKQplbmRvYmoKMSAwIG9iago8PCAvVGl0bGUgMzEgMCBS IC9Qcm9kdWNlciAzMiAwIFIgL0NyZWF0b3IgMzMgMCBSIC9DcmVhdGlvbkRhdGUgMzQgMCBSIC9N b2REYXRlCjM0IDAgUiA+PgplbmRvYmoKeHJlZgowIDM1CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDAxMzMxNCAwMDAwMCBuIAowMDAwMDAwMzY4IDAwMDAwIG4gCjAwMDAwMDUyMDIgMDAwMDAgbiAK MDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDAwMzQ5IDAwMDAwIG4gCjAwMDAwMDA0NzMgMDAwMDAg biAKMDAwMDAwMzMwNiAwMDAwMCBuIAowMDAwMDA1NTE1IDAwMDAwIG4gCjAwMDAwMDUzOTcgMDAw MDAgbiAKMDAwMDAwMDU3MCAwMDAwMCBuIAowMDAwMDAzMjg1IDAwMDAwIG4gCjAwMDAwMDM3NDgg MDAwMDAgbiAKMDAwMDAwMzM0MiAwMDAwMCBuIAowMDAwMDAzNzI4IDAwMDAwIG4gCjAwMDAwMDM4 NTYgMDAwMDAgbiAKMDAwMDAwNTQzNSAwMDAwMCBuIAowMDAwMDA0NTI3IDAwMDAwIG4gCjAwMDAw MDM5NTQgMDAwMDAgbiAKMDAwMDAwNDUwNyAwMDAwMCBuIAowMDAwMDA0NjM1IDAwMDAwIG4gCjAw MDAwMDU0NzUgMDAwMDAgbiAKMDAwMDAwNDk5NiAwMDAwMCBuIAowMDAwMDA0NzMzIDAwMDAwIG4g CjAwMDAwMDQ5NzYgMDAwMDAgbiAKMDAwMDAwNTEwNCAwMDAwMCBuIAowMDAwMDA1MzU3IDAwMDAw IG4gCjAwMDAwMDUzMDcgMDAwMDAgbiAKMDAwMDAwNjE2MCAwMDAwMCBuIAowMDAwMDA2NDE2IDAw MDAwIG4gCjAwMDAwMTMxMjMgMDAwMDAgbiAKMDAwMDAxMzE0NCAwMDAwMCBuIAowMDAwMDEzMTk0 IDAwMDAwIG4gCjAwMDAwMTMyNDYgMDAwMDAgbiAKMDAwMDAxMzI3MiAwMDAwMCBuIAp0cmFpbGVy Cjw8IC9TaXplIDM1IC9Sb290IDI3IDAgUiAvSW5mbyAxIDAgUiAvSUQgWyA8MGMzNjk1MDE5MjY1 ZjZlNmYxZTFjYTMyMjRmMzg0MTU+CjwwYzM2OTUwMTkyNjVmNmU2ZjFlMWNhMzIyNGYzODQxNT4g XSA+PgpzdGFydHhyZWYKMTM0MTkKJSVFT0YK --Apple-Mail=_2654BE89-A60B-4307-A071-EEDA18894103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Damien Saucez=20 On 17 Mar 2015, at 13:35, Luigi Iannone wrote: > Hi All, >=20 > no changes on the agenda have been requested, which is now confirmed. >=20 > All speakers are invited to send me their slides by Sunday morning at = latest. >=20 > ciao >=20 > L. >=20 >> On 09 Mar 2015, at 23:05, Luigi Iannone = wrote: >>=20 >> Hi All, >>=20 >> The preliminary agenda for our meeting in Dallas is now online: >>=20 >> http://www.ietf.org/proceedings/92/agenda/agenda-92-lisp >>=20 >> Please let the chair know any proposed change before next Monday = March 16th. >>=20 >> ciao >>=20 >> Luigi >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_2654BE89-A60B-4307-A071-EEDA18894103-- From nobody Mon Mar 23 13:06:03 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC871B29E6 for ; Mon, 23 Mar 2015 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo4kcQGcs_9h for ; Mon, 23 Mar 2015 13:05:57 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D721ACE6F for ; Mon, 23 Mar 2015 13:05:56 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 5196090013 for ; Mon, 23 Mar 2015 22:05:53 +0200 (EET) Date: Mon, 23 Mar 2015 22:05:53 +0200 From: Ilari Liusvaara To: lisp@ietf.org Message-ID: <20150323200553.GA22156@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: [lisp] Review of draft-ietf-lisp-crypto-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:06:00 -0000 > 4. Encoding and Transmitting Key Material > > The Diffie-Hellman key material is transmitted in Map-Request and > Map-Reply messages. Diffie-Hellman parameters are encoded in the > LISP Security Type LCAF [LCAF]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AFI = 16387 | Rsvd1 | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 11 | Rsvd2 | 6 + n | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key Length | Key Material ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Key Material | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AFI = x | Locator Address ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Diffie-Hellman parameters encoded in Key Material field > > The 'Key Count' field encodes the number of {'Key-Length', 'Key- > Material'} fields included in the encoded LCAF. A maximum number of > keys that can be encoded are 3 keys, each identified by key-id 1, > followed by key-id 2, an finally key-id 3. > > The 'R' bit is not used for this use-case of the Security Type LCAF > but is reserved for [LISP-DDT] security. > > The 'Key Algorithm' encodes the cryptographic algorithm used. The > following values are defined: > > > > > > Farinacci Expires July 16, 2015 [Page 4] > > Internet-Draft LISP Data-Plane Confidentiality January 2015 > > > Null: 0 > Group-ID: 1 > AES: 2 > 3DES: 3 > SHA-256: 4 These don't look to be of the same type? And 3DES in 2015? If you want serious backup for AES, there is Chacha20. Also, one can't encrypt data with AES, one also needs mode for it. Basically, for encryption strapped on top of DH, you need: - (EC)DH group (or monoid) - Hash function to use for key derivation. - AEAD cipher. > When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material' > field is encoded as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Group ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public Key ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Points to Key Material values from IANA Registry > > The Group-ID values are defined in [RFC2409] and [RFC3526] which > describe the Diffie Hellman parameters used for key exchange. All the groups from RFC 2409 and the lowest from RFC 3526 look too weak for modern use. This might also be a good place to stick ECDH groups. Those would do really nice things to the MTU: - CFRG basic ECDH: 32 bytes/key - CFRG high-security ECDH: 56 bytes/key - ECDH "stratospheric" level: 66 bytes/key - DH basic: 256 bytes/key. And that "high-security ECDH" is considered stronger than even IKE group 18 (1024 bytes/key!). And "stratospheric" is so big that finding bigger curves is pretty difficult. Also, if this one is selected, what will be the symmetric cipher? > When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key > Material' field is encoded as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | g-length | g-value ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | p-length | p-value ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Public Key ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Key Length describes the length of the Key Material field What is the difference of AES vs. 3DES vs SHA256 here? > 7. Future Work What I think should be done about crypto: - Actually specify how algorithm negotiation is supposed to work (I can't make heads or tails about that) - Always use authenticated encryption (algorithms like AES-GCM and Chacha20-Poly1305), and also authenticate at least some of the LISP headers (those that aren't supposed to change)[1]. - Swap out 3DES for something more serious. - Support ECDH, including modern Montgomery-curve ECDH (for stronger key exchange & smaller keys). - Hash the map-request/map-reply packets into the encryption key computation[2], along with the DH result. [1] IPSec ESP can be broken if no authentication is used. [2] TLS didn't use to do this. Caused security issues. -Ilari From nobody Tue Mar 24 21:31:32 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3501ACD94 for ; Tue, 24 Mar 2015 21:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlKdIOLkVOGH for ; Tue, 24 Mar 2015 21:31:30 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF571ACD91 for ; Tue, 24 Mar 2015 21:31:29 -0700 (PDT) Received: by wixw10 with SMTP id w10so20970653wix.0 for ; Tue, 24 Mar 2015 21:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xMB4zBkIBCZpgM1WWlU2Kf4SFeY+Jf0NmXRkg072D+4=; b=p3OzFu+XJagAwakTfp+vTfpDwsUNzu2lkFjUSht1GvNuAFGBuWRw//1XvLhI8sc6p6 0VkhkIVY4UtwfzJl0ZFBRNOtXGSFbfPwx8ccSWsV4zcmy8OuTgpIq66AtoXNnweWD9tl nP9SgemPEOvrTFuEH9+47iRyeAk/UAsdI6ss3NZFgyhSYsfiwrGCcKkw9ZgVa7VIXpH/ ++SEl1QQb0TWMyx52RUHYWQz1uE07EY6g+FT8ogNByKtDSvMYVgqYv4QHW27TlaUDfSg Rsi2J3U7US5GKQpfhqDsH1H3UNNcbb8mWftOzEJT+E6n4dvuOcyGs84MySq9AF+pxdcD bYGQ== X-Received: by 10.194.92.169 with SMTP id cn9mr13638872wjb.61.1427257888635; Tue, 24 Mar 2015 21:31:28 -0700 (PDT) Received: from dhcp-8ee3.meeting.ietf.org (dhcp-8ee3.meeting.ietf.org. [31.133.142.227]) by mx.google.com with ESMTPSA id hw7sm1749181wjb.24.2015.03.24.21.31.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 21:31:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Dino Farinacci In-Reply-To: <20150323200553.GA22156@LK-Perkele-VII> Date: Tue, 24 Mar 2015 21:31:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150323200553.GA22156@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Review of draft-ietf-lisp-crypto-00 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 04:31:32 -0000 Ilari, thanks for your comments. I agree with all of them you are = providing th expert crypto comments we need in this working group. Brian Weis and I are working on a draft update that should reflect your = comments. We will post it in short-term. Thanks a lot, Dino > On Mar 23, 2015, at 1:05 PM, Ilari Liusvaara = wrote: >=20 >=20 >=20 >> 4. Encoding and Transmitting Key Material >>=20 >> The Diffie-Hellman key material is transmitted in Map-Request and >> Map-Reply messages. Diffie-Hellman parameters are encoded in the >> LISP Security Type LCAF [LCAF]. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D 16387 | Rsvd1 | Flags = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D 11 | Rsvd2 | 6 + n = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Key Length | Key Material ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Key Material | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI =3D x | Locator Address ... = | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Diffie-Hellman parameters encoded in Key Material field >>=20 >> The 'Key Count' field encodes the number of {'Key-Length', 'Key- >> Material'} fields included in the encoded LCAF. A maximum number = of >> keys that can be encoded are 3 keys, each identified by key-id 1, >> followed by key-id 2, an finally key-id 3. >>=20 >> The 'R' bit is not used for this use-case of the Security Type LCAF >> but is reserved for [LISP-DDT] security. >>=20 >> The 'Key Algorithm' encodes the cryptographic algorithm used. The >> following values are defined: >>=20 >>=20 >>=20 >>=20 >>=20 >> Farinacci Expires July 16, 2015 [Page = 4] >>=20 >> Internet-Draft LISP Data-Plane Confidentiality January = 2015 >>=20 >>=20 >> Null: 0 >> Group-ID: 1 >> AES: 2 >> 3DES: 3 >> SHA-256: 4 >=20 > These don't look to be of the same type? And 3DES in 2015? If you want > serious backup for AES, there is Chacha20. >=20 > Also, one can't encrypt data with AES, one also needs mode for it. >=20 > Basically, for encryption strapped on top of DH, you need: >=20 > - (EC)DH group (or monoid) > - Hash function to use for key derivation. > - AEAD cipher. >=20 >> When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material' >> field is encoded as: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Group ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Public Key ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Points to Key Material values from IANA Registry >>=20 >> The Group-ID values are defined in [RFC2409] and [RFC3526] which >> describe the Diffie Hellman parameters used for key exchange. >=20 > All the groups from RFC 2409 and the lowest from RFC 3526 look too > weak for modern use. >=20 > This might also be a good place to stick ECDH groups. Those would do > really nice things to the MTU: >=20 > - CFRG basic ECDH: 32 bytes/key > - CFRG high-security ECDH: 56 bytes/key > - ECDH "stratospheric" level: 66 bytes/key > - DH basic: 256 bytes/key. >=20 > And that "high-security ECDH" is considered stronger than even > IKE group 18 (1024 bytes/key!). And "stratospheric" is so big that > finding bigger curves is pretty difficult. >=20 >=20 > Also, if this one is selected, what will be the symmetric cipher? >=20 >> When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key >> Material' field is encoded as: >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | g-length | g-value ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | p-length | p-value ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Public Key ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> Key Length describes the length of the Key Material field >=20 > What is the difference of AES vs. 3DES vs SHA256 here? >=20 >=20 >> 7. Future Work >=20 > >=20 > What I think should be done about crypto: > - Actually specify how algorithm negotiation is supposed to work (I > can't make heads or tails about that) > - Always use authenticated encryption (algorithms like AES-GCM and > Chacha20-Poly1305), and also authenticate at least some of the LISP > headers (those that aren't supposed to change)[1]. > - Swap out 3DES for something more serious. > - Support ECDH, including modern Montgomery-curve ECDH (for stronger > key exchange & smaller keys). > - Hash the map-request/map-reply packets into the encryption key > computation[2], along with the DH result. >=20 >=20 >=20 > [1] IPSec ESP can be broken if no authentication is used. >=20 > [2] TLS didn't use to do this. Caused security issues. >=20 >=20 > -Ilari >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Sun Mar 29 18:03:46 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D137A1A89A8 for ; Sun, 29 Mar 2015 18:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GIMpXavCnmO for ; Sun, 29 Mar 2015 18:03:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557D61A89A3 for ; Sun, 29 Mar 2015 18:03:39 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 01:03:18 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0125.002; Mon, 30 Mar 2015 01:03:18 +0000 From: Ross Callon To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-01 Thread-Index: AQHQWnSPQbPJi+hgVUqTeQIKhdZvrp00M8Zg Date: Mon, 30 Mar 2015 01:03:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: gigix.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1430; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(53754006)(164054003)(92566002)(15975445007)(62966003)(2900100001)(50986999)(19300405004)(66066001)(76176999)(54356999)(122556002)(102836002)(99286002)(40100003)(19580405001)(19580395003)(86362001)(230783001)(106116001)(19609705001)(19625215002)(2950100001)(77156002)(76576001)(2656002)(46102003)(19617315012)(74316001)(16236675004)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY1PR0501MB1430; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 05315CBE52 Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB14304477BFF1F86BAFC810B3A5F50BY1PR0501MB1430_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2015 01:03:17.8622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: "draft-ietf-lisp-impact@tools.ietf.org" Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 01:03:45 -0000 --_000_BY1PR0501MB14304477BFF1F86BAFC810B3A5F50BY1PR0501MB1430_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Generally I think that this document needs more work before it will be read= y to submit for publication. Some comments on draft-ietf-lisp-impact-01: First of all, I assume that the TBD at the end of section 3 will be fixed. = This reads: TBD: add a paragraph to explain the operational difference while dealing with a pull model instead of a push. Also in section 3, the third paragraph begins: In addition, Iannone and Bonaventure [IB07] show that the number of mapping entries that must be handled by an ITR of a campus network with 10,000 users is limited to few tens of thousands, and does not represent more than 3 to 4 Megabytes of memory. Reference [IB07] is of course: Iannone, L. and O. Bonaventure, "On the cost of caching locat= or/id mappings", In Proc. ACM CoNEXT 2007, December 2007. This paper states: In our analysis, we assume that the granularity of the EID-to-RLOC mapping is the prefix blocks assigned by RIRs. We call it /BGP granularity. In particular, we used the list of prefixes made available by the iPlane Project [15], containing around 240,000 entries. Using /BGP granularity means that each EID is first mapped on a /BGP prefix. The cache will thus contain /BGP to RLOC mappings.2 This is a natural choice, since routing locators are supposed to be border routers. The authors should be aware that there is some aggregation / summarization = being done in the operation of BGP routing, and that the granularity of rou= tes which appear in the default-free BGP routing tables is fundamentally di= fferent from the granularity of enterprise network / ISP boundaries across = which traffic is exchanged. The same paragraph cites Kim et al. [KIF11], which is Kim, J., Iannone, L.= , and A. Feldmann, "Deep dive into the lisp cache and what isps should know= about it", In Proc. IFIP Networking 2011, May 2011. From this document: In addition, we use a local BGP prefixes database, fed with the list of BGP prefixes published by the iPlane Pro= ject [17]. The database is used to group EID-to-RLOCs mappings with the granularit= y of existing BGP prefixes, because, as for today, there is no sufficient in= formation to predict what will be the granularity of mappings in a LISP-enabled I= nternet. I agree that "there is not sufficient information to predict what will be t= he granularity of mappings in a LISP-enabled Internet". However, not knowin= g what the mapping granularity will be does not justify using an extremely = optimistic guess, and then acting as if the results are meaningful. These a= ssumptions are clearly off by some number of orders of magnitude, but how m= any orders of magnitude is unknown. We will note that the current internet = default-free routing table includes a few hundred thousand entries (roughly= twice the 240,000 entries that existed when this study was done). For example, we might assume that the intended global deployment model invo= lves xTRs at the boundary between enterprise networks and service providers= , and might note that there are several million companies in the USA alone = (most of these are relatively small companies, of course). Thus there may b= e very roughly on the order of a hundred million or so companies worldwide.= If each one had a separate entry in the mapping table, then the number of = entries will be nearly 1,000 times larger than BGP-prefix granularity. Section 4 mentions as one possible use of LISP: "enable mobility of subscri= ber end points". If individual end points are advertised into LISP, then th= e granularity of the mapping table may be on the order of individual system= s. In this case the number of mapping table entries that could exist global= ly might be on the same order of magnitude as the number of people in the w= orld, or very roughly 7 Billion entries. This would suggest that the mappin= g table might be roughly 30,000 times finer grained than was assumed in the= referenced studies. I don't see how we can accurately predict the control plane load of LISP wi= thout some sense for what the granularity of the mapping table will be. It = should however be possible to bound the control plane load. The referenced = studies give a lower bound on possible control plane load (it won't be any = less), but give neither an accurate measurement nor an upper bound on the p= otential control plane load. I don't think that the document can claim to e= xplain the impact of LISP without there being an attempt to measure an uppe= r bound on the control plane load. Finally, perhaps I missed it but I didn't see any discussion of the volume = of overhead related to OAM traffic used for liveness detection (the need fo= r ITR's to determine the reachability of ETR's). Thanks, Ross From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone Sent: Monday, March 09, 2015 10:22 AM To: LISP mailing list list Cc: draft-ietf-lisp-impact@tools.ietf.org Subject: [lisp] WG Last Call draft-ietf-lisp-impact-01 Hi All, the authors of the LISP Impact document [https://tools.ietf.org/html/draft= -ietf-lisp-impact-01] requested the Work Group Last Call. This email starts a WG Last Call, to end March 30th, 2015. Because usually the pre-meeting period is already overloaded, the LC durati= on is set to three weeks. Please review this updated WG document and let the WG know if you agree tha= t it is ready for handing to the AD. If you have objections, please state your reasons why, and explain what it = would take to address your concerns. Any raised issue will be discussed during the WG meeting in Dallas. Thanks Luigi & Joel --_000_BY1PR0501MB14304477BFF1F86BAFC810B3A5F50BY1PR0501MB1430_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Generally I think that th= is document needs more work before it will be ready to submit for publicati= on. Some comments on draft-ietf-lisp-impact-01:

 <= /p>

First of all, I assume th= at the TBD at the end of section 3 will be fixed. This reads:

 <= /p>

   TBD: add a p= aragraph to explain the operational difference while

   dealing with= a pull model instead of a push.

 <= /p>

 <= /p>

Also in section 3, the th= ird paragraph begins:

 <= /p>

   In addition,= Iannone and Bonaventure [IB07] show that the number of

   mapping entr= ies that must be handled by an ITR of a campus network

   with 10,000 = users is limited to few tens of thousands, and does not

   represent mo= re than 3 to 4 Megabytes of memory.

 <= /p>

Reference [IB07] is of co= urse:

 <= /p>

    &= nbsp;         Iannone, L. and O. Bo= naventure, "On the cost of caching locator/id mappings", In

    &= nbsp;         Proc. ACM CoNEXT= 2007, December 2007.

 <= /p>

This paper states:

 <= /p>

    In our= analysis, we assume that the granularity of the

    EID-to= -RLOC mapping is the prefix blocks assigned by

    RIRs. = We call it /BGP granularity. In particular, we

    used t= he list of prefixes made available by the iPlane

    Projec= t [15], containing around 240,000 entries. Using

    /BGP g= ranularity means that each EID is first mapped

    on a /= BGP prefix. The cache will thus contain /BGP

    to RLO= C mappings.2 This is a natural choice, since

    routin= g locators are supposed to be border routers.

 <= /p>

The authors should be awa= re that there is some aggregation / summarization being done in the operati= on of BGP routing, and that the granularity of routes which appear in the default-free BGP routing tables is fundamentally different f= rom the granularity of enterprise network / ISP boundaries across which tra= ffic is exchanged.

 <= /p>

The same paragraph cites = Kim et al.  [KIF11], which is Kim, J., Iannone, L., and A. Feldmann, &= quot;Deep dive into the lisp cache and what isps should know about it", In Proc.  IFIP Networking 2011, May 2011.  From this d= ocument:

 <= /p>

    In add= ition, we use a local BGP prefixes

    databa= se, fed with the list of BGP prefixes published by the iPlane Project [17].=

    The da= tabase is used to group EID-to-RLOCs mappings with the granularity of<= /o:p>

    existi= ng BGP prefixes, because, as for today, there is no sufficient information<= o:p>

    to pre= dict what will be the granularity of mappings in a LISP-enabled Internet.

 <= /p>

I agree that “there= is not sufficient information to predict what will be the granularity of m= appings in a LISP-enabled Internet”. However, not knowing what the mapping granularity will be does not justify using an extremely optimi= stic guess, and then acting as if the results are meaningful. These assumpt= ions are clearly off by some number of orders of magnitude, but how many or= ders of magnitude is unknown. We will note that the current internet default-free routing table includes a = few hundred thousand entries (roughly twice the 240,000 entries that existe= d when this study was done).

 <= /p>

For example, we might ass= ume that the intended global deployment model involves xTRs at the boundary= between enterprise networks and service providers, and might note that there are several million companies in the USA alone (most= of these are relatively small companies, of course). Thus there may be ver= y roughly on the order of a hundred million or so companies worldwide. If e= ach one had a separate entry in the mapping table, then the number of entries will be nearly 1,000 times l= arger than BGP-prefix granularity.

 <= /p>

Section 4 mentions as one= possible use of LISP: “enable mobility of subscriber end points̶= 1;. If individual end points are advertised into LISP, then the granularity of the mapping table may be on the order of individual systems. In this ca= se the number of mapping table entries that could exist globally might be o= n the same order of magnitude as the number of people in the world, or very= roughly 7 Billion entries. This would suggest that the mapping table might be roughly 30,000 times finer g= rained than was assumed in the referenced studies.

 <= /p>

I don’t see how we = can accurately predict the control plane load of LISP without some sense fo= r what the granularity of the mapping table will be. It should however be possible to bound the control plane load. The referenced studie= s give a lower bound on possible control plane load (it won’t be any = less), but give neither an accurate measurement nor an upper bound on the p= otential control plane load. I don’t think that the document can claim to explain the impact of LISP without there be= ing an attempt to measure an upper bound on the control plane load.

 <= /p>

 <= /p>

Finally, perhaps I missed= it but I didn’t see any discussion of the volume of overhead related= to OAM traffic used for liveness detection (the need for ITR’s to determine the reachability of ETR’s).

 <= /p>

Thanks, Ross

 <= /p>

From: lisp [ma= ilto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone
Sent: Monday, March 09, 2015 10:22 AM
To: LISP mailing list list
Cc: draft-ietf-lisp-impact@tools.ietf.org
Subject: [lisp] WG Last Call draft-ietf-lisp-impact-01

 

Hi All,

 

the authors of the LISP Impact document  [https://tools.= ietf.org/html/draft-ietf-lisp-impact-01] requested the Work Group Last = Call.

 

This email starts a WG Last Call, to end March 30th,= 2015.

Because usually the pre-meeting period is already ov= erloaded, the LC duration is set to three weeks.

 

Please review this updated WG document and let the W= G know if you agree that it is ready for handing to the AD.

If you have objections, please state your reasons wh= y, and explain what it would take to address your concerns.

 

Any raised issue will be discussed during the WG mee= ting in Dallas.

 

Thanks


Luigi & Joel

 

--_000_BY1PR0501MB14304477BFF1F86BAFC810B3A5F50BY1PR0501MB1430_-- From nobody Sun Mar 29 18:36:36 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157B91A89FE for ; Sun, 29 Mar 2015 18:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdRvy0aSVDZf for ; Sun, 29 Mar 2015 18:36:32 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9531A89FB for ; Sun, 29 Mar 2015 18:36:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0108C1BC7215; Sun, 29 Mar 2015 18:36:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3FF191BC7213; Sun, 29 Mar 2015 18:36:31 -0700 (PDT) Message-ID: <5518A89C.3090108@joelhalpern.com> Date: Sun, 29 Mar 2015 21:36:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ross Callon , Luigi Iannone , LISP mailing list list References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-lisp-impact@tools.ietf.org" Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 01:36:34 -0000 Putting aside the TBD (which of course needs to be fixed), I have trouble figuring out what you want us to say about the main issue in your review. On the one hand, this is the very issue that we have been asked to comment on, and on the other hand you say that we don't know. What do you think it is reasoanble to say? Yours, Joel On 3/29/15 9:03 PM, Ross Callon wrote: > Generally I think that this document needs more work before it will be > ready to submit for publication. Some comments on draft-ietf-lisp-impact-01: > > First of all, I assume that the TBD at the end of section 3 will be > fixed. This reads: > > TBD: add a paragraph to explain the operational difference while > > dealing with a pull model instead of a push. > > Also in section 3, the third paragraph begins: > > In addition, Iannone and Bonaventure [IB07] show that the number of > > mapping entries that must be handled by an ITR of a campus network > > with 10,000 users is limited to few tens of thousands, and does not > > represent more than 3 to 4 Megabytes of memory. > > Reference [IB07] is of course: > > Iannone, L. and O. Bonaventure, "On the cost of caching > locator/id mappings", In > > Proc. ACM CoNEXT 2007, December 2007. > > This paper states: > > In our analysis, we assume that the granularity of the > > EID-to-RLOC mapping is the prefix blocks assigned by > > RIRs. We call it /BGP granularity. In particular, we > > used the list of prefixes made available by the iPlane > > Project [15], containing around 240,000 entries. Using > > /BGP granularity means that each EID is first mapped > > on a /BGP prefix. The cache will thus contain /BGP > > to RLOC mappings.2 This is a natural choice, since > > routing locators are supposed to be border routers. > > The authors should be aware that there is some aggregation / > summarization being done in the operation of BGP routing, and that the > granularity of routes which appear in the default-free BGP routing > tables is fundamentally different from the granularity of enterprise > network / ISP boundaries across which traffic is exchanged. > > The same paragraph cites Kim et al. [KIF11], which is Kim, J., Iannone, > L., and A. Feldmann, "Deep dive into the lisp cache and what isps should > know about it", In Proc. IFIP Networking 2011, May 2011. From this > document: > > In addition, we use a local BGP prefixes > > database, fed with the list of BGP prefixes published by the iPlane > Project [17]. > > The database is used to group EID-to-RLOCs mappings with the > granularity of > > existing BGP prefixes, because, as for today, there is no > sufficient information > > to predict what will be the granularity of mappings in a > LISP-enabled Internet. > > I agree that “there is not sufficient information to predict what will > be the granularity of mappings in a LISP-enabled Internet”. However, not > knowing what the mapping granularity will be does not justify using an > extremely optimistic guess, and then acting as if the results are > meaningful. These assumptions are clearly off by some number of orders > of magnitude, but how many orders of magnitude is unknown. We will note > that the current internet default-free routing table includes a few > hundred thousand entries (roughly twice the 240,000 entries that existed > when this study was done). > > For example, we might assume that the intended global deployment model > involves xTRs at the boundary between enterprise networks and service > providers, and might note that there are several million companies in > the USA alone (most of these are relatively small companies, of course). > Thus there may be very roughly on the order of a hundred million or so > companies worldwide. If each one had a separate entry in the mapping > table, then the number of entries will be nearly 1,000 times larger than > BGP-prefix granularity. > > Section 4 mentions as one possible use of LISP: “enable mobility of > subscriber end points”. If individual end points are advertised into > LISP, then the granularity of the mapping table may be on the order of > individual systems. In this case the number of mapping table entries > that could exist globally might be on the same order of magnitude as the > number of people in the world, or very roughly 7 Billion entries. This > would suggest that the mapping table might be roughly 30,000 times finer > grained than was assumed in the referenced studies. > > I don’t see how we can accurately predict the control plane load of LISP > without some sense for what the granularity of the mapping table will > be. It should however be possible to bound the control plane load. The > referenced studies give a lower bound on possible control plane load (it > won’t be any less), but give neither an accurate measurement nor an > upper bound on the potential control plane load. I don’t think that the > document can claim to explain the impact of LISP without there being an > attempt to measure an upper bound on the control plane load. > > Finally, perhaps I missed it but I didn’t see any discussion of the > volume of overhead related to OAM traffic used for liveness detection > (the need for ITR’s to determine the reachability of ETR’s). > > Thanks, Ross > > *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi Iannone > *Sent:* Monday, March 09, 2015 10:22 AM > *To:* LISP mailing list list > *Cc:* draft-ietf-lisp-impact@tools.ietf.org > *Subject:* [lisp] WG Last Call draft-ietf-lisp-impact-01 > > Hi All, > > the authors of the LISP Impact document > [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested the > Work Group Last Call. > > This email starts a WG Last Call, to end March 30th, 2015. > > Because usually the pre-meeting period is already overloaded, the LC > duration is set to three weeks. > > Please review this updated WG document and let the WG know if you agree > that it is ready for handing to the AD. > > If you have objections, please state your reasons why, and explain what > it would take to address your concerns. > > Any raised issue will be discussed during the WG meeting in Dallas. > > Thanks > > > Luigi & Joel > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Sun Mar 29 18:50:11 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCE01A8A20 for ; Sun, 29 Mar 2015 18:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9labblrfpuk for ; Sun, 29 Mar 2015 18:50:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343981A8A23 for ; Sun, 29 Mar 2015 18:50:07 -0700 (PDT) Received: from BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) by BY1PR0501MB1430.namprd05.prod.outlook.com (25.160.107.152) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 01:50:04 +0000 Received: from BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) by BY1PR0501MB1430.namprd05.prod.outlook.com ([25.160.107.152]) with mapi id 15.01.0125.002; Mon, 30 Mar 2015 01:50:04 +0000 From: Ross Callon To: "Joel M. Halpern" , Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-01 Thread-Index: AQHQWnSPQbPJi+hgVUqTeQIKhdZvrp00M8ZggAArMgCAAAJBgA== Date: Mon, 30 Mar 2015 01:50:04 +0000 Message-ID: References: <5518A89C.3090108@joelhalpern.com> In-Reply-To: <5518A89C.3090108@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1430; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(479174004)(164054003)(24454002)(51704005)(2656002)(76576001)(2950100001)(77156002)(74316001)(87936001)(46102003)(50986999)(76176999)(54356999)(66066001)(92566002)(62966003)(2900100001)(15975445007)(86362001)(19580405001)(19580395003)(106116001)(230783001)(102836002)(122556002)(40100003)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1430; H:BY1PR0501MB1430.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY1PR0501MB1430; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1430; x-forefront-prvs: 05315CBE52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2015 01:50:04.4852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1430 Archived-At: Cc: "draft-ietf-lisp-impact@tools.ietf.org" Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 01:50:10 -0000 I suppose that there are two options: 1. Admit that we have no clue what the cache size or control overhead will = be. 2. Repeat the cited studies, but with a pessimistic (worse case) rather tha= n optimistic (better than best case) assumption about cache granularity.=20 The second option would allow us to actually have some idea what would happ= en if LISP were deployed on an Internet-wide scale, but would of course tak= e more time and more work.=20 Ross PS: I will be offline at meetings all of this week, so I might be a bit slo= wer to respond for the next few days. =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Sunday, March 29, 2015 9:36 PM To: Ross Callon; Luigi Iannone; LISP mailing list list Cc: draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Putting aside the TBD (which of course needs to be fixed), I have=20 trouble figuring out what you want us to say about the main issue in=20 your review. On the one hand, this is the very issue that we have been=20 asked to comment on, and on the other hand you say that we don't know.=20 What do you think it is reasoanble to say? Yours, Joel On 3/29/15 9:03 PM, Ross Callon wrote: > Generally I think that this document needs more work before it will be > ready to submit for publication. Some comments on draft-ietf-lisp-impact-= 01: > > First of all, I assume that the TBD at the end of section 3 will be > fixed. This reads: > > TBD: add a paragraph to explain the operational difference while > > dealing with a pull model instead of a push. > > Also in section 3, the third paragraph begins: > > In addition, Iannone and Bonaventure [IB07] show that the number of > > mapping entries that must be handled by an ITR of a campus network > > with 10,000 users is limited to few tens of thousands, and does not > > represent more than 3 to 4 Megabytes of memory. > > Reference [IB07] is of course: > > Iannone, L. and O. Bonaventure, "On the cost of caching > locator/id mappings", In > > Proc. ACM CoNEXT 2007, December 2007. > > This paper states: > > In our analysis, we assume that the granularity of the > > EID-to-RLOC mapping is the prefix blocks assigned by > > RIRs. We call it /BGP granularity. In particular, we > > used the list of prefixes made available by the iPlane > > Project [15], containing around 240,000 entries. Using > > /BGP granularity means that each EID is first mapped > > on a /BGP prefix. The cache will thus contain /BGP > > to RLOC mappings.2 This is a natural choice, since > > routing locators are supposed to be border routers. > > The authors should be aware that there is some aggregation / > summarization being done in the operation of BGP routing, and that the > granularity of routes which appear in the default-free BGP routing > tables is fundamentally different from the granularity of enterprise > network / ISP boundaries across which traffic is exchanged. > > The same paragraph cites Kim et al. [KIF11], which is Kim, J., Iannone, > L., and A. Feldmann, "Deep dive into the lisp cache and what isps should > know about it", In Proc. IFIP Networking 2011, May 2011. From this > document: > > In addition, we use a local BGP prefixes > > database, fed with the list of BGP prefixes published by the iPlane > Project [17]. > > The database is used to group EID-to-RLOCs mappings with the > granularity of > > existing BGP prefixes, because, as for today, there is no > sufficient information > > to predict what will be the granularity of mappings in a > LISP-enabled Internet. > > I agree that "there is not sufficient information to predict what will > be the granularity of mappings in a LISP-enabled Internet". However, not > knowing what the mapping granularity will be does not justify using an > extremely optimistic guess, and then acting as if the results are > meaningful. These assumptions are clearly off by some number of orders > of magnitude, but how many orders of magnitude is unknown. We will note > that the current internet default-free routing table includes a few > hundred thousand entries (roughly twice the 240,000 entries that existed > when this study was done). > > For example, we might assume that the intended global deployment model > involves xTRs at the boundary between enterprise networks and service > providers, and might note that there are several million companies in > the USA alone (most of these are relatively small companies, of course). > Thus there may be very roughly on the order of a hundred million or so > companies worldwide. If each one had a separate entry in the mapping > table, then the number of entries will be nearly 1,000 times larger than > BGP-prefix granularity. > > Section 4 mentions as one possible use of LISP: "enable mobility of > subscriber end points". If individual end points are advertised into > LISP, then the granularity of the mapping table may be on the order of > individual systems. In this case the number of mapping table entries > that could exist globally might be on the same order of magnitude as the > number of people in the world, or very roughly 7 Billion entries. This > would suggest that the mapping table might be roughly 30,000 times finer > grained than was assumed in the referenced studies. > > I don't see how we can accurately predict the control plane load of LISP > without some sense for what the granularity of the mapping table will > be. It should however be possible to bound the control plane load. The > referenced studies give a lower bound on possible control plane load (it > won't be any less), but give neither an accurate measurement nor an > upper bound on the potential control plane load. I don't think that the > document can claim to explain the impact of LISP without there being an > attempt to measure an upper bound on the control plane load. > > Finally, perhaps I missed it but I didn't see any discussion of the > volume of overhead related to OAM traffic used for liveness detection > (the need for ITR's to determine the reachability of ETR's). > > Thanks, Ross > > *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi Iannone > *Sent:* Monday, March 09, 2015 10:22 AM > *To:* LISP mailing list list > *Cc:* draft-ietf-lisp-impact@tools.ietf.org > *Subject:* [lisp] WG Last Call draft-ietf-lisp-impact-01 > > Hi All, > > the authors of the LISP Impact document > [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested the > Work Group Last Call. > > This email starts a WG Last Call, to end March 30th, 2015. > > Because usually the pre-meeting period is already overloaded, the LC > duration is set to three weeks. > > Please review this updated WG document and let the WG know if you agree > that it is ready for handing to the AD. > > If you have objections, please state your reasons why, and explain what > it would take to address your concerns. > > Any raised issue will be discussed during the WG meeting in Dallas. > > Thanks > > > Luigi & Joel > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Sun Mar 29 18:55:27 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F228F1A8A66 for ; Sun, 29 Mar 2015 18:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn1SwzVSY5Rm for ; Sun, 29 Mar 2015 18:55:23 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C8B1A8A60 for ; Sun, 29 Mar 2015 18:55:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DAF1A1BC721C; Sun, 29 Mar 2015 18:55:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2B1941BC7210; Sun, 29 Mar 2015 18:55:22 -0700 (PDT) Message-ID: <5518AD07.9090200@joelhalpern.com> Date: Sun, 29 Mar 2015 21:55:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brian Haberman , "BRUNGARD, DEBORAH A (ATTLABS)" References: <5518A89C.3090108@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 01:55:27 -0000 Brian, Deborah, if we modified the section to say that we do not know what the impact on cache size and control overhead will be, as the studies that have been made have been disputed as to their relevance to the core Internet case, would the document still meet the IESG requirements for evaluating the impact. I don't want to ask the authors if they can live with a certain change if that change will cause other necessary reviewers to complain. I do not see it as sensible to hold up the publication of this and the other LISP work while researchers go off to see if they can calculate better results. Particularly not when publishing this document is required to do other work. Yours, Joel On 3/29/15 9:50 PM, Ross Callon wrote: > I suppose that there are two options: > > 1. Admit that we have no clue what the cache size or control overhead > will be. > > 2. Repeat the cited studies, but with a pessimistic (worse case) > rather than optimistic (better than best case) assumption about cache > granularity. > > The second option would allow us to actually have some idea what > would happen if LISP were deployed on an Internet-wide scale, but > would of course take more time and more work. > > Ross > > PS: I will be offline at meetings all of this week, so I might be a > bit slower to respond for the next few days. > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Sunday, March 29, 2015 9:36 PM To: > Ross Callon; Luigi Iannone; LISP mailing list list Cc: > draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last > Call draft-ietf-lisp-impact-01 > > Putting aside the TBD (which of course needs to be fixed), I have > trouble figuring out what you want us to say about the main issue in > your review. On the one hand, this is the very issue that we have > been asked to comment on, and on the other hand you say that we don't > know. What do you think it is reasoanble to say? > > Yours, Joel > > On 3/29/15 9:03 PM, Ross Callon wrote: >> Generally I think that this document needs more work before it will >> be ready to submit for publication. Some comments on >> draft-ietf-lisp-impact-01: >> >> First of all, I assume that the TBD at the end of section 3 will >> be fixed. This reads: >> >> TBD: add a paragraph to explain the operational difference while >> >> dealing with a pull model instead of a push. >> >> Also in section 3, the third paragraph begins: >> >> In addition, Iannone and Bonaventure [IB07] show that the number >> of >> >> mapping entries that must be handled by an ITR of a campus network >> >> with 10,000 users is limited to few tens of thousands, and does >> not >> >> represent more than 3 to 4 Megabytes of memory. >> >> Reference [IB07] is of course: >> >> Iannone, L. and O. Bonaventure, "On the cost of caching locator/id >> mappings", In >> >> Proc. ACM CoNEXT 2007, December 2007. >> >> This paper states: >> >> In our analysis, we assume that the granularity of the >> >> EID-to-RLOC mapping is the prefix blocks assigned by >> >> RIRs. We call it /BGP granularity. In particular, we >> >> used the list of prefixes made available by the iPlane >> >> Project [15], containing around 240,000 entries. Using >> >> /BGP granularity means that each EID is first mapped >> >> on a /BGP prefix. The cache will thus contain /BGP >> >> to RLOC mappings.2 This is a natural choice, since >> >> routing locators are supposed to be border routers. >> >> The authors should be aware that there is some aggregation / >> summarization being done in the operation of BGP routing, and that >> the granularity of routes which appear in the default-free BGP >> routing tables is fundamentally different from the granularity of >> enterprise network / ISP boundaries across which traffic is >> exchanged. >> >> The same paragraph cites Kim et al. [KIF11], which is Kim, J., >> Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and >> what isps should know about it", In Proc. IFIP Networking 2011, >> May 2011. From this document: >> >> In addition, we use a local BGP prefixes >> >> database, fed with the list of BGP prefixes published by the >> iPlane Project [17]. >> >> The database is used to group EID-to-RLOCs mappings with the >> granularity of >> >> existing BGP prefixes, because, as for today, there is no >> sufficient information >> >> to predict what will be the granularity of mappings in a >> LISP-enabled Internet. >> >> I agree that "there is not sufficient information to predict what >> will be the granularity of mappings in a LISP-enabled Internet". >> However, not knowing what the mapping granularity will be does not >> justify using an extremely optimistic guess, and then acting as if >> the results are meaningful. These assumptions are clearly off by >> some number of orders of magnitude, but how many orders of >> magnitude is unknown. We will note that the current internet >> default-free routing table includes a few hundred thousand entries >> (roughly twice the 240,000 entries that existed when this study was >> done). >> >> For example, we might assume that the intended global deployment >> model involves xTRs at the boundary between enterprise networks and >> service providers, and might note that there are several million >> companies in the USA alone (most of these are relatively small >> companies, of course). Thus there may be very roughly on the order >> of a hundred million or so companies worldwide. If each one had a >> separate entry in the mapping table, then the number of entries >> will be nearly 1,000 times larger than BGP-prefix granularity. >> >> Section 4 mentions as one possible use of LISP: "enable mobility >> of subscriber end points". If individual end points are advertised >> into LISP, then the granularity of the mapping table may be on the >> order of individual systems. In this case the number of mapping >> table entries that could exist globally might be on the same order >> of magnitude as the number of people in the world, or very roughly >> 7 Billion entries. This would suggest that the mapping table might >> be roughly 30,000 times finer grained than was assumed in the >> referenced studies. >> >> I don't see how we can accurately predict the control plane load of >> LISP without some sense for what the granularity of the mapping >> table will be. It should however be possible to bound the control >> plane load. The referenced studies give a lower bound on possible >> control plane load (it won't be any less), but give neither an >> accurate measurement nor an upper bound on the potential control >> plane load. I don't think that the document can claim to explain >> the impact of LISP without there being an attempt to measure an >> upper bound on the control plane load. >> >> Finally, perhaps I missed it but I didn't see any discussion of >> the volume of overhead related to OAM traffic used for liveness >> detection (the need for ITR's to determine the reachability of >> ETR's). >> >> Thanks, Ross >> >> *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi >> Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP mailing >> list list *Cc:* draft-ietf-lisp-impact@tools.ietf.org *Subject:* >> [lisp] WG Last Call draft-ietf-lisp-impact-01 >> >> Hi All, >> >> the authors of the LISP Impact document >> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested >> the Work Group Last Call. >> >> This email starts a WG Last Call, to end March 30th, 2015. >> >> Because usually the pre-meeting period is already overloaded, the >> LC duration is set to three weeks. >> >> Please review this updated WG document and let the WG know if you >> agree that it is ready for handing to the AD. >> >> If you have objections, please state your reasons why, and explain >> what it would take to address your concerns. >> >> Any raised issue will be discussed during the WG meeting in >> Dallas. >> >> Thanks >> >> >> Luigi & Joel >> >> >> >> _______________________________________________ lisp mailing list >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >> > From nobody Mon Mar 30 08:18:44 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95FF1AD071 for ; Mon, 30 Mar 2015 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLe_7XqIrZMH for ; Mon, 30 Mar 2015 08:18:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556051AD0A6 for ; Mon, 30 Mar 2015 08:18:15 -0700 (PDT) Received: from BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 15:17:58 +0000 Received: from BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) by BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) with mapi id 15.01.0125.002; Mon, 30 Mar 2015 15:17:58 +0000 From: Ronald Bonica To: "Joel M. Halpern" , Brian Haberman , "BRUNGARD, DEBORAH A (ATTLABS)" Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-01 Thread-Index: AQHQWnSPtp3FrZs9xUaprzBtSdSj9p00VbOAgAAJRQCAAAPNAIAAAXiAgADc9UA= Date: Mon, 30 Mar 2015 15:17:58 +0000 Message-ID: References: <5518A89C.3090108@joelhalpern.com> <5518AD07.9090200@joelhalpern.com> In-Reply-To: <5518AD07.9090200@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(479174004)(377454003)(51704005)(53754006)(24454002)(87936001)(122556002)(46102003)(66066001)(106116001)(54356999)(33656002)(2656002)(19580405001)(62966003)(40100003)(230783001)(50986999)(76176999)(2900100001)(93886004)(99286002)(2950100001)(561944003)(102836002)(15975445007)(92566002)(19580395003)(86362001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:BLUPR05MB433.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB433; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB433; x-forefront-prvs: 05315CBE52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2015 15:17:58.2354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB433 Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:18:43 -0000 Brian, Deborah, I realize that the authors are frustrated. Maybe we can run with Joel's pro= posal if we make the disclaimer complete. Shouldn't the disclaimer read something like, "We do not know the impact of= cache size and control overhead on {x, y, z}", where x, y and z might be: - LISP scaling - LISP security - LISP resiliency - other ??? Given that, might we draw some conclusions regarding LISP's applicability? Ron > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Sunday, March 29, 2015 9:55 PM > To: Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS) > Cc: LISP mailing list list > Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 >=20 > Brian, Deborah, if we modified the section to say that we do not know wha= t > the impact on cache size and control overhead will be, as the studies tha= t > have been made have been disputed as to their relevance to the core > Internet case, would the document still meet the IESG requirements for > evaluating the impact. I don't want to ask the authors if they can live = with a > certain change if that change will cause other necessary reviewers to > complain. >=20 > I do not see it as sensible to hold up the publication of this and the ot= her LISP > work while researchers go off to see if they can calculate better results= . > Particularly not when publishing this document is required to do other wo= rk. >=20 > Yours, > Joel >=20 > On 3/29/15 9:50 PM, Ross Callon wrote: > > I suppose that there are two options: > > > > 1. Admit that we have no clue what the cache size or control overhead > > will be. > > > > 2. Repeat the cited studies, but with a pessimistic (worse case) > > rather than optimistic (better than best case) assumption about cache > > granularity. > > > > The second option would allow us to actually have some idea what would > > happen if LISP were deployed on an Internet-wide scale, but would of > > course take more time and more work. > > > > Ross > > > > PS: I will be offline at meetings all of this week, so I might be a > > bit slower to respond for the next few days. > > > > -----Original Message----- From: Joel M. Halpern > > [mailto:jmh@joelhalpern.com] Sent: Sunday, March 29, 2015 9:36 PM To: > > Ross Callon; Luigi Iannone; LISP mailing list list Cc: > > draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last Call > > draft-ietf-lisp-impact-01 > > > > Putting aside the TBD (which of course needs to be fixed), I have > > trouble figuring out what you want us to say about the main issue in > > your review. On the one hand, this is the very issue that we have > > been asked to comment on, and on the other hand you say that we don't > > know. What do you think it is reasoanble to say? > > > > Yours, Joel > > > > On 3/29/15 9:03 PM, Ross Callon wrote: > >> Generally I think that this document needs more work before it will > >> be ready to submit for publication. Some comments on > >> draft-ietf-lisp-impact-01: > >> > >> First of all, I assume that the TBD at the end of section 3 will be > >> fixed. This reads: > >> > >> TBD: add a paragraph to explain the operational difference while > >> > >> dealing with a pull model instead of a push. > >> > >> Also in section 3, the third paragraph begins: > >> > >> In addition, Iannone and Bonaventure [IB07] show that the number of > >> > >> mapping entries that must be handled by an ITR of a campus network > >> > >> with 10,000 users is limited to few tens of thousands, and does not > >> > >> represent more than 3 to 4 Megabytes of memory. > >> > >> Reference [IB07] is of course: > >> > >> Iannone, L. and O. Bonaventure, "On the cost of caching locator/id > >> mappings", In > >> > >> Proc. ACM CoNEXT 2007, December 2007. > >> > >> This paper states: > >> > >> In our analysis, we assume that the granularity of the > >> > >> EID-to-RLOC mapping is the prefix blocks assigned by > >> > >> RIRs. We call it /BGP granularity. In particular, we > >> > >> used the list of prefixes made available by the iPlane > >> > >> Project [15], containing around 240,000 entries. Using > >> > >> /BGP granularity means that each EID is first mapped > >> > >> on a /BGP prefix. The cache will thus contain /BGP > >> > >> to RLOC mappings.2 This is a natural choice, since > >> > >> routing locators are supposed to be border routers. > >> > >> The authors should be aware that there is some aggregation / > >> summarization being done in the operation of BGP routing, and that > >> the granularity of routes which appear in the default-free BGP > >> routing tables is fundamentally different from the granularity of > >> enterprise network / ISP boundaries across which traffic is > >> exchanged. > >> > >> The same paragraph cites Kim et al. [KIF11], which is Kim, J., > >> Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and what > >> isps should know about it", In Proc. IFIP Networking 2011, May 2011. > >> From this document: > >> > >> In addition, we use a local BGP prefixes > >> > >> database, fed with the list of BGP prefixes published by the iPlane > >> Project [17]. > >> > >> The database is used to group EID-to-RLOCs mappings with the > >> granularity of > >> > >> existing BGP prefixes, because, as for today, there is no sufficient > >> information > >> > >> to predict what will be the granularity of mappings in a LISP-enabled > >> Internet. > >> > >> I agree that "there is not sufficient information to predict what > >> will be the granularity of mappings in a LISP-enabled Internet". > >> However, not knowing what the mapping granularity will be does not > >> justify using an extremely optimistic guess, and then acting as if > >> the results are meaningful. These assumptions are clearly off by some > >> number of orders of magnitude, but how many orders of magnitude is > >> unknown. We will note that the current internet default-free routing > >> table includes a few hundred thousand entries (roughly twice the > >> 240,000 entries that existed when this study was done). > >> > >> For example, we might assume that the intended global deployment > >> model involves xTRs at the boundary between enterprise networks and > >> service providers, and might note that there are several million > >> companies in the USA alone (most of these are relatively small > >> companies, of course). Thus there may be very roughly on the order of > >> a hundred million or so companies worldwide. If each one had a > >> separate entry in the mapping table, then the number of entries will > >> be nearly 1,000 times larger than BGP-prefix granularity. > >> > >> Section 4 mentions as one possible use of LISP: "enable mobility of > >> subscriber end points". If individual end points are advertised into > >> LISP, then the granularity of the mapping table may be on the order > >> of individual systems. In this case the number of mapping table > >> entries that could exist globally might be on the same order of > >> magnitude as the number of people in the world, or very roughly > >> 7 Billion entries. This would suggest that the mapping table might be > >> roughly 30,000 times finer grained than was assumed in the referenced > >> studies. > >> > >> I don't see how we can accurately predict the control plane load of > >> LISP without some sense for what the granularity of the mapping table > >> will be. It should however be possible to bound the control plane > >> load. The referenced studies give a lower bound on possible control > >> plane load (it won't be any less), but give neither an accurate > >> measurement nor an upper bound on the potential control plane load. I > >> don't think that the document can claim to explain the impact of LISP > >> without there being an attempt to measure an upper bound on the > >> control plane load. > >> > >> Finally, perhaps I missed it but I didn't see any discussion of the > >> volume of overhead related to OAM traffic used for liveness detection > >> (the need for ITR's to determine the reachability of ETR's). > >> > >> Thanks, Ross > >> > >> *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi > >> Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP mailing > >> list list *Cc:* draft-ietf-lisp-impact@tools.ietf.org *Subject:* > >> [lisp] WG Last Call draft-ietf-lisp-impact-01 > >> > >> Hi All, > >> > >> the authors of the LISP Impact document > >> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested the > >> Work Group Last Call. > >> > >> This email starts a WG Last Call, to end March 30th, 2015. > >> > >> Because usually the pre-meeting period is already overloaded, the LC > >> duration is set to three weeks. > >> > >> Please review this updated WG document and let the WG know if you > >> agree that it is ready for handing to the AD. > >> > >> If you have objections, please state your reasons why, and explain > >> what it would take to address your concerns. > >> > >> Any raised issue will be discussed during the WG meeting in Dallas. > >> > >> Thanks > >> > >> > >> Luigi & Joel > >> > >> > >> > >> _______________________________________________ lisp mailing > list > >> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp > >> > > >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Mar 30 16:19:56 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4ED1A88DD for ; Mon, 30 Mar 2015 16:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHYhwKFAFKVS for ; Mon, 30 Mar 2015 16:19:53 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91471A88E1 for ; Mon, 30 Mar 2015 16:19:52 -0700 (PDT) Received: by wgra20 with SMTP id a20so518436wgr.3 for ; Mon, 30 Mar 2015 16:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9iMW1E6ffr/GCZrGjwgi4FgzejbiLrI1QL/nX87lAac=; b=pqkVRk4dj2bs/MMqGkmK9/fylSEfilZFa4EDd0k6+Di7OZRhDimXNhOTkfs0PPr++d 7fNbAOFvEWxA7iJ/O6KakCNFT8++CRGlLfCYdWXkEVm7rHL7wQeNx5N4f1US8ZuaGgRi FC61k/NxYE/8b6fatqDMhzcm78FdBlcuDWphQzxFcH8G8TwRXhsRxpdPfT6BjbIrJOJe tg7BD+QFPyB6gQpaFLi+kbF4LB2Lx3cE/yjinXYsZVL70cL5v0weBxPBWuhIFqp7erE3 A+jrwZhmzA7iry8OpiDx61iszoZvG7AL8yPS+7B28oS3dZWiw7n88iAnAp+/3qcxURAL sedQ== X-Received: by 10.180.187.171 with SMTP id ft11mr313912wic.0.1427757591467; Mon, 30 Mar 2015 16:19:51 -0700 (PDT) Received: from [172.17.2.79] (ANice-652-1-11-157.w86-193.abo.wanadoo.fr. [86.193.242.157]) by mx.google.com with ESMTPSA id dm6sm17693315wib.22.2015.03.30.16.19.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 16:19:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Damien Saucez In-Reply-To: Date: Tue, 31 Mar 2015 01:19:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <580EAA3E-7B39-430B-A23B-001F0E8E597B@gmail.com> References: <5518A89C.3090108@joelhalpern.com> <5518AD07.9090200@joelhalpern.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: LISP mailing list list , "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 23:19:56 -0000 Ron, As one of the authors I can say I am not frustrated :-) We are looking on how to address in the best way the comments of this thread. Just that it is unrealistic to hope a new full study on the cache size = from research partners as such a study takes a lot of time and resources (to produce the experimentation, then to get reviewed in a conference or journal and finally get published) and would not change any conclusion with regards to the analytical studies reference in the draft already = and that draw general conclusions. The best solution could be to ask your customers to provide me the necessary information so that I could evaluate the impact of LISP for their needs. Without that, I am afraid that the only thing that we can reasonably provide is theoretical/analytical studies. The disclaimer you propose to add is just incorrect. It is not true that we don=92t know the impact of cache size. Actually, in the draft, we already reference the analytical study [CCD12] that demonstrates analytically that it is possible to link cache size, traffic pattern, = and miss rate. Here is the paragraph present in the draft: [CCD12] generalizes the caching discussion and proposes an analytic model for the EID-to-RLOC cache size when prefix-level traffic has a stationary generating process. The model shows that miss rate can be accurately predicted from the EID-to-RLOC cache size and a small set of easily measurable traffic parameters, meaning that operators can provision the EID-to-RLOC cache of their ITRs according to the miss rate they want to achieve for their given traffic. That is clear enough for me and unless someone can prove the model wrong I am perfectly fine with this observation that is supported by=20 empirical data. Cheers, Damien Saucez=20 On 30 Mar 2015, at 17:17, Ronald Bonica wrote: > Brian, Deborah, >=20 > I realize that the authors are frustrated. Maybe we can run with = Joel's proposal if we make the disclaimer complete. >=20 > Shouldn't the disclaimer read something like, "We do not know the = impact of cache size and control overhead on {x, y, z}", where x, y and = z might be: >=20 > - LISP scaling > - LISP security > - LISP resiliency > - other ??? >=20 > Given that, might we draw some conclusions regarding LISP's = applicability? >=20 > Ron >=20 >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. = Halpern >> Sent: Sunday, March 29, 2015 9:55 PM >> To: Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS) >> Cc: LISP mailing list list >> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 >>=20 >> Brian, Deborah, if we modified the section to say that we do not know = what >> the impact on cache size and control overhead will be, as the studies = that >> have been made have been disputed as to their relevance to the core >> Internet case, would the document still meet the IESG requirements = for >> evaluating the impact. I don't want to ask the authors if they can = live with a >> certain change if that change will cause other necessary reviewers to >> complain. >>=20 >> I do not see it as sensible to hold up the publication of this and = the other LISP >> work while researchers go off to see if they can calculate better = results. >> Particularly not when publishing this document is required to do = other work. >>=20 >> Yours, >> Joel >>=20 >> On 3/29/15 9:50 PM, Ross Callon wrote: >>> I suppose that there are two options: >>>=20 >>> 1. Admit that we have no clue what the cache size or control = overhead >>> will be. >>>=20 >>> 2. Repeat the cited studies, but with a pessimistic (worse case) >>> rather than optimistic (better than best case) assumption about = cache >>> granularity. >>>=20 >>> The second option would allow us to actually have some idea what = would >>> happen if LISP were deployed on an Internet-wide scale, but would of >>> course take more time and more work. >>>=20 >>> Ross >>>=20 >>> PS: I will be offline at meetings all of this week, so I might be a >>> bit slower to respond for the next few days. >>>=20 >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com] Sent: Sunday, March 29, 2015 9:36 PM = To: >>> Ross Callon; Luigi Iannone; LISP mailing list list Cc: >>> draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last = Call >>> draft-ietf-lisp-impact-01 >>>=20 >>> Putting aside the TBD (which of course needs to be fixed), I have >>> trouble figuring out what you want us to say about the main issue in >>> your review. On the one hand, this is the very issue that we have >>> been asked to comment on, and on the other hand you say that we = don't >>> know. What do you think it is reasoanble to say? >>>=20 >>> Yours, Joel >>>=20 >>> On 3/29/15 9:03 PM, Ross Callon wrote: >>>> Generally I think that this document needs more work before it will >>>> be ready to submit for publication. Some comments on >>>> draft-ietf-lisp-impact-01: >>>>=20 >>>> First of all, I assume that the TBD at the end of section 3 will be >>>> fixed. This reads: >>>>=20 >>>> TBD: add a paragraph to explain the operational difference while >>>>=20 >>>> dealing with a pull model instead of a push. >>>>=20 >>>> Also in section 3, the third paragraph begins: >>>>=20 >>>> In addition, Iannone and Bonaventure [IB07] show that the number of >>>>=20 >>>> mapping entries that must be handled by an ITR of a campus network >>>>=20 >>>> with 10,000 users is limited to few tens of thousands, and does not >>>>=20 >>>> represent more than 3 to 4 Megabytes of memory. >>>>=20 >>>> Reference [IB07] is of course: >>>>=20 >>>> Iannone, L. and O. Bonaventure, "On the cost of caching locator/id >>>> mappings", In >>>>=20 >>>> Proc. ACM CoNEXT 2007, December 2007. >>>>=20 >>>> This paper states: >>>>=20 >>>> In our analysis, we assume that the granularity of the >>>>=20 >>>> EID-to-RLOC mapping is the prefix blocks assigned by >>>>=20 >>>> RIRs. We call it /BGP granularity. In particular, we >>>>=20 >>>> used the list of prefixes made available by the iPlane >>>>=20 >>>> Project [15], containing around 240,000 entries. Using >>>>=20 >>>> /BGP granularity means that each EID is first mapped >>>>=20 >>>> on a /BGP prefix. The cache will thus contain /BGP >>>>=20 >>>> to RLOC mappings.2 This is a natural choice, since >>>>=20 >>>> routing locators are supposed to be border routers. >>>>=20 >>>> The authors should be aware that there is some aggregation / >>>> summarization being done in the operation of BGP routing, and that >>>> the granularity of routes which appear in the default-free BGP >>>> routing tables is fundamentally different from the granularity of >>>> enterprise network / ISP boundaries across which traffic is >>>> exchanged. >>>>=20 >>>> The same paragraph cites Kim et al. [KIF11], which is Kim, J., >>>> Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and = what >>>> isps should know about it", In Proc. IFIP Networking 2011, May = 2011. >>>> =46rom this document: >>>>=20 >>>> In addition, we use a local BGP prefixes >>>>=20 >>>> database, fed with the list of BGP prefixes published by the iPlane >>>> Project [17]. >>>>=20 >>>> The database is used to group EID-to-RLOCs mappings with the >>>> granularity of >>>>=20 >>>> existing BGP prefixes, because, as for today, there is no = sufficient >>>> information >>>>=20 >>>> to predict what will be the granularity of mappings in a = LISP-enabled >>>> Internet. >>>>=20 >>>> I agree that "there is not sufficient information to predict what >>>> will be the granularity of mappings in a LISP-enabled Internet". >>>> However, not knowing what the mapping granularity will be does not >>>> justify using an extremely optimistic guess, and then acting as if >>>> the results are meaningful. These assumptions are clearly off by = some >>>> number of orders of magnitude, but how many orders of magnitude is >>>> unknown. We will note that the current internet default-free = routing >>>> table includes a few hundred thousand entries (roughly twice the >>>> 240,000 entries that existed when this study was done). >>>>=20 >>>> For example, we might assume that the intended global deployment >>>> model involves xTRs at the boundary between enterprise networks and >>>> service providers, and might note that there are several million >>>> companies in the USA alone (most of these are relatively small >>>> companies, of course). Thus there may be very roughly on the order = of >>>> a hundred million or so companies worldwide. If each one had a >>>> separate entry in the mapping table, then the number of entries = will >>>> be nearly 1,000 times larger than BGP-prefix granularity. >>>>=20 >>>> Section 4 mentions as one possible use of LISP: "enable mobility of >>>> subscriber end points". If individual end points are advertised = into >>>> LISP, then the granularity of the mapping table may be on the order >>>> of individual systems. In this case the number of mapping table >>>> entries that could exist globally might be on the same order of >>>> magnitude as the number of people in the world, or very roughly >>>> 7 Billion entries. This would suggest that the mapping table might = be >>>> roughly 30,000 times finer grained than was assumed in the = referenced >>>> studies. >>>>=20 >>>> I don't see how we can accurately predict the control plane load of >>>> LISP without some sense for what the granularity of the mapping = table >>>> will be. It should however be possible to bound the control plane >>>> load. The referenced studies give a lower bound on possible control >>>> plane load (it won't be any less), but give neither an accurate >>>> measurement nor an upper bound on the potential control plane load. = I >>>> don't think that the document can claim to explain the impact of = LISP >>>> without there being an attempt to measure an upper bound on the >>>> control plane load. >>>>=20 >>>> Finally, perhaps I missed it but I didn't see any discussion of the >>>> volume of overhead related to OAM traffic used for liveness = detection >>>> (the need for ITR's to determine the reachability of ETR's). >>>>=20 >>>> Thanks, Ross >>>>=20 >>>> *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi >>>> Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP mailing >>>> list list *Cc:* draft-ietf-lisp-impact@tools.ietf.org *Subject:* >>>> [lisp] WG Last Call draft-ietf-lisp-impact-01 >>>>=20 >>>> Hi All, >>>>=20 >>>> the authors of the LISP Impact document >>>> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested = the >>>> Work Group Last Call. >>>>=20 >>>> This email starts a WG Last Call, to end March 30th, 2015. >>>>=20 >>>> Because usually the pre-meeting period is already overloaded, the = LC >>>> duration is set to three weeks. >>>>=20 >>>> Please review this updated WG document and let the WG know if you >>>> agree that it is ready for handing to the AD. >>>>=20 >>>> If you have objections, please state your reasons why, and explain >>>> what it would take to address your concerns. >>>>=20 >>>> Any raised issue will be discussed during the WG meeting in Dallas. >>>>=20 >>>> Thanks >>>>=20 >>>>=20 >>>> Luigi & Joel >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ lisp mailing >> list >>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Mar 31 03:16:15 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5B1A8A3E for ; Tue, 31 Mar 2015 03:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10DBzN7iDBwS for ; Tue, 31 Mar 2015 03:16:12 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42311A8991 for ; Tue, 31 Mar 2015 03:16:11 -0700 (PDT) Received: by wgra20 with SMTP id a20so13505099wgr.3 for ; Tue, 31 Mar 2015 03:16:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=J3Vj+yHS14YoDLrB3Cv9SODFwOTiA/F/5C053uugQXw=; b=Pad23KU8XCY+dL3JucKtLkcJKEB/LwOiuizT8MybrNbcLMgCvglo1B2RDDZ6GkV7ma bXy/zybWcfQKj1FezXJhhuyx4nVTPFxOtKfy4jwSlNVtbK+kp8FNZrpS8MkQLZzv9tN2 4XR3aA0XvMhSXc85CzyNSRqsnu5ms/sQ+quwF/Zg+5MQeOB0WMGxCF6zuPy6qEBpHbQ7 mp/d3r+0UhT1RUrU6mNH4YXnBs2iIAmspY+Z70U+u3yR/2GJGMA7oqREtu37gpXrOHbx Ysz8CMi18lvk+WH4OavEdiRON+o1/G+gigxQ+j9sX6GhK9kXK+vVD47oeILfRmq1xbdS ExYA== X-Gm-Message-State: ALoCoQl1MTJTuXD3z+7tZlwGyWDYkvoDnfuD8NGnRQzFzqgf0FYQE4qxp0mM4fWbHUbYu3jLHLFz X-Received: by 10.194.174.106 with SMTP id br10mr73167244wjc.21.1427796970198; Tue, 31 Mar 2015 03:16:10 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:2c8e:eb89:58c4:d450? ([2001:660:330f:a4:2c8e:eb89:58c4:d450]) by mx.google.com with ESMTPSA id gy9sm10312893wib.12.2015.03.31.03.16.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 03:16:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFFB60A1-1EA8-4EE3-B733-D32741B146D9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Luigi Iannone In-Reply-To: Date: Tue, 31 Mar 2015 12:16:09 +0200 Message-Id: <970C4554-20F8-4636-8143-B02B2EE81409@gigix.net> References: To: LISP mailing list list X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:16:14 -0000 --Apple-Mail=_BFFB60A1-1EA8-4EE3-B733-D32741B146D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, the WG LC period for the impact document is now come to and end.=20 While there was clear consensus in the room during the last meeting, the = latest reviews from=20 Ross and Ron raise reasonable points to be clarified before going = further. Hence, the authors will work with Ross and Ron to make a fair = description of=20 LISP=E2=80=99s impact, and clarifying the assumptions used by the cited = research work. ciao Luigi=20 > On 09 Mar 2015, at 15:22, Luigi Iannone wrote: >=20 > Hi All, >=20 > the authors of the LISP Impact document = [https://tools.ietf.org/html/draft-ietf-lisp-impact-01 = ] requested the = Work Group Last Call. >=20 > This email starts a WG Last Call, to end March 30th, 2015. > Because usually the pre-meeting period is already overloaded, the LC = duration is set to three weeks. >=20 > Please review this updated WG document and let the WG know if you = agree that it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > Any raised issue will be discussed during the WG meeting in Dallas. >=20 > Thanks >=20 > Luigi & Joel >=20 --Apple-Mail=_BFFB60A1-1EA8-4EE3-B733-D32741B146D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

the= WG LC period for the impact document is now come to and = end. 
While there was clear consensus in the = room during the last meeting, the latest reviews from 
Ross and Ron raise reasonable points to be clarified before = going further.

Hence, the authors will work with Ross and Ron to make a fair = description of 
LISP=E2=80=99s impact, and = clarifying the assumptions used by the cited research work.

ciao

Luigi 

On 09 Mar 2015, at 15:22, Luigi Iannone <ggx@gigix.net> = wrote:

Hi All,

the authors of the LISP = Impact document  [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] = requested the Work Group Last Call.

This email starts a WG Last Call, to end March 30th, = 2015.
Because usually the = pre-meeting period is already overloaded, the LC duration is set to = three weeks.

Please review this updated WG document and let the WG know if = you agree that it is ready for handing to the AD.
If you have objections, please state your reasons why, and = explain what it would take to address your concerns.

Any raised issue will be discussed during the WG meeting in = Dallas.

Thanks

Luigi & Joel


= --Apple-Mail=_BFFB60A1-1EA8-4EE3-B733-D32741B146D9-- From nobody Tue Mar 31 03:24:52 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5169F1A8A9C for ; Tue, 31 Mar 2015 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UCX8pwAyDQ8 for ; Tue, 31 Mar 2015 03:24:49 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3908E1A8A97 for ; Tue, 31 Mar 2015 03:24:49 -0700 (PDT) Received: by wgoe14 with SMTP id e14so13558470wgo.0 for ; Tue, 31 Mar 2015 03:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=NITVJnKQ5rf40SXNgxkFDgZ5GHUbeD3sn0PDvmxs/Zc=; b=aEi+ZY/l6nIhHKtuWYQ8Dd7IzXZiZbv+Qd5Ub2b9gGpgBufkDccJas61/UAPV15Ydv ySEKodxZ9E1EYD4av/8f//WWYHsInRC2kLc9xG8xqrlgHz5uAEdInKMDd1Lj1yKzh6iK 48fMJB+NPbywpGlcIb21cfoorxpGX74BuBxH7h4Yhdpz//GmE6DPU9iK/EntuFgiweLn dnC827V9npZe2YljQWIXAbqIAxGfr52yecRXfEt4WykSH7nRR6kr/qQMOX7LS9ciYIBa 29RXiZPGgR1XHOmtXXjUnSohOAli2xFeVNADv/5I5nC777+FU2m7WD7naQhVIxNzIgBP sudg== X-Gm-Message-State: ALoCoQkV2sJHybuErz+q9jon7CSpZXwn/KYknUsC4BgJRBjMhu3nDaMMjJPnuK5/VtQap9T8RAhU X-Received: by 10.194.61.12 with SMTP id l12mr71992935wjr.139.1427797487711; Tue, 31 Mar 2015 03:24:47 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:2c8e:eb89:58c4:d450? ([2001:660:330f:a4:2c8e:eb89:58c4:d450]) by mx.google.com with ESMTPSA id j7sm19653111wix.4.2015.03.31.03.24.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 03:24:46 -0700 (PDT) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_58A02503-6005-481C-880F-AAF7BA2BC8A5" Date: Tue, 31 Mar 2015 12:24:46 +0200 Message-Id: <84BEB8D1-06A4-4925-AA20-0C0220B0C4B2@gigix.net> To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [lisp] WG LC draft-ietf-lisp-threats-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:24:51 -0000 --Apple-Mail=_58A02503-6005-481C-880F-AAF7BA2BC8A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, During 92nd IETF LISP WG meeting the authors of the LISP Threats = document [http://www.ietf.org/id/draft-ietf-lisp-threats-12.txt = ] requested the = Work Group Last Call. There was rough consensus in the room for last call, hence, to confirm = such outcome,=20 this email starts the two weeks WG Last Call, to end April 14th, 2015. Please review this updated WG document and let the WG know if you agree = that it is ready for handing to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. Thanks Luigi & Joel= --Apple-Mail=_58A02503-6005-481C-880F-AAF7BA2BC8A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

During 92nd IETF  LISP WG meeting the authors of = the LISP Threats document
[http://www.ietf.org/id/draft-ietf-lisp-threats-12.txt] = requested the Work Group Last Call.

There was rough consensus in the room = for last call, hence, to confirm such outcome, 
this email starts the two weeks WG Last Call, to end April = 14th, 2015.

Please review this updated WG document and let the WG = know if you agree that it is ready for handing to the AD.
If= you have objections, please state your reasons why, and explain what it = would take to address your concerns.

Thanks

Luigi & = Joel
= --Apple-Mail=_58A02503-6005-481C-880F-AAF7BA2BC8A5-- From nobody Tue Mar 31 10:49:04 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925731A7003 for ; Tue, 31 Mar 2015 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWLv2qHZA40j for ; Tue, 31 Mar 2015 10:48:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2441A6FF7 for ; Tue, 31 Mar 2015 10:48:50 -0700 (PDT) Received: from BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 31 Mar 2015 17:48:45 +0000 Received: from BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) by BLUPR05MB433.namprd05.prod.outlook.com ([169.254.6.195]) with mapi id 15.01.0125.002; Tue, 31 Mar 2015 17:48:45 +0000 From: Ronald Bonica To: Damien Saucez Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-01 Thread-Index: AQHQWnSPtp3FrZs9xUaprzBtSdSj9p00VbOAgAAJRQCAAAPNAIAAAXiAgADc9UCAAInEAIABMXWA Date: Tue, 31 Mar 2015 17:48:44 +0000 Message-ID: References: <5518A89C.3090108@joelhalpern.com> <5518AD07.9090200@joelhalpern.com> <580EAA3E-7B39-430B-A23B-001F0E8E597B@gmail.com> In-Reply-To: <580EAA3E-7B39-430B-A23B-001F0E8E597B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(53754006)(76104003)(13464003)(479174004)(377454003)(33656002)(106116001)(2950100001)(19580395003)(2656002)(40100003)(15975445007)(102836002)(76176999)(561944003)(122556002)(54356999)(2900100001)(77156002)(230783001)(62966003)(92566002)(99286002)(86362001)(46102003)(93886004)(74316001)(76576001)(87936001)(50986999)(19580405001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:BLUPR05MB433.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB436; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB436; x-forefront-prvs: 0532BF6DC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 17:48:44.8840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: LISP mailing list list , "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:49:02 -0000 Damien, In his email below, Joel asks: > >>if we modified the section to say that we do not know > >> what the impact on cache size and control overhead will be, as the > >> studies that have been made have been disputed as to their relevance > >> to the core Internet case, would the document still meet the IESG > >> requirements for evaluating the impact I support Joel's request, so long as the disclaimer is complete. If cache s= ize and control overhead have impact, they must have impact upon something.= Do we know what they will impact? If so, tell us. If not, tell us that. = Ron > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@gmail.com] > Sent: Monday, March 30, 2015 7:19 PM > To: Ronald Bonica > Cc: Joel Halpern; Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS); LISP > mailing list list > Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 >=20 > Ron, >=20 > As one of the authors I can say I am not frustrated :-) >=20 > We are looking on how to address in the best way the comments of this > thread. >=20 > Just that it is unrealistic to hope a new full study on the cache size fr= om > research partners as such a study takes a lot of time and resources (to > produce the experimentation, then to get reviewed in a conference or > journal and finally get published) and would not change any conclusion wi= th > regards to the analytical studies reference in the draft already and that= draw > general conclusions. >=20 > The best solution could be to ask your customers to provide me the > necessary information so that I could evaluate the impact of LISP for the= ir > needs. Without that, I am afraid that the only thing that we can reasonab= ly > provide is theoretical/analytical studies. >=20 > The disclaimer you propose to add is just incorrect. It is not true that = we > don't know the impact of cache size. Actually, in the draft, we already > reference the analytical study [CCD12] that demonstrates analytically tha= t it is > possible to link cache size, traffic pattern, and miss rate. >=20 > Here is the paragraph present in the draft: >=20 > [CCD12] generalizes the caching discussion and proposes an analytic > model for the EID-to-RLOC cache size when prefix-level traffic has a > stationary generating process. The model shows that miss rate can be > accurately predicted from the EID-to-RLOC cache size and a small set > of easily measurable traffic parameters, meaning that operators can > provision the EID-to-RLOC cache of their ITRs according to the miss > rate they want to achieve for their given traffic. >=20 > That is clear enough for me and unless someone can prove the model wrong > I am perfectly fine with this observation that is supported by empirical = data. >=20 > Cheers, >=20 > Damien Saucez >=20 > On 30 Mar 2015, at 17:17, Ronald Bonica wrote: >=20 > > Brian, Deborah, > > > > I realize that the authors are frustrated. Maybe we can run with Joel's > proposal if we make the disclaimer complete. > > > > Shouldn't the disclaimer read something like, "We do not know the impac= t > of cache size and control overhead on {x, y, z}", where x, y and z might = be: > > > > - LISP scaling > > - LISP security > > - LISP resiliency > > - other ??? > > > > Given that, might we draw some conclusions regarding LISP's applicabili= ty? > > > > Ron > > > >> -----Original Message----- > >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. > >> Halpern > >> Sent: Sunday, March 29, 2015 9:55 PM > >> To: Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS) > >> Cc: LISP mailing list list > >> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 > >> > >> Brian, Deborah, if we modified the section to say that we do not know > >> what the impact on cache size and control overhead will be, as the > >> studies that have been made have been disputed as to their relevance > >> to the core Internet case, would the document still meet the IESG > >> requirements for evaluating the impact. I don't want to ask the > >> authors if they can live with a certain change if that change will > >> cause other necessary reviewers to complain. > >> > >> I do not see it as sensible to hold up the publication of this and > >> the other LISP work while researchers go off to see if they can calcul= ate > better results. > >> Particularly not when publishing this document is required to do other > work. > >> > >> Yours, > >> Joel > >> > >> On 3/29/15 9:50 PM, Ross Callon wrote: > >>> I suppose that there are two options: > >>> > >>> 1. Admit that we have no clue what the cache size or control > >>> overhead will be. > >>> > >>> 2. Repeat the cited studies, but with a pessimistic (worse case) > >>> rather than optimistic (better than best case) assumption about > >>> cache granularity. > >>> > >>> The second option would allow us to actually have some idea what > >>> would happen if LISP were deployed on an Internet-wide scale, but > >>> would of course take more time and more work. > >>> > >>> Ross > >>> > >>> PS: I will be offline at meetings all of this week, so I might be a > >>> bit slower to respond for the next few days. > >>> > >>> -----Original Message----- From: Joel M. Halpern > >>> [mailto:jmh@joelhalpern.com] Sent: Sunday, March 29, 2015 9:36 PM > To: > >>> Ross Callon; Luigi Iannone; LISP mailing list list Cc: > >>> draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last > >>> Call > >>> draft-ietf-lisp-impact-01 > >>> > >>> Putting aside the TBD (which of course needs to be fixed), I have > >>> trouble figuring out what you want us to say about the main issue in > >>> your review. On the one hand, this is the very issue that we have > >>> been asked to comment on, and on the other hand you say that we > >>> don't know. What do you think it is reasoanble to say? > >>> > >>> Yours, Joel > >>> > >>> On 3/29/15 9:03 PM, Ross Callon wrote: > >>>> Generally I think that this document needs more work before it will > >>>> be ready to submit for publication. Some comments on > >>>> draft-ietf-lisp-impact-01: > >>>> > >>>> First of all, I assume that the TBD at the end of section 3 will be > >>>> fixed. This reads: > >>>> > >>>> TBD: add a paragraph to explain the operational difference while > >>>> > >>>> dealing with a pull model instead of a push. > >>>> > >>>> Also in section 3, the third paragraph begins: > >>>> > >>>> In addition, Iannone and Bonaventure [IB07] show that the number of > >>>> > >>>> mapping entries that must be handled by an ITR of a campus network > >>>> > >>>> with 10,000 users is limited to few tens of thousands, and does not > >>>> > >>>> represent more than 3 to 4 Megabytes of memory. > >>>> > >>>> Reference [IB07] is of course: > >>>> > >>>> Iannone, L. and O. Bonaventure, "On the cost of caching locator/id > >>>> mappings", In > >>>> > >>>> Proc. ACM CoNEXT 2007, December 2007. > >>>> > >>>> This paper states: > >>>> > >>>> In our analysis, we assume that the granularity of the > >>>> > >>>> EID-to-RLOC mapping is the prefix blocks assigned by > >>>> > >>>> RIRs. We call it /BGP granularity. In particular, we > >>>> > >>>> used the list of prefixes made available by the iPlane > >>>> > >>>> Project [15], containing around 240,000 entries. Using > >>>> > >>>> /BGP granularity means that each EID is first mapped > >>>> > >>>> on a /BGP prefix. The cache will thus contain /BGP > >>>> > >>>> to RLOC mappings.2 This is a natural choice, since > >>>> > >>>> routing locators are supposed to be border routers. > >>>> > >>>> The authors should be aware that there is some aggregation / > >>>> summarization being done in the operation of BGP routing, and that > >>>> the granularity of routes which appear in the default-free BGP > >>>> routing tables is fundamentally different from the granularity of > >>>> enterprise network / ISP boundaries across which traffic is > >>>> exchanged. > >>>> > >>>> The same paragraph cites Kim et al. [KIF11], which is Kim, J., > >>>> Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and > >>>> what isps should know about it", In Proc. IFIP Networking 2011, May > 2011. > >>>> From this document: > >>>> > >>>> In addition, we use a local BGP prefixes > >>>> > >>>> database, fed with the list of BGP prefixes published by the iPlane > >>>> Project [17]. > >>>> > >>>> The database is used to group EID-to-RLOCs mappings with the > >>>> granularity of > >>>> > >>>> existing BGP prefixes, because, as for today, there is no > >>>> sufficient information > >>>> > >>>> to predict what will be the granularity of mappings in a > >>>> LISP-enabled Internet. > >>>> > >>>> I agree that "there is not sufficient information to predict what > >>>> will be the granularity of mappings in a LISP-enabled Internet". > >>>> However, not knowing what the mapping granularity will be does not > >>>> justify using an extremely optimistic guess, and then acting as if > >>>> the results are meaningful. These assumptions are clearly off by > >>>> some number of orders of magnitude, but how many orders of > >>>> magnitude is unknown. We will note that the current internet > >>>> default-free routing table includes a few hundred thousand entries > >>>> (roughly twice the > >>>> 240,000 entries that existed when this study was done). > >>>> > >>>> For example, we might assume that the intended global deployment > >>>> model involves xTRs at the boundary between enterprise networks > and > >>>> service providers, and might note that there are several million > >>>> companies in the USA alone (most of these are relatively small > >>>> companies, of course). Thus there may be very roughly on the order > >>>> of a hundred million or so companies worldwide. If each one had a > >>>> separate entry in the mapping table, then the number of entries > >>>> will be nearly 1,000 times larger than BGP-prefix granularity. > >>>> > >>>> Section 4 mentions as one possible use of LISP: "enable mobility of > >>>> subscriber end points". If individual end points are advertised > >>>> into LISP, then the granularity of the mapping table may be on the > >>>> order of individual systems. In this case the number of mapping > >>>> table entries that could exist globally might be on the same order > >>>> of magnitude as the number of people in the world, or very roughly > >>>> 7 Billion entries. This would suggest that the mapping table might > >>>> be roughly 30,000 times finer grained than was assumed in the > >>>> referenced studies. > >>>> > >>>> I don't see how we can accurately predict the control plane load of > >>>> LISP without some sense for what the granularity of the mapping > >>>> table will be. It should however be possible to bound the control > >>>> plane load. The referenced studies give a lower bound on possible > >>>> control plane load (it won't be any less), but give neither an > >>>> accurate measurement nor an upper bound on the potential control > >>>> plane load. I don't think that the document can claim to explain > >>>> the impact of LISP without there being an attempt to measure an > >>>> upper bound on the control plane load. > >>>> > >>>> Finally, perhaps I missed it but I didn't see any discussion of the > >>>> volume of overhead related to OAM traffic used for liveness > >>>> detection (the need for ITR's to determine the reachability of ETR's= ). > >>>> > >>>> Thanks, Ross > >>>> > >>>> *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi > >>>> Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP mailing > >>>> list list *Cc:* draft-ietf-lisp-impact@tools.ietf.org *Subject:* > >>>> [lisp] WG Last Call draft-ietf-lisp-impact-01 > >>>> > >>>> Hi All, > >>>> > >>>> the authors of the LISP Impact document > >>>> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested > >>>> the Work Group Last Call. > >>>> > >>>> This email starts a WG Last Call, to end March 30th, 2015. > >>>> > >>>> Because usually the pre-meeting period is already overloaded, the > >>>> LC duration is set to three weeks. > >>>> > >>>> Please review this updated WG document and let the WG know if you > >>>> agree that it is ready for handing to the AD. > >>>> > >>>> If you have objections, please state your reasons why, and explain > >>>> what it would take to address your concerns. > >>>> > >>>> Any raised issue will be discussed during the WG meeting in Dallas. > >>>> > >>>> Thanks > >>>> > >>>> > >>>> Luigi & Joel > >>>> > >>>> > >>>> > >>>> _______________________________________________ lisp > mailing > >> list > >>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>> > >> > >> _______________________________________________ > >> lisp mailing list > >> lisp@ietf.org > >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Mar 31 20:58:48 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A411A7023 for ; Tue, 31 Mar 2015 20:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZBYTCQJskey for ; Tue, 31 Mar 2015 20:58:45 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467A71A702A for ; Tue, 31 Mar 2015 20:58:43 -0700 (PDT) Received: by padcy3 with SMTP id cy3so39481924pad.3 for ; Tue, 31 Mar 2015 20:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=zTzn5r4icwaY44k5x53e684XkP6LjIHWfs4iULTbHYg=; b=a2e6INlfzXoEsElvLiVIDb7Uc0kFb6iWsuxieDAxdB3jfgKXenv3qkBDYuJz18enls mfSAbE3dMxPh0WawfjrUesXGsCLQMHwjwf0nILsUrpPE2XCbEhvk0VJJ1RhHVYCWeVCb 8gzfJnJ1xPQnOuKArbUeKffHkjtDyDXmf42GSOreh2xV9e1Z6s/QoKI7WxGv2DUabZ2o zc0olSH9nC4rBxANfd5qYv6hCztic6olAD63qaym+PgMDN8ncnpYQkW1bfNsD7Px24v+ iJaFWlGH0Mnxzyo+Alpf9XzjPLOvypB/4NR6rMPpjhlCiGzMHfMO0fVwV/pl6pMe/2kY DbyA== X-Received: by 10.69.0.163 with SMTP id az3mr72807659pbd.21.1427860722963; Tue, 31 Mar 2015 20:58:42 -0700 (PDT) Received: from ?IPv6:2601:9:8380:447:8940:ec7c:e65e:6cf8? ([2601:9:8380:447:8940:ec7c:e65e:6cf8]) by mx.google.com with ESMTPSA id jc9sm438779pbd.54.2015.03.31.20.58.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 20:58:41 -0700 (PDT) From: Sharon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 31 Mar 2015 20:58:38 -0700 Message-Id: <2DB9153F-698C-4228-A01B-34EBB4112664@gmail.com> To: LISP mailing list list X-Mailer: iPhone Mail (12D508) Archived-At: Subject: [lisp] Lisp to Nvo3 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 03:58:47 -0000 In the short re-charter discussion there was a proposal to offer lisp archit= ecture (with multi encapsulations option) as one of the possible control pla= nes for nvo3. There was a comment regarding inter-networking with legacy vpn. We recently faced such a requirement for service provider-anchored VPN overl= ays.=20 These VPN overlays are implemented such that the "real" XTRs are in the prov= ider regional data centers, while "satellite" XTRs at customer premise use t= hem as anchors and do not use the mapping directly. Much like Vina's NAT traversal draft.=20 This makes it easier to cluster virtual network functions next to the "real"= XTRs, same rack, and share their capacity across XTRs over the high speed c= ore underlay. The point is that the inter-networking - into and out of the VPN Overlay - i= s handled, much like any other "extra" functionality over basic lisp. It is h= andled the NFV way.=20 This means that the complexity of external BGP talkers to other VPNs or to t= he Internet routers is locked inside the VNFs, and the capacity of these VNFs= is shared across the VPN held by the XTRs using the mapping service as glob= al locator. Similar to the multicast replication function proposal, or similar to how fi= rewall functions are chained, using SFC. Is there interest in such a draft? There should probably be a common part ap= plicable to any function, eg the Schema for instances, scoping of each, affi= nity for the return path, and locations (as in RLOCs), in the mapping.=20 Then specifically for the inter VPN VNF what is the lisp FlowMapping behavio= r in each of the XTRs to accommodate. Alternately we can also take it a func= tion at a time. --szb= From nobody Tue Mar 31 22:57:50 2015 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367AC1A88DE for ; Tue, 31 Mar 2015 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y52It3y_zRSV for ; Tue, 31 Mar 2015 22:57:47 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833451A1ADC for ; Tue, 31 Mar 2015 22:57:47 -0700 (PDT) Received: by pddn5 with SMTP id n5so44262802pdd.2 for ; Tue, 31 Mar 2015 22:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NRYvdI/AqvefBNDFnX+VzSwIlWTVeHEbFSePgt9wM9E=; b=c1Mvy7VLNrgRIOXXDHI1Dx4N8Fcaiat135aTD0Cev3Z2nNA5zgHt/f4mBtTCR3DeLo BWYgTZPthfYWs0zkexhtspgmFZn9Wdq4PFYGpyjn1soED62sclPIOVwzkAQ8IqduxqDM HdBtHnsamfr/H7amGw4Dhwgojq3MwENc/y0bQefE+7pnFBwHKbxdsPluR4RQkwin9aMF s1Gx5Dh0rRJ8+VsX9fVSYBnfLTWba7JHNrMq6uF5nU/wOdDfUAeRRGBj272Jjgz3YN9W ZRk9aPEpEeNeuFEm9sHUYkGoEZ7ObhruYRI2JsI8vCIdLXE6Ypql3kEsXoNlBuIXH8f0 iN6A== X-Received: by 10.66.100.138 with SMTP id ey10mr73831022pab.142.1427867867222; Tue, 31 Mar 2015 22:57:47 -0700 (PDT) Received: from [192.168.1.86] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id sw4sm776947pbc.64.2015.03.31.22.57.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 22:57:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12D508) In-Reply-To: <2DB9153F-698C-4228-A01B-34EBB4112664@gmail.com> Date: Tue, 31 Mar 2015 22:57:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <800A8189-4788-4C12-BA9F-434486A3D3AA@gmail.com> References: <2DB9153F-698C-4228-A01B-34EBB4112664@gmail.com> To: Sharon Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Lisp to Nvo3 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:57:49 -0000 We should definitely have a multi-tenancy NFV use-case draft. We know the ar= chitecture can support it.=20 Dino > On Mar 31, 2015, at 8:58 PM, Sharon wrote: >=20 >=20 > In the short re-charter discussion there was a proposal to offer lisp arch= itecture (with multi encapsulations option) as one of the possible control p= lanes for nvo3. >=20 > There was a comment regarding inter-networking with legacy vpn. > We recently faced such a requirement for service provider-anchored VPN ove= rlays.=20 > These VPN overlays are implemented such that the "real" XTRs are in the pr= ovider regional data centers, while "satellite" XTRs at customer premise use= them as anchors and do not use the mapping directly. >=20 > Much like Vina's NAT traversal draft.=20 >=20 > This makes it easier to cluster virtual network functions next to the "rea= l" XTRs, same rack, and share their capacity across XTRs over the high speed= core underlay. >=20 > The point is that the inter-networking - into and out of the VPN Overlay -= is handled, much like any other "extra" functionality over basic lisp. It i= s handled the NFV way.=20 > This means that the complexity of external BGP talkers to other VPNs or to= the Internet routers is locked inside the VNFs, and the capacity of these V= NFs is shared across the VPN held by the XTRs using the mapping service as g= lobal locator. > Similar to the multicast replication function proposal, or similar to how f= irewall functions are chained, using SFC. >=20 > Is there interest in such a draft? There should probably be a common part a= pplicable to any function, eg the Schema for instances, scoping of each, aff= inity for the return path, and locations (as in RLOCs), in the mapping.=20 > Then specifically for the inter VPN VNF what is the lisp FlowMapping behav= ior in each of the XTRs to accommodate. Alternately we can also take it a fu= nction at a time. >=20 > --szb > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp